RFC4020 日本語訳

Network Working Group                                        K. Kompella
Request for Comments: 4020                              Juniper Networks
BCP: 100                                                        A. Zinin
Category: Best Current Practice                                  Alcatel
                                                           February 2005

Kompellaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4020年の杜松はBCPをネットワークでつなぎます: 100A.ジニンカテゴリ: 最も良い現在の練習アルカテル2005年2月

          Early IANA Allocation of Standards Track Code Points

標準化過程コード・ポイントの早めのIANA配分

Status of This Memo

このメモの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This memo discusses earlier allocation of code points by IANA as a
   remedy to the problem created by the "Standards Action" IANA policy
   for protocols for which, by the IETF process, implementation and
   deployment experience is desired or required prior to publication.

このメモは療法としてIETFプロセスによる実装と展開経験が公表の前に望まれているか、または必要であるプロトコルのために「規格動作」IANA方針で生じた問題とIANAによるコード・ポイントの以前の配分について議論します。

1.  Introduction

1. 序論

   In Standards Track RFCs, there is often a need to allocate code
   points for various objects, messages, or other protocol entities so
   that implementations can interoperate.  Many of these code point
   spaces have registries handled by the Internet Assigned Number
   Authority (IANA).  Several IANA allocation policies are described in
   RFC 2434 [2434].  Some of them, such as First Come First Served or
   Expert Review, do not require a formal IETF action before the IANA
   performs allocation.  However, in situations where code points are a
   scarce resource and/or the IETF community is willing to retain tight
   control of the protocol, policies such as IESG Approval, IETF
   Consensus, or Standards Action have been used.  The Standards Action
   policy represents a problem in situations where implementation and/or
   deployment experience are desired or required for the Standards
   Action.

Standards Track RFCsに、様々なオブジェクト、メッセージ、または他のプロトコル実体のためにコード・ポイントを割り当てる必要が、実装が共同利用できるように、しばしばあります。 これらのコードポイント空間の多くで、ISOCの機関の一つで(IANA)は登録を扱います。 いくつかのIANA配分方針がRFC2434[2434]で説明されます。 First Come First ServedやExpert Reviewのように、IANAが配分を実行する前に彼らの何人かが正式なIETF動作を必要としません。 しかしながら、コード・ポイントが不十分なリソースであり、IETF共同体がプロトコルの厳格な管理を保有しても構わないと思っている状況で、IESG Approval、IETF Consensus、またはStandards Actionなどの方針は使用されました。 Standards Action方針は実装、そして/または、展開経験が望まれているか、またはStandards Actionに必要である状況における問題を表します。

   To break the deadlock, "pre-RFC" implementations have sometimes
   simply chosen some "seemingly unused" code points; these may turn out
   to be different from those later assigned by IANA.  To make matters
   worse, these "pre-RFC" implementations are often deployed.  This
   creates several potential interoperability problems between early

局面を打開するために、「プレRFC」実装は時々単にいくつかの「外観上未使用」のコード・ポイントを選びました。 これらは後でIANAによって割り当てられたものと異なると判明するかもしれません。 いっそう困ったことに、これらの「プレRFC」実装はしばしば配布されます。 これは早いことの間にいくつかの潜在的相互運用性問題を生じさせます。

Kompella & Zinin         Best Current Practice                  [Page 1]

RFC 4020        Early Allocation of Standard Code Points   February 2005

標準のコードのKompellaとジニン最も良い現在の習慣[1ページ]RFC4020の早めの配分は2005年2月に指します。

   implementations and implementations of the final standard, as
   described below:

以下で説明されるとしての最終的な規格の実装と実装:

   1. IANA allocates code points different from those that early
      implementations assumed would be allocated.  Early implementations
      won't interoperate with standard ones.

1. IANAは早めの実装が割り当てられると仮定したそれらと異なったコード・ポイントを割り当てます。 早めの実装は標準のもので共同利用しないでしょう。

   2. IANA allocates code points used silently for other extensions.
      Different extensions will collide.

2. IANAは他の拡大に静かに使用されるコード・ポイントを割り当てます。 異なった拡大は衝突するでしょう。

   This gets in the way of the main purpose of standards; namely, to
   facilitate interoperable implementations.

これは規格の主な目的の邪魔をします。 すなわち、共同利用できる実装を容易にするために。

   It is easy to say that pre-RFC implementations should be kept private
   and should not be deployed; however, both the length of the standards
   process and the immense value of early implementations and early
   deployments suggest finding a better solution.  As an example, in the
   case of documents produced by Working Groups in the Routing Area, a
   pre-RFC implementation is highly desirable and sometimes even
   required, and early deployments provide useful feedback on the
   technical and operational quality of the specification.

