RFC 4450 - Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4450
タイトル : RFC 4450 - Cruftを取り除く：時代遅れの標準文書を特定して再分類する実験からの報告
翻訳編集 : 自動生成

[要約] RFC 4450は、古くなった標準文書を特定し再分類する実験の結果を報告しています。このRFCの目的は、ネットワーク標準の整理と更新を促進することです。

Network Working Group                                            E. Lear
Request for Comments: 4450                            Cisco Systems GmbH
Category: Informational                                    H. Alvestrand
                                                           Cisco Systems
                                                              March 2006

Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents

Cruftを取り除く：時代遅れの標準文書を特定して再分類する実験からの報告

Status of This Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic.

このメモは、今日の世界で文書化された実践を反映していないものとして提案された基準をレビューおよび分類する実験を文書化しています。結果は、現在歴史的として再分類されている提案された基準としてマークされた一連のドキュメントを特定します。

Table of Contents

   1. Introduction and History ........................................1
   2. Bulk Decommissioning Procedure ..................................2
   3. Input, Mailing list, Output, and Observations ...................2
   4. Discussion ......................................................4
   5. Next Steps ......................................................5
   6. IANA Considerations .............................................6
   7. Security Considerations .........................................6
   8. Acknowledgements ................................................6
   9. Normative References ............................................6

1. Introduction and History

1. はじめに

RFC 2026, and RFC 1602 before it, specified timelines for review of immature (draft or proposed) standards. The purpose of such review was to determine whether such documents should be advanced, retired, or developed further [1].

RFC 2026、およびその前のRFC 1602は、未熟な（ドラフトまたは提案されている）標準のレビューのためのタイムラインを指定しました。このようなレビューの目的は、そのような文書を進めたり、退職したり、さらに開発すべきかを判断することでした[1]。

This procedure has never been followed in the history of the IETF. Since this procedure has not been followed, members of the community have suggested that the retiring of a document to Historic is a significant event, which should be justified carefully -- leading to the production of documents such as RFC 2556 (OSI Connectionless Transport Services on top of UDP Applicability Statement for Historic Status) and RFC 3166 (Request to Move RFC 1403 to Historic Status).

この手順は、IETFの歴史では決して守られていません。この手順が守られていないため、コミュニティのメンバーは、歴史への文書の引退は慎重に正当化されるべきである重要なイベントであることを示唆しています。歴史的ステータスのためのUDPアプリケーションステートメントのトップ）およびRFC 3166（RFC 1403を歴史的ステータスに移動するリクエスト）。

Such documents require significant time and effort on the part of authors, area directors, and the RFC Editor.

このような文書には、著者、エリアディレクター、およびRFCエディターの側でかなりの時間と労力が必要です。

2. Bulk Decommissioning Procedure

2. バルク廃止措置手順

From the Fall of 2004 through the Spring of 2005, the authors conducted an experiment to determine how many Proposed Standards could be considered obsolete. The experiment was operated as follows:

2004年の秋から2005年の春まで、著者は、提案された基準の数を時代遅れと見なすことができるものを決定するための実験を実施しました。実験は次のように操作されました。

o Identify a group of documents that are standards. o Assume by default that each document will be retired. o Create a mailing list for discussion with a policy of open access. o Allow any document to be removed from the list of those to be retired for virtually any reason, so long as a reason is provided. o Present the list to the working group, IETF, and IESG for review. o Revise list based on comments. o Write up results.

o 標準であるドキュメントのグループを特定します。oデフォルトでは、各ドキュメントが廃止されると仮定します。oオープンアクセスのポリシーで議論するためのメーリングリストを作成します。o理由が提供されている限り、実質的に何らかの理由で廃止されるドキュメントを削除することを許可します。oレビューのために、ワーキンググループ、IETF、およびIESGにリストを提示します。oコメントに基づいてリストを修正します。o結果を書きます。

