RFC3932 日本語訳
3932 The IESG and RFC Editor Documents: Procedures. H. Alvestrand. October 2004. (Format: TXT=17093 bytes) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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ページ]
一覧
スポンサーリンク