RFC3932 日本語訳

Network Working Group                                      H. Alvestrand
Request for Comments: 3932                                  October 2004
BCP: 92
Updates: 3710, 2026
Category: Best Current Practice

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3932 2004年10月のBCP: 92のアップデート: 3710、2026カテゴリ: 最も良い現在の習慣

             The IESG and RFC Editor Documents: Procedures

IESGとRFCエディタドキュメント: 手順

Status of this Memo

この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 (2004).

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

Abstract

要約

   This document describes the IESG's procedures for handling documents
   submitted for RFC publication via the RFC Editor, subsequent to the
   changes proposed by the IESG at the Seoul IETF, March 2004.

このドキュメントはRFC公表のためにRFC Editorを通して提出された取り扱いドキュメントのためにIESGの手順について説明します、ソウルIETF(2004年3月)のIESGによって提案された変化に、その後です。

   This document updates procedures described in RFC 2026 and RFC 3710.

このドキュメントはRFC2026とRFC3710で説明された手順をアップデートします。

1.  Introduction and History

1. 序論と歴史

   There are a number of different methods by which an RFC is published,
   some of which include review in the Internet Engineering Task Force
   (IETF), and some of which include approval by the Internet
   Engineering Steering Group (IESG):

RFCが発行される多くの異なった方法があります、それのどれがインターネット・エンジニアリング・タスク・フォースでのレビューを含むかに関する(IETF)、および或るものがインターネットEngineering Steering Group(IESG)による承認を含んでいるいくつか:

   o  IETF Working Group (WG) to Standards Track: Includes WG consensus,
      review in the IETF, IETF Last Call, and IESG approval

o 規格へのIETF作業部会(WG)は追跡します: WGコンセンサス、IETF、IETF Last Call、およびIESG承認におけるレビューを含んでいます。

   o  IETF WG to Experimental/Informational: Includes WG consensus,
      review in the IETF, and IESG approval

o 実験的であるか情報へのIETF WG: WGコンセンサス、IETF、およびIESG承認におけるレビューを含んでいます。

   o  Area Director (AD) sponsored to Standards Track: Includes review
      in the IETF, IETF Last Call, and IESG approval

o Standards Trackに後援された領域のディレクター(AD): IETF、IETF Last Call、およびIESG承認におけるレビューを含んでいます。

   o  AD Sponsored Individual to Experimental/Informational: Includes
      some form of review in the IETF and IESG approval

o ADは実験的であるか情報に個人を後援しました: IETFとIESG承認における、何らかの形式のレビューを含んでいます。

   o  Documents for which special rules exist

o 特別な規則が存在するドキュメント

