RFC4450 日本語訳
4450 Getting Rid of the Cruft: Report from an Experiment inIdentifying and Reclassifying Obsolete Standards Documents. E. Lear,H. Alvestrand. March 2006. (Format: TXT=23822 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Lear
Request for Comments: 4450 Cisco Systems GmbH
Category: Informational H. Alvestrand
Cisco Systems
March 2006
コメントを求めるワーキンググループE.リア要求をネットワークでつないでください: 4450年のシスコシステムズGmbHカテゴリ: 2006年の情報のH.Alvestrandシスコシステムズの行進
Getting Rid of the Cruft: Report from an Experiment in Identifying and
Reclassifying Obsolete Standards Documents
粗末な作りの結果について排除するようになります: 実験から、時代遅れの規格文書を特定して、分類し直す際に報告してください。
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このメモは、反射でないのが今日世界の中に習慣を記録したので、Proposed Standardsを見直して、分類するために実験を記録します。 結果は現在Historicとして分類し直されるProposed Standardsとしてマークされた1セットのドキュメントを特定します。
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. 序論と歴史…1 2. 手順の使用を中止して、膨れてください…2 3. 入力、Mailingリスト、Output、およびObservations…2 4. 議論…4 5. 次のステップ…5 6. IANA問題…6 7. セキュリティ問題…6 8. 承認…6 9. 標準の参照…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].
RFC2026、およびそれの前のRFC1602は未熟な(草稿の、または、提案された)規格のレビューのためのスケジュールを指定しました。 そのようなレビューの目的は、そのようなドキュメントが進められるべきであるかどうか決定するためにあったか、退職したか、または一層の[1]を開発しました。
Lear & Alvestrand Informational [Page 1] RFC 4450 Cruft Removal March 2006
2006年の[1ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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の歴史で一度も従われたことがありません。 この手順が従われていなくて以来、共同体のメンバーは、Historicへのドキュメントの退職が重大な行事であると示唆しています。(RFC2556(Historic StatusのためのUDP Applicability Statementの上のOSI Connectionless Transport Services)やRFC3166(Historic StatusへのMove RFC1403に要求します)などのドキュメントの生産に通じて、それは、慎重に正当化されるべきです)。
Such documents require significant time and effort on the part of authors, area directors, and the RFC Editor.
そのようなドキュメントは作者、領域ディレクター、およびRFC Editor側の重要な時間と取り組みを必要とします。
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年のFallから2005年のSpringまで、作者は、時代遅れであるといくつのProposed Standardsを考えることができたかを決定するために実験を行いました。 実験は以下の通り操作されました:
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 Assumeであるドキュメントの回収されたそれぞれが、ドキュメントであるグループを特定してください。実際にはどんな理由でも引退するべきそれらのリストから取り除きます. o Presentを理由に提供する限り、レビューo Reviseが記載するので、ワーキンググループ、IETF、およびIESGへのリストはコメントを基礎づけました。開いているアクセサリーo Allowの方針との議論のためのo Create aメーリングリストは結果として生じますいずれも、o Writeが上昇するということになるようにドキュメントである。
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.
作者の初期の意図はHistoricとして分類し直されるためにドキュメントのリストを提示することでした。 NEWTRKワーキンググループはこの視点をサポートしました。 IESG、および共同体としてのIETFは決裁します。 私たちは以下では、より遠い状態でこれについて議論するつもりです。
3. Input, Mailing list, Output, and Observations
3. 入力、Mailingリスト、Output、およびObservations
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未満の数でRFCsであるように設定された私たちの初期のドキュメントとProposed Standardの状態から始まりました。 私たちが使用した2004年11月25日に始まっている入力はAppendix A.Thereで見つけられているのが、全部でおよそ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日の上、または、2004年11月15日の周りのIETF発表しているリストに発行されました。 メーリングリストの29人のメンバーがいました。 およそ244のメッセージをリストに送りました。 人々がimplementerが新しい実装を書くか、または既存のものを維持するだろうかどうかに関する質問を考えるよう奨励されました。
Lear & Alvestrand Informational [Page 2] RFC 4450 Cruft Removal March 2006
2006年の[2ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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.
レビューの間、RFCs1518と1519は仕事が彼らを改訂することにおいて進行中であるという事実に基づいて取り外されました。 同様に、彼らが活発にそうであったという信念に基づいて使用中でありRFCs1381、1382、1471、1472、1473、1582、1598、および1755を取り除きました。 RFC1584は予想された将来の依存に基づいて取り外されました。
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
RFC1234(IP Networksを通してIPX Trafficにトンネルを堀ります)RFC1239(Standard MIBsへのExperimental MIBsの再割当て)RFC1276(インターネットディレクトリUsing X.500を提供する模写とDistributed Operations Extensions)RFC1285(FDDI Management Information基地)RFC1314(インターネットのイメージズのExchangeのためのFile Format)RFC1328(X.400 1988年から1984Downgrading)RFC1370(OSPFのための適用性Statement)RFC1378(PPP AppleTalk Controlプロトコル(ATCP))RFC1397; (ボーダ・ゲイトウェイ・プロトコルのBGP2とBGP3バージョンにおけるデフォルトルート広告) RFC1414(識別MIB)RFC1415(FTP-FTAMゲートウェイ仕様)RFC1418(オウシの上のSNMP)RFC1419(AppleTalkの上のSNMP)RFC1421; (インターネット電子メールのためのプライバシー増進: 私: メッセージ暗号化と認証手順を分けてください) RFC1422(インターネット電子メールのためのプライバシー増進: パートII: 証明書ベースのKey Management)RFC1423(インターネット電子メールのためのプライバシー増進: パートIII: アルゴリズム、モード、および識別子)RFC1424(インターネット電子メールのためのプライバシー増進: パートIV: 主要な証明と関連サービス)RFC1461(X.25の上のMultiprotocol内部連絡のためのSNMP MIB拡張子)RFC1469(トークンリングローカル・エリア・ネットワークの上のIPマルチキャスト)RFC1474(二地点間プロトコルのブリッジネットワーク制御プロトコルのための管理オブジェクトの定義); MessagesのMIME文書内容Are PresentであることのRFC1478(Inter-ドメインPolicyルート設定のためのArchitecture)RFC1479(相互Domain Policyルート設定プロトコルSpecification: バージョン1)RFC1494(1988X.400とRFC-822 Message Bodiesの間の等価性)RFC1496(X.400/88からX.400/84までのDowngrading Messagesのための規則)
Lear & Alvestrand Informational [Page 3] RFC 4450 Cruft Removal March 2006
2006年の[3ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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)
RFC1502(拡張文字集合のX.400使用)RFC1512(FDDI管理情報ベース)RFC1513(リモートネットワーク監視MIBへのトークンリング拡大)RFC1525(ソースルート設定ブリッジのための管理オブジェクトの定義)RFC1552(pppインターネットワーキングパケット交換制御プロトコル(IPXCP))RFC1553(青白いメディア(CIPX)の上にIPXヘッダーを圧縮します)RFC1648(X.400操作のための郵便局長コンベンション)RFC1666(SMIv2を使用するSNA NAUsのための管理オブジェクトの定義)RFC1692; (輸送マルチプレクシングプロトコル(TMux)) RFC1696(SMIv2を使用するモデム管理情報ベース(MIB))RFC1742(AppleTalk管理情報ベースII)RFC1747(SMIv2を使用するSNAデータリンク制御(SDLC)のための管理オブジェクトの定義)RFC1749; (SMIv2を使用しているIEEE802.5駅のソースルート設定MIB)RFC1763(pppバニヤンつる植物はプロトコル(BVCP)を制御します)RFC1764(ppp XNS IDP制御プロトコル(XNSCP))RFC1828(合わせられたMD5を使用するIP認証)RFC1835(WHOIS++サービスのアーキテクチャ)RFC1848、(MIMEオブジェクトセキュリティー・サービス) RFC1913(Whois++インデックスサービスのアーキテクチャ)RFC1914(どう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.
1通の追加ドキュメント、RFC1829(ESP DES-CBC変換)はHistoric状態に示されましたが、この場合、グループコンセンサスは共同体がこのアルゴリズムを使用するセキュリティ含意について説明する別々のドキュメントの利益を得るだろうということです。
4. Discussion
4. 議論
As one peruses this list one sees several classes of documents:
1つがこのリストを熟読するとき、人は数人のクラスのドキュメントを見ます:
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 X.400プロトコルのためのAppletalkなどのように時代遅れであることのMultiprotocol機能か定義されましたが、使用されなかったPEMかWhois++などのoプロトコル
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:
どちらかの場合では、上では、プロトコルが使用中であって、かつサポートされそうであるかどうかに関して判断が必要です。 私たちの実験のパラメタはプロトコルがサポートされるのが継続的でありそうだったケースを避けることができるくらい保守的でした。 すなわち、だれでもどんな理由によるリストからもドキュメントを取り外すことができました。 事実上、いくつかの場合、私たちは保守的過ぎたかもしれません。 したがって、また、リストから取り外されたドキュメントのカテゴリを考える価値があります:
Lear & Alvestrand Informational [Page 4] RFC 4450 Cruft Removal March 2006
2006年の[4ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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 現在、IETFの中にレビュー中である前進o仕様は考えられるべきである完全利用であるのが知られている仕様が以前に、不賛成のために考えられて、拒絶されたo Specificationsを処理します。
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.
最後のカテゴリはtelnetオプションに限っています。(オプションは1990年代後半に見直されました)。 論証上、そのようなオプションは不賛成のために再考されるべきです。 現実的に、だれも例えば、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つの場合では、不賛成の議論はドキュメントへの作業に拍車をかけました。 例えば、進行中のClassless Inter-ドメインルート設定(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. この実験の結果を受け入れてください、そして、最後の呼び出しを発行してください、そして、リストに最後の呼び出しを超えて残っている規格を非難してください。 これはRFC2026の意図を保存する攻撃的なアプローチです。 2. 新しい習慣を示すためにこの実験とアップデートRFC2026の結果を受け入れないでください。 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.
ワーキンググループは第1の選択を選びました。 RFC EditorがHistoricとして上の記載された規格をマークするよう要求されています。
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未満の数がある提案された標準とそれらのRFCsだけを見ただけであると指摘されるべきです。 1番目か上のオプションの3のどちらか番目を受け入れるなら、規格と数年が考えられるべきであるより古いそれらを作成してください。
Lear & Alvestrand Informational [Page 5] RFC 4450 Cruft Removal March 2006
2006年の[5ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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データベースは言及されたRFCsの状態の情報を含んでいません。
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.
この実験は古い規格メーリングリストのメンバーの参加なしで完全に役に立たなかったでしょう。 ペッカSavalo、ボブ・ブレーデン、およびジョンKlensinは議論への最も著しく、非常に活発な貢献者でした。
9. Normative References
9. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
Lear & Alvestrand Informational [Page 6] RFC 4450 Cruft Removal March 2006
2006年の[6ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
Appendix A. Input RFCs
付録A.入力RFCs
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)
RFC0698(telnetの拡張ASCIIオプション)RFC0726(遠隔操作のトランスミッションとtelnetオプションを反映します)RFC0727、(telnetがログアウトする、オプション) RFC0735(改訂されたtelnetバイトマクロオプション)RFC0736(telnet SUPDUPオプション)RFC0749(telnet SUPDUP-出力オプション)RFC; 0779(位置を発信させているtelnet Option)RFC0885(Record Optionのtelnet End)RFC0927(TACACS User Identification Telnet Option)RFC0933(出力Marking Telnet Option)RFC0946(telnet Terminal Location Number Option)RFC0977(ネットワークの電子情報を転送するプロトコル); RFC1041(3270年のtelnet政権オプション)RFC1043(telnetデータ・エントリ端末オプション: DODIIS実装)RFC1053(telnet X.3パッドオプション)RFC1073(telnet窓のsSizeオプション)RFC1079(telnet端末速度オプション)RFC1091(telnet端末のタイプオプション)RFC1096(telnet Xディスプレイ位置のオプション)RFC1144(低速連続のリンクへのTCP/IPヘッダーを圧縮します)RFC1195、(OSIの使用、-、TCP/IPで二元的のルート設定) RFC1234(IPネットワークを通したトンネリングIPXトラフィック)RFC1239、(Expの再割当てStandard MIBs) RFC1256(ICMP RouterディスカバリーMessages)RFC1269(ボーダ・ゲイトウェイ・プロトコルのためのManaged Objectsの定義: バージョン3)RFC1274(COSINEとインターネットX.500 Schema)RFC1276へのerimental MIBs、(模写とDistributed Operations Extensions、ProvideへのインターネットディレクトリUsing X.500) RFC1277(Non- OSI Lower Layersの上でNetwork AddressesをSupport Operationにコード化します)RFC1285(FDDI Management Information基地)RFC1314(インターネットのイメージズのExchangeのためのFile Format); ボーダ・ゲイトウェイ・プロトコルのersion) RFC1413(識別プロトコル)RFC1414(識別MIB)
Lear & Alvestrand Informational [Page 7] RFC 4450 Cruft Removal March 2006
2006年の[7ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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)
RFC1415(FTP-FTAMゲートウェイ仕様)RFC1418(オウシの上のSNMP)RFC1419(AppleTalkの上のSNMP)RFC1420(IPXの上のSNMP)RFC1421(インターネット電子メールのためのプライバシー増進: 私: メッセージ暗号化と認証手順を分けてください)RFC1422; (インターネット電子メールのためのプライバシー増進: パートII: 証明書ベースのKey Management) RFC1423(インターネット電子メールのためのプライバシー増進: パートIII: アルゴリズム、モード、および識別子)RFC1424(インターネット電子メールのためのプライバシー増進: パートIV: 主要な証明と関連サービス); RFC1461(X.25の上のMultiprotocol InterconnectのためのSNMP MIB拡張子)RFC1469(Token-リングローカル・エリア・ネットワークの上のIP Multicast)RFC1471(PointからポイントへのプロトコルのLink ControlプロトコルのためのManaged ObjectsのDefinitions)RFC1472(PointからポイントへのプロトコルのSecurityプロトコルのためのManaged ObjectsのDefinitions)RFC1473(PointからポイントへのプロトコルのIP Network ControlプロトコルのためのManaged ObjectsのDefinitions)RFC1474(二地点間プロトコルのブリッジネットワーク制御プロトコルのための管理オブジェクトの定義)RFC1478(相互ドメイン方針ルート設定のためのアーキテクチャ)RFC1479(相互ドメイン方針ルート設定プロトコル仕様: バージョン1)RFC1494(1988X.400とRFC-822メッセージボディーの間の等価性)RFC1496(X.400/88からX.400/84までメッセージを格下げするための規則)RFC1502(拡張文字集合のX.400使用)RFC1510(ケルベロスネットワーク認証サービス(V5))RFC1512; (FDDI管理情報ベース) RFC1513(リモートネットワーク監視MIBへのトークンリング拡大)RFC1517(階級のない相互ドメインルート設定(CIDR)の実装のための適用性証明)RFC1518(CIDRとのIPアドレス配分のためのアーキテクチャ); RFC1519(階級のない相互ドメインルート設定(CIDR): アドレス課題と集合戦略)RFC1525(ソースルート設定ブリッジのための管理オブジェクトの定義)RFC1552(pppインターネットワーキングパケット交換制御プロトコル)RFC1553、(IPXを圧縮すること。 青白いメディア(CIPX)RFC1570(ppp LCP拡張子)RFC1572(telnet環境オプション)RFC1582(要求が回路であるとサポートするために裂く拡大)RFC1584(OSPFへのマルチキャスト拡大)RFC1598の上のヘッダー(X.25のppp)
Lear & Alvestrand Informational [Page 8] RFC 4450 Cruft Removal March 2006
2006年の[8ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
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)
RFC1618(ISDNの上のPPP)RFC1628(UPS Management Information基地)RFC1648(X.400 Operationsの郵便局長Convention)RFC1663(PPP Reliable Transmission)RFC1666(SNA NAUs Using SMIv2のためのManaged Objectsの定義)RFC1692(輸送Multiplexingプロトコル(TMux))RFC1696(SMIv2を使用するモデムManagement Information基地(MIB))RFC1697(リレーショナルデータベース管理システム(RDBMS)管理)RFC1731(IMAP4 Authentication Mechanisms)RFC1734(POP3 AUTHenticationコマンド)RFC1738; (Uniform Resource Locator(URL)) RFC1740(マッキントッシュファイルのMIMEカプセル化--MacMIME)RFC1742(AppleTalk管理情報ベースII)RFC1747(SNAデータリンク制御のための管理オブジェクトの定義)RFC1749(SMIv2を使用しているIEEE802.5駅のソースルート設定MIB); RFC1752(IP次世代プロトコルのための推薦)RFC1755(気圧でのIPの気圧シグナリングサポート)RFC1763(pppバニヤンつる植物はプロトコル(BVCP)を制御します)RFC1764(ppp XNS IDP制御プロトコル(XNSCP))RFC1767、(Encapsulatをまねてください。EDI Objectsのイオン) RFC1793(OSPFをSupport Demand Circuitsに広げています)RFC1808(相対的なUniform Resource Locator)RFC1812(IPバージョン4Routersのための要件)RFC1828(Keyed MD5を使用するIP Authentication)RFC1829(超能力DES-CBC Transform)RFC1831(RPC: リモートProcedure CallプロトコルSpecificationバージョン2)RFC1833(ONC RPCバージョン2のための拘束力があるプロトコル)RFC1835(WHOIS++サービスのアーキテクチャ)RFC1847(複合の、または、署名しているMIMEのためのセキュリティMultipartsと暗号化されたMultipart/)RFC1848; (MIMEオブジェクトセキュリティー・サービス) RFC1913(Whois++インデックスサービスのアーキテクチャ)RFC1914(どうWhois++メッシュと対話するか)RFC1928(ソックスはバージョン5について議定書の中で述べます)RFC1929(ソックスV5のためのユーザ名/パスワード認証)RFC1961; (ソックスバージョン5)RFC1962(ppp圧縮制御プロトコル(CCP))RFC1964(ケルベロスバージョン5GSS-APIメカニズム)RFC1968(ppp暗号化制御プロトコル(ECP))RFC1973(フレームリレーにおけるppp)RFC1982(通し番号演算)RFCのためのGSS-API認証方法 1985(リモートメッセージキュー始めのためのSMTPサービス拡張子)RFC1995(DNSの増加のゾーン転送)RFC1996(ゾーン変化(DNSは通知する)の迅速な通知のためのメカニズム)RFC1997(BGP共同体属性)
Lear & Alvestrand Informational [Page 9] RFC 4450 Cruft Removal March 2006
2006年の[9ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアとAlvestrand
Authors' Addresses
作者のアドレス
Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland
エリオットリアシスコシステムズGmbHグラット-com Glattzentrum、ZH CH-8301スイス
Phone: +41 1 878 7525 EMail: lear@cisco.com
以下に電話をしてください。 +41 1 878 7525はメールされます: lear@cisco.com
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim Norway
ハラルドTveit AlvestrandシスコシステムズWeidemanns vei27 7043トロンヘイムノルウェー
EMail: harald@alvestrand.no
メール: harald@alvestrand.no
Lear & Alvestrand Informational [Page 10] RFC 4450 Cruft Removal March 2006
2006年の[10ページ]RFC4450粗末な作りの結果取り外し行進の情報のリアと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)によって提供されます。
Lear & Alvestrand Informational [Page 11]
リアとAlvestrand情報です。[11ページ]
一覧
スポンサーリンク