プレRFC実装が個人的に保たれるべきであり、配布されるべきでないと言うのは簡単です。 しかしながら、標準化過程の長さと早めの実装の莫大な値と早めの展開の両方が、良い解決策を見つけるのを示します。 例として、プレRFC実装が、ルート設定AreaでWorking Groupsによって製作されたドキュメントの場合では、非常に望ましくて、時々必要でさえあります、そして、早めの展開は仕様の技術的で操作上の品質の役に立つフィードバックを提供します。

   This memo proposes that, under strictly controlled circumstances,
   IANA make an early allocation of code points.  The memo lays out the
   conditions for early allocation, as well as the process to be
   followed; it also says how these allocations are dealt with in the
   event of a failure in the process (such as the RFC not being
   published).

このメモは、IANAが厳密に制御された状況でコード・ポイントの早めの配分をするよう提案します。 メモは続かれるように早めの配分、およびプロセスのための状態を広げます。 また、それはこれらの配分が失敗の場合、プロセス(発行されないRFCなどの)でどう対処されているかを示します。

   This memo only addresses the early allocation of code points from
   spaces whose allocation policy is "Standards Action" [2434] AND that
   have been amended to permit early allocation.  This permission must
   be granted by the IESG, and code spaces with permission for early
   allocation must be marked as such in the IANA registry.

このメモは配分方針が「規格動作」[2434]であり、早めの配分を可能にするために修正された空間からのコード・ポイントの早めの配分を扱うだけです。 IESGはこの許可を与えなければなりません、そして、早めの配分のための許可があるコード空間はIANA登録にそういうものとして示されなければなりません。

2.  Conditions for Early Allocation

2. 早めの配分のための状態

   The following conditions must hold before a request may be made for
   early allocation of code points:

コード・ポイントの早めの配分のために要求をするかもしれない前に以下の条件は成立しなければなりません:

   a) The code points must be from a space designated as "Standards
      Action", amended by IESG approval to permit Early Allocation.

a) コード・ポイントは「規格動作」がEarly Allocationを可能にするためのIESG許可で修正したので指定されたスペースから来ているに違いありません。

   b) The format, semantics, processing, and other rules related to
      handling the protocol entities defined by the code points
      (henceforth called "specifications") must be adequately described
      in an Internet draft that is proposed as Standards Track.

b) Standards Trackとして提案されるインターネット草稿でプロトコル実体がコード・ポイントで定義した取り扱いに関連する形式、意味論、処理、および他の規則(今後は、「仕様」と呼ばれる)について適切に説明しなければなりません。

Kompella & Zinin         Best Current Practice                  [Page 2]

RFC 4020        Early Allocation of Standard Code Points   February 2005

標準のコードのKompellaとジニン最も良い現在の習慣[2ページ]RFC4020の早めの配分は2005年2月に指します。

   c) The specifications of these code points must be stable; i.e., if
      there is a change, implementations based on the earlier and later
      specifications must be seamlessly interoperable.

c) これらのコード・ポイントの仕様は安定しているに違いありません。 すなわち、変化があれば、より初期の、そして、より遅い仕様に基づく実装はシームレスに共同利用できなければなりません。

   d) There is sufficient interest in early (pre-RFC) implementation and
      deployment in the community.

d) 早め(プレRFC)の実装と展開への十分な関心が共同体にあります。

   If conditions (a) or (b) are not met, then the processes in this memo
   do not apply.

条件(a)か(b)が満たされないなら、このメモによるプロセスは適用されません。

3.  Process for Early Allocation

3. 早めの配分には、処理してください。

   There are three processes associated with early allocation: making
   the request for code points; following up on the request; and
   revoking an early allocation.  It cannot be emphasized enough that
   these processes must have a minimal impact on IANA itself, or they
   will not be feasible.

早めの配分に関連している3つのプロセスがあります: コードを求める要求をするのは指します。 要求のときに、追求します。 そして、早めの配分を取り消すこと。 それをこれらのプロセスがIANA自身に最小量の影響力を持たなければならない、さもなければ、可能にならないくらいには強調できません。

   The processes described below assume that the document in question is
   the product of an IETF Working Group.  If this is not the case,
   replace "WG chairs" below with "shepherding Area Director".

以下で説明されたプロセスは、問題のドキュメントがIETF作業部会の製品であると仮定します。 これがそうでないなら、「WGいす」を以下に「Areaディレクターを導きます」に取り替えてください。

3.1.  Request

3.1. 要求

   The process for requesting and obtaining early allocation of code
   points is as follows:

コード・ポイントの早めの配分を要求して、得るためのプロセスは以下の通りです:

   1) The authors (editors) of the document submit a request for early
      allocation to the Working Group chairs, specifying which code
      points require early allocation and which document they should be
      assigned to.