The initial intent of the authors was to present a list of documents to be reclassified as Historic. The NEWTRK working group supported this view. The IESG, and the IETF as a community, makes the final decision. We will discuss this further below.

著者の最初の意図は、歴史的として再分類される文書のリストを提示することでした。NewTrkワーキンググループはこの見解をサポートしました。IESGとコミュニティとしてのIETFは、最終決定を下します。これについては以下でさらに説明します。

3. Input, Mailing list, Output, and Observations

3. 入力、メーリングリスト、出力、および観察

We started with our initial document set being all RFCs with numbers less than 2000 and a status of Proposed Standard. The input we used, starting November 25, 2004, can be found in Appendix A. There were some 125 documents in all.

最初のドキュメントセットは、2000未満の数字と提案された標準のステータスを持つすべてのRFCであることから始めました。2004年11月25日から使用した入力は、付録Aに記載されています。全部で125のドキュメントがありました。

A mailing list, old-standards@alvestrand.no, was created to discuss and remove candidates from this list. A call for participation was issued to the IETF-Announce list on or around the November 15, 2004. There were 29 members of the mailing list. Approximately 244 messages were sent to the list. People were encouraged to consider the question of whether or not an implementer would either write a new implementation or maintain an existing one.

メーリングリスト、old-standards@alvestrand.noは、このリストから候補者について話し合い、削除するために作成されました。2004年11月15日またはその頃に、IETF-Announceリストに参加の呼びかけが発行されました。メーリングリストには29人のメンバーがいました。約244個のメッセージがリストに送信されました。人々は、実装者が新しい実装を書くか、既存の実装を維持するかどうかの問題を検討するよう奨励されました。

After some months the list of documents to be considered was reduced considerably. This list was then forwarded to the IETF discussion list on December 16, 2004, and to the NEWTRK working group list for wider review.

数か月後、考慮すべき文書のリストが大幅に削減されました。このリストは、2004年12月16日のIETFディスカッションリストと、より広いレビューのためにNewTrkワーキンググループリストに転送されました。

During review, RFCs 1518 and 1519 were removed, based on the fact that work is ongoing to revise them. Similarly, RFCs 1381, 1382, 1471, 1472, 1473, 1582, 1598, and 1755 were removed based on the belief that they were actively in use. RFC 1584 was removed based on an expected future dependency.

レビュー中、RFCS 1518および1519は、それらを修正するために作業が進行しているという事実に基づいて削除されました。同様に、RFCS 1381、1382、1471、1472、1473、1582、1598、および1755は、積極的に使用されているという信念に基づいて削除されました。RFC 1584は、予想される将来の依存関係に基づいて削除されました。

Here are the results:

結果は次のとおりです。

RFC 1234 (Tunneling IPX Traffic through IP Networks) RFC 1239 (Reassignment of Experimental MIBs to Standard MIBs) RFC 1276 (Replication and Distributed Operations Extensions to provide an Internet Directory Using X.500) RFC 1285 (FDDI Management Information Base) RFC 1314 (A File Format for the Exchange of Images in the Internet) RFC 1328 (X.400 1988 to 1984 Downgrading) RFC 1370 (Applicability Statement for OSPF) RFC 1378 (The PPP AppleTalk Control Protocol (ATCP)) RFC 1397 (Default Route Advertisement in BGP2 and BGP3 Version of the Border Gateway Protocol) RFC 1414 (Identification MIB) RFC 1415 (FTP-FTAM Gateway Specification) RFC 1418 (SNMP over OSI) RFC 1419 (SNMP over AppleTalk) RFC 1421 (Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures) RFC 1422 (Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management) RFC 1423 (Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers) RFC 1424 (Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services) RFC 1461 (SNMP MIB Extension for Multiprotocol Interconnect over X.25) RFC 1469 (IP Multicast over Token-Ring Local Area Networks) RFC 1474 (The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol) RFC 1478 (An Architecture for Inter-Domain Policy Routing) RFC 1479 (Inter-Domain Policy Routing Protocol Specification: Version 1) RFC 1494 (Equivalences between 1988 X.400 and RFC-822 Message Bodies) RFC 1496 (Rules for Downgrading Messages from X.400/88 to X.400/84) when MIME Content-types Are Present in the Messages

