idnits 2.17.00 (12 Aug 2021) /tmp/idnits52410/draft-housley-implementer-obligations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 September 2013) is 3176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Informational Vigil Security 4 Expires: 9 March 2014 9 September 2013 6 Obligations of Implementers of IETF Protocols 7 9 Abstract 11 By choosing to implement an IETF protocol, one accepts an obligation 12 to follow the specification, associated best current practices, and 13 IANA registry practices. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 IETF protocols foster interoperability. This interoperability brings 54 great benefits. IETF protocols are building blocks for many products 55 and services, and they enable innovation. Yet, IETF standards are 56 voluntary standards. No one is required to implement them. 57 Implementation is a choice. By making this choice, implementor 58 accept three obligations: 60 (1) Follow the protocol specification; 61 (2) Follow associated Best Current Practices (BCPs); and 62 (3) Follow associated IANA registry practices. 64 Following these obligations allow protocols to interoperate as 65 intended by the IETF. 67 2. First Obligation: Follow the Protocol Specification 69 To repeat, IETF protocols foster interoperability, and this 70 interoperability brings great benefits. If one does not follow the 71 protocol specification, then interoperability is jeopardized. 73 Of course, one should follow Postel's Law while implementing the 74 specification: 76 In general, an implementation should be conservative in its 77 sending behavior, and liberal in its receiving behavior. [RFC760] 79 Following Postel's Law simply increases interoperability. One should 80 be careful to send well-formed protocol data units and carefully 81 follow elements of procedure; which avoids surprised for 82 communicating peers that use other implementations. On the other 83 hand, one should accept any protocol data unit that can be 84 interpreted, which heightens interoperability in the face of 85 technical errors by others. 87 3. Second Obligation: Follow Associated Best Current Practices 89 Best Current Practices (BCPs) about IETF protocols (not the BCPs that 90 define IETF processes and procedures) are intended to standardize 91 practices. 93 The Internet is composed of networks operated by a great variety of 94 organizations, with diverse goals and rules. By following the BCPs, 95 implementers, operators, and administrators are able to provide a 96 common experience when using the protocol, regardless of their point 97 of attachment to the Internet. 99 4. Third Obligation: Follow Associated IANA Registry Practices 101 Many IETF protocols use of identifiers consisting of constants and 102 other well-known values. Even after a protocol has been defined and 103 deployed, new values may be needed. To ensure that such quantities 104 have consistent values and interpretations across all 105 implementations, assignment is administered by a central authority, 106 the Internet Assigned Numbers Authority (IANA). In order to manage a 107 namespace (which might also be called an assigned number, an assigned 108 value, a code point, a a protocol constant, or a protocol parameter) 109 in support of a particular IETF protocol, IANA is given instructions 110 and conditions under which new values should be assigned or when 111 modifications to existing values can be made. 113 Implementers are obligated to follow the IANA registry practices 114 associated with the protocol, especially in the assignment of new 115 values. By following these practices, other implementations will 116 learn about new values and make the appropriate updates to handle 117 them properly. 119 Note that IP addresses and the top levels of the DNS name hierarchy 120 are managed in IANA registries [RFC2860]. Please follow the IANA 121 registry practices for the assignment of special IP addresses and 122 top-level DNS names in the rare cases where such values are needed. 124 5. Security Considerations 126 This document calls for implementers to follow the protocol 127 specification, follow associated best current practices, and follow 128 IANA registry practices. These actions should greatly improve 129 interoperability, and these actions may also reduce security 130 incidents due to incomplete protocol implementations. 132 Security processing is an exception to Postel's Law. For example, a 133 password that is close, but not exactly right, is not sufficient to 134 gain access. Processing associated with integrity, authentication, 135 access control, non-repudiation, and confidentiality mechanisms 136 cannot be forgiving. 138 6. IANA Considerations 140 {{ RFC Editor: Please remove this section prior to publication. }} 142 This document has no actions for IANA. 144 7. References 146 7.1. Normative References 148 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 149 Understanding Concerning the Technical Work of the 150 Internet Assigned Numbers Authority", RFC 2860, June 2000. 152 7.2. Informative References 154 [RFC760] Postel, J., "DoD standard Internet Protocol", RFC 760, 155 January 1980. 157 Author's Address 159 Russ Housley 160 Vigil Security, LLC 161 918 Spring Knoll Drive 162 Herndon, VA 20170 163 USA 165 EMail: housley@vigilsec.com