1) ドキュメントの作者(エディタ)は早めの配分を求める要求を作業部会いすに提出します、どのコード・ポイントが早めの配分を必要とするか、そして、それらがどのドキュメントに割り当てられるべきであるかを指定して。

   2) The WG chairs determine whether the conditions for early
      allocations described in section 2 are met; particularly,
      conditions (c) and (d).

2) WGいすは、セクション2で説明された早めの配分のための条件が満たされるかどうかと決心しています。 特に状態(c)と(d)。

   3) The WG chairs gauge whether there is consensus within the WG that
      early allocation is appropriate in the case of the given document.

3) WGいすは、早めの配分が与えられたドキュメントの場合で適切であるというWGの中のコンセンサスがあるかどうかを測ります。

   4) If it is, with the approval of the Area Director(s), the WG chairs
      request IANA to make an early allocation.

4) それがAreaディレクターの承認をもってあるなら、WGいすは、早めの配分をするようIANAに要求します。

   5) IANA makes an allocation from the appropriate registry, marking it
      as "temporary", valid for a period of one year from the date of
      allocation.  The date of allocation should also be recorded in the
      registry and made visible to the public.

5) IANAは適切な登録から配分をします、「一時的である」としてそれをマークして、1年間配分の日付から、有効です。 また、配分の日付を登録に記録して、公衆にとって目に見えるようにするべきです。

Kompella & Zinin         Best Current Practice                  [Page 3]

RFC 4020        Early Allocation of Standard Code Points   February 2005

標準のコードのKompellaとジニン最も良い現在の習慣[3ページ]RFC4020の早めの配分は2005年2月に指します。

   Note that Internet Drafts should not include a specific value of a
   code point until this value has been formally allocated by IANA.

この値がIANAによって正式に割り当てられるまでインターネットDraftsがコード・ポイントの特定の値を含んでいるはずがないことに注意してください。

3.2.  Follow-Up

3.2. フォローアップ

   It is the responsibility of the document authors and the Working
   Group chairs to review changes in the document, and especially in the
   specifications of the code points for which early allocation was
   requested, to ensure that the changes are backward compatible.

ドキュメント、および特に早めの配分が変化が後方にあるのを保証するよう要求されたコード・ポイントの仕様に基づく変化を見直すのは、ドキュメント作者と作業部会いすの責任です。互換性がある。

   If at some point changes that are not backward compatible are
   nonetheless required, a decision needs to be made as to whether
   previously allocated code points must be deprecated (see section 3.3
   for more information on code point deprecation).  The considerations
   include aspects such as the possibility of existing deployments of
   the older implementations and, hence, the possibility for a collision
   between older and newer implementations in the field.

いくつかの後方でないポイント変化で互換性があるのは、以前に割り当てられたコードが指すかどうかに関して作られるべき必要性が推奨しないに違いないという(コードポイント不賛成の詳しい情報に関してセクション3.3を見ます)それにもかかわらず、必要なa決定です。 問題は、より古い実装の既存の展開の可能性やしたがって、その分野の、より古くて、より新しい実装の間の衝突のための可能性などの局面を含んでいます。

   If the document progresses to the point at which IANA normally makes
   code point allocations, it is the responsibility of the authors and
   the WG chairs to remind IANA that there were early allocations, and
   of the code point values so allocated, in the IANA Considerations
   section of the RFC-to-be.  Allocation is then just a matter of
   removing the "temporary" tag from the allocation description.

ドキュメントがIANAが通常コードポイント配分をするポイントに進んでいるなら、それは配分が早くあったのをIANAに思い出させる作者とWGいす、およびしたがって値が割り当てたコード・ポイントの責任です、未来のRFCのIANA Considerations部で。 そして、配分はただ配分記述から「一時的な」タグを取り除く問題です。

3.3.  Expiry

3.3. 満期

   If early allocations expire before the document progresses to the
   point where IANA normally makes allocations, the authors and WG
   chairs may follow an abbreviated version of the process in section
   3.1 to request renewal of the code points.  At most, one renewal
   request may be made; thus, authors should choose carefully when the
   original request is to be made.

ドキュメントがIANAが通常配分をするポイントに進む前に早めの配分が期限が切れるなら、作者とWGいすは、コード・ポイントの更新を要求するためにセクション3.1でプロセスの簡略版に従うかもしれません。 1つの更新要求を高々、するかもしれません。 したがって、作者は、オリジナルの要求がいつ作られるかことであることを慎重に選ぶべきです。

   As an exception to the above rule, under rare circumstances, more
   than one allocation renewal may be justified.  All such renewal
   requests must be reviewed by the IESG.  The renewal request to the
   IESG must include the reasons why such renewal is necessary, and the
   WG's plans regarding the specification.