RFC 1234（IPネットワークを介したTunneling IPXトラフィック）RFC 1239（実験的MIBSの標準MIBSへの再割り当て）RFC 1276（X.500を使用してインターネットディレクトリを提供するためのレプリケーションおよび分散操作拡張）RFC 1285（FDDI管理情報ベース）RFC 1314（インターネット内の画像交換のためのファイル形式）RFC 1328（X.400 1988から1984格下げ）RFC 1370（OSPFのアプリケーションステートメント）RFC 1378（PPP Appletalk Control Protocol（ATCP））RFC 1397（デフォルトのルート広告でのデフォルトルート広告の広告BGP2およびBGP3バージョンのBorder Gateway Protocol）RFC 1414（識別MIB）RFC 1415（FTP-FTAMゲートウェイ仕様）RFC 1418（OSI上のSNMP）RFC 1419（AppleTalk上のSNMP）RFC 1421（インターネット電子メールのプライバシー拡張I：メッセージ暗号化と認証手順）RFC 1422（インターネット電子メールのプライバシー強化：パートII：証明書ベースのキー管理）RFC 1423（インターネット電子メールのプライバシー強化：パートIII：アルゴリズム、モード、識別子）RFC 1424（インターネット電子メールのプライバシー強化：パートIV：キー認定および関連サービス）RFC 1461（X.25を超えるマルチプロトコル相互接続のSNMP MIB拡張）ポイントツーポイントプロトコルのブリッジネットワーク制御プロトコルのオブジェクト）RFC 1478（ドメイン間ポリシールーティングのアーキテクチャ）RFC 1479（ドメイン間ポリシールーティングプロトコル仕様：バージョン1）RFC 1494（1988年の等価X。400およびRFC-822メッセージボディ）RFC 1496（X.400/88からX.400/84へのメッセージの格下げのルール）メッセージにMIMEコンテンツタイプが存在する場合

RFC 1502 (X.400 Use of Extended Character Sets) RFC 1512 (FDDI Management Information Base) RFC 1513 (Token Ring Extensions to the Remote Network Monitoring MIB) RFC 1525 (Definitions of Managed Objects for Source Routing Bridges) RFC 1552 (The PPP Internetworking Packet Exchange Control Protocol (IPXCP)) RFC 1553 (Compressing IPX Headers over WAN Media (CIPX)) RFC 1648 (Postmaster Convention for X.400 Operations) RFC 1666 (Definitions of Managed Objects for SNA NAUs using SMIv2) RFC 1692 (Transport Multiplexing Protocol (TMux)) RFC 1696 (Modem Management Information Base (MIB) Using SMIv2) RFC 1742 (AppleTalk Management Information Base II) RFC 1747 (Definitions of Managed Objects for SNA Data Link Control (SDLC) Using SMIv2) RFC 1749 (IEEE 802.5 Station Source Routing MIB using SMIv2) RFC 1763 (The PPP Banyan Vines Control Protocol (BVCP)) RFC 1764 (The PPP XNS IDP Control Protocol (XNSCP)) RFC 1828 (IP Authentication using Keyed MD5) RFC 1835 (Architecture of the WHOIS++ Service) RFC 1848 (MIME Object Security Services) RFC 1913 (Architecture of the Whois++ Index Service) RFC 1914 (How to Interact with a Whois++ Mesh)

