| < draft-ymbk-downref-02.txt | draft-ymbk-downref-03.txt > | |||
|---|---|---|---|---|
| Network Working Group R. Bush | Network Working Group R. Bush | |||
| Internet-Draft IIJ | Internet-Draft IIJ | |||
| Updates: 2026 (if approved) T. Narten | Updates: 2026 (if approved) T. Narten | |||
| Expires: August 16, 2004 IBM Corporation | Expires: January 2005 IBM Corporation | |||
| April 8, 2004 | July 19, 2004 | |||
| Clarifying when Standards Track Documents may Refer Normatively to | Clarifying when Standards Track Documents may Refer Normatively to | |||
| Documents at a Lower Level | Documents at a Lower Level | |||
| draft-ymbk-downref-02.txt | draft-ymbk-downref-03.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, I certify that any applicable | |||
| patent or other IPR claims of which I am aware have been disclosed, | patent or other IPR claims of which I am aware have been disclosed, | |||
| and any of which I become aware will be disclosed, in accordance with | and any of which I become aware will be disclosed, in accordance with | |||
| RFC 3667. | RFC 3667. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |||
| www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on August 16, 2004. | This Internet-Draft will expire on December 11, 2004. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
| Abstract | Abstract | |||
| IETF procedures generally require that a standards track RFC may not | IETF procedures generally require that a standards track RFC may not | |||
| have a normative reference to a document at a lower standards level. | have a normative reference to another standards track document at a | |||
| For example a standards track document may not have a normative | lower maturity level or to a non standards track specification (other | |||
| reference to an informational RFC. There are needs for exceptions to | than specifications from other standards bodies). For example a | |||
| this rule, often caused by the IETF using informational RFCs to | standards track document may not have a normative reference to an | |||
| describe non-IETF standards, or IETF-specific modes of use of such | informational RFC. There are needs for exceptions to this rule, | |||
| standards. This document clarifies the procedure used in these | often caused by the IETF using informational RFCs to describe non- | |||
| IETF standards, or IETF-specific modes of use of such standards. This | ||||
| document clarifies and updates the procedure used in these | ||||
| circumstances. | circumstances. | |||
| 1. Normative References Expected to be to Equal or Higher Level | 1. Normative References Expected to be to Equal or Higher Level | |||
| The Internet Standards Process [RFC2026] Section 4.2.4 specifies: | The Internet Standards Process [RFC2026] Section 4.2.4 specifies: | |||
| Standards track specifications normally must not depend on other | Standards track specifications normally must not depend on other | |||
| standards track specifications which are at a lower maturity level | standards track specifications which are at a lower maturity level | |||
| or on non standards track specifications other than referenced | or on non standards track specifications other than referenced | |||
| specifications from other standards bodies. | specifications from other standards bodies. | |||
| One intent is to avoid creating a perception that a standard is more | One intent is to avoid creating a perception that a standard is more | |||
| mature than it actually is. | mature than it actually is. | |||
| 1.1 Definitions of Normative References | It should also be noted that Best Current Practice documents | |||
| [RFC1818] have generally been considered similar to Standards Track | ||||
| documents in terms of what they can reference. For example, a | ||||
| normative reference to an Experimental RFC has been considered an | ||||
| improper reference per [RFC2026]. | ||||
| Note: this section is adapted from the RFC Editor's definition of | 1.1 Normative References | |||
| "normative" as given in [RFC2223bis]. | ||||
| Within an RFC, references to other documents fall into two general | Within an RFC, references to other documents fall into two general | |||
| categories: "normative" and "informative". Normative references | categories: "normative" and "informative". Broadly speaking, a | |||
| specify documents that must be read to understand or implement the | normative reference specifies a document that must be read to fully | |||
| subject matter in the new RFC, or whose contents are effectively part | understand or implement the subject matter in the new RFC, or whose | |||
| of the new RFC and whose omission would leave the new RFC | contents are effectively part of the new RFC in the sense that its | |||
| incompletely specified. An informative reference is not normative; | omission would leave the new RFC incompletely specified. An | |||
| rather, it provides only additional information. For example, an | informative reference is not normative; rather, it provides only | |||
| informative reference might provide background or historical | additional, background information. | |||
| information, or provide an example of possible usage. Material in an | ||||
| informative reference is not required to be read in order to | ||||
| understand subject matter in the RFC. | ||||
| In the case of protocols, a reference is normative if it refers to | An exact and precise definition of what is (and is not) a normative | |||
| packet formats or other protocol mechanisms that are needed to fully | reference has proven challenging in practice, as the details and | |||
| implement the protocol in the current specification. For example, if | implications can be subtle. Morever, whether a reference needs to be | |||
| a protocol relies on IPsec to provide security, one cannot fully | normative can depend on the context in which a particular RFC is | |||
| implement the protocol without the specification for IPsec also being | being published in the first place. For example, in an IETF | |||
| available; hence, the reference would be normative. In the case of | Standard's context, it is important that all dependent pieces be | |||
| MIB documents, an IMPORTS clause by definition is a normative | clearly specified and available in an archival form, so that there is | |||
| reference. | no disagreement over what constitutes a standard. This is not always | |||
| the case for other documents. | ||||
| The rest of this section provides guidance on what might (and might | ||||
| not) be considered normative in the context of the IETF standards | ||||
| process. | ||||
| In the IETF, it is a basic assumption that implementors must have a | ||||
| clear understanding of what they need to implement in order to be | ||||
| fully compliant with a standard and to be able to interoperate with | ||||
| other implementations of that standard. For documents that are | ||||
| referenced, any document that includes key information an implementer | ||||
| needs would be normative. For example, if one needs to understand a | ||||
| packet format defined in another document in order to fully implement | ||||
| a specification, the reference to that format would be normative. | ||||
| Likewise, if a reference to a required algorithm is made, the | ||||
| reference would be normative. | ||||
| Some specific examples: | ||||
| - if a protocol relies on IPsec to provide security, one cannot | ||||
| fully implement the protocol without the specification for IPsec | ||||
| also being available; hence, the reference would be normative. | ||||
| The referenced specification would likely include details about | ||||
| specific key management requirements, which transforms are | ||||
| required and which are optional, etc. | ||||
| - in the case of MIB documents, an IMPORTS clause by definition is | ||||
| a normative reference. | ||||
| - when a reference to an example is made, such a reference need | ||||
| not be normative. For example, text such as "an algorithm such | ||||
| as the one specified in [RFCxxx] would be acceptable" indicates | ||||
| an informative reference, since that cited algorithm is just one | ||||
| of several possible algorithms that could be used. | ||||
| 2. The Need for Downward References | 2. The Need for Downward References | |||
| There are a number of circumstances where a normative reference to a | There are a number of circumstances where an IETF document may need | |||
| document at a lower maturity level may be needed. | to make a normative reference to a document at a lower maturity | |||
| level, but such a reference is in conflict with Section 4.2.4 of | ||||
| [RFC2026]. For example: | ||||
| o A standards track document may need to refer to a protocol or | o A standards track document may need to refer to a protocol or | |||
| algorithm developed by an external body but modified, adapted, or | algorithm developed by an external body but modified, adapted, or | |||
| profiled by an IETF informational RFC, for example MD5 [RFC1321] | profiled by an IETF informational RFC, for example MD5 [RFC1321] | |||
| and HMAC [RFC2104]. Note that this does not override the IETF's | and HMAC [RFC2104]. Note that this does not override the IETF's | |||
| duty to see that the specification is indeed sufficiently clear to | duty to see that the specification is indeed sufficiently clear to | |||
| enable creation of interoperable implementations. | enable creation of interoperable implementations. | |||
| o A standards document may need to refer to a proprietary protocol, | o A standards document may need to refer to a proprietary protocol, | |||
| and the IETF normally documents proprietary protocols using | and the IETF normally documents proprietary protocols using | |||
| informational RFCs. | informational RFCs. | |||
| o A migration or co-existence document may need to define a | o A migration or co-existence document may need to define a | |||
| standards track mechanism for migration from, and/or co-existence | standards track mechanism for migration from, and/or co-existence | |||
| with, an historic protocol, a proprietary protocol, or possibly a | with, an historic protocol, a proprietary protocol, or possibly a | |||
| non-standards track protocol. | non-standards track protocol. | |||
| o There are exceptional procedural or legal reasons which force the | o There are exceptional procedural or legal reasons which force the | |||
| target of the normative reference to be an informational or | target of the normative reference to be an informational or | |||
| historical RFC, or for it to be at a lower standards level than | historical RFC, or for it to be at a lower standards level than | |||
| the referring document. | the referring document. | |||
| o A BCP document may want to describe best current practices for | ||||
| o A BCP document may want to describe best current practices for | ||||
| experimental or informational specifications. | experimental or informational specifications. | |||
| 3. The Procedure to be Used | 3. The Procedure to be Used | |||
| For Standards Track or BCP documents requiring normative reference to | For Standards Track or BCP documents requiring normative reference to | |||
| documents of lower maturity, the normal IETF Last Call procedure will | documents of lower maturity, the normal IETF Last Call procedure will | |||
| be issued, with the need for the downward reference explicitly | be issued, with the need for the downward reference explicitly | |||
| documented in the Last Call itself. Any community comments on the | documented in the Last Call itself. Any community comments on the | |||
| appropriateness of downward references will be considered by the IESG | appropriateness of downward references will be considered by the IESG | |||
| as part of its deliberations. Once a specific precedent has been set | as part of its deliberations. | |||
| (i.e., the same exception has been made for a particular reference a | ||||
| few times), the need for an explicit mention of the issue during Last | Once a specific down reference to a particular document has been | |||
| Call may be waived. | accepted by the community (e.g., has been mentioned in several Last | |||
| Calls), an Area Director may waive subsequent notices in the Last | ||||
| Call of down references to it. This should only occur when the same | ||||
| document (and version) are being referenced and when the AD believes | ||||
| that the document's use is an accepted part of the community's | ||||
| understanding of the relevant technical area. For example, the use | ||||
| of MD5 [RFC1321] and HMAC [RFC2104] is well known among | ||||
| cryptographers. | ||||
| This procedure should not be used when the appropriate step to take | This procedure should not be used when the appropriate step to take | |||
| is to move the document to which the reference is being made into the | is to move the document to which the reference is being made into the | |||
| appropriate category. I.e., this is not intended as an easy way out | appropriate category. I.e., this is not intended as an easy way out | |||
| of normal process. Rather, it is intended for dealing with specific | of normal process. Rather, it is intended for dealing with specific | |||
| cases where putting particular documents into the required category | cases where putting particular documents into the required category | |||
| is problematical and unlikely to ever happen. | is problematical and unlikely to ever happen. | |||
| 4. BCPs and Experimental Protocols | 4. Security Considerations | |||
| Best Current Practice documents have generally been considered | ||||
| similar to Standards Track documents in terms of what they can | ||||
| reference. For example, a normative reference to an Experimental RFC | ||||
| has been considered an improper reference per [2026]. Recently, the | ||||
| mboned Working Group wanted to publish BCPs on multicast issues. But | ||||
| many of the protocols are Experimental and are not expected to be | ||||
| moved onto the Standards Track (e.g., [RFC2362]). Thus, the | ||||
| Experimental protocols represent what is being used, and it is useful | ||||
| to publish BCP documents that refer to them. This document | ||||
| explicitely allows BCP documents to contain normative references to | ||||
| non-Standards Track documents. Also, it should be noted that the | ||||
| current practice has been that BCPs can reference Proposed Standards, | ||||
| and because BCPs have no concept of "advancing in grade", there are | ||||
| no down-reference issues when a BCP refers to a document on the | ||||
| Standards Track. | ||||
| 5. Security Considerations | ||||
| This document is not known to create any new vulnerabilities for the | This document is not known to create any new vulnerabilities for the | |||
| internet. On the other hand, inappropriate or excessive use of the | Internet. On the other hand, inappropriate or excessive use of the | |||
| process might be considered a down-grade attack on the quality of | process might be considered a down-grade attack on the quality of | |||
| IETF standards, or worse, on the rigorous review of security aspects | IETF standards, or worse, on the rigorous review of security aspects | |||
| of standards. | of standards. | |||
| 6. Acknowledgments | 5. Acknowledgments | |||
| This document is the result of discussion within the IESG, with | This document is the result of discussion within the IESG, with | |||
| particular contribution by Harald Alvestrand, Steve Bellovin, Scott | particular contribution by Harald Alvestrand, Steve Bellovin, Scott | |||
| Bradner, Ned Freed, Jeff Schiller, and Bert Wijnen. | Bradner, Ned Freed, Allison Mankin, Jeff Schiller, and Bert Wijnen. | |||
| Normative References | Normative References | |||
| [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
| 3", BCP 9, RFC 2026, October 1996. | 3", BCP 9, RFC 2026, October 1996. | |||
| Informative References | Informative References | |||
| [RFC1818] Best Current Practices, J. Postel, T. Li, Y. Rekhter. RFC | ||||
| 1818, August 1995. | ||||
| [2223bis] "Instructions to Request for Comments (RFC) Authors", | [2223bis] "Instructions to Request for Comments (RFC) Authors", | |||
| draft-rfc-editor-rfc2223bis-07.txt. | draft-rfc-editor-rfc2223bis-07.txt. | |||
| [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |||
| April 1992. | April 1992. | |||
| [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- | |||
| Hashing for Message Authentication", RFC 2104, February | Hashing for Message Authentication", RFC 2104, February | |||
| 1997. | 1997. | |||
| End of changes. 18 change blocks. | ||||
| 62 lines changed or deleted | 93 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||