RFC2872 日本語訳
2872 Application and Sub Application Identity Policy Element for Usewith RSVP. Y. Bernet, R. Pabbati. June 2000. (Format: TXT=10933 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Bernet
Request for Comments: 2872 R. Pabbati
Category: Standards Track Microsoft
June 2000
Bernetがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2872年のR.Pabbatiカテゴリ: 標準化過程マイクロソフト2000年6月
Application and Sub Application Identity Policy Element for
Use with RSVP
RSVPとの使用のためのアプリケーションと潜水艦アプリケーションアイデンティティ方針要素
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Conventions used in this document
本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Abstract
要約
RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information.
RSVP[RFC2205]シグナリングメッセージは方針データ・オブジェクトを通常含んでいます。(順番に、データ・オブジェクトは方針要素を含みます)。 方針要素はユーザ、そして/または、アプリケーション情報について説明するかもしれません。(それは、RSVPの意識しているネットワーク要素によって使用されて、)適切な政策決定を交通の流れに適用するかもしれません。 このメモはアプリケーション情報を提供する方針要素の使用法を詳しく述べます。
1. Overview
1. 概要
RSVP aware network elements may act as policy enforcement points (PEPs). These work together with policy decision points (PDPs) to enforce QoS policy. Briefly, PEPs extract policy information from RSVP signaling requests and compare the information against information stored by a PDP in a (possibly remotely located) policy database or directory. A policy decision is made based on the results of the comparison.
方針実施が(PEPs)を指すとき、RSVPの意識しているネットワーク要素は作用するかもしれません。 これらはQoS方針を実施するという政策決定ポイント(PDPs)と共に働いています。 簡潔に、PEPsは(ことによると離れて見つけられています)の方針データベースかディレクトリで要求に合図するRSVPから方針情報を抜粋して、PDPによって保存された情報に対して情報を比較します。 比較の結果に基づいて政策決定をします。
Bernet & Pabbati Standards Track [Page 1] RFC 2872 Application Identifiers for RSVP June 2000
Bernet&Pabbati規格は2000年6月にRSVPのためのRFC2872アプリケーション識別子を追跡します[1ページ]。
One type of policy information describes the application on behalf of which an RSVP signaling request is generated. When application policy information is available, network administrators are able to manage QoS based on application type. So, for example, a network administrator may establish a policy that prioritizes known mission- critical applications over games.
1つのタイプの方針情報はアプリケーションを代表してRSVPシグナリング要求が発生している説明します。 アプリケーション方針情報が利用可能であるときに、ネットワーク管理者はアプリケーションタイプに基づくQoSに対処できます。 そのように、例えば、ネットワーク管理者はゲームの上の知られている任務重要なアプリケーションを最優先させる方針を確立するかもしれません。
This memo describes a structure for a policy element that can be used to identify application traffic flows. The policy element includes a number of attributes, one of which is a policy locator. This policy locator includes the following hierarchically ordered sub-elements (in descending levels of hierarchy):
このメモはアプリケーション交通の流れを特定するのに使用できる方針要素のために構造について説明します。 方針要素は多くの属性を含んでいます。その1つは方針ロケータです。 この方針ロケータは下位要素(階層構造のレベルを滑降させることにおける)が階層的で注文された以下を含んでいます:
1. identifier that uniquely identifies the application vendor
2. identifier of the application
3. version number of the application
4. sub-application identifier
1. 唯一アプリケーション4サブアプリケーション識別子のアプリケーション3バージョン番号に関するアプリケーションベンダー2識別子を特定する識別子
An arbitrary number of sub-application identifiers may be included in the policy locator. An example of such an identifier is 'print transaction'.
サブアプリケーション識別子の特殊活字の数字は方針ロケータに含まれるかもしれません。 そのような識別子に関する例は'印刷トランザクション'です。
This memo specifies the structure of the application policy element and proposes keywords for the sub-elements at each level of the hierarchy. It does not enumerate specific values for the sub- elements: such an enumeration is beyond the scope of this memo.
このメモは、アプリケーション方針要素の構造を指定して、階層構造の各レベルにおける下位要素のためのキーワードを提案します。 それはサブ要素のために特定の値を列挙しません: そのような列挙はこのメモの範囲を超えています。
2. Simple Application Identity Policy Element Structure
2. 簡単なアプリケーションアイデンティティ方針要素構造
General application identity policy elements are defined in [RFC2752]. These are policy elements with a P-type of AUTH_APP. Following the policy element header is a list of authentication attributes.
一般的適用アイデンティティ方針要素は[RFC2752]で定義されます。 AUTH_APPのP-タイプに従って、これらは方針要素です。 方針要素ヘッダーに続くのは、認証属性のリストです。
The first authentication attribute is of the A-type POLICY_LOCATOR. The sub-type of the POLICY_LOCATOR attribute is of type ASCII_DN [RFC1779] or UNICODE_DN. The actual attribute data is formatted as an X.500 distinguished name (DN), representing a globally unique identifier, the application, version number and sub-application in a hierarchical structure. The POLICY_LOCATOR attribute contains keywords as described in section 2. For further details on the format of the POLICY_LOCATOR attribute, see [RFC2752].
A-タイプPOLICY_LOCATORには最初の認証属性があります。 タイプASCIIの_DN[RFC1779]か_ユニコードDNにはPOLICY_LOCATOR属性のサブタイプがあります。 実際の属性データはX.500分類名(DN)としてフォーマットされます、階層構造でグローバルにユニークな識別子、アプリケーション、バージョン番号、およびサブアプリケーションを表して。 POLICY_LOCATOR属性はセクション2で説明されるようにキーワードを含んでいます。 さらに詳しい明細についてはPOLICY_LOCATOR属性の形式では、[RFC2752]を見てください。
The second authentication attribute is of the A-type CREDENTIAL. The sub-type of the CREDENTIAL attribute is of type ASCII_ID or UNICODE_ID. The actual attribute data is an ASCII or Unicode string representing the application name. This structure is illustrated in the following diagram:
A-タイプCREDENTIALには2番目の認証属性があります。 CREDENTIAL属性のサブタイプはタイプASCII_IDかユニコード_IDのものです。 実際の属性データは、アプリケーション名を表すASCIIかユニコードストリングです。 この構造は以下のダイヤグラムで例証されます:
Bernet & Pabbati Standards Track [Page 2] RFC 2872 Application Identifiers for RSVP June 2000
Bernet&Pabbati規格は2000年6月にRSVPのためのRFC2872アプリケーション識別子を追跡します[2ページ]。
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Length (8) | P-type = AUTH_APP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = | Sub-type = |
| | POLICY_LOCATOR| ASCII_DN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application policy locator attribute data in X.500 DN format |
| (see below) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = | Sub-type = |
| | CREDENTIAL | ASCII_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application name as ASCII string |
| (e.g. SAP.EXE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEの長さ(8)| P-タイプはAUTH_装置と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性の長さ| 1タイプの=| サブタイプ=| | | 方針_ロケータ| ASCII_DN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X.500 DN形式におけるアプリケーション方針ロケータ属性データ| | (以下を見ます) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性の長さ| 1タイプの=| サブタイプ=| | | 資格証明書| ASCII_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCIIストリングとしてのアプリケーション名| | (例えば、SAP.EXE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following keywords are recommended although others MAY be used:
他のものは使用されるかもしれませんが、以下のキーワードはお勧めです:
Key Attribute -------------- GUID Globally Unique Identifier (optional) APP Application Name VER Application Version Number SAPP Sub Application (optional)
キー属性-------------- GUIDグローバルにユニークな識別子(任意の)装置アプリケーション名VERアプリケーションバージョン数のサップ潜水艦アプリケーション(任意)です。
The following are examples of conformant policy locators:
↓これはconformant方針ロケータに関する例です:
"APP=SAP, VER=1.1, SAPP=Print"
「VER=1.1、装置は体液と等しく、サップは印刷と等しいです」
"GUID=http://www.microsoft.com/apps, APP=MyApplication, VER=1.2.3"
「GUIDは http://www.microsoft.com/apps と等しく、装置はMyApplicationと等しく、VERは1.2と何0.3インチも等しいです」
The APP, VER and SAPP attributes SHOULD describe the application to a human reader in as unique and unambiguous a way as possible. The GUID attribute MAY be used when absolute uniqueness of application identification is required and its contents MUST be an identifier from a globally-unique source (e.g. domain names as assigned by the corresponding registration authorities). Note that publication of the chosen identifiers in a suitable format is strongly encouraged.
APP、VER、およびサップ属性SHOULDはできるだけユニークで明白な方法で人間の読者にアプリケーションについて説明します。 アプリケーション識別の絶対ユニークさが必要であり、コンテンツがグローバルにユニークなソース(例えば対応する登録局によって割り当てられるドメイン名)からの識別子であるに違いないときに、GUID属性は使用されるかもしれません。 適当な形式の選ばれた識別子の公表が強く奨励されることに注意してください。
Bernet & Pabbati Standards Track [Page 3] RFC 2872 Application Identifiers for RSVP June 2000
Bernet&Pabbati規格は2000年6月にRSVPのためのRFC2872アプリケーション識別子を追跡します[3ページ]。
3. Security Considerations
3. セキュリティ問題
The proposed simple policy element does not guarantee that element is indeed associated with the application it claims to be associated with. In order to provide such guarantees, it is necessary to sign applications. Signed application policy elements may be proposed at a future date. Note that, typically, the application policy element will be included in an RSVP message with an encrypted and authenticated user policy element. A level of security is provided by trusting the application policy element only if the user policy element is trusted.
提案された簡単な方針要素は、本当に、要素が関連しているそれが、主張するアプリケーションに関連しているのを保証しません。 そのような保証を提供するために、アプリケーションに署名するのが必要です。 署名しているアプリケーション方針要素は後日に提案されるかもしれません。 通常、アプリケーション方針要素がRSVPメッセージに暗号化されて認証されたユーザ方針要素で含まれることに注意してください。 ユーザ方針要素が信じられる場合にだけアプリケーション方針要素を信じることによって、セキュリティのA級試験を提供します。
All RSVP integrity considerations apply to the message containing the application policy element.
すべてのRSVP保全問題がアプリケーション方針要素を含むメッセージに適用されます。
4. References
4. 参照
[RFC2205] Braden, R., Zhang, L., Berson, L., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) - Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、L.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC1779] Kille, S., "A String Representation of Distinguished
Names", RFC 1779, March 1995.
[RFC1779] Kille、S.、「分類名のストリング表現」、RFC1779、1995年3月。
[RFC2752] Yadav, S., Yavatkar, R., Pabbati, R,. Ford, P., Moore, T.
and S. Herzog, "Identity Representation for RSVP", RFC
2752, January 2000.
[RFC2752]YadavとS.とYavatkarとR.とPabbatiとRと. フォードとP.、ムーアとT.とS.ハーツォグ、「RSVPのアイデンティティ表現」RFC2752(2000年1月)。
[ASCII] Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
2.0", Addison-Wesley, Reading, MA, 1996.
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン2インチ、アディソン-ウエスリー、読書、MA、1996。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
5. Acknowledgments
5. 承認
Thanks to Tim Moore, Shai Mohaban, Andrew Smith, Ulrich Homann and other contributors to the IETF's RAP WG for their input.
彼らの入力をIETFのRAP WGのティム・ムーア、Shai Mohaban、アンドリュー・スミス、ユーリッヒHomann、および他の貢献者をありがとうございます。
Bernet & Pabbati Standards Track [Page 4] RFC 2872 Application Identifiers for RSVP June 2000
Bernet&Pabbati規格は2000年6月にRSVPのためのRFC2872アプリケーション識別子を追跡します[4ページ]。
6. Authors' Addresses
6. 作者のアドレス
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
ヨラムBernetマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: (425) 936-9568 EMail: yoramb@microsoft.com
以下に電話をしてください。 (425) 936-9568 メールしてください: yoramb@microsoft.com
Ramesh Pabbati One Microsoft Way Redmond, WA 98052
Ramesh Pabbati1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: rameshpa@microsoft.com
メール: rameshpa@microsoft.com
Bernet & Pabbati Standards Track [Page 5] RFC 2872 Application Identifiers for RSVP June 2000
Bernet&Pabbati規格は2000年6月にRSVPのためのRFC2872アプリケーション識別子を追跡します[5ページ]。
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Bernet & Pabbati Standards Track [Page 6]
Bernet&Pabbati標準化過程[6ページ]
一覧
スポンサーリンク