RFC 1502（X.400拡張文字セットの使用）RFC 1512（FDDI管理情報ベース）RFC 1513（リモートネットワーク監視MIBへのトークンリング拡張機能MIBへ）RFC 1525（ソースルーティングブリッジの管理されたオブジェクトの定義）インターネットワークパケット交換制御プロトコル（IPXCP））RFC 1553（WANメディア（CIPX）上のIPXヘッダーの圧縮（CIPX））RFC 1648（X.400操作のポストマスターコンベンション）RFC 1666（SMIV2を使用したSNA NAUSの管理オブジェクトの定義）RFC 1692（輸送輸送多重化プロトコル（TMUX））RFC 1696（SMIV2を使用したモデム管理情報ベース（MIB））RFC 1742（AppleTalk Management Information Information Base II）RFC 1747（SMIV2を使用したSNAデータリンクコントロールの管理オブジェクトの定義）RFC 1749（IEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE802.5 SMIV2）RFC 1763を使用したステーションソースルーティングMIB（PPP Banyan Vines Control Protocol（BVCP））RFC 1764（PPP XNS IDPコントロールプロトコル（XNSCP））RFC 1828（Keyed MD5を使用したIP認証）RFC 1835（WHAISのアーキテクチャサービス）RFC 1848（MIMEオブジェクトセキュリティサービス）RFC 1913（WHOISインデックスサービスのアーキテクチャ）RFC 1914（WHOISメッシュと対話する方法）

One additional document, RFC 1829, the ESP DES-CBC transform, was suggested for Historic status, but in this case, the group consensus is that the community would benefit from a separate document describing the security implications of using this algorithm.

追加のドキュメントであるRFC 1829、ESP Des-CBC変換は歴史的なステータスのために提案されましたが、この場合、グループのコンセンサスは、コミュニティがこのアルゴリズムを使用することのセキュリティの意味を説明する別のドキュメントから恩恵を受けるということです。

4. Discussion

4. 考察

As one peruses this list one sees several classes of documents:

このリストを熟読すると、いくつかのクラスのドキュメントが表示されます。

o Multiprotocol functions for protocols that are obsolete, such as Appletalk or X.400. o Protocols that were defined but not used, such as PEM or Whois++

o AppleTalkやX.400など、時代遅れのプロトコルのマルチプロトコル機能。o PEMやWHOISなど、定義されたが使用されていないプロトコル

In either case above, a judgment is necessary as to whether or not a protocol is both in use and likely to be supported. The parameters of our experiment were sufficiently conservative to avoid cases where protocols were likely to continue to be supported. That is, anyone could remove a document from the list for any reason. In fact, in some cases we may have been too conservative. Thus, it is also worth considering the categories of documents that were removed from the list: o specifications known to be in full use that should be considered for advancement o specifications that are currently under review within the IETF process o Specifications that were previously considered for deprecation and rejected.

上記のいずれの場合でも、プロトコルが使用されているか、サポートされる可能性が高いかどうかについての判断が必要です。私たちの実験のパラメーターは、プロトコルが引き続きサポートされ続ける可能性がある場合を回避するために十分に保守的でした。つまり、誰でも何らかの理由でリストからドキュメントを削除できます。実際、場合によっては、保守的すぎたかもしれません。したがって、リストから削除されたドキュメントのカテゴリを検討する価値があります。O進歩を検討する必要があるo最終的に使用される必要があるo IETFプロセスo以前に検討されていたIETFプロセスo仕様o仕様o仕様を検討する価値があります。非難と拒否。

The last category is exclusive to telnet options, which were reviewed in the late 1990s. Arguably, such options should be reconsidered for deprecation. Realistically, nobody is going to develop a new version of telnet that supports the TACACS option, for instance. Nevertheless, as a first cut we were still left with 61 documents that could be reclassified.

最後のカテゴリは、1990年代後半にレビューされたTelnetオプション専用です。おそらく、そのようなオプションは非推奨のために再考する必要があります。現実的には、たとえばTACACSオプションをサポートするTelnetの新しいバージョンを開発する人はいません。それにもかかわらず、最初のカットとして、再分類できる61の文書がまだ残っていました。

In at least one case, discussion of deprecation has spurred work on documents. For instance, there is a Classless Inter-Domain Routing (CIDR) update in progress.

