RFC4693 日本語訳
4693 IETF Operational Notes. H. Alvestrand. October 2006. (Format: TXT=19268 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Alvestrand Request for Comments: 4693 Google Category: Experimental October 2006
Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4693年のGoogleカテゴリ: 実験的な2006年10月
IETF Operational Notes
IETFの操作上の注意
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
このドキュメントはIETF操作ドキュメントと無作為のウェブページより明確な取り扱い手順で使用のために倉庫として意図する新しいドキュメントシリーズについて説明します。(RFCsよりはかないのですが、それは、インターネット草稿より参照可能であるはずです)。
It proposes to establish this series as an RFC 3933 process experiment.
それは、RFC3933が実験を処理するときこのシリーズを確立するよう提案します。
Table of Contents
目次
1. Introduction ....................................................2
2. A Description of the ION Mechanism ..............................2
2.1. Properties of an ION .......................................2
2.2. ION Approval ...............................................3
2.3. Draft IONs .................................................3
2.4. The ION Store ..............................................4
3. Proposed Initial IONs ...........................................4
4. Success Criteria and Sunset Period ..............................5
5. Background and Motivation .......................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
1. 序論…2 2. イオンメカニズムの記述…2 2.1. イオンの特性…2 2.2. イオン承認…3 2.3. イオンを作成してください…3 2.4. イオンストア…4 3. 初期のイオンを提案します…4 4. 成功評価基準と日没の期間…5 5. バックグラウンドと動機…6 6. IANA問題…7 7. セキュリティ問題…8 8. 承認…8 9. 参照…8 9.1. 標準の参照…8 9.2. 有益な参照…8
Alvestrand Experimental [Page 1] RFC 4693 ION October 2006
[1ページ]RFC4693イオン2006年10月に実験的なAlvestrand
1. Introduction
1. 序論
This document describes a new document series, called the IETF Operational Notes, or IONs.
IETF Operational Notes、またはIONsが、このドキュメントが新しいドキュメントシリーズについて説明すると呼びました。
This document series is intended to capture the set of procedures that the IETF follows, but for which the RFC process is an inappropriate documentation vehicle.
このドキュメントシリーズがIETFが続きますが、RFCの過程が不適当なドキュメンテーション手段である手順のセットを得ることを意図します。
The document series defined here does not modify the IETF process rules that are defined in currently valid BCP documents.
ここで定義されたドキュメントシリーズは現在有効なBCPドキュメントで定義されるIETFプロセスルールを変更しません。
The document series is a process experiment according to RFC 3933 [RFC3933].
RFC3933[RFC3933]に従って、ドキュメントシリーズは過程実験です。
2. A Description of the ION Mechanism
2. イオンメカニズムの記述
2.1. Properties of an ION
2.1. イオンの特性
An ION is a document with a certain set of attributes ("front page
matter"). This specification does not place any limits on what else
an ION can contain.
IONはあるセットの属性(「第一面の件」)があるドキュメントです。 この仕様はIONが含むことができる他の何にどんな限界も置かないか。
An ION has the following attributes:
IONには、以下の属性があります:
o A name, which is usable as the filename of the document
o 名前。(その名前はドキュメントのファイル名として使用可能です)。
o A title
o タイトル
o A date of approval
o 承認の日付
o An identification of the body that approved this version
o このバージョンを承認したボディーの識別
The format of the document is not restricted by this document. It's suggested that there be an ION that describes expectations for ION formats.
ドキュメントの形式はこのドキュメントによって制限されません。 それは期待をIONに説明したIONが形式であったならそこにそれを示しました。
An ION is a versioned document. When a new ION is issued with the same name, it obsoletes the previous version. When one desires to retire an ION, one issues an ION saying "This document name is now obsolete".
IONはversionedドキュメントです。 新しいIONが同じ名前で発行されるとき、それは旧バージョンを時代遅れにします。 人が、IONを引退させることを望んでいるとき、1つは「このドキュメント名は現在、時代遅れです」と言うIONを発行します。
The ION name + the approval date forms a stable identifier for one particular version of an ION; once it is published, it shall never be changed, although it may be withdrawn (see below).
IONは承認の日付が安定した識別子を形成する+をIONの1つの特定のバージョンと命名します。 いったんそれを発行すると、それを引っ込めるかもしれませんが(以下を見てください)、それを決して変えないものとします。
Alvestrand Experimental [Page 2] RFC 4693 ION October 2006
[2ページ]RFC4693イオン2006年10月に実験的なAlvestrand
The properties list does not include a "category"; while the set of documents that might be IONs is extremely wide, we do not know yet which categories could make sense. The question of categories might get revisited at the end of the experiment period.
特性のリストは「カテゴリ」を含んでいません。 IONsであるかもしれないドキュメントのセットが非常に広い、私たちは、どのカテゴリが理解できるかもしれないかをまだ知っていません。 カテゴリの問題は実験の期間の終わりに再訪するかもしれません。
Procedurally, an ION has the formal authority of a statement from its approving body. This means that an ION cannot change those procedures of the IETF that are documented via the BCP series, since the BCP series represents a determination of IETF consensus.
Procedurallyに、IONには、承認しているボディーからの声明の形式的権限があります。 これは、IONがBCPシリーズで記録されるIETFのそれらの手順を変えることができないことを意味します、BCPシリーズがIETFコンセンサスの決断を表すので。
2.2. ION Approval
2.2. イオン承認
An ION is always approved by some body. The IESG is granted authority by this document over the practical management of the series and the definition of detailed processes and rules associated with it.
IONはいつもあるボディーによって承認されます。 IESGはこのドキュメントでシリーズの実用的な管理と詳細な過程とそれに関連している規則の定義の上に権威を与えます。
The IESG, the IAB, and IAOC are given the right to approve IONs by this document. The IESG, IAB, or IAOC may decide that other groups or roles should be given the right to approve IONs.
このドキュメントでIONsを承認する権利をIESG、IAB、およびIAOCに与えます。 IESG、IAB、またはIAOCが、IONsを承認する権利が他のグループか役割に与えられるべきであると決めるかもしれません。
The ION-approving groups are expected to issue IONs related to their own areas of responsibility, and to use common sense when IONs are needed where it isn't obvious who's responsible for them.
IONsがだれが彼らに責任があるかが、明白でないところで必要であるときに、IONを承認しているグループは、それら自身の責任の領域に関連するIONsを発行して、常識を使用すると予想されます。
An updated ION will normally be approved by the same body that approved the previous version, or by another body with the approval of the previously-approving body. In case of conflict, or when the previous body no longer exists, the IESG will decide who gets to approve an updated ION.
通常、アップデートされたIONは旧バージョンを承認した同じボディー、または以前に承認しているボディーの承認がある別のボディーによって承認されるでしょう。 IESGは、前のボディーが闘争の場合にはもう存在しないという場合にだれが、アップデートされたIONを承認し始めるかを決めるでしょう。
A decision by any other body than the IESG to approve an ION can be appealed to the IESG, in which case the IESG can nullify the approval. A decision of the IESG can be appealed using the common IETF appeals procedure, except that an IESG decision to nullify an IAB decision to approve an ION cannot be appealed to the IAB.
IONを承認するIESGよりいかなる他のボディーによる決定もIESGに上告できます、その場合、IESGは承認を無効にすることができます。 一般的なIETF上告手順を用いることでIESGの決定を上告できます、IONを承認するというIAB決定を無効にするというIESG決定をIABに上告できないのを除いて。
In the case that the IESG ceases to exist, its successors or assignees will take over the tasks given to the IESG in this document.
IESGが消滅して、その後継者か指定代理人が本書ではIESGに与えられたタスクを引き継ぐでしょう。
2.3. Draft IONs
2.3. 草稿イオン
There is no requirement that an ION will be published as a draft before publication. This will, however, be desirable in many cases, and thus, this document describes the properties and procedures for handling draft IONs.
IONが公表の前に草稿として発行されるという要件が全くありません。 しかしながら、多くの場合、これは望ましくなるでしょう、そして、その結果、このドキュメントは取り扱い草稿IONsのために特性と手順について説明します。
Alvestrand Experimental [Page 3] RFC 4693 ION October 2006
[3ページ]RFC4693イオン2006年10月に実験的なAlvestrand
Draft IONs shall have, instead of an approval date and an identification of the body that approved it, information about:
草稿IONsには、それを承認したボディーの承認の日付と識別の代わりに以下に関して情報があるものとします。
o The word "DRAFT", prominently displayed
o 「草稿」が顕著に表示したという単語
o The publication date and time
o 公表日時
o The approval date of the document it is intended to update (if
any)
o アップデートすることを意図するドキュメントの承認の日付(もしあれば)
o The body that is intended to approve this version
o このバージョンを承認することを意図するボディー
o The appropriate forum for discussion of this draft (if any)
o この草稿の議論のための適切なフォーラム(もしあれば)
2.4. The ION Store
2.4. イオンストア
All approved IONs are archived, in all their versions, and made publicly available from resources operated by the IETF secretariat. The store should be reachable by common methods like HTTP and FTP, and should offer both easy access to the "current" version of all IONs and bulk download of all IONs, all versions.
すべての承認されたIONsを彼らのすべてのバージョンに格納して、IETF事務局によって運用されたリソースから利用可能に公的にします。 店は、HTTPとFTPのような共通方法で届くべきであり、すべてのIONsの「現在」のバージョンへの簡単なアクセスとすべてのIONsの大量のダウンロードの両方を提供するはずです、すべてのバージョン。
This document does not constrain the form of the ION Store, but mandates that there be a public one.
このドキュメントは、IONストアのフォームを抑制しませんが、公衆が1歳であったならそこでそれを強制します。
Public draft IONs are published separately from the approved IONs. Old versions may be published in the draft store and must be kept in a version management system for the duration of the experiment. Experience will show what the best policy for draft retention is if the series is made permanent.
公共の草稿IONsは別々に承認されたIONsから発行されます。 古いバージョンを草稿店で発行されるかもしれなくて、実験の持続時間のバージョン管理システムに保たなければなりません。 経験は、シリーズであるなら草稿保有のための最善の策がものであることを永久的にするのを示すでしょう。
3. Proposed Initial IONs
3. 提案された初期のイオン
The following IONs should be created as soon as possible after this document is published, to give the details of the maintenance of the ION series, in order to bootstrap the process:
このドキュメントがIONシリーズの維持の詳細を明らかにするために発表された後に以下のIONsはできるだけ早く作成されるべきです、過程を独力で進むために:
o The ION Format Guide
o イオン形式ガイド
o The ION Store Description
o イオンストア記述
The following list of documents, some of which currently exist, provides examples of documents that could be converted to IONs. This is not a binding recommendation, but gives examples of what IONs can be good for.
ドキュメントの以下のリストはIONsに変換できたドキュメントに関する例を提供します。その或るものは現在、存在します。 これは、拘束力がある推薦ではありませんが、何に、IONsが良い場合があるかに関する例を出します。
o The I-D publishing procedure
o I-D出版手順
Alvestrand Experimental [Page 4] RFC 4693 ION October 2006
[4ページ]RFC4693イオン2006年10月に実験的なAlvestrand
o The checklist for I-D submission to the IESG (formerly known as
id-nits)
o IESGへのI-D服従のためのチェックリスト(以前、イド夜として知られています)
o Procedures for spam control on IETF mailing lists
o IETFメーリングリストにおけるスパム制御装置のための手順
o Procedures for requesting a WG meeting slot
o WGミーティングスロットを要求するための手順
o Procedures for IETF minutes
o IETF分間の手順
o Procedures for IESG meeting minutes
o IESG議事録のための手順
Once the ION series is permanent, the existence of the ION series may cause the following documents to be split into a "policy and principles" BCP and a "procedures and boilerplate" document published as ION:
IONシリーズがいったん永久的になると、IONシリーズの存在で、以下のドキュメントを「方針と原則」BCPとIONとして発表された「手順と決まり文句」ドキュメントに分けるかもしれません:
o IETF Rights in Documents (currently BCP 78) RFC 3978 [RFC3978]
o ドキュメント(現在のBCP78)RFC3978のIETF権利[RFC3978]
o IETF Rights in Technology (currently BCP 79) RFC 3979 [RFC3979]
o 技術(現在のBCP79)RFC3979のIETF権利[RFC3979]
o IETF mailing list management (currently RFC 3005 [RFC3005], BCP
45, RFC 3683 [RFC3683], BCP 83, and RFC 3934 [RFC3934], BCP 94)
o IETFメーリングリスト管理(現在のRFC3005[RFC3005]、BCP45、RFC3683[RFC3683]、BCP83、およびRFC3934[RFC3934]、BCP94)
If someone wishes to do such a split while the experiment is running, the BCPs cannot refer to the "procedures" documents as IONs, since the concept of an ION may go away. In that case, any procedures removed from a BCP must either be reinstated or otherwise stored as a permanently available reference.
実験が走行ですが、だれかがそのような股割りをしたいなら、BCPsは「手順」ドキュメントをIONsと呼ぶことができません、IONの概念が遠ざかるかもしれないので。 その場合、BCPから取り除かれたどんな手順も、復職しなければならないか、または別の方法で永久に利用可能な参照として格納しなければなりません。
4. Success Criteria and Sunset Period
4. 成功評価基準と日没の期間
This experiment is expected to run for a period of 12 months, starting from the date of the first ION published using this mechanism. At the end of the period, the IESG should issue a call for comments from the community, asking for people to state their agreement to one of the following statements (or a suitable reformulation thereof):
この実験がしばらく12カ月走らせると予想されます、このメカニズムを使用することで発行された最初のIONの日付から始めて。 期間の終わりに、IESGは共同体からコメントのための呼び出しを発行するはずです、人々が以下の声明(または、それの適当な再定式化)の1つへの彼らの協定を述べるように頼んで:
1. This document series has proved useful, and should be made
permanent
1. このドキュメントシリーズは有用であることが分かって、永久的にするべきです。
2. This document series is less useful than the equivalent
information in RFCs and informal Web pages, and should be
abandoned
2. このドキュメントシリーズは、RFCsの同等な情報と非公式のウェブページほど役に立たないで、捨てられるべきです。
3. We cannot decide yet; the experiment should continue
3. 私たちはまだ決めることができません。 実験は続くべきです。
Alvestrand Experimental [Page 5] RFC 4693 ION October 2006
[5ページ]RFC4693イオン2006年10月に実験的なAlvestrand
The author believes that establishing objective metrics for the success or failure of this experiment is not a worthwhile exercise; the success or failure will be readily apparent in the community's attitudes towards the series.
作者は、この実験の成否のために客観的な測定基準を確立するのが、価値がある運動でないと信じています。 成否はシリーズに対する共同体の態度で容易に明らかになるでしょう。
If the feedback reveals a community consensus for keeping the series, the IESG may choose to create a new BCP RFC containing the information herein, suitably modified by experience.
フィードバックがシリーズを保つことに関する共同体コンセンサスを顕にするなら、IESGは、経験でここに、適当に変更された情報を含む新しいBCP RFCを作成するのを選ぶかもしれません。
If the IESG decides that the feedback warrants terminating the series, the repository will be closed for new documents, and the existing ION documents will be returned to having the same status as any other Web page or file on the IETF servers -- this situation will closely resemble the situation before the experiment started.
IETFサーバのいかなる他のウェブページかファイルとも同じ状態を持っているのにIONが記録する存在を返すでしょう--IESGが、フィードバックが、シリーズを終えるのを保証すると決めると、倉庫は新しいドキュメントのために閉じられるでしょう、そして、実験が始まる前にこの状況は密接に状況に類似するでしょう。
5. Background and Motivation
5. バックグラウンドと動機
The IETF is an open organization, which means (among other things) that there are always newcomers coming in to learn how to perform work; this places a requirement on the organization to document its processes and procedures in an accessible manner.
IETFは開放組織です。(それは、仕事を実行する方法を学ぶために入る新来者が(特に)いつもいることを意味します)。 これはアクセスしやすい方法でその過程と手順を記録するという組織に関する要件を置きます。
The IETF is also a large organization, which means that when procedures change, there are a number of people who will like to know of the change, to figure out what has changed, and possibly to protest or appeal the change if they disagree with it.
また、IETFは大きな組織です。(その大きな組織は手順が変化するとき、彼らがそれと意見を異にするならことによると変化を変化を知るか、何が変化したかを理解して、異議を申し立てるか、または上告するのが好きである多くの人々がいることを意味します)。
At the present time (spring 2006), there are three kinds of documents used for IETF documentation of its operations and procedures:
現在(2006年春)に、その操作と手順のIETFドキュメンテーションに使用される3種類のドキュメントがあります:
o BCP and Informational RFCs, which require an IETF consensus call
for BCP, approval by the IESG, and usually a great deal of debate
and effort to change, and which bind up editing resources in the
final edit stage, as well as being limited (in practice) to ASCII.
The BCP number forms a means of having a stable reference for new
versions of a document, but an updated Info RFC has a completely
different identifier from the RFC that it updates; "updates/
obsoletes" links can give some of the same information, but can
also be quite confusing to follow.
o BCPとInformational RFCs。(そのInformational RFCsはBCPのためのIETFコンセンサス呼び出し、IESGによる承認、通常大きな討論、および変化するための努力を必要として、ASCIIに制限されること(実際には)と同様に最終的な編集段階でリソースを編集するのに付きます)。 BCP番号はドキュメントの新しいバージョンの安定した参照を持つ手段を形成しますが、アップデートされたInfo RFCには、それがアップデートするRFCからの完全に異なった識別子があります。 「/が時代遅れにするアップデート」リンクも、同じ情報についていくつかを与えることができますが、また、続くように全く紛らわしい場合があります。
o Web pages, which can be changed without notice, provide very
little ability to track changes, and have no formal standing --
confusion is often seen about who has the right to update them,
what the process for updating them is, and so on. It is hard when
looking at a Web page to see whether this is a current procedure,
a procedure introduced and abandoned, or a draft of a future
procedure. For certain procedures, their informal documentation
o どんな正式な地位も持たないでください--ウェブページ(予告なしで変えることができる)はほとんど変化を追う能力を前提としません、そして、だれが権利があるかに関して混乱はそれら、それらをアップデートするための過程が何であるかということであり、などをアップデートするのをしばしば見られます。 これが現在の手順、導入されて、やめられた手順、または将来の手順の草稿であるかを確認するためにウェブページを見るとき、それは困難です。 ある手順、それらの非公式のドキュメンテーションのために
Alvestrand Experimental [Page 6] RFC 4693 ION October 2006
[6ページ]RFC4693イオン2006年10月に実験的なAlvestrand
in the "IESG Guide" wiki has partially clarified this situation
but has no official status.
「IESGガイド」では、wikiはこの状況を部分的にはっきりさせましたが、どんな公式の状態も持っていません。
o "floating" Internet-Drafts, which are frequently updated, in a
trackable manner, but have no approval mechanism, are limited (in
practice) to ASCII format, and whose use as semi-permanent
documents clutters up their use as 6-month temporary working
documents.
o 「浮いている」インターネット草稿(「道-可能」方法で頻繁にアップデートしますが承認のメカニズムを全く持っていない)はASCII書式に制限されます、そして、(実際には)半永久的であるとしての使用がだれのものを記録するかが6カ月の一時的な働くドキュメントとして彼らの使用を取り散ります。
This note introduces a new series that seems to fulfil the requirements for "something in between":
この注意は「間の何か」のための要件を充足するように思える新物を紹介します:
o Unlike RFCs, they can be produced without a post-editing stage,
they can be in any format the controllers of the series choose
(allowing web pages with hyperlinks, which is an advantage for
newcomers).
o RFCsと異なって、後編集ステージなしで彼らを生産できて、シリーズのコントローラが選ぶどんな形式にも彼らがいることができます(ハイパーリンクがある新来者のための利点であるウェブページを許容して)。
o Also unlike RFCs, they can be produced by any body that the IESG
gives the right to use the mechanism; this allows certain
procedures to be updated without having to wait for the IESG
approval cycle.
o RFCsと異なっても、IESGがメカニズムを使用する権利を与えるどんなボディーも彼らを生産できます。 これは、IESG承認のサイクルの間、待つ必要はなくてある手順をアップデートするのを許容します。
o Unlike Internet-Drafts, they have an explicit approval step --
this allows a reader to easily see the difference between an idea
and an operational procedure.
o インターネット草稿と異なって、それらには、明白な承認のステップがあります--これで、読者は容易に考えと操作手順の違いを見ることができます。
o Unlike Web pages, there is an explicit mechanism for finding "all
current versions", and a mechanism for tracking the history of a
document.
o ウェブページと異なって、「すべての最新版」を見つけるための明白なメカニズム、およびドキュメントの歴史を追跡するためのメカニズムがあります。
The "author" attribute has quite deliberately been omitted from the required property list. While there may be many cases where identifying an author is a Good Thing, the responsibility for an approved ION rests with the approving body.
「作者」属性は全く故意に必要な特性のリストから省略されました。 多くのケースが作者を特定するのが、Good Thingであるところにあるかもしれませんが、承認されたIONへの責任は承認しているボディーに責任があります。
Note: This proposal is NOT intended to affect the standards track in any way -- a side effect may be to reduce the number of "process BCPs" emitted, but this has no direct bearing on the IETF's technical specifications. It is therefore not within the scope of the NEWTRK working group.
以下に注意してください。 この提案が何らかの方法で標準化過程に影響することを意図しません--副作用は放たれた「過程BCPs」の数を減少させることになっているかもしれませんが、これはIETFの技術仕様書に直接の関係を全く持っていません。 したがって、NEWTRKワーキンググループのいずれの範囲の中にもそれはありません。
6. IANA Considerations
6. IANA問題
IONs will not include protocol specifications, so IONs will make no requests for IANA actions. IANA will not need to review all IONs.
IONsがプロトコル仕様を含まないので、IONsはIANA動作を求める要求を全くしないでしょう。 IANAはすべてのIONsを見直す必要はないでしょう。
This document makes no requests of IANA either.
このドキュメントはIANAの要求も全くしません。
Alvestrand Experimental [Page 7] RFC 4693 ION October 2006
[7ページ]RFC4693イオン2006年10月に実験的なAlvestrand
7. Security Considerations
7. セキュリティ問題
IONs will not include protocol specifications, so shouldn't have much need to talk about security the way RFCs do.
IONsは、多くが、プロトコル仕様を含まないので、セキュリティに関してRFCsがそうする方法と話す必要があらせるはずがありません。
8. Acknowledgements
8. 承認
Many people have contributed over the years to the ideas that I have tried to express here.
多くの人々が数年間私がここに表そうとした考えに貢献しています。
I'm in particular indebted to John Klensin for his work on trying to find a balance between formalism and flexibility in the IETF process, and for his earlier attempts at creating such a document series as an adjunct to the "ISD" effort, and for his many valuable comments on this document.
私はIETFの過程による形式と柔軟性の間のバランスを見つけようとするとの彼の取り組み、"ISD"の努力に付属物のようなドキュメントシリーズを作成することへの彼の以前の試み、およびこのドキュメントの彼の多くの貴重なコメントのために特にジョンKlensinの世話になられます。
In addition, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam Hartman, and David Black (gen-ART reviewer) provided valuable comments at Last Call time.
さらに、デーヴ・クロッカー、スペンサー・ダウキンズ、ジェフHutzelman、サム・ハートマン、およびデヴィッドBlack(ARTに情報を得ている評論家)はLast Call時に貴重なコメントを提供しました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", BCP 93, RFC 3933, November 2004.
[RFC3933] KlensinとJ.とS.ダウキンズ、「IETF過程実験のためのモデル」、BCP93、RFC3933、2004年11月。
9.2. Informative References
9.2. 有益な参照
[RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45,
RFC 3005, November 2000.
[RFC3005] ハリス、S.、「IETFディスカッション・リスト憲章」、BCP45、RFC3005、2000年11月。
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
mailing lists", BCP 83, RFC 3683, February 2004.
[RFC3683]ローズ、M.、「IETFメーリングリストへのRevoking Posting RightsのためのPractice」、BCP83、RFC3683、2004年2月。
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the
Management of IETF Mailing Lists", BCP 94, RFC 3934,
October 2004.
[RFC3934] ワッサーマン、M.、「IETFメーリングリストの管理に関するRFC2418へのアップデート」、BCP94、RFC3934、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] ブラドナー、S.、「IETF技術による知的所有権」、BCP79、RFC3979、2005年3月。
Alvestrand Experimental [Page 8] RFC 4693 ION October 2006
[8ページ]RFC4693イオン2006年10月に実験的なAlvestrand
Author's Address
作者のアドレス
Harald Tveit Alvestrand Google Beddingen 10 N-7014 Trondheim Norway
ハラルドTveit Alvestrand Google Beddingen10N-7014トロンヘイムノルウェー
EMail: harald@alvestrand.no
メール: harald@alvestrand.no
Alvestrand Experimental [Page 9] RFC 4693 ION October 2006
[9ページ]RFC4693イオン2006年10月に実験的なAlvestrand
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Alvestrand Experimental [Page 10]
Alvestrand実験的です。[10ページ]
一覧
スポンサーリンク
