RFC3198 日本語訳
3198 Terminology for Policy-Based Management. A. Westerinen, J.Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format: TXT=47806 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Westerinen
Request for Comments: 3198 J. Schnizlein
Category: Informational Cisco Systems
J. Strassner
Intelliden Corporation
M. Scherling
xCert
B. Quinn
Celox Networks
S. Herzog
PolicyConsulting
A. Huynh
Lucent Technologies
M. Carlson
Sun Microsystems
J. Perry
Network Appliance
S. Waldbusser
November 2001
Westerinenがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3198年のJ.Schnizleinカテゴリ: 情報のシスコシステムズの社のM.Scherling xCert B.クインJ.Strassner Intelliden Celoxはサン・マイクロシステムズJ.ペリーネットアプライアンスS.Waldbusser2001年11月にS.Herzog PolicyConsulting A.HuynhルーセントテクノロジーズのM.カールソンをネットワークでつなぎます。
Terminology for Policy-Based Management
方針を拠点とする管理のための用語
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).
このドキュメントは方針関連の用語の用語集です。それはこれらの用語の使用のための略語、説明、および推薦を提供します。ドキュメントはRFC2828のアプローチと形式を取ります。(RFCはインターネットSecurity Glossaryを定義します)。 意図が分かり易さを改良することであり、それを書く一貫性はネットワーク方針特にインターネットStandardsドキュメント(ISDs)に対処します。
Westerinen, et al. Informational [Page 1] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[1ページ]のRFC3198用語
Table of Contents
目次
1. Introduction................................................... 2 2. Explanation of Paragraph Markings.............................. 3 3. Terms.......................................................... 3 4. Intellectual Property.......................................... 16 5. Acknowledgements............................................... 17 6. Security Considerations........................................ 17 7. References..................................................... 17 8. Authors' Addresses............................................. 19 9. Full Copyright Statement....................................... 21
1. 序論… 2 2. パラグラフ印に関する説明… 3 3. 用語… 3 4. 知的所有権… 16 5. 承認… 17 6. セキュリティ問題… 17 7. 参照… 17 8. 作者のアドレス… 19 9. 完全な著作権宣言文… 21
1. Introduction
1. 序論
This document provides abbreviations, definitions, and explanations of terms related to network policy. All definitions are provided in Section 3, with the terms listed in alphabetical order.
このドキュメントはネットワーク方針に関連する用語に関する略語、定義、および説明を提供します。 用語がアルファベット順にリストアップされている状態で、すべての定義をセクション3に提供します。
The intent is to improve the comprehensibility and consistency of Internet Standards documents (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as part of the Internet Standards Process [RFC2026]. Benefits across the ISDs are well-stated in the Introduction to RFC 2828 [RFC2828]:
意図はインターネットStandardsドキュメント(ISDs)の分かり易さと一貫性を改良することです--すなわち、RFCs、インターネット草稿、およびインターネットStandards Processの一部として作り出された他の材料[RFC2026]。 ISDsの向こう側の利益はIntroductionにRFC2828[RFC2828]によく述べられています:
o "Clear, Concise, and Easily Understood Documentation" - Requires
that the set of terms and definitions be consistent, self-
supporting and uniform across all ISDs.
o 「明確である、Concise、およびEasily Understood Documentation、」 --用語と定義のセットがすべてのISDsの向こう側の一貫した自己サポートとユニフォームであることが必要です。
o Technical Excellence - Where all ISDs use terminology accurately,
precisely, and unambiguously.
o 技術的なExcellence--すべてのISDsが正確に、正確に、明白に用語を使用するところ。
o Prior Implementation and Testing - Requires that terms are used in
their plainest form, that private and "made-up" terms are avoided
in ISDs, and that new definitions are not created that conflict
with established ones.
o 先のImplementationとTesting--用語がそれらの最も明瞭なフォームで使用されて、個人的で「作り上げている」用語がISDsで避けられて、新しい定義が作成されないで、それが確立したものと衝突するということであることが必要です。
o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms that
are proprietary or otherwise favor a particular vendor, or that
create a bias toward a particular technology or mechanism.
o ISDsが独占である用語を避けるか、または別の方法で特定のベンダー、またはそれを支持するところの「風通しの良さ、Fairness、およびTimeliness」は特定の技術かメカニズムに向かって偏見を作成します。
Common and/or controversial policy terms are defined. These terms are directly related and specific to network policy.
一般的な、そして/または、論議を呼んだ方針用語は定義されます。 これらの用語は、ネットワーク方針に直接関連していて特定です。
Wherever possible, this document takes definitions from existing ISDs. It should be noted that:
どこでも、可能であるところでは、このドキュメントが既存のISDsから定義を取ります。 以下のことに注意されるべきです。
o Expired Internet-Drafts are not referenced, nor are their
terminology and definitions used in this document.
o 満期のインターネット草稿は参照をつけられません、そして、彼らの用語と定義は本書では使用されません。
Westerinen, et al. Informational [Page 2] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[2ページ]のRFC3198用語
o Multiple definitions may exist across the ISDs. Each definition
is listed, with its source.
o 複数の定義がISDsの向こう側に存在するかもしれません。 各定義はソースと共に記載されています。
2. Explanation of Paragraph Markings
2. パラグラフ印に関する説明
Section 3 marks terms and definitions as follows:
セクション3は、用語と定義は以下の通りであるとマークします:
o Capitalization: Only terms that are proper nouns are capitalized.
o 資源化: 固有名詞である唯一の用語は大文字で書かれます。
o Paragraph Marking: Definitions and explanations are stated in
paragraphs that are marked as follows:
o パラグラフマーク: 定義と説明は以下の通りであるとマークされるパラグラフで述べられています:
- "P" identifies basic policy-related terms.
- 「P」は基本の方針関連の用語を特定します。
- "T" identifies various techniques to create or convey policy-
related information in a network. For example, COPS and an
"Information Model" are two techniques for communicating and
describing policy-related data. SNMP and MIBs are another.
- 「T」は、ネットワークで方針関連情報を作成するか、または伝えるために様々なテクニックを特定します。 例えば、COPSと「情報モデル」は、方針関連のデータについて伝えて、説明するための2つのテクニックです。 SNMPとMIBsは別です。
- "A" identifies specific Work Groups and general "areas of use"
of policy. For example, AAA and QoS are two "areas of use"
where policy concepts are extremely important to their function
and operation.
- 「A」は方針について特定のWork Groupsと一般的な「使用の領域」を特定します。 例えば、AAAとQoSは2歳です。方針概念が彼らの機能と操作に非常に重要である「使用の領域。」
3. Terms
3. 用語
Note: In providing policy definitions, other "technology specific" terms (for example, related to Differentiated Services) may be used and referenced. These non-policy terms will not be defined in this document, and the reader is requested to go to the referenced ISD for additional detail.
以下に注意してください。 方針定義、他の「技術特有」の用語を提供する、(例えば、関連される、Differentiated Services) 中古で参照をつけられるかもしれなくなってください。 これらの無政策用語は本書では定義されないでしょう、そして、読者が追加詳細に参照をつけられたISDに行くよう要求されています。
$ AAA
See "Authentication, Authorization, Accounting".
$AAAは「認証、承認、会計」を見ます。
$ abstraction levels
See "policy abstraction".
$抽象度See「方針抽象化。」
$ action
See "policy action".
$動作See「政策的措置。」
$ Authentication, Authorization, Accounting (AAA)
(A) AAA deals with control, authentication, authorization and
accounting of systems and environments based on policies set
by the administrators and users of the systems. The use of
policy may be implicit - as defined by RADIUS [RFC2138]. In
RADIUS, a network access server sends dial-user credentials to
an AAA server, and receives authentication that the user is
$認証、Authorization、Accounting(AAA)(A)AAAはシステムのコントロール、認証、承認、および会計に対処します、そして、方針に基づく環境はシステムの管理者とユーザでセットします。RADIUS[RFC2138]によって定義されるように方針の使用は暗黙であるかもしれません。 RADIUSでは、ネットワークアクセス・サーバーは、AAAサーバへのダイヤルユーザ資格証明書を送って、ユーザがそうである認証を受けます。
Westerinen, et al. Informational [Page 3] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[3ページ]のRFC3198用語
who he/she claims, along with a set of attribute-value pairs
authorizing various service features. Policy is implied in
both the authentication, which can be restricted by time of
day, number of sessions, calling number, etc., and the
attribute-values authorized.
その人は様々なサービス機能を認可する1セットの属性値組と共にだれを要求しますか? 方針は時刻、セッションの数、数と呼ぶことなどによって制限される場合がある認証と属性値が認可した両方で含意されます。
$ CIM
See "Common Information Model".
$CIMは「一般的な情報モデル」を見ます。
$ Common Information Model (CIM)
(T) An object-oriented information model published by the DMTF
(Distributed Management Task Force) [DMTF]. It consists of a
Specification detailing the abstract modeling constructs and
principles of the Information Model, and a textual language
definition to represent the Model. CIM's schemas are defined
as a set of files, written in the language of the
Specification, with graphical renderings using UML [UML].
Sets of classes and associations represent CIM's Core and
Common Models, defining an information model for the
"enterprise" - addressing general concepts (in Core), and
systems, devices, users, software distribution, the physical
environment, networks and policy (in the Common Models). (See
also "information model".)
DMTF(分配されたManagement Task Force)[DMTF]でオブジェクト指向情報モデルが発行した$の一般的な情報Model(CIM。)(T) それはModelを表すために抽象的なモデル構造物、情報Modelの本質、およびテキスト形式言語定義について詳述するSpecificationから成ります。 グラフィカルなレンダリングがUML[UML]を使用している状態で、CIMのschemasはSpecificationの言葉を借りて言えば書かれた1セットのファイルと定義されます。 クラスと協会のセットはCIMのCoreとCommon Modelsを表します、一般概念(Coreの)、システム、デバイス、ユーザ、ソフトウェア配布、物理的環境、ネットワーク、および方針(Common Modelsの)に演説して、「企業」の情報モデルを定義して。 (また、「情報モデル」を見てください。)
$ Common Open Policy Service (COPS)
(T) A simple query and response TCP-based protocol that can be
used to exchange policy information between a Policy Decision
Point (PDP) and its clients (Policy Enforcement Points, PEPs)
[RFC2748]. The COPS protocol is used to provide for the
outsourcing of policy decisions for RSVP [RFC2749]. Another
usage is for the provisioning of policy [RFC3084]. (See also
"Policy Decision Point" and "Policy Enforcement Point".)
Policy Decision Point(PDP)とそのクライアント(方針Enforcement Points、PEPs)[RFC2748]の間の為替政策情報に使用できる$の一般的なオープンPolicy Service(COPS)の(T)のA簡単な質問と応答のTCPベースのプロトコル。 COPSプロトコルは、RSVP[RFC2749]のために政策決定のアウトソーシングに備えるのに使用されます。 別の用法は方針[RFC3084]の食糧を供給するものです。 (また、「政策決定ポイント」と「方針実施ポイント」を見てください。)
$ condition
See "policy condition".
「方針状態」という$状態See。
$ configuration
(P) "Configuration" can be defined from two perspectives:
- The set of parameters in network elements and other systems
that determine their function and operation. Some
parameters are static, such as packet queue assignment and
can be predefined and downloaded to a network element.
Others are more dynamic, such as the actions taken by a
network device upon the occurrence of some event. The
distinction between static (predefined) "configuration" and
the dynamic state of network elements blurs as setting
parameters becomes more responsive, and signaling controls
greater degrees of a network device's behavior.
2つの見解から$構成(P)「構成」を定義できます: - 彼らの機能と操作を決定するネットワーク要素と他のシステムのパラメタのセット。 いくつかのパラメタをネットワーク要素にパケット待ち行列課題などのように静的であり、事前に定義して、ダウンロードできます。 他のものは何らかのイベントの発生のときにネットワークデバイスによって取られた行動などのように、よりダイナミックです。 静的である(事前に定義される)「構成」とパラメタを設定するとしてのダイナミックなネットワークの状態要素ぼやけの区別は、より敏感になります、そして、シグナリングは、より大きい度合いのネットワークデバイスの振舞いを制御します。
Westerinen, et al. Informational [Page 4] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[4ページ]のRFC3198用語
- A static setup of a network element, done before shipment
to a customer and which cannot be modified by the customer.
The first is the accepted usage in the Internet community.
- 顧客によって顧客とどれがあることができないかに変更されないで、出荷の前に行われたネットワーク要素の静的なセットアップ。 1番目はインターネットコミュニティの一般に認められた語法です。
$ COPS
See "Common Open Policy Service".
$巡査は「一般的なオープンポリシーサービス」を見ます。
$ data model
(T) A mapping of the contents of an information model into a form
that is specific to a particular type of data store or
repository. A "data model" is basically the rendering of an
information model according to a specific set of mechanisms
for representing, organizing, storing and handling data. It
has three parts [DecSupp]:
- A collection of data structures such as lists, tables,
relations, etc.
- A collection of operations that can be applied to the
structures such as retrieval, update, summation, etc.
- A collection of integrity rules that define the legal
states (set of values) or changes of state (operations on
values).
(See also "information model".)
$データは特定のタイプのデータ・ストアか倉庫に特定のフォームに(T) 情報モデルのコンテンツに関するマッピングをモデル化します。 「データモデル」は基本的にデータを表して、組織化して、保存して、扱うための特定のセットのメカニズムに従った情報モデルのレンダリングです。 それには、3つの部品[DecSupp]があります: - リスト、テーブル、関係などのデータ構造の収集 - 検索、アップデート、足し算などの構造に適用できる操作の収集 - 法的な州を定義する保全規則の収集(値のセット)か状態の変化(値における操作)。 (また、「情報モデル」を見てください。)
$ DEN
See "Directory Enabled Networks".
$書斎は「ディレクトリの可能にされたネットワーク」を見ます。
$ Differentiated Services (DS)
(T) The IP header field, called the DS-field. In IPv4, it defines
the layout of the ToS (Type of Service) octet; in IPv6, it is
the Traffic Class octet [RFC2474].
(A) "Differentiated Services" is also an "area of use" for QoS
policies. It requires policy to define the correspondence
between codepoints in the packet's DS-field and individual
per-hop behaviors (to achieve a specified per-domain
behavior). In addition, policy can be used to specify the
routing of packets based on various classification criteria.
(See also "Quality of Service" and "filter".)
$はDS-分野と呼ばれる(T) IPヘッダーのServices(DS)分野を差別化しました。 IPv4では、ToS(Serviceのタイプ)八重奏のレイアウトを定義します。 IPv6では、それはTraffic Class八重奏[RFC2474]です。 (A) また、「差別化されたServices」はQoS方針のための「使用領域」です。 パケットのDS-分野と1ホップあたりの個々の振舞い(1ドメインあたり1つの指定された振舞いを達成する)でcodepointsの間の通信を定義するのが方針を必要とします。 さらに、様々な分類評価基準に基づくパケットのルーティングを指定するのに方針を使用できます。 (また、「サービスの質」と「フィルタ」を見てください。)
$ diffserv
See "Differentiated Services".
$diffserv Seeは「サービスを差別化しました」。
$ Directory Enabled Networks (DEN)
(T) A data model that is the LDAP mapping of CIM (the Common
Information Model). Its goals are to enable the deployment
and use of policy by starting with common service and user
concepts (defined in the information model), specifying their
$ディレクトリEnabled Networks(DEN)(T)Aデータはモデル化されます。それはCIM(Common情報Model)を写像するLDAPです。 目標は共益サービスとユーザ概念(情報モデルでは、定義される)から始まることによって方針の展開と使用を可能にすることです、指定している、それら
Westerinen, et al. Informational [Page 5] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[5ページ]のRFC3198用語
mapping/storage in an LDAP-based repository, and using these
concepts in vendor/device-independent policy rules [DMTF].
(See also "Common Information Model" and "data model".)
LDAPベースの倉庫でのマッピング/ストレージと、デバイスからベンダー/独立している政策ルール[DMTF]でこれらの概念を使用すること。 (参照、「一般的な情報モデル」と「データはモデル化します」。)
$ domain
(P) A collection of elements and services, administered in a
coordinated fashion. (See also "policy domain".)
連携ファッションで管理された要素の、そして、サービスの$ドメイン(P)A収集。 (また、「方針ドメイン」を見てください。)
$ DS
See "Differentiated Services".
$DSは「差別化されたサービス」を見ます。
$ filter
(T) A set of terms and/or criteria used for the purpose of
separating or categorizing. This is accomplished via single-
or multi-field matching of traffic header and/or payload data.
"Filters" are often manipulated and used in network operation
and policy. For example, packet filters specify the criteria
for matching a pattern (for example, IP or 802 criteria) to
distinguish separable classes of traffic.
1セットの用語、そして/または、評価基準が分離か分類の目的に使用した$フィルタ(T)。 これはトラフィックヘッダー、そして/または、ペイロードデータの単一の、または、マルチ分野のマッチングで達成されます。 「フィルタ」は、ネットワーク操作と方針でしばしば操られて、使用されます。 例えば、パケットフィルタは分離できるクラスのトラフィックを区別するために、パターン(例えば、IPか802の評価基準)を合わせる評価基準を指定します。
$ goal
See "policy goal".
$目標See「方針目標。」
$ information model
(T) An abstraction and representation of the entities in a managed
environment, their properties, attributes and operations, and
the way that they relate to each other. It is independent of
any specific repository, software usage, protocol, or
platform.
$情報は管理された環境と、彼らの特性と、属性と操作、およびそれらが互いに関連する方法で(T) 実体の抽象化と表現をモデル化します。 それはどんな特定の倉庫、ソフトウェア用法、プロトコル、またはプラットホームからも独立しています。
$ Management Information Base (MIB)
(T) A collection of information that can be accessed via the
Simple Network Management Protocol. Management information is
defined in MIB modules using the rules contained in SNMP's
Structure of Management Information (SMI) specifications
[RFC2570]. Management information is an abstract concept, and
definitions can be created for high level policy
specifications, low level policy, as well as technology and
vendor specific configurations, status and statistics. (See
also "Simple Network Management Protocol" and "Structure of
Management Information".)
Simple Network Managementプロトコルでアクセスできる情報の$管理Information基地(MIB)の(T)A収集。 経営情報は、MIBモジュールでSNMPのManagement情報(SMI)仕様[RFC2570]のStructureに含まれた規則を使用することで定義されます。 経営情報は抽象概念です、そして、高い平らな方針仕様のために定義は作成できます、低い平らな方針、技術、ベンダーの特定の構成、状態、および統計と同様に。 (また、「簡単なネットワーク管理プロトコル」と「経営情報の構造」を見てください。)
$ MIB
See "Management Information Base".
$MIBは「管理情報ベース」を見ます。
Westerinen, et al. Informational [Page 6] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[6ページ]のRFC3198用語
$ MPLS
See "Multiprotocol Label Switching". (Also, MPLS may refer to
Multi-Protocol Lambda Switching in optical networks. But, this is
unrelated to policy and not discussed further in this document.)
$MPLSは「Multiprotocolラベルの切り換え」を見ます。 (また、MPLSは光学ネットワークにおけるMulti-プロトコルLambda Switchingについて言及するかもしれません。 しかし、これは、本書では方針に関係なくさらに議論されていません。)
$ Multiprotocol Label Switching (MPLS)
(T) Integrates a label swapping and switching framework with
network layer routing [RFC2702]. The basic idea involves
assigning short fixed length labels to packets at the ingress
to an MPLS cloud. Throughout the interior of the MPLS domain,
the labels attached to packets are used to make forwarding
decisions (usually without recourse to the original packet
headers).
$Multiprotocol Label Switching(MPLS)(T)はネットワーク層ルーティング[RFC2702]とラベルスワッピングと切り換えフレームワークを統合します。 基本的な考え方は、イングレスで脆い固定長ラベルをパケットに割り当てることをMPLS雲に伴います。 MPLSドメインの内陸部中では、パケットに取り付けられたラベルは、推進を決定(通常、オリジナルのパケットのヘッダーへの償還請求のない)にするのに使用されます。
$ outsourced policy
(P) An execution model where a policy enforcement device issues a
query to delegate a decision for a specific policy event to
another component, external to it. For example, in RSVP, the
arrival of a new RSVP message to a PEP requires a fast policy
decision (not to delay the end-to-end setup). The PEP may use
COPS-RSVP to send a query to the PDP, asking for a policy
decision [RFC2205, RFC2748]. "Outsourced policy" is
contrasted with "provisioned policy", but they are not
mutually exclusive and operational systems may combine the
two.
方針実施デバイスが特定保険証券イベントのための決定を別のコンポーネントへ代表として派遣するために質問を発行するところで$は実行がモデル化する方針(P)を社外調達しました、それに、外部です。 例えば、RSVPでは、PEPへの新しいRSVPメッセージの到着は速い政策決定(終わりから終わりへのセットアップを遅らせない)を必要とします。 政策決定[RFC2205、RFC2748]を求めて、PEPは、質問をPDPに送るのにCOPS-RSVPを使用するかもしれません。 彼らは互いに排他的ではありません、そして、「社外調達された方針」は「食糧を供給された方針」に対して対照されますが、基幹系システムは2を結合するかもしれません。
$ PCIM
See "Policy Core Information Model".
$PCIMは「方針コア情報モデル」を見ます。
$ PDP
See "Policy Decision Point".
$PDPは「政策決定ポイント」を見ます。
$ PEP
See "Policy Enforcement Point".
$気力は「方針実施ポイント」を見ます。
$ PIB
See "Policy Information Base".
$PIBは「方針Information基地」を見ます。
$ policy
(P) "Policy" can be defined from two perspectives:
- A definite goal, course or method of action to guide and
determine present and future decisions. "Policies" are
implemented or executed within a particular context (such
as policies defined within a business unit).
- Policies as a set of rules to administer, manage, and
control access to network resources [RFC3060].
2つの見解から$方針(P)「方針」を定義できます: - 動作が現在の、そして、今後の決定を誘導して、決定するしっかりした目的、コースまたはメソッド。 「方針」は、特定の文脈(ビジネス部の中で定義された方針などの)の中で実装されるか、または実行されます。 - 管理して、管理して、制御する1セットの規則としての方針は[RFC3060]にネットワーク資源にアクセスします。
Westerinen, et al. Informational [Page 7] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[7ページ]のRFC3198用語
Note that these two views are not contradictory since
individual rules may be defined in support of business goals.
(See also "policy goal", "policy abstraction" and "policy
rule".)
独特の規則が企業目標を支持して定義されるかもしれないのでこれらの2つの視点が相容れなくないことに注意してください。 (また、「方針目標」、「方針抽象化」、および「政策ルール」を見てください。)
$ policy abstraction
(P) Policy can be represented at different levels, ranging from
business goals to device-specific configuration parameters.
Translation between different levels of "abstraction" may
require information other than policy, such as network and
host parameter configuration and capabilities. Various
documents and implementations may specify explicit levels of
abstraction. However, these do not necessarily correspond to
distinct processing entities or the complete set of levels in
all environments. (See also "configuration" and "policy
translation".)
企業目標からデバイス特有の設定パラメータまで及んで、異なったレベルで$方針抽象化(P)方針を表すことができます。 「抽象化」の異なったレベルの間の翻訳は方針以外の情報を必要とするかもしれません、ネットワークや、ホストパラメタ構成や能力のように。 様々なドキュメントと実装は明白なレベルの抽象化を指定するかもしれません。 しかしながら、これらは必ず異なった処理実体かすべての環境における完全なレベルに対応するというわけではありません。 (また、「構成」と「方針翻訳」を見てください。)
$ policy action
(P) Definition of what is to be done to enforce a policy rule,
when the conditions of the rule are met. Policy actions may
result in the execution of one or more operations to affect
and/or configure network traffic and network resources.
- In [RFC3060], a rule's actions may be ordered.
何に関する$政策的措置(P)定義は政策ルールを実施するためにすることであるか、規則に関する条件が満たされるとき。 政策的措置は、影響する1つ以上の操作の実行をもたらす、そして/または、ネットワークトラフィックとネットワーク資源を構成するかもしれません。 - [RFC3060]では、規則の動作は命令されるかもしれません。
$ policy condition
(P) A representation of the necessary state and/or prerequisites
that define whether a policy rule's actions should be
performed. This representation need not be completely
specified, but may be implicitly provided in an implementation
or protocol. When the policy condition(s) associated with a
policy rule evaluate to TRUE, then (subject to other
considerations such as rule priorities and decision
strategies) the rule should be enforced.
(T) In [RFC3060], a rule's conditions can be expressed as either
an ORed set of ANDed sets of statements (disjunctive normal
form), or an ANDed set of ORed sets of statements (conjunctive
normal form). Individual condition statements can also be
negated.
$方針状態(P) 政策ルールの動作が実行されるべきであるかどうかを定義する必要な状態、そして/または、前提条件の表現。 この表現を完全に指定しなければならないというわけではありませんが、それとなく実装かプロトコルに提供するかもしれません。 政策ルールに関連している方針状態であるときには当時(規則プライオリティや決定戦略などの他の問題を条件とした)のTRUEに規則を評価してください。実施されるべきです。 (T) [RFC3060]では、声明のANDedセットのORedセット(離接的な正規形)か声明のORedセットのANDedセット(論理積正規形)のどちらかとして規則の状態を言い表すことができます。 また、個々の状態声明を否定できます。
$ policy conflict
(P) Occurs when the actions of two rules (that are both satisfied
simultaneously) contradict each other. The entity
implementing the policy would not be able to determine which
action to perform. The implementers of policy systems must
provide conflict detection and avoidance or resolution
mechanisms to prevent this situation. "Policy conflict" is
contrasted with "policy error".
2つの規則(それは同時に、ともに満足している)の動作が互いに逆らうと、$方針闘争(P)は起こります。 政策を実施する実体は、どの動作を実行したらよいかを決定できないでしょう。 方針システムのimplementersは、この状況を防ぐために闘争検出と回避か解決メカニズムを提供しなければなりません。 「方針闘争」は「方針誤り」に対して対照されます。
Westerinen, et al. Informational [Page 8] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[8ページ]のRFC3198用語
$ policy conversion
See "policy translation".
$方針変換See「方針翻訳。」
$ Policy Core Information Model (PCIM) [RFC3060]
(T) An information model describing the basic concepts of policy
groups, rules, conditions, actions, repositories and their
relationships. This model is described as a "core" model
since it cannot be applied without domain-specific extensions
(for example, extensions for QoS or IPsec). PCIM is "core"
with respect to the area of policy. However, it is a "Common
Model," with respect to CIM - in that it extends the basic CIM
concepts for policy. (See also "Common Information Model".)
方針グループに関する基本概念について説明する情報モデル(規則)が条件とさせる$方針Core情報Model(PCIM)[RFC3060](T)、動作、倉庫、およびそれらの関係。 このモデルは、ドメイン特有の拡大(例えば、QoSかIPsecのための拡大)なしでそれを適用できないので、「コア」モデルとして記述されています。 PCIMは方針の領域に関する「コア」です。 しかしながら、それは「一般的なモデル」です、方針のための基本のCIM概念について敷衍しているのでCIMに関して。 (また、「一般的な情報モデル」を見てください。)
$ policy decision
(P) Two perspectives of "policy decision" exist:
- A "process" perspective that deals with the evaluation of a
policy rule's conditions
- A "result" perspective that deals with the actions for
enforcement, when the conditions of a policy rule are TRUE
「政策決定」の(P)Two見解が存在しているという$方針決定: - 政策ルールの状態の評価に対処する「プロセス」見解--政策ルールの状態がTRUEであるときに実施のための動作に対処する「結果」見解
$ Policy Decision Point (PDP)
(P) A logical entity that makes policy decisions for itself or for
other network elements that request such decisions [RFC2753].
(See also "policy decision".)
それ自体か他のネットワークのための政策決定をそのような決定[RFC2753]を要求する要素にする$の方針Decision Point(PDP)の(P)のA論理的な実体。 (また、「政策決定」を見てください。)
$ policy domain
(P) A collection of elements and services, and/or a portion of an
Internet over which a common and consistent set of policies
are administered in a coordinated fashion [RFC2474]. This
definition of a policy domain does not preclude multiple
sources of policy creation within an organization, but does
require that the resultant policies be coordinated.
- Policies defined in the context of one domain may need to
be communicated or negotiated outside of that domain. (See
also "policy negotiation".)
要素の、そして、サービスの$方針ドメイン(P)A収集、そして/または、一般的で一貫したセットの方針が連携ファッションで管理されるインターネットの部分[RFC2474]。 方針ドメインのこの定義は、組織の中で方針作成の複数の源を排除しませんが、結果の方針が調整されるのを必要とします。 - 1つのドメインの文脈で定義された方針は、そのドメインの外でコミュニケートするか、または交渉される必要があるかもしれません。 (また、「方針交渉」を見てください。)
$ policy enforcement
(P) The execution of a policy decision.
$方針実施、(P) 政策決定の実行。
$ Policy Enforcement Point (PEP)
(P) A logical entity that enforces policy decisions [RFC2753].
(See also "policy enforcement".)
政策決定[RFC2753]を実施する$の方針Enforcement Point(PEP)の(P)のA論理的な実体。 (また、「方針実施」を見てください。)
$ policy error
(P) "Policy errors" occur when attempts to enforce policy actions
fail, whether due to temporary state or permanent mismatch
between the policy actions and the device enforcement
capabilities. This is contrasted with "policy conflict".
政策的措置を実施する試みが失敗すると、$方針誤り(P)「方針誤り」は起こります、政策的措置とデバイス実施能力の間の一時的な状態か永久的なミスマッチにかかわらず。 これは「方針闘争」に対して対照されます。
Westerinen, et al. Informational [Page 9] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[9ページ]のRFC3198用語
$ policy goal
(P) Goals are the business objectives or desired state intended to
be maintained by a policy system. As the highest level of
abstraction of policy, these goals are most directly described
in business rather than technical terms. For example, a goal
might state that a particular application operate on a network
as though it had its own dedicated network, despite using a
shared infrastructure. 'Policy goals' can include the
objectives of a service level agreement, as well as the
assignment of resources to applications or individuals. A
policy system may be created that automatically strives to
achieve a goal through feedback regarding whether the goal
(such as a service level) is being met.
$方針目標(P)目標は経営目標であるか方針システムによって必要な州は維持されるつもりでした。 方針の抽象化の最高水準として、これらの目標は専門用語よりむしろビジネスで最も直接説明されます。例えば、目標は、まるでそれにはそれ自身の専用ネットワークがあるかのように特定用途がネットワークを経営すると述べるかもしれません、共有されたインフラストラクチャを使用しますが。 '方針目標'はサービスレベル協定の目的を含むことができます、アプリケーションか個人へのリソースの課題と同様に。 目標(サービスレベルなどの)が達成されるかどうかに関するフィードバックで目的を達成するように自動的に努力する方針システムは作成されるかもしれません。
$ Policy Information Base (PIB)
(T) Collections of related PRovisioning Classes (PRCs), defined as
a module. (See also "PRovisioning Class".)
モジュールと定義された関連するPRovisioning Classes(PRCs)の$方針Information基地(PIB)の(T)収集。 (「クラスに食糧を供給します」も見てください。)
$ policy mapping
See "policy translation".
「方針翻訳」という$方針マッピングSee。
$ policy negotiation
(P) Exposing the desired or appropriate part of a policy to
another domain. This is necessary to support partial
interconnection between domains, which are operating with
different sets of policies.
方針の必要であるか適切な部分を別のドメインに暴露する$方針交渉(P)。 これが、ドメインの間の部分的なインタコネクトをサポートするのに必要です。ドメインは異なったセットの方針で作動しています。
$ policy repository
(P) "Policy repository" can be defined from three perspectives:
- A specific data store that holds policy rules, their
conditions and actions, and related policy data. A
database or directory would be an example of such a store.
- A logical container representing the administrative scope
and naming of policy rules, their conditions and actions,
and related policy data. A "QoS policy" domain would be an
example of such a container.
- In [RFC3060], a more restrictive definition than the prior
one exists. A PolicyRepository is a model abstraction
representing an administratively defined, logical container
for reusable policy elements.
3つの見解から$方針倉庫(P)「方針倉庫」を定義できます: - 彼らの政策ルール、状態、および動作を保持する特定のデータ・ストア、および関連する方針データ。 データベースかディレクトリがそのような店に関する例でしょう。 - 彼らの政策ルールの管理範囲と命名、状態、および動作を表す論理的なコンテナ、および関連する方針データ。 「QoS方針」ドメインはそのようなコンテナに関する例でしょう。 - [RFC3060]では、先のものより制限している定義は存在しています。 PolicyRepositoryは再利用できる方針要素のために行政上定義されて、論理的なコンテナを表すモデル抽象化です。
$ policy request
(P) A message requesting a policy-related service. This may refer
to a request to retrieve a specific set of policy rules, to
determine the actions to enforce, or other policy requests.
When sent by a PEP to a PDP, it is more accurately qualified
as a "policy decision request" [RFC2753]. (See also "policy
decision".)
$方針は(P) 方針関連のサービスを要求するメッセージを要求します。 これは特定の政策ルールを検索するという動作が実施することを決定するという要求か他の方針要求を示すかもしれません。 PEPによってPDPに送られると、それは「政策決定要求」[RFC2753]として正確により適切です。 (また、「政策決定」を見てください。)
Westerinen, et al. Informational [Page 10] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[10ページ]のRFC3198用語
$ policy rule
(P) A basic building block of a policy-based system. It is the
binding of a set of actions to a set of conditions - where the
conditions are evaluated to determine whether the actions are
performed [RFC3060].
$方針は(P) 方針ベースのシステムの基本的なブロックを統治します。 それは状態が動作が実行されるかどうか[RFC3060]決定するために評価されるところの1セットの状態への1セットの機能の結合です。
$ policy server
(P) A marketing term whose definition is imprecise. Originally,
[RFC2753] referenced a "policy server". As the RFC evolved,
this term became more precise and known as the Policy Decision
Point (PDP). Today, the term is used in marketing and other
literature to refer specifically to a PDP, or for any entity
that uses/services policy.
定義が不正確である$方針サーバ(P)Aマーケティング用語。 元々、[RFC2753]は「方針サーバ」に参照をつけました。 RFCが発展したとき、今期は、より正確でPolicy Decision Pointとして知られるようになりました(PDP)。 それは、どんな実体のためにも、方針を今日、用語が特にPDPについて言及するのにマーケティングと他の文学で使用されるか、使用するか、または修理します。
$ policy translation
(P) The transformation of a policy from a representation and/or
level of abstraction, to another representation or level of
abstraction. For example, it may be necessary to convert PIB
data to a command line format. In this "conversion," the
translation to the new representation is likely to require a
change in the level of abstraction (becoming more or less
specific). Although these are logically distinct tasks, they
are (in most cases) blurred in the act of
translating/converting/mapping. Therefore, this is also known
as "policy conversion" or "policy mapping".
$方針翻訳、(P) 抽象化の表現、そして/または、レベルから別の表現かレベルの抽象化までの方針の変換。 例えば、PIBデータをコマンドライン形式に変換するのが必要であるかもしれません。 変換..翻訳..新しい..表現..ありそう..必要..変化..レベル..抽象化..なる..多少..特定 これらは論理的に異なったタスクですが、(多くの場合、)それらは翻訳/変換/マッピングの行為でぼかされます。 したがって、また、これは「方針変換」か「方針マッピング」として知られています。
$ PolicyGroup
(T) An abstraction in the Policy Core Information Model [RFC3060].
It is a class representing a container, aggregating either
policy rules or other policy groups. It allows the grouping
of rules into a Policy, and the refinement of high-level
Policies to lower-level or different (i.e., converted or
translated) peer groups.
$PolicyGroup、(T) Policy Core情報Model[RFC3060]での抽象化。 それは政策ルールか方針グループのどちらかに他の集めて、コンテナを表すクラスです。 それは低レベルか異なった(すなわち、変換されるか、または翻訳される)ピアグループにPolicyへの規則の組分け、およびハイレベルのPoliciesの気品を許容します。
$ PRC
See "PRovisioning Class".
$PRCは「クラスに食糧を供給します」を見ます。
$ PRI
See "PRovisioning Instance".
$PRIは「インスタンスに食糧を供給します」を見ます。
$ provisioned policy
(P) An execution model where network elements are pre-configured,
based on policy, prior to processing events. Configuration is
pushed to the network device, e.g., based on time of day or at
initial booting of the device. The focus of this model is on
the distribution of configuration information, and is
exemplified by Differentiated Services [RFC2475]. Based on
events received, devices use downloaded (pre-provisioned)
ネットワーク要素が処理イベントの前に方針に基づいてあらかじめ設定されるところで$は実行がモデル化する方針(P)に食糧を供給しました。 構成は例えば、ネットワークデバイス、または、時刻に基づいたデバイスの初期の穂ばらみで押されます。 このモデルの焦点は、設定情報の分配にはあって、Differentiated Services[RFC2475]によって例示されます。 受け取られたイベントに基づいて、デバイス使用はダウンロードされました。(あらかじめ食糧を供給されます)
Westerinen, et al. Informational [Page 11] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[11ページ]のRFC3198用語
mechanisms to implement policy. "Provisioned policy" is
contrasted with "outsourced policy".
政策を実施するメカニズム。 「食糧を供給された方針」は「社外調達された方針」に対して対照されます。
$ PRovisioning Class (PRC)
(T) An ordered set of attributes representing a type of policy
data. PRCs are defined in PIB modules (encoded using SPPI)
and registered in the Object Identifier tree. Instances of
each PRC are organized in tables, similar to conceptual tables
in SMIv2. (See also "Structure of Policy Provisioning
Information" and "Policy Information Base".)
The acronym, PRC, has evolved from "policy rule class" to
"provisioning class". The reason for the change is that a
discrepancy existed between the use of the words, "policy
rule" in the PRC context versus other uses in PCIM and the
industry. In the latter, rules are If/Then statements - a
binding of conditions to actions. PRCs are not "rules" by
this definition, but the encoding of (network-wide)
configuration information for a device.
$PRovisioning Class、(PRC) (T) 一種の方針データを表す1つの順序集合の属性。 PRCsはPIBモジュール(SPPIを使用することで、コード化される)で定義されて、Object Identifier木に登録されます。 それぞれのPRCのインスタンスは、SMIv2でテーブルで組織化されていて、概念的なテーブルと同様です。 (また、「情報に食糧を供給する方針の構造」と「方針Information基地」を見てください。) 頭文字語(PRC)は「政策ルールのクラス」から「クラスに食糧を供給します」に発展しました。 変更理由は食い違いが単語の使用、PCIMと産業における他の用途に対するPRC文脈の「政策ルール」の間に存在したということです。 後者では、規則はIf/当時の声明です--動作への状態の結合。 PRCsはこの定義による「規則」ではなくデバイスのための(ネットワーク全体)の設定情報のコード化です。
$ PRovisioning Instance (PRI)
(T) An instantiation of a PRovisioning Class. (See also
"PRovisioning Class".)
$PRovisioning Instance、(PRI) (T) PRovisioning Classの具体化。 (「クラスに食糧を供給します」も見てください。)
$ QoS
See "Quality of Service".
$QoSは「サービスの質」を見ます。
$ Quality of Service (QoS)
(A) At a high level of abstraction, "Quality of Service" refers to
the ability to deliver network services according to the
parameters specified in a Service Level Agreement. "Quality"
is characterized by service availability, delay, jitter,
throughput and packet loss ratio. At a network resource
level, "Quality of Service" refers to a set of capabilities
that allow a service provider to prioritize traffic, control
bandwidth, and network latency. There are two different
approaches to "Quality of Service" on IP networks: Integrated
Services [RFC1633], and Differentiated Service [RFC2475].
Integrated Services require policy control over the creation
of signaled reservations, which provide specific quantitative
end-to-end behavior for a (set of) flow(s). In contrast,
Differentiated Services require policy to define the
correspondence between codepoints in the packet's DS-field and
individual per-hop behaviors (to achieve a specified per-
domain behavior). A maximum of 64 per-hop behaviors limit the
number of classes of service traffic that can be marked at any
point in a domain. These classes of service signal the
treatment of the packets with respect to various QoS aspects,
such as flow priority and packet drop precedence. In
高いレベルの抽象化におけるService(QoS)(A)の$品質、「サービスの質」はサービス・レベル・アグリーメントで指定されたパラメタに応じてネットワーク・サービスを提供する能力を示します。 「品質」はサービスの有用性、遅れ、ジター、スループット、およびパケット損害率によって特徴付けられます。 ネットワーク資源レベルでは、「サービスの質」はサービスプロバイダーがトラフィック、コントロール帯域幅、およびネットワーク潜在を最優先させることができる1セットの能力を示します。 IPネットワークの「サービスの質」への2つの異なるアプローチがあります: 統合サービス[RFC1633]、および差別化されたサービス[RFC2475]。 統合Servicesは(セットされます)流動のための終わりから終わりへの特定の量的な振舞いを提供する合図された予約の作成の方針コントロールを必要とします。 対照的に、Differentiated ServicesがパケットのDS-分野と1ホップあたりの個々の振舞いでcodepointsの間の通信を定義するために方針を必要とする、(aを達成するのが指定した、-、ドメインの振舞い) 1ホップあたりの最大64の振舞いはドメインで任意な点に示されることができる業務用輸送のクラスの数を制限します。 これらのサービスのクラスは様々なQoS局面に関してパケットの処理を示します、流れ優先権やパケット低下先行のように。 コネ
Westerinen, et al. Informational [Page 12] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[12ページ]のRFC3198用語
addition, policy can be used to specify the routing of packets
based on various classification criteria. Policy controls the
set of configuration parameters and routing for each class in
Differentiated Service, and the admission conditions for
reservations in Integrated Services. (See also "policy
abstraction" and "Service Level Agreement".)
様々な分類評価基準に基づくパケットのルーティングを指定するのに追加、方針を使用できます。 方針はDifferentiated Serviceの各クラス、および予約のためのIntegrated Servicesの入場状態のために設定パラメータとルーティングのセットを制御します。 (また、「方針抽象化」を見てください、そして、「平らな協定を修理してください」。)
$ Resource reSerVation Protocol (RSVP)
(T) A setup protocol designed for an Integrated Services Internet,
to reserve network resources for a path [RFC2205]. And, a
signaling mechanism for managing application traffic's QoS in
a Differentiated Service network.
セットアッププロトコルが経路[RFC2205]への蓄えのネットワーク資源へのIntegrated Servicesインターネットに設計した$リソースreSerVationプロトコル(RSVP)(T)。 そして、Differentiated ServiceネットワークでアプリケーショントラフィックのQoSを管理するためのシグナル伝達機構。
$ role
(P) "Role" is defined from three perspectives:
- A business position or function, to which people and
logical entities are assigned [X.500]
- The labeled endpoints of a UML (Unified Modeling Language)
association. Quoting from [UML], "When a class
participates in an association, it has a specific role that
it plays in that relationship; a role is just the face the
class at the near end of the association presents to the
class at the other end of the association". The Policy
Core Information Model [RFC3060] uses UML to depict its
class hierarchy. Relationships/associations are significant
in the model.
- An administratively specified characteristic of a managed
element (for example, an interface). It is a selector for
policy rules and PRovisioning Classes (PRCs), to determine
the applicability of the rule/PRC to a particular managed
element [RFC3060].
Only the third definition (roles as selectors of policy) is
directly related to the management of network policy. However,
the first definition (roles as business positions and
functions) may be referenced in policy conditions and actions.
$役割(P)「役割」は3つの見解から定義されます: - ビジネスポジションか機能、どの人々的で論理的に、実体は割り当てられるか[X.500]--UML(統一モデリング言語)協会のラベルされた終点。 [UML]から引用して、「クラスが協会に参加するとき、それには、その関係で果たす特定の役割があります」。 「役割はただ協会の近い終わりのクラスが協会のもう一方の端のクラスに提示する表面です。」 Policy Core情報Model[RFC3060]は、クラス階層構造について表現するのにUMLを使用します。 関係/協会はモデルで重要です。 - 管理された要素(例えば、インタフェース)の行政上指定された特性。 それは、規則/PRCの適用性を特定の管理された要素[RFC3060]まで決定するためには政策ルールのためのセレクタとPRovisioning Classes(PRCs)です。 3番目の定義(方針のセレクタとしての役割)だけが直接ネットワーク方針の管理に関連します。 しかしながら、最初の定義(ビジネスポジションと機能としての役割)は保険約款と動作で参照をつけられるかもしれません。
$ role combination
(P) A lexicographically ordered set of roles that characterize
managed elements and indicate the applicability of policy
rules and PRovisioning Classes (PRCs). A policy system uses
the set of roles reported by the managed element to determine
the correct rules/PRCs to be sent for enforcement. That
determination may examine all applicable policy rules
identified by the role combination, its sub-combinations and
the individual roles in the combination [RFC3060]. In the
case of PRCs, a PRC must explicitly match the role combination
of the managed element in order to be applicable and/or
enforced. (The comparison is typically case-sensitive.) The
辞書編集が設定するよう命令した管理された要素を特徴付けて、政策ルールの適用性を示す役割とPRovisioning Classes(PRCs)の$役割の組み合わせ(P)。 方針システムは管理された要素によって正しい規則/PRCsが実施のために送られることを決定すると報告された役割のセットを使用します。 その決断は役割の組み合わせ、サブ組み合わせ、および組み合わせ[RFC3060]における個々の役割によって特定されたすべての適切な政策ルールを調べるかもしれません。 PRCsの場合では、PRCは、適切である、そして/または、実施されているために明らかに管理された要素の役割の組み合わせに合わなければなりません。 (比較は通常大文字と小文字を区別しています。) The
Westerinen, et al. Informational [Page 13] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[13ページ]のRFC3198用語
final set of rules/PRCs for enforcement are defined by the
policy system, as appropriate for the specified role
combination of the managed element.
実施のための規則/PRCsのファイナルセットは方針システムによって定義されます、管理された要素の指定された役割の組み合わせにおいて、適切です。
$ RSVP
See "Resource reSerVation Protocol".
$RSVPは「資源予約プロトコル」を見ます。
$ rule
See "policy rule".
$規則See「政策ルール。」
$ rule based engine
(T) A rule based engine is able to evaluate policy condition(s)
and trigger appropriate policy actions. A particular rule
based engine may only be capable of acting upon policy rules
that are formatted in a specified way or adhere to a specific
language.
規則のベースのエンジンができるベースのエンジン(T)が方針状態を評価するという$規則と引き金は政策的措置を当てます。 ベースのエンジンが指定された方法でフォーマットされるか、または特定の言語を固く守る政策ルールに行動させることができるだけであるかもしれない特定の規則。
$ schema
(T) Two different perspectives of schema are defined:
- A set of rules that determines what data can be stored in a
database or directory service [DirServs]
- A collection of data models that are each bound to the same
type of repository.
The latter is the preferred and recommended one for Internet
Standards documents. (See also "data model".)
図式の$の図式の(T)Two異なった見解は定義されます: - データベースかディレクトリサービス[DirServs]にどんなデータを保存できるかを決定する1セットの規則--それぞれであるデータモデルの収集は同じタイプの倉庫に付きました。 後者はインターネットStandardsドキュメントのための都合のよくてお勧めのものです。 (また、「データモデル」を見てください。)
$ service
(P) The behavior or functionality provided by a network, network
element or host [DMTF, RFC2216]. Quoting from RFC 2216
[RFC2216], in order to completely specify a "service", one
must define the "functions to be performed ..., the
information required ... to perform these functions, and the
information made available by the element to other elements of
the system". Policy can be used to configure a "service" in a
network or on a network element/host, invoke its
functionality, and/or coordinate services in an interdomain or
end-to-end environment.
ネットワーク、ネットワーク要素またはホスト[DMTF、RFC2216]で振舞いか機能性が提供した$サービス(P)。 「サービス」を完全に指定するためにRFC2216[RFC2216]から引用して、「実行されるべき機能」を定義しなければなりません…, 「情報が必要です…これらの機能、および要素で利用可能にシステムの他の原理までされた情報を実行するために。 」 終わりからinterdomainか終わりへの環境でネットワークかネットワーク要素/ホストの上で「サービス」を構成して、機能性を呼び出す、そして/または、サービスを調整するのに方針を使用できます。
$ Service Level Agreement (SLA)
(P) The documented result of a negotiation between a
customer/consumer and a provider of a service, that specifies
the levels of availability, serviceability, performance,
operation or other attributes of the service [RFC2475]. (See
also "Service Level Objective".)
$はLevel Agreement(SLA)を調整します。(P) 顧客/消費者の間の交渉の記録された結果とサービスのプロバイダー、それは有用性のレベルを指定します、実用性、性能、操作であるか他のサービスの属性[RFC2475]。 (また、「サービスレベル目的」を見てください。)
Westerinen, et al. Informational [Page 14] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[14ページ]のRFC3198用語
$ Service Level Objective (SLO)
(P) Partitions an SLA into individual metrics and operational
information to enforce and/or monitor the SLA. "Service Level
Objectives" may be defined as part of an SLA, an SLS, or in a
separate document. It is a set of parameters and their
values. The actions of enforcing and reporting monitored
compliance can be implemented as one or more policies. (See
also "Service Level Agreement".)
$サービスLevel Objective(SLO)(P)は、SLAを実施する、そして/または、モニターするために個々の測定基準と運用情報にSLAを仕切ります。 「サービスLevel Objectives」はSLA、SLSを離れさせるか、または別々のドキュメントで定義されるかもしれません。 それは、1セットのパラメタとそれらの値です。 1つ以上の方針としてモニターされたコンプライアンスを実施して、報告する動作を実装することができます。 (また、「サービスレベル協定」を見てください。)
$ Service Level Specification (SLS)
(P) Specifies handling of customer's traffic by a network
provider. It is negotiated between a customer and the
provider, and (for example) in a DiffServ environment, defines
parameters such as specific Code Points and the Per-Hop-
Behavior, profile characteristics and treatment of the traffic
for those Code Points. An SLS is a specific SLA (a negotiated
agreement) and its SLOs (the individual metrics and
operational data to enforce) to guarantee quality of service
for network traffic. (See also "Service Level Agreement" and
"Service Level Objective".)
$サービスLevel Specification(SLS)(P)はネットワーク内の提供者で顧客のトラフィックの取り扱いを指定します。 それは、顧客とプロバイダーの間と、そして、(例えば、)DiffServ環境で交渉されて、それらのCode Pointsのためにトラフィックの特定のCode Pointsや、Per-ホップ振舞いや、プロフィールの特性や処理などのパラメタを定義します。 SLSはネットワークトラフィックにサービスの質を保証する特定のSLA(交渉された協定)とそのSLOs(実施する個々の測定基準と操作上のデータ)です。 (また、「サービスレベル協定」と「サービスレベル目的」を見てください。)
$ Simple Network Management Protocol (SNMP)
(T) SNMP is a framework (including a protocol) for managing
systems in a network environment [RFC2570]. It can be used
for policy-based configuration and control using a specific
MIB Module designed to execute policies on managed elements
via scripts. The elements (instances) in a network device are
evaluated using a policy filter, to determine where policy
will be applied.
$簡単なNetwork Managementプロトコル(SNMP)(T)SNMPは、ネットワーク環境[RFC2570]でシステムを管理するためのフレームワーク(プロトコルを含んでいる)です。 方針ベースの構成とコントロールにスクリプトで管理された要素に関する方針を実行するように設計された特定のMIB Moduleを使用することでそれを使用できます。 ネットワークデバイスの要素(インスタンス)は、方針がどこに適用されるかを決定するのに方針フィルタを使用することで評価されます。
$ SLA
See "Service Level Agreement".
$SLAは「サービスレベル協定」を見ます。
$ SLO
See "Service Level Objective".
$SLOは「サービスレベル目的」を見ます。
$ SLS
See "Service Level Specification".
$SLSは「サービスレベル指定」を見ます。
$ SMIv2
See "Structure of Management Information".
$SMIv2は「経営情報の構造」を見ます。
$ SNMP
See "Simple Network Management Protocol".
$SNMPは「簡単なネットワーク管理プロトコル」を見ます。
$ SPPI
See "Structure of Policy Provisioning Information".
$SPPIは「情報に食糧を供給する方針の構造」を見ます。
Westerinen, et al. Informational [Page 15] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[15ページ]のRFC3198用語
$ Structure of Policy Provisioning Information (SPPI)
(T) An adapted subset of SNMP's Structure of Management
Information (SMIv2) that is used to encode collections of
related PRovisioning Classes as a PIB [RFC3159]. (See also
"Policy Information Base" and "PRovisioning Class".)
$構造、Policy Provisioning情報(SPPI)(T)では、SNMPの収集をコード化するのにおいて使用されたManagement情報(SMIv2)のStructureの適合している部分集合はPIB[RFC3159]としてPRovisioning Classesを関係づけました。 (また、「方針Information基地」と「クラスに食糧を供給します」を見てください。)
$ Structure of Management Information, version 2 (SMIv2)
(T) An adapted subset of OSI's Abstract Syntax Notation One, ASN.1
(1988) used to encode collections of related objects as SNMP
Management Information Base (MIB) modules [RFC2578].
Management情報の$構造、バージョン2(SMIv2) (T) OSIの抽象的なSyntax Notation Oneの適合している部分集合、ASN.1(1988)は以前はSNMP Management Information基地(MIB)のモジュール[RFC2578]としてよく関連するオブジェクトの収集をコード化していました。
$ subject
(P) An entity, or collection of entities, which originates a
request, and is verified as authorized/not authorized to
perform that request.
$対象、(P) 要求を溯源して、その要求を実行するのは認可されなかった認可された/が確かめられる実体、または実体の収集。
$ target
(P) An entity, or collection of entities, which is affected by a
policy. For example, the "targets" of a policy to reconfigure
a network device are the individual services that are updated
and configured.
$は(P) 方針で影響を受ける実体、または実体の収集を狙います。 例えば、ネットワークデバイスを再構成する方針の「目標」はアップデートして、構成する個々のサービスです。
4. Intellectual Property
4. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。
Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Westerinen, et al. Informational [Page 16] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[16ページ]のRFC3198用語
5. Acknowledgements
5. 承認
This document builds on the work of previous terminology drafts. The authors of these documents were Fran Reichmeyer, Dan Grossman, John Strassner, Ed Ellesson and Matthew Condell. Also, definitions for the general concepts of policy and policy rule include input from Predrag Spasic. Very helpful comments and suggestions were received from Juergen Schoenwaelder, Joe Salowey, Jon Saperia, Ravi Sahita, Bob Moore, Guus Sliepen, T.H. Jonatan and Dave Perkins.
このドキュメントは前の用語草稿の仕事のときに建てられます。 これらのドキュメントの作者は、フランReichmeyerと、ダン・グロースマンと、ジョンStrassnerと、エドEllessonとマシュー・コンデルでした。 また、方針と政策ルールに関する一般概念のための定義はプレドラッグSpasicからの入力を含んでいます。 ユルゲンSchoenwaelder、ジョーSalowey、ジョンSaperia、ラービーSahita、ボブ・ムーア、フースSliepen、T.H.Jonatan、およびデーヴ・パーキンスから非常に役立っているコメントと提案を受領しました。
6. Security Considerations
6. セキュリティ問題
This document only defines policy-related terms. It does not describe in detail the vulnerabilities of, threats to, or mechanisms that protect specific policy implementations or policy-related Internet protocols.
このドキュメントは方針関連の用語を定義するだけです。詳細に脆弱性について説明しない、脅威、または、特定の政策の実施か方針関連のインターネットプロトコルを保護するメカニズム。
7. References
7. 参照
[DecSupp] Building Effective Decision Support Systems. R.
Sprague, and E. Carleson. Prentice Hall, 1982.
[DecSupp] 有効な意思決定支援システムR.スプレーグ、およびE.Carlesonを造ります。 新米のホール、1982。
[DirServs] Understanding and Deploying LDAP Directory Services. T.
Howes, M. Smith, and G. Good. MacMillan Technical
Publications, 1999.
[DirServs] 分かって、LDAPにディレクトリサービスを配布します。 T。 ハウズ、M.スミス、およびG.利益。 マクミランの技術的な刊行物、1999。
[DMTF] Common Information Model (CIM) Schema, version 2.x.
Distributed Management Task Force, Inc. The components
of the CIM v2.x schema are available via links on the
following DMTF web page:
http://www.dmtf.org/standards/standard_cim.php.
[DMTF]一般的な情報Model(CIM)図式、バージョン2.x。 分配されたManagement Task Force Inc.、CIM v2.x図式の成分は以下のDMTFウェブページのリンクを通して利用可能です: http://www.dmtf.org/standards/standard_cim.php 。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: An Overview", RFC
1633, June 1994.
[RFC1633] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, April 1997.
[RFC2138]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
Westerinen, et al. Informational [Page 17] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[17ページ]のRFC3198用語
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", September 1997.
[RFC2216]ShenkerとS.とJ.Wroclawski、「ネットワーク要素サービス仕様テンプレート」、1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[RFC2570]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M. and S.Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", RFC 2578, April 1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」RFC2578(1999年4月)。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2702]AwducheとD.、マルコムとJ.とAgogbuaとJ.とオデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.
and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RFC2748] ダラム、D.、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.
and A. Sastry, "COPS Usage for RSVP", RFC 2749, January
2000.
[RFC2749]ハーツォグ、S.、ボイル(J.、コーエン、R.、ダラム、D.、Rajan、R.、およびA.Sastry)は「RSVPのために用法を獲得します」、RFC2749、2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[RFC2753] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[RFC2828]Shirey(R.、「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。
[RFC3060] Moore, B., Ellesson, E., Strassner, J. and A.
Westerinen, "Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3060] ムーア、B.、Ellesson、E.、Strassner、J.、およびA.Westerinen、「方針コア情報はモデル化されます--バージョン1仕様」、RFC3060、2001年2月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, February 2001.
[RFC3084]チェン(K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ハーツォグ、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス)は、「方針の食糧を供給する(PRを獲得している)用法を獲得します」、RFC3084、2001年2月。
Westerinen, et al. Informational [Page 18] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[18ページ]のRFC3198用語
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure
of Policy Provisioning Information," RFC 3159, August
2001.
[RFC3159]McCloghrie、K.、おかげさまで元気です、M.、Seligson、J.、チェン、K.、ハーン、S.、Sahita、R.、スミス、A.、およびF.Reichmeyer、「方針の構造は情報に食糧を供給し」て、RFC3159、2001年8月。
[UML] The Unified Modeling Language User Guide. G. Booch, J.
Rumbaugh, and I. Jacobson. Addison-Wesley, 1999.
[UML] 統一モデリング言語ユーザガイド。 G。 Booch、J.Rumbaugh、およびI.ジェーコブソン。 アディソン-ウエスリー、1999。
[X.500] Data Communications Networks Directory, Recommendations
X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth
Plenary Assembly, Melbourne. November 1988.
[X.500] データ通信網ディレクトリ、推薦X.500-X.521、巻VIII--分冊VIII.8。 CCITT、IXth総会、メルボルン。 1988年11月。
8. Authors' Addresses
8. 作者のアドレス
Andrea Westerinen Cisco Systems, Bldg 20 725 Alder Drive Milpitas, CA 95035
アンドレアWesterinenシスコシステムズ、Bldg20 725ハンノキDriveミルピタス、カリフォルニア 95035
EMail: andreaw@cisco.com
メール: andreaw@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744
Loughran Roadワシントン砦、ジョンSchnizleinシスコシステムズ9123MD 20744
EMail: john.schnizlein@cisco.com
メール: john.schnizlein@cisco.com
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 Phone: +1-719-785-0648
ジョンStrassner Intelliden社90の南カスケードアベニューコロラド・スプリングス、CO 80903は以下に電話をします。 +1-719-785-0648
EMail: john.strassner@intelliden.com
メール: john.strassner@intelliden.com
Mark Scherling Xcert International Inc. Suite 300 505 Burrard Street Vancouver, BC V7X 1M3
マーク・Scherling Xcertの国際株式会社スイート300 505バラード通りバンクーバー、紀元前V7X 1M3
EMail: mscherling@xcert.com
メール: mscherling@xcert.com
Westerinen, et al. Informational [Page 19] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[19ページ]のRFC3198用語
Bob Quinn Celox Networks 2 Park Central Drive Southborough, MA 01772
ボブクインCeloxネットワーク2はSouthborough、中央のDrive MA 01772を駐車します。
EMail: bquinn@celoxnetworks.com
メール: bquinn@celoxnetworks.com
Jay Perry Network Appliance 495 East Java Drive Sunnyvale, CA 94089
Driveサニーベル、ジェイペリーネットアプライアンス495の東Javaカリフォルニア 94089
EMail: jay.perry@netapp.com
メール: jay.perry@netapp.com
Shai Herzog PolicyConsulting.com 200 Clove Rd. New Rochelle, NY 10801
ShaiハーツォグPolicyConsulting.com200Clove通り ニューロシェル、ニューヨーク 10801
EMail: herzog@PolicyConsulting.com
メール: herzog@PolicyConsulting.com
An-Ni Huynh Lucent Technologies 2139 Route 35 Holmdel, NJ 07733
2139年の1NiのHuynhルーセントテクノロジーズルート35Holmdel、ニュージャージー 07733
Mark Carlson Sun Microsystems, Inc. 500 Eldorado Boulevard Broomfield, CO 80021
マークカールソンサン・マイクロシステムズ・インク500のエルドラドBoulevardブルームフィールド、CO 80021
EMail: mark.carlson@sun.com
メール: mark.carlson@sun.com
Steve Waldbusser
スティーブWaldbusser
Phone: +1-650-948-6500 Fax: +1-650-745-0671 EMail: waldbusser@nextbeacon.com
以下に電話をしてください。 +1-650-948-6500 Fax: +1-650-745-0671 メールしてください: waldbusser@nextbeacon.com
Westerinen, et al. Informational [Page 20] RFC 3198 Terminology for Policy-Based Management November 2001
Westerinen、他 方針ベースの管理2001年11月のための情報[20ページ]のRFC3198用語
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Westerinen, et al. Informational [Page 21]
Westerinen、他 情報[21ページ]
一覧
スポンサーリンク
