idnits 2.17.1 draft-housley-implementer-obligations-02.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 (10 May 2014) is 3632 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: 10 November 2014 10 May 2014 6 Expectations of Implementers of IETF Protocols 7 9 Abstract 11 By choosing to implement an IETF protocol, one is expected to follow 12 the specification, associated best current practices, and IANA 13 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) 2014 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 This document provides advice to implementers of IETF protocols to 54 improve interoperability of their implementations. 56 IETF protocols foster interoperability. This interoperability brings 57 great benefits. IETF protocols are building blocks for many products 58 and services, and they enable innovation. Yet, IETF standards are 59 voluntary standards. No one is required to implement them. 60 Implementation is a choice. By making this choice, an implementor is 61 expected to: 63 (1) Follow the protocol specification; 64 (2) Follow associated Best Current Practices (BCPs); and 65 (3) Follow associated IANA registry practices. 67 When implementers meet these expectations, protocols interoperate as 68 intended by the IETF. 70 These expectations reflect the fundamental philosophy of the IETF. 71 That is, interoperability is achieved when people choose to 72 cooperate. By taking these actions one can expect to achieve greater 73 interoperability with others. 75 2. First Expectation: Follow the Protocol Specification 77 To repeat, IETF protocols foster interoperability, and this 78 interoperability brings great benefits. If one does not follow the 79 protocol specification, then interoperability is jeopardized. 81 Of course, one should follow Postel's Law while implementing the 82 specification: 84 In general, an implementation should be conservative in its 85 sending behavior, and liberal in its receiving behavior. [RFC760] 87 Following Postel's Law simply increases interoperability. One should 88 be careful to send well-formed protocol data units and carefully 89 follow elements of procedure; which avoids surprises for 90 communicating peers that use other implementations. On the other 91 hand, one should accept any protocol data unit that can be 92 interpreted, which heightens interoperability in the face of 93 technical errors by others. 95 Many protocol specifications are living documents; things that change 96 over time. An implementer should plan to maintain their 97 implementation. It is not sufficient to do an initial implementation 98 of the protocol. One needs to apply changes as they come out. The 99 most obvious and urgent example involves specification revisions that 100 fix security issues that are found after the initial publication of a 101 protocol specification. 103 3. Second Expectation: Follow Associated Best Current Practices 105 Best Current Practices (BCPs) about IETF protocols (not the BCPs that 106 define IETF processes and procedures) are intended to standardize 107 practices. 109 The Internet is composed of networks operated by a great variety of 110 organizations, with diverse goals and rules. By following the BCPs, 111 implementers, operators, and administrators are able to provide a 112 common experience when using the protocol, regardless of their point 113 of attachment to the Internet. 115 Sometimes BCPs are referenced in the protocol specification. Often 116 the implementer needs to look through the BCP index to find related 117 BCPs. 119 4. Third Expectation: Follow Associated IANA Registry Practices 121 Many IETF protocols use identifiers consisting of constants and other 122 well-known values. Even after a protocol has been defined and 123 deployed, new values may be needed. To ensure that such quantities 124 have consistent values and interpretations across all 125 implementations, assignment is administered by a central authority, 126 the Internet Assigned Numbers Authority (IANA). In order to manage a 127 namespace (which might also be called an assigned number, an assigned 128 value, a code point, a a protocol constant, or a protocol parameter) 129 in support of a particular IETF protocol, IANA is given instructions 130 and conditions under which new values should be assigned or when 131 modifications to existing values can be made. 133 Implementers are expected to follow the IANA registry practices 134 associated with the protocol, especially in the assignment of new 135 values. By following these practices, other implementations will 136 learn about new values and make the appropriate updates to handle 137 them properly. 139 Note that IP addresses and the top levels of the DNS name hierarchy 140 are managed in IANA registries [RFC2860]. Please follow the IANA 141 registry practices for the assignment of special IP addresses and 142 top-level DNS names in the rare cases where such values are needed. 144 5. Security Considerations 146 This document calls for implementers to follow the protocol 147 specification, follow associated best current practices, and follow 148 IANA registry practices. These actions improve interoperability, and 149 these actions may also reduce security incidents due to incomplete 150 protocol implementations. 152 It is not sufficient to do an initial implementation of the protocol. 153 Maintenance is needed to apply changes as they come out in the 154 future, especially to fix security issues that are found after the 155 initial publication of a protocol specification. 157 Security processing is an exception to Postel's Law. For example, a 158 password that is close, but not exactly right, is not sufficient to 159 gain access. Processing associated with integrity, authentication, 160 access control, and confidentiality mechanisms cannot be forgiving. 162 6. IANA Considerations 164 This document has no actions for IANA. 166 7. Acknowledgements 168 Thanks to the people that reviewed this document and suggested 169 important improvements, including Bernard Aboba, Richard Barnes, 170 Scott Brim, Randy Bush, John Curran, Lars Eggert, Adrian Farrel, 171 Stephen Farrell, and Joel Jaeggli. 173 8. Normative References 175 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 176 Understanding Concerning the Technical Work of the 177 Internet Assigned Numbers Authority", RFC 2860, June 2000. 179 9. Informative References 181 [RFC760] Postel, J., "DoD standard Internet Protocol", RFC 760, 182 January 1980. 184 Author's Address 186 Russ Housley 187 Vigil Security, LLC 188 918 Spring Knoll Drive 189 Herndon, VA 20170 190 USA 192 EMail: housley@vigilsec.com