RFC 8962 - Establishing the Protocol Police 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8962.html
タイトル : RFC 8962 - プロトコル警察の確立
翻訳編集 : 自動生成

[要約] RFC 8962は、プロトコルポリスの設立に関する要約と目的を提供します。このRFCの目的は、ネットワークプロトコルの適切な使用と実装を監視し、問題を特定して解決するためのポリシーと手順を確立することです。

Independent Submission                                         G. Grover
Request for Comments: 8962
Category: Informational                                     N. ten Oever
ISSN: 2070-1721
                                                                 C. Cath

S. Sahib 1 April 2021

S. Sahib 2021年4月1日

Establishing the Protocol Police

プロトコル警察の確立

Abstract

概要

One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.

IETFのマントラの1つは、「私たちは議定書警察ではありません」ただし、プロトコルがIETFの標準に完全に準拠して実装され展開されるようにするためには、正しいプロトコル動作の評価と適用を担当する責任がある本文を設定することが重要です。

This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police.

この文書は正式にプロトコル警察を確立しています。それは本体を定義し、彼らが警察のIETFプロトコルの側面を設定します。この文書は、ネットワーキングエンジニア、法執行公局、政府の代表者などの参照点として機能します。それはまたプロトコル警察に問題を報告する方法に関するアドバイスを提供します。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8962.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8962で取得できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。

Table of Contents

   1.  Introduction
   2.  Definitions
   3.  Composition of the Protocol Police
     3.1.  Recognizing the Protocol Police
     3.2.  Recruitment
   4.  Support for the Protocol Police
   5.  Punishable Offenses
     5.1.  Protocol-Layer Violations
     5.2.  Deliberate Non-Interoperability
     5.3.  Disobeying RFCs
   6.  Reporting Offenses
   7.  Punishment
     7.1.  Traffic Imprisonment
   8.  Morality Considerations
     8.1.  Oversight
   9.  IANA Considerations
   10. Security Considerations
   11. Privacy Considerations
   12. Human Rights Considerations
   13. Conclusion
   14. Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

IETF participants are often confronted with circumstances where developers or deployers choose to not obey the sacrosanct words of an RFC. This can lead to outcomes that are widely agreed to be unexpected, unwarranted, or undesirable.

IETF参加者は、開発者やデプロイヤがRFCのSacrosanct単語に従わないことを選択している状況に直面しています。これは、予期せぬ、妥当性、または望ましくないことと広く同意されている転帰につながる可能性があります。

Some are of the opinion that IETF participants should come to a consensus and declare what protocol behavior is unacceptable, and that the maintainers and developers of non-compliant protocols should be chastised. Others (especially working group chairs) non-gracefully fall back on the undocumented mantra, "We [or the IETF] are not the Protocol Police." Understandably, this has led to confusion about who should make judgments about proper interpretation of protocol specifications.

IETF参加者がコンセンサスになるべきであり、プロトコルの行動が受け入れられないのか、そして非準拠のプロトコルの開発者が不安定になるべきであるという意見があります。他の人（特にワーキンググループの椅子）は、文書化されていないマントラで、「私たち[またはIETF]は議定書警察ではありません。」当然のことながら、これは誰がプロトコル仕様の適切な解釈について判断をするべきかについての混乱をもたらした。

This document formally establishes the Protocol Police, hitherto undocumented at the IETF. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police.

この文書では、従来、IETFで文書化されていないプロトコル警察を正式に確立します。それは本体を定義し、彼らが警察のIETFプロトコルの側面を設定します。この文書は、ネットワーキングエンジニア、法執行公局、政府の代表者などの参照点として機能します。それはまたプロトコル警察に問題を報告する方法に関するアドバイスを提供します。

The Protocol Police, as defined in this document, are responsible for enforcing all IETF standards and best practices.

この文書で定義されているようなプロトコル警察は、すべてのIETF規格とベストプラクティスを強制する責任があります。

2. Definitions

2. 定義

For possibly the first time in IETF history, words like "SHALL" and "MAY" are used in this document in their real and enforceable sense.