少なくとも1つのケースでは、非推奨の議論は文書の作業に拍車をかけました。たとえば、クラスレスドメイン間ルーティング（CIDR）アップデートが進行中です。

5. Next Steps

5. 次のステップ

As we mention in the introduction, the current process requires reconsideration of immature standards, and this review currently does not occur. This experiment has been an attempt at a procedure that could ease that review. The final step was working group consideration of what to do next. There were four options:

紹介で言及したように、現在のプロセスでは未熟な基準の再考が必要であり、このレビューは現在発生していません。この実験は、そのレビューを容易にする可能性のある手順の試みでした。最後のステップは、次に何をすべきかについてのワーキンググループの考慮事項でした。4つのオプションがありました。

1. Accept the results of this experiment, issue a last call, and deprecate standards that remain on the list past last call. This is an aggressive approach that would preserve the intent of RFC 2026. 2. Do not accept the results of this experiment and update RFC 2026 to indicate a new practice. 3. Revise the procedure based on the results of this experiment, based on feedback from the IESG. This option might take into account the different types of old standards as described above. 4. Do nothing. This would leave the IETF and the IESG practice inconsistent with documented practice.

1. この実験の結果を受け入れ、最後のコールを発行し、最後のコールを過去にリストに残している基準を非難します。これは、RFC 2026の意図を維持する積極的なアプローチです。2。この実験の結果を受け入れず、RFC 2026を更新して新しいプラクティスを示す。3. IESGからのフィードバックに基づいて、この実験の結果に基づいて手順を修正します。このオプションは、上記のようにさまざまな種類の古い標準を考慮に入れることができます。4.何もしません。これにより、IETFとIESGプラクティスは文書化されたプラクティスと矛盾します。

The working group chose the first option. The RFC Editor is requested to mark the above listed standards as Historic.

ワーキンググループは最初のオプションを選択しました。RFCエディターは、上記の標準を歴史的なものとしてマークするように要求されています。

It should be pointed out that we only looked at proposed standards and only those RFCs with numbers less than 2000. Should either the first or third of the above options be accepted, draft standards and those older than several years should be considered.

提案された標準のみを検討し、2000年未満の数字を持つRFCのみを検討することを指摘する必要があります。上記のオプションの最初または3分の1を受け入れ、ドラフト標準、および数年以上のものを考慮する必要があることを指摘する必要があります。

Finally, should NEWTRK deliver a new document classification system, these documents may provide a basis for one or more new categories of that.

最後に、NewTRKが新しいドキュメント分類システムを提供した場合、これらのドキュメントはその1つ以上の新しいカテゴリの基礎を提供する場合があります。

6. IANA Considerations

6. IANAの考慮事項

The IANA databases contain references to many of these documents. The documents are still the normative definitions for these values, and the IANA databases do not contain information about the status of the RFCs referred to.

IANAデータベースには、これらのドキュメントの多くへの参照が含まれています。ドキュメントは依然としてこれらの値の規範的定義であり、IANAデータベースには、言及されているRFCのステータスに関する情報は含まれていません。

Therefore, the IANA should not need to do anything based on this document.

したがって、IANAはこのドキュメントに基づいて何もする必要はありません。

7. Security Considerations

7. セキュリティに関する考慮事項

Documents that have security problems may require special attention and individual documents to indicate what concerns exist, and when or in what ways an implementation can be deployed to alleviate concerns.

セキュリティ上の問題を抱えているドキュメントでは、懸念が存在するものを示すために、特別な注意と個々のドキュメントが必要になる場合があります。

8. Acknowledgements

8. 謝辞

This experiment would have been completely useless without participation of the members of the old-standards mailing list. Most notably, Pekka Savalo, Bob Braden, and John Klensin were very active contributors to the discussions.

この実験は、古い標準のメーリングリストのメンバーの参加なしに完全に役に立たなかったでしょう。最も顕著なのは、ペッカ・サバロ、ボブ・ブレーデン、ジョン・クレンシンが議論に非常に積極的な貢献者であったことです。

