diff options
Diffstat (limited to 'doc/rfc/rfc4775.txt')
| -rw-r--r-- | doc/rfc/rfc4775.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4775.txt b/doc/rfc/rfc4775.txt new file mode 100644 index 0000000..314f3a4 --- /dev/null +++ b/doc/rfc/rfc4775.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group S. Bradner +Request for Comments: 4775 Harvard +BCP: 125 B. Carpenter, Ed. +Category: Best Current Practice T. Narten + IBM + December 2006 + + + Procedures for Protocol Extensions and Variations + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +Abstract + + This document discusses procedural issues related to the + extensibility of IETF protocols, including when it is reasonable to + extend IETF protocols with little or no review, and when extensions + or variations need to be reviewed by the IETF community. Experience + has shown that extension of protocols without early IETF review can + carry risk. The document also recommends that major extensions to or + variations of IETF protocols only take place through normal IETF + processes or in coordination with the IETF. + + This document is directed principally at other Standards Development + Organizations (SDOs) and vendors considering requirements for + extensions to IETF protocols. It does not modify formal IETF + processes. + + + + + + + + + + + + + + + + +Bradner, et al. Best Current Practice [Page 1] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Technical Risks in Extensions ...................................3 + 3. General Considerations ..........................................4 + 3.1. The Importance of Interoperability .........................4 + 3.2. Registered Values and the Importance of IANA Assignments ...5 + 3.3. Significant Extensions Require Technical Review ............5 + 3.4. Quality and Consistency ....................................6 + 3.5. The Role of Formal Liaisons ................................6 + 4. Procedure for Review of Extensions ..............................7 + 5. Some Specific Issues ...........................................10 + 6. Intellectual Property ..........................................10 + 7. Security Considerations ........................................10 + 8. IANA Considerations ............................................11 + 9. Acknowledgements ...............................................11 + 10. References ....................................................11 + 10.1. Normative References .....................................11 + 10.2. Informative References ...................................12 + +1. Introduction + + BCP 9 [RFC2026] is the current definition of the IETF standards + track. This process applies not only to the initial definition of a + protocol, but also to any subsequent updates, such that continued + interoperability can be guaranteed. However, it is not always clear + whether extensions to a protocol should be made within the IETF + process, especially when they originate outside the IETF community. + This document lays down guidelines and procedures for such + extensions. + + When developing protocols, IETF Working Groups (WGs) typically + include mechanisms whereby these protocols can be extended in the + future. It is, of course, a good principle to design extensibility + into protocols; a common definition of a successful protocol is one + that becomes widely used in ways not originally anticipated. Well- + designed extensibility mechanisms facilitate the evolution of + protocols and help make it easier to roll out incremental changes in + an interoperable fashion. At the same time, experience has shown + that extensibility features should be limited to what is clearly + necessary when the protocol is developed, and any later extensions + should be done carefully and with a full understanding of the base + protocol, existing implementations, and current operational practice. + However, it is not the purpose of this document to describe the + architectural principles of sound extensibility design. + + + + + + +Bradner, et al. Best Current Practice [Page 2] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + When extensions to IETF protocols are made within the IETF, the + normal IETF process is followed, including the normal processes for + IETF-wide review and IESG approval. Extensions developed in this way + should respect the same architectural principles and technical + criteria as any other IETF work. + + In addition to the IETF itself, other Standards Development + Organizations (SDOs), vendors, and technology fora may identify a + requirement for an extension to an IETF protocol. The question + addressed by this document is how such bodies should proceed. There + are several possible scenarios: + + 1. The requirement is straightforward and within the scope of + whatever extension mechanism the base protocol includes. + + 2. The requirement is, or may be, outside that scope, and: + 1. The IETF still has an active WG in the area; + 2. The IETF has no active WG, but has relevant expertise; + 3. The IETF no longer has a nucleus of relevant expertise. + + Especially in the latter three cases, there are technical risks in + extension design, described in the next section. These risks are + higher when extensions to IETF protocols are made outside the IETF + and without consulting the IETF. + + This document is focused on appropriate procedures and practices to + minimize the chance that extensions developed outside the IETF will + encounter these risks and, therefore, become useless or, worse, + damaging to interoperability. Architectural considerations are + documented elsewhere. This document is directed principally at other + SDOs and vendors considering requirements for extensions to IETF + protocols. It does not modify formal IETF processes. + + The IETF claims no special position. Everything said here about IETF + protocols would apply with equal force to protocols specified by any + SDO. The IETF should follow whatever procedures another SDO lays + down for extensions to its own protocols, if the IETF identifies a + need for such an extension. + +2. Technical Risks in Extensions + + Extensions may be developed without full understanding of why the + existing protocol was designed the way that it is -- e.g., what ideas + were brought up during the original development and rejected because + of some problem with them. Also, extensions could unintentionally + negate some key function of the existing protocol (such as security + or congestion control). Design choices can be made without analyzing + their impact on the protocol as a whole, and basic underlying + + + +Bradner, et al. Best Current Practice [Page 3] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + architectural principles of the protocol can be violated. Also, + there is a risk that mutually incompatible extensions may be + developed independently. + + Of course, the IETF itself is not immune to such mistakes, suggesting + a need for WGs to document their design decisions (including paths + rejected) and some rationale for those decisions, for the benefit of + both those within the IETF and those outside the IETF, perhaps years + later. + + Documentation of non-IETF extensions can sometimes be hard to obtain, + so assessing the quality of the specification, verifying + interoperability, and verifying compatibility with other extensions + (including past and future extensions) can be hard or impossible. + + A set of interrelated extensions to multiple protocols typically + carries a greater danger of interoperability issues or + incompatibilities than a simple extension. Consequently, it is + important that such proposals receive earlier and more in-depth + review than unitary extensions. + + All that can be said about extensions applies with equal or greater + force to variations -- in fact, by definition, protocol variations + damage interoperability. They must, therefore, be intensely + scrutinized. An extension adds features and, if well designed, + allows interoperability between old and new implementations. A + variation modifies features in such a way that old and new + implementations may not interoperate. Throughout this document, what + is said about extensions also applies to variations. + +3. General Considerations + +3.1. The Importance of Interoperability + + According to its Mission Statement [RFC3935], the IETF produces high + quality, relevant technical and engineering documents, including + protocol standards. The mission statement goes on to say that the + benefit of these standards to the Internet "is in interoperability - + that multiple products implementing a standard are able to work + together in order to deliver valuable functions to the Internet's + users". + + One consequence of this mission is that the IETF designs protocols + for the single Internet. The IETF expects its protocols to work the + same everywhere. Protocol extensions designed for limited + environments may be reasonable provided that products with these + extensions interoperate with products without the extensions. + Extensions that break interoperability are unacceptable when products + + + +Bradner, et al. Best Current Practice [Page 4] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + with and without the extension are mixed. It is the IETF's + experience that this tends to happen on the Internet even when the + original designers of the extension did not expect this to happen. + + Another consequence of this definition of interoperability is that + the IETF values the ability to exchange one product implementing a + protocol with another. The IETF often specifies mandatory-to- + implement functionality as part of its protocols so that there is a + core set of functionality sufficient for interoperability that all + products implement. The IETF tries to avoid situations where + protocols need to be profiled to specify which optional features are + required for a given environment, because doing so harms + interoperability on the Internet as a whole. + + The IETF, and in particular the IESG, will apply these considerations + when evaluating protocol extensions proposed inside or outside the + IETF. + +3.2. Registered Values and the Importance of IANA Assignments + + An extension is often likely to make use of additional values added + to an existing IANA registry (in many cases, simply by adding a new + "TLV" (type-length-value) field). It is essential that such new + values are properly registered by the applicable procedures, + including expert review where applicable (see BCP 26, [RFC2434]). + Extensions may even need to create new IANA registries in some cases. + + Experience shows that the importance of this is often underestimated + during extension design; designers sometimes assume that a new + codepoint is theirs for the asking, or even simply for the taking. + This is hazardous; it is far too likely that someone just taking a + protocol value will find that the same value will later be formally + assigned to another function, thus guaranteeing an interoperability + problem. + + In many cases, IANA assignment requests trigger a thorough technical + review of the proposal by a designated IETF expert reviewer. + Requests are sometimes refused after such a review. Thus, extension + designers must pay particular attention to any needed IANA + assignments and to the applicable criteria. + +3.3. Significant Extensions Require Technical Review + + Some extensions may be considered minor (e.g., adding a + straightforward new TLV to an application protocol, which will only + impact a subset of hosts) and some may be considered major (e.g., + adding a new IP option type, which will potentially impact every node + on the Internet). This is essentially a matter of judgment. It + + + +Bradner, et al. Best Current Practice [Page 5] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + could be argued that anything requiring at most Expert Review in + [RFC2434] is probably minor, and anything beyond that is major. + However, even an apparently minor extension may have unforeseen + consequences on interoperability. Thus, the distinction between + major and minor is less important than ensuring that the right amount + of technical review takes place in either case. In general, the + expertise for such review lies within the same SDO that developed the + original protocol. Therefore, the expertise for such review for IETF + protocols lies within the IETF. + + There may sometimes be doubt whether a particular proposal is or is + not truly a protocol extension. When in doubt, it is preferable to + err on the side of additional review. However, it should be noted + that if an 'extension' only consists of registering a new value with + IANA in a First Come First Served registry [RFC2434], this document + is not intended to require formal IETF review. Informal review by + experts may, nevertheless, be valuable. In other cases (Section 5), + there is a well-specified procedure for extensions that should be + followed. + + The only safe rule is that, even if an extension appears minor to the + person proposing it, early review by subject matter experts is + advisable. For protocols that have been developed in the IETF, the + appropriate forum for such review is the IETF, either in the relevant + WG or Area, or by individual IETF experts if no such WG exists. + +3.4. Quality and Consistency + + In order to be adequately reviewed by relevant experts, a proposed + extension must be documented in a clear and well-written + specification that IETF subject matter experts have access to and can + review. Ideally, such a document would be published as an Internet + Draft, using terminology and content that is sufficiently consistent + with the unextended specification that these experts can readily + identify the technical changes proposed at an early stage. + +3.5. The Role of Formal Liaisons + + The IETF has formal liaisons in place with a number of SDOs; + documentation of the liaison process is in [RFC4052], [RFC4053], and + [RFC4691]. These liaison channels should be used as relevant for + discussing and reviewing extensions, as should informal communication + at the engineering level (for example, experts from other SDOs are + welcome to participate in IETF meetings and mailing lists). Where + formal liaison does not exist, the point of contact in the IETF + should be the Chairs of relevant WGs, the most appropriate Area + Director, or, in case of doubt, the IESG as a whole. + + + + +Bradner, et al. Best Current Practice [Page 6] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + +4. Procedure for Review of Extensions + + In some cases, explicit provision is made in the relevant RFCs for + extending individual IETF protocols. Nothing in this document + overrides such procedures. Some such cases are mentioned in + Section 5. + + There are several ways in which an extension to an IETF protocol can + be considered for publication as an RFC: + + 1. Extensions to IETF protocols developed within the IETF will be + subject to the normal IETF process, exactly like new designs. It + is not suggested that this is a panacea; appropriate cross- + working-group and cross-area review is needed within the IETF to + avoid oversights and mistakes. + + 2. Extensions to IETF protocols discussed in an IRTF Research Group + may well be the prelude to regular IETF discussion. However, a + Research Group may desire to specify an experimental extension + before the work is mature enough for IETF processing. In this + case, the Research Group is required to involve appropriate IETF + or IANA experts in their process to avoid oversights. + + 3. Extensions to IETF protocols described in Independent Submissions + to the RFC Editor are subject to IESG review, currently described + in BCP 92 [RFC3932]. If appropriate, the IESG advises the RFC + Editor that full IETF processing is needed, or that relevant IANA + procedures need to be followed before publication can proceed. + Note that Independent Submissions cannot be placed on the IETF + Standards Track; they would need to enter full IETF processing. + + Where vendors or other SDOs identify a requirement for extending an + IETF protocol, their first step should be to consider the scenarios + listed in Section 1. If the requirement is straightforward and + within the scope of a documented extension mechanism, the way is + clear, and the documented mechanism must be followed. If these two + conditions are not met, the next step should be to contact the + relevant IETF Area Director to check whether there is an active WG in + the area or, at least, relevant expertise available in the IETF. At + this point, it will be possible to select the most appropriate of the + above three routes. Regular IETF process is most likely to be + suitable, assuming sufficient interest can be found in the IETF + community. IRTF process is unlikely to be suitable unless there is a + genuine research context for the proposed extension. + + + + + + + +Bradner, et al. Best Current Practice [Page 7] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + In the event that the IETF no longer has relevant expertise, there + are still two choices to discuss with the Area Director: bring the + work to the IETF (i.e., the IETF imports expertise) or reach mutual + agreement to do the work elsewhere (i.e., the IETF explicitly exports + change control). + + In the case of an SDO that identifies a requirement for a + standardized extension, a standards development process within the + IETF (while maintaining appropriate liaison) is strongly recommended + in preference to publishing a non-IETF standard. Otherwise, the + implementor community will be faced with a standard split into two or + more parts in different styles, obtained from different sources, with + no unitary control over quality, compatibility, interoperability, and + intellectual property conditions. Note that, since participation in + the IETF is open, there is no formality or restriction for + participants in other SDOs choosing to work in the IETF as well. In + some cases (see Section 5), the IETF has well-defined procedures for + this in place. + + Naturally, SDOs can and do develop scenarios, requirements, and + architectures based on IETF specifications. It is only actual + protocol extensions and changes that need to go through the IETF + process. However, there is large risk of wasted effort if + significant investment is made in planning stages for use of IETF + technology without early review and feedback from the IETF. Other + SDOs are encouraged to communicate informally or formally with the + IETF as early as possible, to avoid false starts. Early technical + review in a collaborative spirit is of great value. Each SDO can + "own" its ideas and discuss them in its own fora, but should start + talking to the IETF experts about those ideas the moment the idea is + well formulated. It is understood that close collaboration may be + needed in order that the IETF experts correctly understand the + systems architecture envisaged by the other SDO. This is much + preferable to a situation where another SDO presents the IANA and the + IETF with a 'fait accompli.' + + Vendors that identify a requirement for an extension are strongly + recommended to start informal discussion in the IETF and to publish a + preliminary Internet Draft describing the requirements. This will + allow the vendor, and the community, to evaluate whether there is + community interest and whether there are any major or fundamental + issues. However, in the case of a vendor that identifies a + requirement for a proprietary extension that does not generate + interest in the IETF (or IRTF) communities, an Independent Submission + to the RFC Editor is strongly recommended in preference to publishing + a proprietary document. Not only does this bring the draft to the + + + + + +Bradner, et al. Best Current Practice [Page 8] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + attention of the community, but it also ensures a minimum of review + [RFC3932], and (if published as an RFC) makes the proprietary + extension available to the whole community. + + If, despite these recommendations, a vendor or SDO does choose to + publish its own specification for an extension to an IETF protocol, + the following guidance applies: + + o Extensions to IETF protocols should be well, and publicly, + documented, and reviewed at an early stage by the IETF community + to be sure that the extension does not undermine basic assumptions + and safeguards designed into the protocol (such as security + functions) or its architectural integrity. + + o Vendors and other SDOs are formally requested to submit any such + proposed publications for IETF review, and are invited to actively + participate in the IETF process. Submission may be by an + established liaison channel if it exists, or by direct + communication with the relevant WG or the IESG. This should be + done at an early stage, before a large investment of effort has + taken place, in case basic problems are revealed. When there is a + formal liaison in place between the other SDO and the IETF, the + liaison channel should be used to ensure that review takes place, + both by relevant experts and by established review teams or + Directorates within the IETF. If there is no formal liaison, the + other SDO or vendor should ask the IESG (or a relevant Area + Director) to obtain such reviews. Note that general aspects such + as security, internationalization, and management may need review, + as well as the protocol as such. + + o In the case of extensions involving only routine IANA parameter + assignments, for which there is an underlying IETF specification + containing clear IANA Considerations, this request is satisfied as + long as those considerations are satisfied (see [RFC2434]). + Anything beyond this requires an explicit protocol review by + experts within the IETF. + + o Note that, like IETF specifications, such proposed publications + must include an IANA Considerations section to ensure that + protocol parameter assignments that are needed to deploy + extensions are not made until after a proposed extension has + received adequate review, and then to ensure that IANA has precise + guidance on how to make those assignments. + + + + + + + + +Bradner, et al. Best Current Practice [Page 9] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + +5. Some Specific Issues + + It is relatively common for MIB modules, which are all, in effect, + extensions of the SMI data model, to be defined or extended outside + the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and + reviewers. + + A number of protocols have foreseen experimental values for certain + IANA parameters, so that experimental usages and extensions may be + tested without need for a special parameter assignment. It must be + stressed that such values are not intended for production use or as a + way to evade the type of technical review described in this document. + See [RFC3692] and [RFC4727]. + + RADIUS [RFC2865] is designed to carry attributes and allow definition + of new attributes. But it is important that discussion of new + attributes involve the IETF community of experts knowledgeable about + the protocol's architecture and existing usage in order to fully + understand the implications of a proposed extension. Adding new + attributes without such discussion creates a high risk of + interoperability or functionality failure. For this reason among + others, the IETF has an active RADIUS Extensions WG at the time of + writing. + + There are certain documents that specify a change process for + specific IETF protocols, such as: + The SIP change process [RFC3427] + The (G)MPLS change process [CHANGEPROC] + + This document does not override such specific change processes. + +6. Intellectual Property + + All IETF documents fall under the IETF's intellectual property rules, + BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, + there are restrictions on the production of derivative works, and + there are rights that remain with the original authors. Anybody + outside the IETF considering an extension based on an IETF document + must bear these legal restrictions and rights in mind. + +7. Security Considerations + + An extension must not introduce new security risks without also + providing an adequate counter-measure, and in particular it must not + inadvertently defeat security measures in the unextended protocol. + This aspect must always be considered during IETF review. + + + + + +Bradner, et al. Best Current Practice [Page 10] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + +8. IANA Considerations + + The IETF requests IANA to pay attention to the requirements of this + document when requested to make protocol parameter assignments for + vendors or other SDOs, i.e., to respect the IANA Considerations of + all RFCs that contain them, and the general considerations of BCP 26 + [RFC2434]. + +9. Acknowledgements + + This document is heavily based on an earlier draft under a different + title by Scott Bradner and Thomas Narten. + + That earlier draft stated: The initial version of this document was + put together by the IESG in 2002. Since then, it has been reworked + in response to feedback from John Loughney, Henrik Levkowetz, Mark + Townsley, Randy Bush, Bernard Aboba, and others. + + Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson, + Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn + Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments + on this document. + + Sam Hartman contributed the section on interoperability. + + This document was produced using the xml2rfc tool [RFC2629]. + +10. References + +10.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., + and B. Rosen, "Change Process for the Session Initiation + Protocol (SIP)", BCP 67, RFC 3427, December 2002. + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, January 2004. + + [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: + Procedures", BCP 92, RFC 3932, October 2004. + + + + +Bradner, et al. Best Current Practice [Page 11] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + + [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", + BCP 95, RFC 3935, October 2004. + + [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, + RFC 3978, March 2005. + + [RFC3979] Bradner, S., "Intellectual Property Rights in IETF + Technology", BCP 79, RFC 3979, March 2005. + + [RFC4052] Daigle, L. and Internet Architecture Board, "IAB + Processes for Management of IETF Liaison Relationships", + BCP 102, RFC 4052, April 2005. + + [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures + for Handling Liaison Statements to and from the IETF", + BCP 103, RFC 4053, April 2005. + + [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB + Documents", BCP 111, RFC 4181, September 2005. + + [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, + ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. + +10.2. Informative References + + [CHANGEPROC] Andersson, L. and A. Farrel, "Change Process for + Multiprotocol Label Switching (MPLS) and Generalized + MPLS (GMPLS) Protocols and Procedures", Work in + Progress, October 2006. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison + to Another Organization", RFC 4691, October 2006. + + + + + + + + + + + + +Bradner, et al. Best Current Practice [Page 12] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + +Authors' Addresses + + Scott Bradner + Harvard University + 29 Oxford St. + Cambridge, MA 02138 + US + + EMail: sob@harvard.edu + + + Brian Carpenter, Ed. + IBM + 8 Chemin de Blandonnet + 1214 Vernier + Switzerland + + EMail: brc@zurich.ibm.com + + + Thomas Narten + IBM + 3039 Cornwallis Ave. + PO Box 12195 - BRQA/502 + Research Triangle Park, NC 27709-2195 + US + + EMail: narten@us.ibm.com + + + + + + + + + + + + + + + + + + + + + + + +Bradner, et al. Best Current Practice [Page 13] + +RFC 4775 Procedures for Protocol Extensions December 2006 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (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. + + 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, THE IETF TRUST, + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Bradner, et al. Best Current Practice [Page 14] + |