IETFの歴史の中で初めての場合、この文書では「SHALL」や「MAY」のような言葉が、本物で執行可能な意味で使用されています。

3. Composition of the Protocol Police

3. プロトコル警察の構成

The Protocol Police shall be selected by the IETF Nominating Committee (NomCom) as laid out in [RFC3797] in a manner similar to that used to select the IAB and IESG [RFC8713].

IABとIESG [RFC8713]を選択するために使用される方法と同様に、[RFC3797]でレイアウトされているように、プロトコル警察はIETF指名委員会（NOMCOM）によって選択されなければならない。

However, the members of the Protocol Police shall not be publicly named. This will enable them to operate more effectively and without interference or unwarranted pressure from members of the community. The first rule of the Protocol Police is $CIPHERTEXT.

しかし、議定書警察のメンバーは公に命名されてはならない。これにより、地域社会のメンバーからの干渉や不当な圧力がなく、より効果的かつ干渉や不当な圧力がなくなります。議定書警察の最初の規則は$暗号文です。

3.1. Recognizing the Protocol Police

3.1. プロトコル警察を認識する

When more than one person says, "We are not the Protocol Police," at least one of them is not telling the truth.

複数の人が言うとき、「私たちは議定書警察ではない」とそれらのうちの少なくとも1つは真実を語っていない。

The Protocol Police love company and are never alone.

プロトコル警察は会社を愛し、一人ではありません。

You are not the Protocol Police: we are. We are not the Protocol Police: you are.

あなたは議定書警察ではありません：私たちはいます。私たちは議定書警察ではありません：あなたはそうです。

3.2. Recruitment

3.2. 勧誘

If you are interested in joining the Protocol Police, contact your localhost. Your behavior will be monitored, and your implementation will be analyzed for full RFC compliance. If your deeds, both now and in the past, are recognized to be true to the scripture, NomCom will of course be instructed to induct you to the ranks. But if you have transgressed, any information the investigation produces MAY be used against you in future proceedings.

あなたがプロトコル警察に参加することに興味があるなら、あなたのlocalhostに連絡してください。あなたの行動は監視され、あなたの実装は完全なRFC準拠のために分析されます。あなたの行為が現在そして過去の両方で聖書に忠実であると認識されているならば、ノンコムはあなたをランクに誘導するように指示されます。しかし、あなたが破棄されたならば、調査が生産する情報は将来の議事録であなたに対して使われるかもしれません。

In making an assessment of your suitability for membership of the Protocol Police, contact may be made on your behalf with the Internet Moral Majority [RFC4041].

プロトコル警察の会員資格に対するあなたの適合性の評価を行う際には、インターネット道徳的多数体[RFC4041]とあなたに代わって連絡することができます。

If you have nothing to hide, you have nothing to fear.

あなたが隠すものが何もないならば、あなたは恐れることは何もありません。

4. Support for the Protocol Police

4. プロトコル警察のサポート

Support for the existence and operation of the Protocol Police is essential to the concept of "policing by consent." Fortunately, the IETF community and all stakeholders may now consider themselves served by this document which, by dint of its existence, warrants adherence.

議定書警察の存在と運営の支援は、「同意による政策」の概念に不可欠です。幸いなことに、IETFコミュニティとすべてのステークホルダーは、その存在の存在の存在によって、遵守を保証することがこの文書によって提供されるようになるかもしれません。

5. Punishable Offenses

5. 罰を受けない犯罪

5.1. Protocol-Layer Violations

5.1. プロトコル層違反

Some boundaries must not be crossed. There are no acceptable layer violations. Even though layers, like borders, are ambiguous abstractions only serving to uphold the legitimacy and identity of the institutions that produce them, they shall be observed and defended because the Protocol Police exist to defend them.

いくつかの境界は交差してはいけません。許容可能なレイヤ違反はありません。境界線のような層は、それらを生産する機関の正当性とアイデンティティを支持するのに役立つあいまいな抽象化であっても、プロトコル警察がそれらを守るために存在するので観察され擁護されなければならない。