Alvestrand               Best Current Practice                  [Page 1]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[1ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

   o  RFC Editor documents to Experimental/Informational

o Experimental/情報へのRFC Editorドキュメント

   This memo is only concerned with the IESG processing of the last
   category.

このメモは最後のカテゴリのIESG処理に関係があるだけです。

   Special rules apply to some documents, including documents from the
   Internet Architecture Board (IAB), April 1st RFCs, and republication
   of documents from other standards development organizations.  The
   IESG and the RFC Editor keep a running dialogue, in consultation with
   the IAB, on these other documents and their classification, but they
   are outside the scope of this memo.

特別な規則はいくつかのドキュメントに適用されます、他の規格開発組織からのインターネット・アーキテクチャ委員会(IAB)、4月1日のRFCs、およびドキュメントの再刊からのドキュメントを含んでいて。 IESGとRFC Editorは走行対話を保ちます、IABとの相談で、これらの他のドキュメントと彼らの分類に関して、しかし、このメモの範囲の外にそれらはあります。

   For the last few years, the IESG has reviewed all RFC Editor
   documents (documents submitted by individuals to the RFC Editor for
   RFC publication) before publication.  In 2003, this review was often
   a full-scale review of technical content, with the ADs attempting to
   clear points with the authors, stimulate revisions of the documents,
   encourage the authors to contact appropriate working groups and so
   on.  This was a considerable drain on the resources of the IESG, and
   since this is not the highest priority task of the IESG members, it
   often resulted in significant delays.

ここ数年間、IESGは公表の前のすべてのRFC Editorドキュメント(RFC公表のために個人によってRFC Editorに提出されたドキュメント)を再検討しています。 2003年に、しばしばこのレビューは技術的な内容の実物大のレビューでした、ADsが、作者と共にポイントをきれいにするのを試みていてドキュメントの改正を刺激してください、そして、作者が適切なワーキンググループなどに連絡するよう奨励してください。 これがIESGに関するリソースへのかなりの負担であり、これ以来IESGメンバーの最優先タスクでない、それはしばしば重要な遅れをもたらしました。

   In March 2004, the IESG decided to make a major change in this review
   model.  The new review model will have the IESG take responsibility
   ONLY for checking for conflicts between the work of the IETF and the
   documents submitted; soliciting technical review is deemed to be the
   responsibility of the RFC Editor.  If an individual IESG member
   chooses to review the technical content of the document and finds
   issues, that member will communicate these issues to the RFC Editor,
   and they will be treated the same way as comments on the documents
   from other sources.

2004年3月に、IESGは、このレビューモデルにおける大きな変化を作ると決めました。 新しいレビューモデルはIESGにIETFの仕事と提出されたドキュメントの間で闘争がないかどうかチェックするだけに取らせるでしょう責任を。 技術審査に請求するのはRFC Editorの責任であると考えられます。 個々のIESGメンバーがドキュメントの技術的な中身を見直すのを選んで、問題を見つけると、そのメンバーはこれらの問題をRFC Editorに伝えるでしょう、そして、それらは同じように他のソースからのドキュメントのコメントとして扱われるでしょう。

   Note: This document describes only the review process done by the
   IESG when the RFC Editor requests that review.  There are many other
   interactions between document editors and the IESG for instance, an
   AD may suggest that an author submit a document as input for work
   within the IETF rather than to the RFC Editor, or the IESG may
   suggest that a document submitted to the IETF is better suited for
   submission to the RFC Editor but these interactions are not described
   in this memo.

以下に注意してください。 このドキュメントはRFC Editorがそのレビューを要求するとIESGによって行われた吟味の過程だけを説明します。 IESGは、ドキュメントエディタと例えば、IESGとの他の多くの相互作用があるか、ADが、RFC EditorにというよりむしろIETFの中の仕事のために入力されるように作者がドキュメントを提出するのを示すか、またはIETFに提出されたドキュメントがRFC Editorへの服従に合うほうがよいのですが、これらの相互作用がこのメモで説明されないのを示すかもしれません。

2.  Background Material

2. バックグラウンドの材料

   The review of independent submissions by the IESG was prescribed by
   RFC 2026 [1] section 4.2.3.  The procedure described in this document
   is compatible with that description.

IESGによる独立している差出のレビューはRFC2026[1]部4.2の.3定められました。 本書では説明された手順はその記述と互換性があります。

Alvestrand               Best Current Practice                  [Page 2]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[2ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

   RFC 3710 [4] section 5.2.2 describes the spring 2003 review process
   (even though the RFC was published in 2004); with the publication of
   this document, the procedure described in RFC 3710 is no longer
   relevant to documents submitted via the RFC Editor.

RFC3710[4]部5.2 .2 2003年春の吟味の過程(RFCは2004年に発行されましたが)を説明します。 このドキュメントの公表で、RFC3710で説明された手順はもうRFC Editorを通して提出されたドキュメントに関連していません。

3.  Detailed Description of IESG Review

3. IESGレビューの詳述

   The RFC Editor reviews submissions for suitability for publications
   as RFC.  Once the RFC Editor thinks a document may be suited for RFC
   publication, the RFC Editor asks the IESG to review the documents for
   conflicts with the IETF standards process or work done in the IETF
   community.

RFC EditorはRFCとして刊行物への適合のための差出を見直します。 RFC Editorが、ドキュメントがRFC公表に合うかもしれないといったん思うと、RFC Editorは、IETF標準化過程かIETF共同体で仕事をするとの闘争のためのドキュメントを再検討するようにIESGに頼みます。

   The review is initiated by a note from the RFC Editor specifying the
   document name, the RFC Editor's belief about the document's present
   suitability for publication, and (if possible) the list of people who
   have reviewed the document for the RFC Editor.

レビューは注意によってドキュメント名を指定するRFC Editor、公表へのドキュメントの現在の適合に関するRFC Editorの信念、および(できれば)RFC Editorのためのドキュメントを再検討した人々のリストから開始されます。

   The IESG may return five different responses, any of which may be
   accompanied by an IESG note to be put on the document if the RFC
   Editor wishes to publish.

IESGは5つの異なった応答を返すかもしれません。RFC Editorが発行したいなら、そのいずれもIESG注意によって伴われて、ドキュメントに置かれるかもしれません。

   1. The IESG has not found any conflict between this document and IETF
      work.

1. IESGはこのドキュメントとIETF仕事との少しの闘争も見つけていません。

   2. The IESG thinks that this work is related to IETF work done in WG
      <X>, but this does not prevent publishing.

2. IESGは、この仕事がWG<X>で行われたIETF仕事に関連すると思いますが、これは、発行するのを防ぎません。

   3. The IESG thinks that publication is harmful to the IETF work done
      in WG <X> and recommends not publishing the document at this time.

3. IESGは、公表がWG<X>で行われたIETF仕事に有害であると思って、このときドキュメントを発表することを勧めません。

   4. The IESG thinks that this document violates IETF procedures for
      <X> and should therefore not be published without IETF review and
      IESG approval.

4. IESGをこのドキュメントが<X>のためにIETF手順に違反すると考えて、したがって、IETFレビューとIESG承認なしで発行するべきではありません。

   5. The IESG thinks that this document extends an IETF protocol in a
      way that requires IETF review and should therefore not be
      published without IETF review and IESG approval.

5. IESGをこのドキュメントがIETFレビューを必要とする方法でIETFプロトコルを広げると考えて、したがって、IETFレビューとIESG承認なしで発行するべきではありません。

   The last two responses are included respectively, for the case where
   a document attempts to take actions (such as registering a new URI
   scheme) that require IETF consensus or IESG approval (as these terms
   are defined in RFC 2434 [2]), and for the case where an IETF protocol
   is proposed to be changed or extended in an unanticipated way that
   may be harmful to the normal usage of the protocol, but where the
   protocol documents do not explicitly say that this type of extension
   requires IETF review.

最後の2つの応答がそれぞれ含まれています、ドキュメントがIETFコンセンサスかIESG承認を必要とする動作(新しいURI計画を登録などなどの)で取るのを試みるケースのために。(これらの用語がRFC2434[2])で定義される、およびIETFプロトコルがプロトコルの正常な用法に有害であるかもしれない思いがけない方法で変えるか、または広げるために提案されますが、プロトコルドキュメントが明らかにそれを書かないケースのために、このタイプの拡張子はIETFレビューを必要とします。

Alvestrand               Best Current Practice                  [Page 3]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[3ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

   If a document requires IETF review, the IESG will offer the author
   the opportunity to ask for publication as an AD-sponsored individual
   document, which is subject to full IESG review, including possible
   assignment to a WG or rejection.  Redirection to the full IESG review
   path is not a guarantee that the IESG will accept the work item, or
   even that the IESG will give it any particular priority; it is a
   guarantee that the IESG will consider the document.

ドキュメントがIETFレビューを必要とすると、IESGはADで後援された個々の文献として公表を求める機会を作者に提供するでしょう、WGか拒絶に可能な課題を含めて。個々の文献は完全なIESGレビューを受けることがあります。 完全なIESGレビュー経路へのリダイレクションはIESGが仕事商品を受け入れるか、またはIESGがそれを少しも特定の優先さえさせるという保証ではありません。 それはIESGがドキュメントを考えるという保証です。

   The IESG will normally have review done within 4 weeks from the RFC
   Editor's notification.  In the case of a possible conflict, the IESG
   may contact a WG or a WG chair for an outside opinion of whether
   publishing the document is harmful to the work of the WG and, in the
   case of a possible conflict with an IANA registration procedure, the
   IANA expert for that registry.

通常、IESGはRFC Editorの通知から4週間以内にレビューさせるでしょう。 可能な闘争の場合では、IESGはドキュメントを発表するのがWGの仕事に有害であるかどうかに関する外の意見とIANA登録手順との可能な闘争に関するケースのIANA専門家のためにWGかWGいすにその登録へ連絡するかもしれません。

   Note that if the IESG has not found any conflict between a submission
   and IETF work, then judging its technical merits, including
   considerations of possible harm to the Internet, will become the
   responsibility of the RFC Editor.  The IESG assumes that the RFC
   Editor, in agreement with the IAB, will manage mechanisms for
   additional technical review.

IESGが服従とIETF仕事との少しの闘争も見つけていないなら可能な害の問題をインターネットに含む技術的な長所を判断するのがRFC Editorの責任になることに注意してください。 IESGは、RFC Editorが追加技術審査のためにIABに合意してメカニズムを管理すると仮定します。

4.  Standard IESG Note

4. 標準のIESG注意

   One of the following IESG notes will be sent to the RFC Editor for
   all documents, with a request for placement either in or immediately
   following the "Status of this Memo" section of the finished RFC,
   unless the IESG decides otherwise:

すべてのドキュメントのために以下のIESG注意の1つをRFC Editorに送るでしょう、プレースメントを求める要求が中かすぐに完成RFCの「このMemoの状態」セクションに従っていて、IESGが別の方法で決めない場合:

   1. For documents that specify a protocol or other technology, and
      that have been considered in the IETF at one time:

1. プロトコルか他の技術と、それを指定するドキュメントに関しては、ひところ、IETFで考えられてください、そうした:

      The content of this RFC was at one time considered by the IETF,
      and therefore it may resemble a current IETF work in progress or a
      published IETF work.  This RFC is not a candidate for any level of
      Internet Standard.  The IETF disclaims any knowledge of the
      fitness of this RFC for any purpose and in particular notes that
      the decision to publish is not based on IETF review for such
      things as security, congestion control, or inappropriate
      interaction with deployed protocols.  The RFC Editor has chosen to
      publish this document at its discretion.  Readers of this RFC
      should exercise caution in evaluating its value for implementation
      and deployment.  See RFC 3932 for more information.

このRFCの内容はひところIETFによって考えられました、そして、したがって、それは進行中の現在のIETF仕事か発行されたIETF仕事に類似するかもしれません。 このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このRFCの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。

Alvestrand               Best Current Practice                  [Page 4]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[4ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

   2. For documents that specify a protocol or similar technology and
      are independent of the IETF process:

2. プロトコルか同様の技術を指定している、IETFから独立しているドキュメントに関しては、処理してください:

      This RFC is not a candidate for any level of Internet Standard.
      The IETF disclaims any knowledge of the fitness of this RFC for
      any purpose and in particular notes that the decision to publish
      is not based on IETF review for such things as security,
      congestion control, or inappropriate interaction with deployed
      protocols.  The RFC Editor has chosen to publish this document at
      its discretion.  Readers of this document should exercise caution
      in evaluating its value for implementation and deployment.  See
      RFC 3932 for more information.

このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。

   3. For documents that do not specify a protocol or similar
      technology:

3. プロトコルか同様の技術を指定しないドキュメントのために:

      This RFC is not a candidate for any level of Internet Standard.
      The IETF disclaims any knowledge of the fitness of this RFC for
      any purpose and notes that the decision to publish is not based on
      IETF review apart from IESG review for conflict with IETF work.
      The RFC Editor has chosen to publish this document at its
      discretion.  See RFC 3932 for more information.

このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的と発行するという決定がIETF仕事との闘争のためのIESGレビューは別としてIETFレビューに基づいていないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 詳しい情報に関してRFC3932を見てください。

5.  Examples of Cases Where Publication Is Harmful

5. 公表が有害であるケースに関する例

   This section gives a couple of examples where delaying or preventing
   publication of a document might be appropriate due to conflict with
   IETF work.  It forms part of the background material, not a part of
   the procedure.

このセクションはドキュメントの公表を遅らせるか、または防ぐのがIETF仕事との闘争のために適切であるかもしれない2、3の例を出します。 それは手順の一部ではなく、バックグラウンドの材料の一部を形成します。

   Rejected Alternative Bypass: A WG is working on a solution to a
   problem, and a participant decides to ask for publication of a
   solution that the WG has rejected.  Publication of the document will
   give the publishing party an RFC number to refer to before the WG is
   finished.  It seems better to have the WG product published first,
   and have the non-adopted document published later, with a clear
   disclaimer note saying that "the IETF technology for this function is
   X".

拒絶された代替の迂回: WGは問題の解決法に取り組んでいます、そして、関係者はWGが拒絶した解決策の公表を求めると決めます。 WGが完成している前にドキュメントの公表は言及するRFC番号を出版パーティーに与えるでしょう。 最初にWG製品を発行させて、後で非採用されたドキュメントを発表させるように、より良く思えます、「この機能のためのIETF技術はXです」と、明確な注意書き注意が言っていて。

   Example: Photuris (RFC 2522), which was published after IKE (RFC
   2409).

例: Photuris(RFC2522)。(そのPhoturisはIKE(RFC2409)の後に発行されました)。

   Inappropriate Reuse of "free" Bits: In 2003, a proposal for an
   experimental RFC was published that wanted to reuse the high bits of
   the "fragment offset" part of the IP header for another purpose.  No
   IANA consideration says how these bits can be repurposed, but the
   standard defines a specific meaning for them.  The IESG concluded

「自由な」ビットの不適当な再利用: 2003年に、実験的なRFCのための提案は別の目的のために「断片オフセット」の高いビットが分けるIPヘッダーの再利用にそんなに欲しい状態で発行されました。 どんなIANAの考慮もこれらのビットを再決意できますが、規格がそれらのためにどう特定の意味を定義するかを言いません。 IESGは結論を下しました。

Alvestrand               Best Current Practice                  [Page 5]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[5ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

   that implementations of this experiment risked causing hard-to-debug
   interoperability problems and recommended not publishing the document
   in the RFC series.  The RFC Editor accepted the recommendation.

この実現が実験されるのが、デバッグしにくい相互運用性問題を引き起こす危険を冒して、RFCシリーズでドキュメントを発表することを勧めませんでした。 RFC Editorは推薦を受け入れました。

   Note: in general, the IESG has no problem with rejected alternatives
   being made available to the community; such publications can be a
   valuable contribution to the technical literature.  However, it is
   necessary to avoid confusion with the alternatives the working group
   did adopt.

以下に注意してください。 一般に、IESGには、共同体が入手する拒絶された代替手段を問題が全くありません。 そのような刊行物は技術文献への有価約因であるかもしれません。 しかしながら、ワーキンググループが採用した代替手段への混乱を避けるのが必要です。

   The RFC series is one of many available publication channels; this
   document takes no position on the question of which documents the RFC
   series is appropriate for.  That is a matter for discussion in the
   IETF community.

RFCシリーズは多くの利用可能な公開チャネルのひとりです。 このドキュメントはRFCシリーズがどのドキュメントに関して適切かに質問の見解を全く取りません。 それはIETF共同体での議論のための問題です。

6.  IAB Statement

6. IAB声明

   In its capacity as the body that approves the general policy followed
   by the RFC Editor (see RFC 2850 [3]), the IAB has reviewed this
   proposal and supports it as an operational change that is in line
   with the respective roles of the IESG and RFC Editor.  The IAB
   continues to monitor the range of organized discussions within the
   IETF about potential adjustments to the IETF document publication
   processes (e.g., NEWTRK working group) and recognizes that the
   process described in this document, as well as other general IETF
   publication processes, may need to be adjusted in the light of the
   outcome of those discussions.

承認するボディーとしての立場では、全般的執行方針はRFC Editorで従いました。(RFC2850[3])を見てください、IABはIESGとRFC Editorのそれぞれの役割に沿ってある操作上の変化として、この提案を見直して、それを支持します。 IABは、IETFの中で潜在的調整に関してIETFドキュメント公表の過程(例えば、NEWTRKワーキンググループ)に組織化された議論の範囲をモニターし続けて、他の一般的なIETF公表の過程と同様に本書では説明された過程が、それらの議論の結果の見地から調整される必要であるかもしれないと認めます。

7.  Security Considerations

7. セキュリティ問題

   The process change described in this memo has no direct bearing on
   the security of the Internet.

このメモで説明された過程変化はインターネットのセキュリティに直接の関係を全く持っていません。

8.  Acknowledgements

8. 承認

   This document is a product of the IESG, and all its members deserve
   thanks for their contributions.

このドキュメントはIESGの製品です、そして、すべてのメンバーが彼らの貢献の感謝に値します。

   This document has been reviewed in the IETF and by the RFC Editor and
   the IAB; the IAB produced the text of section 6.  Special thanks go
   to John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt
   Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter, and all other
   IETF community members who provided valuable feedback on the
   document.

このドキュメントはIETFとRFC EditorとIABによって再検討されました。 IABはセクション6のテキストを製作しました。 特別な感謝はジョンKlensin、キース・ムーア、ピートレズニック、スコット・ブラドナー、カートZeilenga、エリオットリア、ポール・ホフマン、ブライアンCarpenter、およびドキュメントの有益なフィードバックを提供した他のすべてのIETF共同体のメンバーのものになります。

Alvestrand               Best Current Practice                  [Page 6]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[6ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

9.  References

9. 参照

9.1.  Normative Reference

9.1. 引用規格

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

9.2.  Informative References

9.2. 有益な参照

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

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

   [3]  Internet Architecture Board and B. Carpenter, Ed., "Charter of
        the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May
        2000.

[3] インターネット・アーキテクチャ委員会とB.大工(エド)、「インターネット・アーキテクチャ委員会(IAB)の憲章」(BCP39、RFC2850)は2000がそうするかもしれません。

   [4]  Alvestrand, H., "An IESG charter", RFC 3710, February 2004.

[4]Alvestrand、2004年2月のH.、「IESG特許」RFC3710。

Author's Address

作者のアドレス

   Harald Alvestrand

ハラルドAlvestrand

   EMail: harald@alvestrand.no

メール: harald@alvestrand.no

Alvestrand               Best Current Practice                  [Page 7]

RFC 3932       IESG and RFC Editor Documents: Procedures    October 2004

Alvestrandの最も良い現在の習慣[7ページ]RFC3932IESGとRFCエディタドキュメント: 手順2004年10月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

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

   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機能のための基金は現在、インターネット協会によって提供されます。

Alvestrand               Best Current Practice                  [Page 8]

Alvestrandの最も良い現在の習慣[8ページ]