9. Normative References

9. 引用文献

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

[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。

Appendix A. Input RFCs

付録A.

RFC 0698 (Telnet Extended ASCII Option) RFC 0726 (Remote Controlled Transmission and Echoing Telnet Option) RFC 0727 (Telnet Logout Option) RFC 0735 (Revised Telnet Byte Macro Option) RFC 0736 (Telnet SUPDUP Option) RFC 0749 (Telnet SUPDUP-Output Option) RFC 0779 (Telnet send-location Option) RFC 0885 (Telnet End of Record Option) RFC 0927 (TACACS User Identification Telnet Option) RFC 0933 (Output Marking Telnet Option) RFC 0946 (Telnet Terminal Location Number Option) RFC 0977 (Network News Transfer Protocol) RFC 1041 (Telnet 3270 Regime Option) RFC 1043 (Telnet Data Entry Terminal Option: DODIIS Implementation) RFC 1053 (Telnet X.3 PAD Option) RFC 1073 (Telnet Window sSize Option) RFC 1079 (Telnet Terminal Speed Option) RFC 1091 (Telnet Terminal-type Option) RFC 1096 (Telnet X Display Location Option) RFC 1144 (Compressing TCP/IP Headers for Low-speed Serial Links) RFC 1195 (Use of OSI IS-IS for Routing in TCP/IP and Dual) RFC 1234 (Tunneling IPX Traffic through IP Networks) RFC 1239 (Reassignment of Experimental MIBs to Standard MIBs) RFC 1256 (ICMP Router Discovery Messages) RFC 1269 (Definitions of Managed Objects for the Border Gateway Protocol: Version 3) RFC 1274 (The COSINE and Internet X.500 Schema) RFC 1276 (Replication and Distributed Operations Extensions to Provide an Internet Directory Using X.500) RFC 1277 (Encoding Network Addresses to Support Operation over Non-OSI Lower Layers) RFC 1285 (FDDI Management Information Base) RFC 1314 (A File Format for the Exchange of Images in the Internet) RFC 1323 (TCP Extensions for High Performance) RFC 1328 (X.400 1988 to 1984 Downgrading) RFC 1332 (The PPP Internet Protocol Control Protocol (IPCP)) RFC 1370 (Applicability Statement for OSPF) RFC 1372 (Telnet Remote Flow Control Option) RFC 1377 (The PPP OSI Network Layer Control Protocol (OSINLCP)) RFC 1378 (The PPP AppleTalk Control Protocol (ATCP)) RFC 1381 (SNMP MIB Extension for X.25 LAPB) RFC 1382 (SNMP MIB Extension for the X.25 Packet Layer) RFC 1397 (Default Route Advertisement in BGP2 and BGP3 Version of the Border Gateway Protocol) RFC 1413 (Identification Protocol) RFC 1414 (Identification MIB) RFC 1415 (FTP-FTAM Gateway Specification) RFC 1418 (SNMP over OSI) RFC 1419 (SNMP over AppleTalk) RFC 1420 (SNMP over IPX) RFC 1421 (Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures) RFC 1422 (Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management) RFC 1423 (Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers) RFC 1424 (Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services) RFC 1461 (SNMP MIB extension for Multiprotocol Interconnect over X.25) RFC 1469 (IP Multicast over Token-Ring Local Area Networks) RFC 1471 (The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol) RFC 1472 (The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol) RFC 1473 (The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol) RFC 1474 (The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol) RFC 1478 (An Architecture for Inter-Domain Policy Routing) RFC 1479 (Inter-Domain Policy Routing Protocol Specification: Version 1) RFC 1494 (Equivalences between 1988 X.400 and RFC-822 Message Bodies) RFC 1496 (Rules for Downgrading Messages from X.400/88 to X.400/84) RFC 1502 (X.400 Use of Extended Character Sets) RFC 1510 (The Kerberos Network Authentication Service (V5)) RFC 1512 (FDDI Management Information Base) RFC 1513 (Token Ring Extensions to the Remote Network Monitoring MIB) RFC 1517 (Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)) RFC 1518 (An Architecture for IP Address Allocation with CIDR) RFC 1519 (Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy) RFC 1525 (Definitions of Managed Objects for Source Routing Bridges) RFC 1552 (The PPP Internetworking Packet Exchange Control Protocol) RFC 1553 (Compressing IPX Headers over WAN Media (CIPX)) RFC 1570 (PPP LCP Extensions) RFC 1572 (Telnet Environment Option) RFC 1582 (Extensions to RIP to Support Demand Circuits) RFC 1584 (Multicast Extensions to OSPF) RFC 1598 (PPP in X.25) RFC 1618 (PPP over ISDN) RFC 1628 (UPS Management Information Base) RFC 1648 (Postmaster Convention for X.400 Operations) RFC 1663 (PPP Reliable Transmission) RFC 1666 (Definitions of Managed Objects for SNA NAUs Using SMIv2) RFC 1692 (Transport Multiplexing Protocol (TMux)) RFC 1696 (Modem Management Information Base (MIB) Using SMIv2) RFC 1697 (Relational Database Management System (RDBMS) Management) RFC 1731 (IMAP4 Authentication Mechanisms) RFC 1734 (POP3 AUTHentication command) RFC 1738 (Uniform Resource Locators (URL)) RFC 1740 (MIME Encapsulation of Macintosh Files - MacMIME) RFC 1742 (AppleTalk Management Information Base II) RFC 1747 (Definitions of Managed Objects for SNA Data Link Control) RFC 1749 (IEEE 802.5 Station Source Routing MIB Using SMIv2) RFC 1752 (The Recommendation for the IP Next Generation Protocol) RFC 1755 (ATM Signaling Support for IP over ATM) RFC 1763 (The PPP Banyan Vines Control Protocol (BVCP)) RFC 1764 (The PPP XNS IDP Control Protocol (XNSCP)) RFC 1767 (MIME Encapsulation of EDI Objects) RFC 1793 (Extending OSPF to Support Demand Circuits) RFC 1808 (Relative Uniform Resource Locators) RFC 1812 (Requirements for IP Version 4 Routers) RFC 1828 (IP Authentication using Keyed MD5) RFC 1829 (The ESP DES-CBC Transform) RFC 1831 (RPC: Remote Procedure Call Protocol Specification Version 2) RFC 1833 (Binding Protocols for ONC RPC Version 2) RFC 1835 (Architecture of the WHOIS++ Service) RFC 1847 (Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted) RFC 1848 (MIME Object Security Services) RFC 1913 (Architecture of the Whois++ Index Service) RFC 1914 (How to Interact with a Whois++ Mesh) RFC 1928 (SOCKS Protocol Version 5) RFC 1929 (Username/Password Authentication for SOCKS V5) RFC 1961 (GSS-API Authentication Method for SOCKS Version 5) RFC 1962 (The PPP Compression Control Protocol (CCP)) RFC 1964 (The Kerberos Version 5 GSS-API Mechanism) RFC 1968 (The PPP Encryption Control Protocol (ECP)) RFC 1973 (PPP in Frame Relay) RFC 1982 (Serial Number Arithmetic) RFC 1985 (SMTP Service Extension for Remote Message Queue Starting) RFC 1995 (Incremental Zone Transfer in DNS) RFC 1996 (A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)) RFC 1997 (BGP Communities Attribute)

Authors' Addresses

著者のアドレス

Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland

Eliot Lear Cisco Systems Gmbh Glatt-Com Glattzentrum、Zh CH-8301スイス

   Phone: +41 1 878 7525
   EMail: lear@cisco.com

Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim Norway

Harald Tveit Alvestrand Cisco Systems Weidemanns Vei 27 7043 Trondheim Norway

   EMail: harald@alvestrand.no

Full Copyright Statement

完全な著作権声明

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.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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エディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。