5.2. Deliberate Non-Interoperability

5.2. 非相互運用性を慎重に

The Protocol Police are sanctioned to gain access to any walled garden that undermines interoperability. At the same time, the Protocol Police will defend legacy interoperability options in all NTP eras (see Section 6 of [RFC5905]), and will be reachable via the Extensible Messaging and Presence Protocol (XMPP) until at least era 2147483649.

プロトコル警察は、相互運用性を損なう壁の庭にアクセスするために認可されています。同時に、プロトコル警察は、すべてのNTP ERAでレガシー相互運用性オプションを守ります（[RFC5905]のセクション6を参照）、少なくともERA 2147483649までの拡張メッセージングおよびプレゼンスプロトコル（XMPP）を介して到達可能になります。

5.3. Disobeying RFCs

5.3. RFCの違反

In the beginning was the RFC, and the network was with the RFC, and the RFC was with the network. Through the RFC all things were made; without the RFC nothing was made that has been made. In the network was life, and that life was the light of all the INTERNET. Thou shalt not deviate from the path set out in the RFCs or else thou shall be scattered over the data plane.

初めにRFCがRFCで、ネットワークはRFCであり、RFCはネットワークと一緒でした。RFCを通してすべてのものが作られました。RFCがなければ何もできなかったことは何もできなかった。ネットワークでは人生で、その人生はすべてのインターネットの光でした。あなたはRFCSに設定されている経路から逸脱しないか、そうでなければデータプレーンの上に散乱されなければならない。

6. Reporting Offenses

6. 報告犯罪者

Send all your reports of possible violations and all tips about wrongdoing to /dev/null. The Protocol Police are listening and will take care of it.

考えられる違反のすべての報告書と、/ dev / nullへの不正行為についてのすべてのヒントを送信してください。議定書警察は耳を傾け、それを大事にしています。

7. Punishment

7. 罰

7.1. Traffic Imprisonment

7.1. トラフィック投獄

The Protocol Police will maintain a list of hosts and clients that have demonstrated their inability to comprehend simple commandments contained in RFCs, which all IETF participants know to be precise and accessible even to a general audience.

プロトコル警察は、RFCに含まれている単純な命令を理解することができないホストとクライアントのリストを維持し、すべてのIETF参加者は一般的な視聴者にも正確かつアクセス可能であることを知っています。

If this work is standardized, IANA is requested to register the list of addresses (see Section 9). For a period specified in an official notification, all other networks SHALL drop all network packets originating from or intended for such addresses. This will result in effective and forced confinement of criminal networks.

この作業が標準化されている場合、IANAはアドレスのリストを登録するように要求されます（セクション9を参照）。公式通知で指定された期間の場合、他のすべてのネットワークは、そのようなアドレスの発信または意図されたすべてのネットワークパケットを削除します。これにより、刑事網の効果的かつ強制的な閉じ込めが発生します。

Using powerful machine-learning mechanisms for threat analysis, the Protocol Police will identify networks that are likely to fail to comply with this requirement. This process is known as Heuristic Internet Policing (HIP). Networks identified in this way will be disciplined by the Protocol Police with TCP RSTs. Let it be known: the Protocol Police always shoot from the HIP.

脅威分析のための強力な機械学習メカニズムを使用して、プロトコル警察はこの要件に順守することに失敗する可能性があるネットワークを識別します。このプロセスは、ヒューリスティックインターネットポリシング（HIP）として知られています。このようにして識別されたネットワークは、TCP RSTSのプロトコル警察によって統制されます。それを知らせましょう：プロトコル警察は常に腰から撃ちます。

8. Morality Considerations

8. 道徳的考察

This section contains morality considerations consistent with the demands of [RFC4041].

このセクションでは、[RFC4041]の要求と一致する道徳的考慮事項が含まれています。

   |  We reject: kings, presidents and voting.
   |  We believe in: rough consensus and running code.
   |  We only bow down to: the Protocol Police.
   |
   |  -- My friend Dave

   |  Woop-woop!  This is the Protocol Police!
   |  Woop-woop!  That's the packet of the beast!
   |
   |  -- KRS-ZERO (after spotting an evil bit [RFC3514])