上の規則への例外として、まれな状況で、1つ以上の配分更新が正当化されるかもしれません。 IESGはそのようなすべての更新要求を再検討しなければなりません。 IESGへの更新要求はそのような更新が必要である理由、および仕様に関するWGのプランを含まなければなりません。

   If a follow-up request is not made, or the document fails to progress
   to a Standards Track RFC, the WG chairs are responsible for informing
   IANA that the code points are to be marked "deprecated" (and are not
   to be allocated).  The WG chairs are further responsible for
   informing IANA when the deprecated code points can be completely de-
   allocated (i.e., made available for new allocations).

追跡している要求をしないか、またはドキュメントがStandards Track RFCに進んでいないなら、コード・ポイントが「推奨しない」とマークされる(割り当ててはいけなくなってください)ことであることをIANAに知らせるのにWGいすは責任があります。 いつ反-推奨しないコード・ポイントを完全に割り当てることができるかを(すなわち、新しい配分に利用可能に作られています)IANAに知らせるのにWGいすはさらに責任感が強いです。

Kompella & Zinin         Best Current Practice                  [Page 4]

RFC 4020        Early Allocation of Standard Code Points   February 2005

標準のコードのKompellaとジニン最も良い現在の習慣[4ページ]RFC4020の早めの配分は2005年2月に指します。

   In particular, it is not IANA's responsibility to track the status of
   allocations, their expiration, or when they may be re-allocated.

配分、彼らの満了の状態かそれともそれらがいつ再割当てされるかもしれないかを追跡するのは、特に、IANAの責任ではありません。

   Note that if a document is submitted for review to the IESG and at
   the time of submission some early allocations are valid (not
   expired), these allocations should not be expired while the document
   is under IESG consideration or waiting in the RFC Editor's queue
   after approval by the IESG.

レビューのためにIESGにドキュメントを提出して、いくつかの早めの配分が服従時点で有効であるなら(吐き出されません)、IESGの考慮かIESGによる承認の後にRFC Editorの待ち行列で待つ下にドキュメントがある間これらの配分が吐き出されるべきでないことに注意してください。

4.  IANA Considerations

4. IANA問題

   This document defines procedures for early allocation of code points
   in the registries with the Standards Action policy and as such
   directly affects IANA functions.

このドキュメントは、Standards Action方針で登録でのコード・ポイントの早めの配分のための手順を定義して、そういうものとして直接IANA機能に影響します。

5.  Normative References

5. 引用規格

   [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998.

[2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

6.  Security Considerations

6. セキュリティ問題

   It is important to keep in mind 'denial of service' attacks on IANA
   as a result of the processes in this memo.  There are two that are
   immediately obvious: depletion of code space by early allocations and
   process overloading of IANA itself.  The processes described here
   attempt to alleviate both of these, but they should be subject to
   scrutiny to ensure this.

'サービスの否定'がこのメモによるプロセスの結果、IANAで攻撃されるのを覚えておくのは重要です。 すぐに明白な2があります: 早めの配分によるコードスペースの減少とIANA自身のプロセス積みすぎ。 ここで説明されたプロセスは、これらの両方を軽減するのを試みますが、それらは、これを確実にするために精査をなることがあるべきです。

7.  Acknowledgements

7. 承認

   Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their
   input.

彼らの入力のためにバートWijnen、エードリアン・ファレル、およびビル・フェナーをありがとうございます。

Kompella & Zinin         Best Current Practice                  [Page 5]

RFC 4020        Early Allocation of Standard Code Points   February 2005

標準のコードのKompellaとジニン最も良い現在の習慣[5ページ]RFC4020の早めの配分は2005年2月に指します。

Authors' Addresses

作者のアドレス

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089 USA

Kireeti Kompella杜松は1194N.マチルダ・Aveカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。

   EMail:  kireeti@juniper.net

メール: kireeti@juniper.net

   Alex Zinin
   Alcatel
   701 E Middlefield Rd
   Mountain View, CA 94043

アレックスジニンアルカテル701E Middlefield第マウンテンビュー、カリフォルニア 94043

   EMail: zinin@psg.com

メール: zinin@psg.com

Kompella & Zinin         Best Current Practice                  [Page 6]

RFC 4020        Early Allocation of Standard Code Points   February 2005

標準のコードのKompellaとジニン最も良い現在の習慣[6ページ]RFC4020の早めの配分は2005年2月に指します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Kompella & Zinin         Best Current Practice                  [Page 7]

KompellaとジニンBest現在の習慣[7ページ]