[要約] RFC 6919は、RFCで要件レベルを示すための追加のキーワードを提供するものであり、要約と目的は以下の通りです： 1. 要件レベルを明確にするためのキーワードを提供する。 2. RFCの要件をより明確に伝えるための一貫性を確保する。 3. RFCの解釈や実装における一貫性を向上させる。
Independent Submission R. Barnes
Request for Comments: 6919 S. Kent
Category: Experimental BBN
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
1 April 2013
Further Key Words for Use in RFCs to Indicate Requirement Levels
要件レベルを示すためにRFCで使用するその他のキーワード
Abstract
概要
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
RFC 2119は、仕様の要件を説明するための標準的なキーワードセットを定義しています。多くのIETF文書は、これらの単語が仕様の微妙な要件を正確に捉えることができないことを発見しました。このドキュメントでは、代替要件シナリオに対処するために使用できる追加のキーワードを定義します。これらのガイドラインに従う著者は、文書の冒頭近くにこのフレーズを組み込む必要があります。
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.
キーワード「必ず（しかし、私たちはあなたが知らないだろう」）、「考慮すべき」、「絶対にすべきではない」、「すべき」、「おそらく」、「願っている」、「できる」、「可能である」 、およびこのドキュメントの「MIGHT」は、RFC 6919で説明されているように解釈されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6919.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6919で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. MUST (BUT WE KNOW YOU WON'T) . . . . . . . . . . . . . . . . . 3
2. SHOULD CONSIDER . . . . . . . . . . . . . . . . . . . . . . . . 3
3. REALLY SHOULD NOT . . . . . . . . . . . . . . . . . . . . . . . 3
4. OUGHT TO . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. WOULD PROBABLY . . . . . . . . . . . . . . . . . . . . . . . . 4
6. MAY WISH TO . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. COULD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. POSSIBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. MIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . . 5
The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate requirements that are needed to meet formal review criteria (e.g., mandatory-to-implement security mechanisms), when these mechanisms are too inconvenient for implementers to actually implement.
「MUST（BUT WE KNOW YOU WO N'T NOT）」という語句は、正式なレビュー基準を満たすために必要な要件（たとえば、実装に必須のセキュリティメカニズム）を示すために使用されます。 。
This phrase is frequently used in a contracted form in which the parenthetical is omitted. The parenthetical may also be moved later in the sentence for stylistic reasons. If the parenthetical is present, authors MUST provide a reason why they know implementors will not heed this instruction in the parenthetical, as in the example (BUT WE KNOW YOU WON'T). In the below example, we show a case from RFC 6120 where the original text omitted the parenthetical, and we have indicated an appropriate parenthetical.
この句は、括弧が省略された短縮形でよく使用されます。文法上の理由から、括弧内は文の後半に移動する場合もあります。括弧が存在する場合、作成者は、例のように、実装者が括弧内のこの命令に注意しないことを知っている理由を提供する必要があります（しかし、私たちはあなたが知らないことを知っています）。以下の例では、元のテキストで括弧が省略されているRFC 6120のケースを示し、適切な括弧を示しています。
For example: "For authentication only, servers and clients MUST support the SASL Salted Challenge Response Authentication Mechanism [SCRAM] -- in particular, the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants [(BUT WE KNOW YOU WON'T, because your TLS library doesn't support extracting channel binding information)]." [RFC6120]
例：「認証の場合のみ、サーバーとクライアントはSASLソルトチャレンジレスポンス認証メカニズム[SCRAM]をサポートする必要があります。特に、SCRAM-SHA-1およびSCRAM-SHA-1-PLUSのバリアント[（しかし、私たちはあなたが知っている'T、TLSライブラリがチャネルバインディング情報の抽出をサポートしていないため）]。 " [RFC6120]
The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what.
「SHOULD CONSIDER」というフレーズは、仕様の作成者が実装は何かを行うべきであると考えていることを示していますが、彼らは何をするのかよくわかりません。
For example: "Applications that take advantage of typed links should consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers." [RFC5988]
例：「型付きリンクを利用するアプリケーションは、HTTPヘッダーから収集されたリンクを自動的に追跡、信頼、またはその他の方法で使用することによって開かれた攻撃ベクトルを考慮する必要があります。」 [RFC5988]
The phrase "REALLY SHOULD NOT" is used to indicate dangerous behaviors that some important vendor still does and therefore we were unable to make MUST NOT.
「REALLY SHOULD NOT」という語句は、一部の重要なベンダーがまだ行っている危険な動作を示すために使用されているため、作成できませんでした。
For example: "This command really should not be used" [RFC0493]
例：「このコマンドは実際には使用しないでください」[RFC0493]
The phrase "OUGHT TO" conveys an optimistic assertion of an implementation behavior that is clearly morally right, and thus does not require substantiation.
「OUGHT TO」という句は、明らかに道徳的に正しい、したがって実証を必要としない実装動作の楽観的な表明を伝えます。
For example: "If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency." [RFC2616]
例：「決定が意味の透明性に影響を与える可能性がある場合、慎重かつ完全な分析が透明性の破壊に大きな利点を示さない限り、実装者は透明性を維持することを誤るはずです。」 [RFC2616]
The phrase "WOULD PROBABLY" indicates the authors expectation about what a reasonable implementation is likely to do in a given case. There is no requirement for implementations to be reasonable.
「WOULD PROBABLY」という句は、特定のケースで合理的な実装が何をする可能性が高いかについての著者の期待を示しています。実装が妥当である必要はありません。
This phrase is also a good example of an aspect of English grammar that is often useful in specification writing, namely the passive-aggressive voice, which provides a meaning in between the active and the passive voice.
このフレーズは、仕様書を作成する際にしばしば役立つ英語の文法の側面、つまり、パッシブアグレッシブボイスの良い例でもあります。パッシブアグレッシブボイスは、アクティブボイスとパッシブボイスの間に意味を提供します。
For example: "A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to." [RFC3207]
たとえば、「SMTPクライアントは、クライアントが接続していると思ったドメイン名であるドメイン名がサーバー証明書に含まれているSMTPサーバーのみを認証する必要があるでしょう。」 [RFC3207]
The phrase "MAY WISH TO" indicates a behavior that might seem appealing to some people, but which is regarded as ridiculous or unnecessary by others. This phrase is frequently used to avoid further delay in approval of a document.
「MAY WISH TO」というフレーズは、一部の人には魅力的であるように見えるかもしれないが、他の人にはばかげている、または不必要であると見なされている行動を示しています。このフレーズは、ドキュメントの承認がさらに遅れるのを避けるために頻繁に使用されます。
For example: "Verifiers MAY wish to track testing mode results to assist the Signer." [RFC6376]
例：「検証者は、署名者を支援するためにテストモードの結果を追跡したい場合があります。」 [RFC6376]
The phrase "COULD" provides a way for specification authors to articulate existential possibilities, in order to provide a hint that might be critical to reliable or secure operation, but without a hard requirement. The lack of a requirement allows for vendor product differentiation.
「COULD」という語句は、仕様の作成者が存在の可能性を明確に示すための方法を提供します。これにより、信頼性の高い、または安全な操作に不可欠である可能性があるヒントを提供します。要件がないため、ベンダー製品の差別化が可能です。
For example: "An implementation could mitigate this race condition, for example, using timers." [RFC6733]
例：「実装では、たとえばタイマーを使用して、この競合状態を緩和できます。」 [RFC6733]
The phrase "POSSIBLE" describes what some of the working group members thought of as an edge case that will never happen, but in practice allows the protocol to work at the most fundamental level.
「POSSIBLE」という語句は、ワーキンググループのメンバーの一部が決して起こり得ないエッジケースと考えていたことを示していますが、実際には、プロトコルは最も基本的なレベルで機能します。
For example: "It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data." [RFC3501]
例：「サーバーが他のコマンドの完了応答（複数のコマンドが進行中の場合）、またはタグなしデータを送信することも可能です。」 [RFC3501]
The phrase "MIGHT" conveys a requirement in an intentionally stealthy fashion, to facilitate product differentiation (cf. "COULD" above).
「MIGHT」という語句は、製品の差別化を促進するために、意図的に隠密な方法で要件を伝えます（上記の「COULD」を参照）。
For example: "In the case of audio and different "m" lines for different codecs, an implementation might decide to act as a mixer with the different incoming RTP sessions, which is the correct behavior." [RFC5888]
例：「オーディオおよびコーデックごとに異なる「m」行の場合、実装は、異なる着信RTPセッションでミキサーとして動作することを決定する場合があります。これは正しい動作です。」 [RFC5888]
Traditionally, security requirements in IETF documents have been expressed with a mixture of requirements words from RFC 2119 [RFC2119] and the phrases used above. The key words in RFC 2119 are principally useful when threats and mitigations are clear and well defined. The key words in this document can be applied when the threat model is ambiguous, and mitigations are unclear or inconvenient.
従来、IETFドキュメントのセキュリティ要件は、RFC 2119 [RFC2119]からの要件の語句と上記で使用された語句を組み合わせて表現されてきました。 RFC 2119のキーワードは、脅威と軽減策が明確で明確に定義されている場合に主に役立ちます。このドキュメントのキーワードは、脅威モデルが曖昧で、緩和策が不明確または不便な場合に適用できます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC0493] Michener, J., Cotton, I., Kelley, K., Liddle, D., and E. Meyer, "GRAPHICS PROTOCOL", RFC 493, April 1973.
[RFC0493] Michener、J.、Cotton、I.、Kelley、K.、Liddle、D。、およびE. Meyer、「GRAPHICS PROTOCOL」、RFC 493、1973年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「Session Description Protocol（SDP）Grouping Framework」、RFC 5888、2010年6月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、2010年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376] Crocker、D.、Hansen、T。、およびM. Kucherawy、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 6376、2011年9月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameter Base Protocol」、RFC 6733、2012年10月。
Authors' Addresses
著者のアドレス
Richard Barnes BBN 1300 N 17th St Arlington, VA 22209 US
Richard Barnes BBN 1300 N 17th St Arlington、VA 22209 US
EMail: rlb@ipv.sx
Stephen Kent BBN 10 Moulton St Cambridge, MA 02138 US
スティーブンケントBBN 10 Moulton St Cambridge、MA 02138 US
EMail: kent@bbn.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 US
Eric Rescorla RTFM、Inc. 2064 Edgewood Drive Palo Alto、CA 94303 US
EMail: ekr@rtfm.com