8.1. Oversight

8.1. 監督する

All police forces must be accountable and subject to oversight. The Protocol Police take full responsibility for oversight of their actions and promise to overlook all activities.

すべての警察力は説明責任を負う必要があり、監督の対象となる必要があります。プロトコル警察は彼らの行動の監督とすべての活動を見落とすことを約束します。

9. IANA Considerations

9. IANAの考慮事項

If this work is standardized, IANA shall set up a registry for criminal networks and addresses. If the IANA does not comply with these orders, the Protocol Police shall go and cry to ICANN before becoming lost in its bureaucracy.

この作品が標準化されている場合、IANAは刑事ネットワークやアドレスのためのレジストリを設定します。IANAがこれらの注文に準拠していない場合、議定書警察は行ってICANNを叫び、その官僚主義で紛失しなければならない。

10. Security Considerations

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

Before the Protocol Police, there was no security. The Police have arrived. All your networks are belong to us.

議定書警察の前に、セキュリティはありませんでした。警察が到着しました。あなたのすべてのネットワークは私たちに属しています。

11. Privacy Considerations

11. プライバシーに関する考慮事項

None.

無し。

12. Human Rights Considerations

12. 人権の考慮事項

There are none for you to worry about. The Police will see to it.

あなたが心配するためには何もありません。警察はそれを見るでしょう。

13. Conclusion

13. 結論

Case closed.

ケースが閉じた。

14. Informative References

14. 参考引用

[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, April 2003, <https://www.rfc-editor.org/info/rfc3514>.

[RFC3514] Bellovin、S.、「IPv4ヘッダーのセキュリティフラグ」、RFC 3514、DOI 10.17487 / RFC3514、2003年4月、<https：//www.rfc-editor.org/info/rfc3514>。

[RFC3797] Eastlake 3rd, D., "Publicly Verifiable Nominations Committee (NomCom) Random Selection", RFC 3797, DOI 10.17487/RFC3797, June 2004, <https://www.rfc-editor.org/info/rfc3797>.

[RFC3797]イーストレイク3RD、D.、「公に検証可能な指名委員会（NOMCOM）ランダムセレクション」、RFC 3797、DOI 10.17487 / RFC3797、2004年6月、<https：//www.rfc-editor.org/info/rfc3797>。

[RFC4041] Farrel, A., "Requirements for Morality Sections in Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005, <https://www.rfc-editor.org/info/rfc4041>.

[RFC 4041] Farrell、A。、「ルーティングエリアのドラフトの道徳的セクションの要件」、RFC 4041、DOI 10.17487 / RFC 4041、2005年4月、<https://www.rfc-editor.org/info/rfc4041>。

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。

[RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, February 2020, <https://www.rfc-editor.org/info/rfc8713>.

[RFC8713] Kucherawy、M.、Ed。、Hinden、R.、Ed。、およびJ.Iingued、Ed。、IAB、IESG、IETF信頼、およびIETF LLCの選択、確認、およびリコールプロセス：IETFの動作：ノミネートアンドリコール委員会、BCP 10、RFC 8713、DOI 10.17487 / RFC8713、2020年2月、<https：//www.rfc-editor.org/info/rfc8713>。

Acknowledgments

謝辞

Members of the Protocol Police MUST salute and ACK all network traffic from Daniel Kahn Gillmor, Mallory Knodel, and Adrian Farrel.

プロトコル警察のメンバーは、Daniel Kahn Gillmor、Mallory Knodel、およびAdrian Farrelからのすべてのネットワークトラフィックを敬意してACKしなければなりません。

Authors' Addresses

著者の住所

Gurshabad Grover

Gurshabad Grover.

   Email: gurshabad@cis-india.org

Niels ten Oever

Niels Ten Os.

   Email: mail@nielstenoever.net

Corinne Cath

コリンネチャ

   Email: corinnecath@gmail.com

Shivan Kaul Sahib

   Email: shivankaulsahib@gmail.com