idnits 2.17.1 draft-lonvick-private-tax-15.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2018) is 2099 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 761 (Obsoleted by RFC 793, RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1067 (Obsoleted by RFC 1098) -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 2058 (Obsoleted by RFC 2138) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick 3 Internet-Draft July 27, 2018 4 Intended status: Informational 5 Expires: January 28, 2019 7 A Taxonomy on Private Use Fields in Protocols 8 draft-lonvick-private-tax-15.txt 10 Abstract 12 This document attempts to provide some clarification for the way that 13 private use fields have been used in protocols developed in the IETF. 14 It is strictly a taxonomy of what has been published and offers no 15 advice about how to design or use private use options. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 28, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Note on References . . . . . . . . . . . . . . . . . . . . 4 67 2. Origins of the Private Use Namespace . . . . . . . . . . . . . 4 68 3. Observed Characteristics of Private Use Options . . . . . . . 5 69 3.1. Start of Authority . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Focus of the Namespace . . . . . . . . . . . . . . . . . . 7 71 4. Examples of Private Use Options . . . . . . . . . . . . . . . 7 72 4.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.6. Secure Shell . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.7. YANG and NETCONF . . . . . . . . . . . . . . . . . . . . . 12 79 4.8. Extensible Provisioning Protocol . . . . . . . . . . . . . 13 80 5. Observations . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 6. Authoritative Guidance . . . . . . . . . . . . . . . . . . . . 15 82 7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 Simply put, communications protocols are standardized ways for 94 computing entities to convey information. Within each communications 95 protocol, there must be quantified pieces of information that will be 96 communicated, and there may be non-standardized pieces that can be 97 communicated. Since one of the goals of standards is to provide 98 interoperability, all parties participating in any communications 99 protocol must be aware of how to deal with all fields in the 100 protocol. 102 Some protocols have reserved fields for private and experimental use. 103 Indeed, having options reserved for testing and experimentation has 104 been found to be beneficial to the community as has been outlined in 105 "Assigning Experimental and Testing Numbers Considered Useful" 106 [RFC3692]. 108 Fields reserved for private use cannot provide interoperability 109 unless their use is fully documented in openly available documents. 110 This specification uses examples of some protocols to exemplify how 111 some private use options are used. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in "Key words for use in 118 RFCs to Indicate Requirement Levels" [RFC2119]. 120 1.2. Nomenclature 122 In this document, the following words are defined to prevent 123 ambiguity. Some of these words have not been used in the referenced 124 works but their meanings can be ascertained and applied. 126 o Standard option - a field in a protocol frame that may only use 127 values that are strictly defined within a specification 129 o Private use option - a field in a protocol frame that is reserved 130 for private, experimental, testing, or local use only namespaces. 132 o Namespace - the set of possible values a field may contain; its 133 actual content may be a name, a number, or another kind of value. 135 Additionally, the terms "Start of Authority" and "Focus of the 136 Namespace" are defined within their respective contexts and further 137 discussed below. 139 The name "Start of Authority" comes from the domain name system 140 configuration file which describes a "SoA" in "DOMAIN NAMES - 141 CONCEPTS AND FACILITIES" [RFC1034] and "DOMAIN NAMES - IMPLEMENTATION 142 AND SPECIFICATION" [RFC1035]. This includes the person or entity who 143 has ultimate control and decision making powers over the scope of the 144 domain. Some liberties have been taken with using this name in this 145 specification, but the intent is to identify an authoritative source 146 for the namespace. 148 1.3. Note on References 150 In many cases throughout this document, RFCs are referenced even 151 though they are not the most current version of their respective 152 protocol. This is usually done to reference the first occurrence of 153 a private use option, or to point out a distinct feature in that 154 specification. When an RFC is referenced that is not the current 155 version, the reference will be followed by the RFC number of the 156 current version in curly braces. 158 2. Origins of the Private Use Namespace 160 Some standards permit private use options in different ways, while 161 others do not. The "Time Protocol" [RFC0868] is an example of a 162 protocol that only conveys standardized information; there is no way 163 to use private options and no way to add anything other than what is 164 specified in the document. In a more open way, "DOD STANDARD 165 TRANSMISSION CONTROL PROTOCOL" [RFC0761] {[RFC0793]} {[RFC7805]} does 166 have "options" but they must be registered through the IANA [IANAtcp] 167 before use, which does not leave any room for optional information 168 supplied by equipment vendors, network operators, or experimenters. 169 An even more open way may be seen in "Vendor-Identifying Vendor 170 Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)" 171 [RFC3925], which allows for vendor specific options that do not need 172 to be registered with anyone. 174 For the case of TCP [RFC0761] {[RFC0793]} {[RFC7805]}, standard 175 options are expected; senders may use them and receivers may be 176 configured to act upon that information, or to ignore it. If an 177 experimenter wants to add an option, they will have to create a new 178 IETF RFC with specific details, or obtain approval from the IESG to 179 have the IANA add to the registry [IANAtcp]. Similarly, if equipment 180 vendors Foo and Bar were to have a need for a similar option within 181 TCP, they would each have to go through the process to add to the 182 registry. On the other hand, if a properly crafted multipurpose 183 private use option were to be registered, such as in the case of 184 multiple vendor instances within "DHCPv4" [RFC3925], then vendors and 185 experimenters would each be able to use it for their own purposes as 186 long as all network participants could easily differentiate between 187 the entities using the option. 189 "Guidelines for Writing an IANA Considerations Section in RFCs" 190 [RFC2434] {[RFC8126]} describes that values of specific namespaces 191 may either be registered with the IANA, or not. In most cases, there 192 are well defined values for namespaces. However, as the document 193 explains, not all namespaces require centralized administration. In 194 that document, it seems to be assumed that private use namespaces 195 will be domain specific and it will be up to the administrators of 196 any domain to avoid conflicts. The first example given about private 197 use namespaces refers to "Dynamic Host Configuration Protocol" 198 [RFC2131] and presumably "DHCP Options and BOOTP Vendor Extensions" 199 [RFC2132]. In this the example states that "site-specific options in 200 DHCP have significance only within a single site". As noted below 201 this became a problem that was rectified in a later revision of DHCP. 203 Later works identified a need to place a scope on private use 204 namespaces. The second example of private use namespaces in the IANA 205 guidelines [RFC2434] {[RFC8126]} is from "STANDARD FOR THE FORMAT OF 206 ARPA INTERNET TEXT MESSAGES" [RFC0822] {[RFC5322]} which describes X- 207 headers. There was no effort made to control the namespace and the 208 use of the namespace was removed when the specification was updated 209 in 2001 in "Internet Message Format" [RFC2822] {[RFC5322]}. 211 3. Observed Characteristics of Private Use Options 213 This section summarizes the observed characteristics of some private 214 use options that have been developed and deployed. 216 There appear to be three quantifiable characteristics of private use 217 options: 219 o Start of Authority 221 o Focus of the Namespace 223 o Value of the Option 225 3.1. Start of Authority 227 A private use option requires a path to an origin that has the 228 authority to create and maintain the option. If the goal for an 229 origin is to disambiguate each focus of a namespace, then the 230 referent most often seen has been globally unique, and not dependent 231 upon local interpretation. 233 Likely, the first private use option with a globally unique source 234 was defined in the "Structure and Identification of Management 235 Information for TCP/IP-based Internets" [RFC1155] which was first 236 used in "A Simple Network Management Protocol" [RFC1067] {[RFC1157]} 237 (SNMP). The globally unique origin in SNMP is the International 238 Standards Organization [ISO] which is accredited by the United 239 Nations to maintain this structure. 241 While SNMP used the entire OBJECT IDENTIFIER with the prefix, other 242 protocols only used the Private Enterprise Number [IANApen] (PEN) as 243 a truncated identification of an origin. This reduced the length of 244 the identifier but continued to provide a unique identifier through a 245 globally managed namespace. 247 The PEN is sourced by the Internet Assigned Numbers Authority (IANA). 248 PENs may be viewed as being similar to domain names in that they are 249 acquired by individuals, corporations, or other organizations. A 250 notable difference is that when domain names fall into disuse they 251 may be acquired and used by entirely different people or 252 organizations - as per the conditions set forth by the Internet 253 Corporation for Assigned Names and Numbers [ICANN], the source of the 254 domain names. The structure of the PEN registry does not place any 255 limits on the time that a PEN will be active or associated with the 256 requester. This is no different from many other registries 257 maintained by the IANA; they are just a snapshot at the time of the 258 reservation based on the information required by the IANA and 259 provided by the applicant. This eternal association of the PEN, 260 versus the ephemeral association of domain names, has not been shown 261 to present any problems to private use options. This may, in fact, 262 be a feature as this methodology ensures that these namespaces stay 263 unique for the foreseeable future. 265 Some additional information on the PEN may be found in "Enterprise 266 Number for Documentation Use" [RFC5612], and in "Private Enterprise 267 Number (PEN) practices and Internet Assigned Numbers Authority (IANA) 268 registration considerations" [I-D.liang-iana-pen]. 270 An alternative to using a numerical indicator such as the OBJECT 271 IDENTIFIER or PEN, is to use textual strings such as names. 273 Domain names may be more ephemeral than eternal. Unlike PENs that 274 usually become unserviceable when their owning organization goes out 275 of business, domain names that fall into disuse may be acquired and 276 used by entirely different organizations. Similar to the use of 277 PENs, there have not been any problems reported from this from normal 278 use. 280 Uniform Resource Names (URNs) have also been used to convey options. 282 They seem to provide flexibility for many different needs. URNs were 283 first defined in "Uniform Resource Names (URN) Namespace Definition 284 Mechanisms" [RFC3406] {[RFC8141]}. "An IETF URN Sub-namespace for 285 Registered Protocol Parameters" [RFC3553] provides guidance for ways 286 to use URNs as protocol parameters and how to define a start of 287 authority. 289 3.2. Focus of the Namespace 291 Once the start of authority is established as a globally unique 292 source, an actual option, or in some cases multiple options, may be 293 specified. This has usually been seen to be an indicator of what 294 value is expected. Within the domain established by the start of 295 authority, the focus of each value has been seen to be unique. 297 In a very simple example, a private use option may consist of 298 "SoA"+"focus"="value". The SoA will be unique and will specify the 299 start of authority. The focus will be unique as long as the start of 300 authority maintains that uniqueness; e.g., it would be poor form for 301 a private enterprise to define a focus, then to redefine it at a 302 later time. 304 4. Examples of Private Use Options 306 This section contains a review of RFCs that allow the use of private 307 use options. 309 4.1. SNMP 311 SNMP is syntactically complex but has features in the GetRequest PDU 312 that are consistent with the observed characteristics of private use 313 options. The structure of management information (SMI) is currently 314 defined by the "Structure of Management Information Version 2 315 (SMIv2)" [RFC2578]. SMI is a well described tree of OBJECT 316 IDENTIFIERs (OIDs). OIDs have an origin and a path for defined 317 object identifiers which this document describes as standard options. 318 It also allows for experimental and vendor specific object 319 identifiers, which are described as private use options in this 320 document. The IANA maintains a registry of these Network Management 321 Parameters [IANAsmi]. 323 As was noted, the globally unique origin in SNMP is the International 324 Standards Organization [ISO] which is accredited by the United 325 Nations to maintain this structure. 327 The Internet subtree of experimental OBJECT IDENTIFIERs starts with 328 the prefix: 1.3.6.1.3. 330 The Internet subtree of private enterprise OBJECT IDENTIFIERs starts 331 with the prefix: 1.3.6.1.4.1. and is followed by a Private Enterprise 332 Number [IANApen] (PEN) and then the objects defined by that 333 enterprise. After the vendor identifier (the PEN) in the management 334 information base (MIB), a vendor may create many different trees to 335 identify objects. This may result in a very large number of OBJECT 336 IDENTIFIERs, each of which is an identifier, or focus, of a 337 namespace. Each of these are uniquely identified by the vendor and 338 do not require registration with any coordinating authority. 340 The last part of each OBJECT IDENTIFIER is the focus and a 341 placeholder for its value; the varbind. In a GetRequest the SNMP 342 Manager (the client) fills the first part of the varbind with the 343 object identifier. The other portion is transmitted with an ASN.1 344 NULL value. In a typical case, the SNMP Agent (the server) responds 345 by replacing the NULL with the actual value in the response. Since 346 this field is defined by the vendor, it may actually be a 347 concatenation of values. 349 The SetRequest PDU is similar to the GetRequest PDU in that it has an 350 OID and may use a PID to identify the objects, however, the varbind 351 is populated differently than in a GetRequest PDU. The other PDUs 352 also use the OID and may use a PID, but behave differently than the 353 GetRequest PID. 355 Specific codes, known as error-indexes, are used to indicate when a 356 request cannot be processed because a device does not understand a 357 request. 359 4.2. RADIUS 361 "The Remote Authentication Dial In User Service (RADIUS)" [RFC2058] 362 {[RFC2865]} specification documented how to use just the PEN (without 363 the rest of the SMI path to the root) to allow "vendors" to 364 articulate their own options. In that document, these are called 365 Vendor-Specific Attributes (VSA). 367 There are many attributes defined in RADIUS [RFC2058] {[RFC2865]} 368 which may be considered to be standard options. Each of these 369 attributes is specified within a "type length value" (TLV) container. 370 For this protocol, the attribute "type" is a specific numerical value 371 which differentiates it from other attributes. 373 One example of a RADIUS standard option is Type 26, which denotes the 374 Vendor Specified Attribute. It is "available to allow vendors to 375 support their own extended Attributes not suitable for general 376 usage". The PEN of the "vendor" starts the "value" which should then 377 include a subsequent nested TLV so the vendor may define and 378 enumerate their own options within that field. 380 As noted above, the globally unique origin for "RADIUS" [RFC2865] is 381 the PEN. The remainder of the Attribute field after the PEN is 382 deliberately undefined in the specification. It is practically 383 suggested that the field contain embedded TLVs. Each vendor may then 384 have conflicting "types" (e.g. "1") which would be disambiguated by 385 the origin. For example [PEN="N", type="1"] is different from 386 [PEN="M", type="1"]. 388 The values for each type are bounded by the length of the attribute. 389 In some cases, it is feasible that a value has no length. In that 390 case, the transmission of the type alone, has been seen to be a 391 signal of some sort to the receiver. 393 The original specification of [RFC2058] {[RFC2865]} provided guidance 394 that invalid packets were to be silently discarded. That was 395 augmented in [RFC2865] as follows: 397 o Servers not equipped to interpret the vendor-specific information 398 sent by a client MUST ignore it (although it may be reported). 400 o Clients which do not receive desired vendor-specific information 401 SHOULD make an attempt to operate without it, although they may do 402 so (and report they are doing so) in a degraded mode. 404 o The Attribute-Specific field is dependent on the vendor's 405 definition of that attribute. 407 o It SHOULD be encoded as a sequence of vendor type / vendor length 408 / value fields. 410 o Multiple subattributes MAY be encoded within a single Vendor- 411 Specific Attribute, although they do not have to be. 413 4.3. Mobile IP 415 "Mobile IP Vendor Specific Extensions" [RFC3115] defines two 416 extensions that can be used for making organization specific 417 extensions by vendors/organizations for their own specific purposes 418 for Mobile IP [RFC2002] {[RFC5944]}. 420 In that specification, two TLVs have been defined to contain private 421 use options. These are collectively called Vendor/Organization 422 Specific Extensions (VSE). 424 o When the Critical Vendor/Organization Specific Extension (CVSE) is 425 encountered but not recognized, the message containing the 426 extension MUST be silently discarded. 428 o When a Normal Vendor/Organization Specific Extension (NVSE) is 429 encountered but not recognized, the extension SHOULD be ignored, 430 but the rest of the Extensions and message data MUST still be 431 processed. 433 Having two VSEs of this nature for private use options is consistent 434 with the original Mobile IP specification [RFC2002] {[RFC5944]} which 435 states: 437 When an Extension numbered in either of these sets within the 438 range 0 through 127 is encountered but not recognized, the message 439 containing that Extension MUST be silently discarded. When an 440 Extension numbered in the range 128 through 255 is encountered 441 which is not recognized, that particular Extension is ignored, but 442 the rest of the Extensions and message data MUST still be 443 processed. 445 The structure of the origin, type, and value of the CVSEs and NVSEs 446 for "Mobile IP" [RFC3115] has been seen to be used in a manner very 447 similar to that of RADIUS. The PEN is the origin and types and 448 values may be stacked within the field. The values are constrained 449 by the respective lengths of the types or subtypes. 451 4.4. DHCP 453 The introduction to "Vendor-Identifying Vendor Options for Dynamic 454 Host Configuration Protocol version 4 (DHCPv4)" [RFC3925] states: 456 The DHCP protocol for IPv4, [RFC2131], defines options that allow 457 a client to indicate its vendor type (option 60), and the DHCP 458 client and server to exchange vendor-specific information (option 459 43) [RFC2132]. Although there is no prohibition against passing 460 multiple copies of these options in a single packet, doing so 461 would introduce ambiguity of interpretation, particularly if 462 conveying vendor-specific information for multiple vendors. 464 This appears to indicate that "Dynamic Host Configuration Protocol" 465 [RFC2131] specified that there was one instance of the vendor type, 466 and the receiver used that namespace to set the scope for the fields 467 in the vendor-specific information option. This version of DHCP did 468 not allow for multiple origins; only a single origin was permitted 469 and the types were to be defined subsequent to that. Evidently this 470 was found to be unworkable when different vendors needed to expand 471 private use options in the protocol. 473 This situation was resolved with the publication of "Vendor- 474 Identifying Vendor Options for Dynamic Host Configuration Protocol 475 version 4 (DHCPv4)" [RFC3925] which cautions: 477 The Dynamic Host Configuration Protocol (DHCP) options for Vendor 478 Class and Vendor-Specific Information can be limiting or ambiguous 479 when a DHCP client represents multiple vendors. 481 The DHCP [RFC3925] specification then used the PEN [IANApen] to 482 define a unique namespace for private use options in this protocol. 483 Similar to other protocols of this era, TLV containers were used. 485 When this protocol was updated to conform to the requirements of 486 IPv6, the PEN was again used as the way to identify the origin of the 487 private use option. 489 DHCP [RFC3925] provides guidance on actions to take if servers and 490 clients do not comprehend a request or a response. 492 Servers not equipped to interpret the vendor-specific information 493 sent by a client MUST ignore it. Clients that do not receive 494 desired vendor-specific information SHOULD make an attempt to 495 operate without it. 497 4.5. Syslog 499 "The Syslog Protocol" [RFC5424] also uses the PEN to uniquely qualify 500 the namespace for a private use option. Standard options do not 501 contain the "@" character. Private use options must have the PEN 502 following the "@" character. This allows a vendor or experimenter to 503 have overlapping namespaces which the PEN will then uniquely 504 identify. For example the standard option of tzKnown may only have 505 associated values of "0" and "1". However tzKnown@32473 may have any 506 value assigned to it by the owner of enterprise number 32473. 508 Syslog transport receivers are supposed to accept all correctly 509 formatted Syslog messages. Unlike RADIUS, the receiving Syslog 510 application does not have to have immediate knowledge of all variable 511 options to continue operations. If a private use option is not 512 immediately known to the receiving application, it may still store 513 the message and an Operator or Administrator may look it up at a 514 later time if they are interested. 516 The Syslog protocol [RFC5424] uses the PEN as the origin and allows 517 for the focus of the private use option to be fully defined by the 518 vendor within the structured data. Specifically, a vendor may define 519 a "type" of private use option by concatenating it with the PEN by 520 using the @ character. Within the bounds of the structured data, 521 multiple elements may be used that have identifiers and values. 523 4.6. Secure Shell 525 "The Secure Shell (SSH) Protocol Architecture" [RFC4251] uses 526 character strings rather than PENs. Similar to Syslog, but actually 527 predating it, standard options must not have the "@" character in 528 them. Private use options will have an origin identifier preceding 529 an "@" character followed by a namespace field. For example, in "The 530 Secure Shell (SSH) Connection Protocol" [RFC4254] SSH channels may be 531 opened by specifying a channel type when sending the 532 SSH_MSG_CHANNEL_OPEN message. Standard options for the channel type 533 include "session" and "x11". A private use option for a channel type 534 could be "example_session@example.com". 536 The character strings are domain names as defined in [RFC1034] and 537 [RFC1035]. This is specified in "The Secure Shell (SSH) Protocol 538 Architecture" [RFC4251]. The rational for choosing the manner of 539 providing a format for private use options is given in Section 4.2 of 540 [RFC4251]. 542 We have chosen to identify algorithms, methods, formats, and 543 extension protocols with textual names that are of a specific 544 format. DNS names are used to create local namespaces where 545 experimental or classified extensions can be defined without fear 546 of conflicts with other implementations. 548 In the SSH protocol [RFC4250], the origin is a domain name and the 549 focus of the option is dependent upon context. For example, 550 ourcipher-cbc@example.com can only be used when negotiating ciphers, 551 while example_session@example.com can only be used when negotiating 552 channel types, per the examples in [RFC4250]. 554 Generally, the guidance given is that if a private use option is not 555 understood the receiver is to convey an error code to its peer. 557 4.7. YANG and NETCONF 559 One example of a protocol utilizing URNs is "Network Configuration 560 Protocol (NETCONF)" [RFC6241]. NETCONF may utilize "YANG - A Data 561 Modeling Language for the Network Configuration Protocol (NETCONF)" 562 [RFC6020] as a means to describe and convey options. 564 "YANG - A Data Modeling Language for the Network Configuration 565 Protocol (NETCONF)" [RFC6020] and "Network Configuration Protocol 566 (NETCONF)" [RFC6241] use URIs to indicate private use namespaces. 568 Section 8.3 of YANG [RFC6020] describes the parsing of the YANG 569 payload. It contains a good deal of information about how to process 570 elements or values that are not recognized. 572 Similarly, NETCONF [RFC6241] contains much information about 573 processing requests that cannot be completed because elements or 574 values are not recognized. 576 Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate 577 private use options of a device. The use of this comes from XPATH 578 [W3C.REC-xpath-19991116]. In both of these, the start of authority 579 is the domain name in the URI and the origin is the full URI path. 580 Many private use options may be described within YANG. From that, 581 each private use option may be populated in NETCONF. 583 4.8. Extensible Provisioning Protocol 585 The "Extensible Provisioning Protocol (EPP)" [RFC5730] is another 586 example of a protocol that utilizes URN namespaces. From the 587 Protocol Description section 2: 589 EPP uses XML namespaces to provide an extensible object management 590 framework and to identify schemas required for XML instance 591 parsing and validation. These namespaces and schema definitions 592 are used to identify both the base protocol schema and the schemas 593 for managed objects. 595 The specification provides clear guidance and an example on how to 596 extend the base protocol and how to map new objects through the use 597 of separate documents. However, commands and responses may be 598 extended through the use of an element. In this 599 protocol, and the extensions, the start of authority is the domain 600 name in the URI and the focus is the full URI path. 602 Guidance has been provided about incomplete understanding. First, a 603 section is provided on responses for received messages that are not 604 understandable, are beyond boundaries, or are not in compliance with 605 policy. Additionally, guidance is given about incomplete 606 understanding of a response: 608 Command success or failure MUST NOT be assumed if no response is 609 returned or if a returned response is malformed. Protocol 610 idempotency ensures the safety of retrying a command in cases of 611 response-delivery failure. 613 The associated RFCs of "Extensible Provisioning Protocol (EPP) Domain 614 Name Mapping" [RFC5731] and "Extensible Provisioning Protocol (EPP) 615 Host Mapping" [RFC5732] provide a mechanism to temporally bind 616 options. 618 5. Observations 620 Private use options are a way to allow vendors, network operators, 621 and experimenters to convey dynamic information without going through 622 any process to register each variable. However, there is no one size 623 fits all. The use of a very specific and fixed format works for 624 RADIUS which requires speed in processing. On the other hand, the 625 open nature of the private use options in Syslog are appropriate for 626 that protocol where event messages need not be fully parsed at the 627 time of reception. 629 As with all good things, the use of private use options comes with a 630 cost. Adding any extra fields to a protocol will require additional 631 processing for both the sender and the receiver. Also, larger 632 packets will take up more bandwidth in transmission. In another 633 aspect, the code needed to deal with private use options may be 634 considered wasteful if it is not used. 636 There appear to be five quantifiable features that have been 637 documented in using a private use option. 639 o One feature is to have a definable way for the community to 640 ascertain the nature of all private use options. For example, 641 several vendors have published their RADIUS VSAs on web pages, 642 which are easy to find. From that, anyone creating a new RADIUS 643 server would have access to, and be able to incorporate the 644 information available. 646 o Instructions have frequently been provided on how to deal with 647 incomplete understanding; where private use options are not 648 understood by a receiver. Within the example protocol 649 specifications given in this document, some behavior has usually 650 been established about what to do if the receiver does not 651 understand a namespace. Some protocols have defined that a 652 receiver will silently discard packets that contain private use 653 options they do not understand. Other protocols have defined that 654 they will only discard the private use option rather than the 655 entire packet. On the other hand some other protocols have no 656 need for the receiver to have any understanding of any private use 657 options when it receives any. 659 o The values of private use options have frequently followed the 660 same guidance given for standard options in their respective 661 specifications. In most of the examples given, the value of each 662 private use option has been well defined and bounded. Most have 663 been defined to be extensible so as to accommodate future 664 requirements. 666 o Private use options may be extensible in a clearly designed way. 667 RADIUS suggests that the string containing the option be another 668 TLV. This allows a vendor to define multiple private use options 669 within their own namespace field. These have been called 670 subattributes. 672 o In some cases, a unique option may only be used once within the 673 context of an exchange. This may define a value of an option once 674 and will not change that value during the remainder of the 675 session. RADIUS and DHCP seem to either state this or strongly 676 imply it. However, while it is not explicitly discussed, it 677 appears that nothing prevents this within Syslog, and it seems to 678 be acceptable behavior to resend unique options multiple times 679 within EPP. 681 Clear documentation has been seen to achieve uniformity and 682 interoperability in these features. Obviously implementers will need 683 to adhere closely to these standards for complete interoperability. 685 6. Authoritative Guidance 687 This document is not an encouragement or recommendation to define 688 private use fields in IETF protocols. Rather, since private use 689 options are being used by the community, this document is an attempt 690 to document the ways in which they have been used. 692 However, "Design Considerations for Protocol Extensions" [RFC6709] is 693 intended to provide guidance on designing protocol extensions. It 694 has several examples and pointers to other material that will aid in 695 the development of protocol extensions. 697 "Procedures for Protocol Extensions and Variations" [RFC4775] is a 698 companion document to [RFC6709] and provides the procedures for 699 review and standardization for extensions to be added to protocols. 701 Finally, the usage of any private use values on the wire before any 702 namespace is properly reserved with the IANA is entirely inadvisable. 704 7. Authors Notes 706 This section will be removed prior to publication. 708 This is version -15. I have received ISE feedback, but don't have 709 time right now to integrate it into the document. No changes from 710 the prior version; just an update to overcome the document timing 711 out. 713 8. Security Considerations 715 This document reviews ways that options are being used in various 716 protocols. As such, there are no security considerations inherent in 717 this document. 719 While it is not a problem that can be technically addressed, 720 fraudulently purporting to be an owner of a domain name, a PEN, or 721 other identifier may allow the misuse of private namespaces. 723 Readers and implementers should be aware of the context of 724 implementing options in protocols they are using or that are being 725 developed. 727 9. IANA Considerations 729 This document does not propose a standard and does not require the 730 IANA to do anything. 732 10. Acknowledgments 734 The idea for documenting this came from questions asked in the SIP- 735 CLF Working Group and the author is grateful for the discussion 736 around this topic. 738 The following people have contributed to this document. Listing 739 their names here does not mean that they agree with or endorse the 740 document, but that they have contributed to its substance: 742 David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen 743 Schoenwalder, Nevil Brownlee, Klaas Wierenga, Brian Carpenter, and 744 Randy Presuhn. 746 11. References 748 11.1. Normative References 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 752 RFC2119, March 1997, 753 . 755 [RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, 756 "Procedures for Protocol Extensions and Variations", 757 BCP 125, RFC 4775, DOI 10.17487/RFC4775, December 2006, 758 . 760 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 761 Considerations for Protocol Extensions", RFC 6709, 762 DOI 10.17487/RFC6709, September 2012, 763 . 765 11.2. Informative References 767 [IANAtcp] Internet Assigned Numbers Authority, "IANA Transmission 768 Control Protocol (TCP) Parameters, TCP Option Kind 769 Numbers", 2011, . 772 [IANAsmi] Internet Assigned Numbers Authority, "Network Management 773 Parameters", 2011, 774 . 776 [IANApen] Internet Assigned Numbers Authority, "IANA PRIVATE 777 ENTERPRISE NUMBERS", 2011, 778 . 780 [ISO] International Standards Organization, "International 781 Standards Organization", 2011, . 783 [ICANN] Internet Corporation for Assigned Names and Numbers, 784 "Internet Corporation for Assigned Names and Numbers", 785 2011, . 787 [I-D.liang-iana-pen] 788 Liang, P., Melnikov, A., and D. Conrad, "Private 789 Enterprise Number (PEN) practices and Internet Assigned 790 Numbers Authority (IANA) registration considerations", 791 draft-liang-iana-pen-06 (work in progress), July 2015. 793 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 794 RFC 761, January 1980. 796 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 797 RFC 793, DOI 10.17487/RFC0793, September 1981, 798 . 800 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 801 text messages", STD 11, RFC 822, August 1982. 803 [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, 804 RFC 868, May 1983. 806 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 807 STD 13, RFC 1034, November 1987. 809 [RFC1035] Mockapetris, P., "Domain names - implementation and 810 specification", STD 13, RFC 1035, November 1987. 812 [RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 813 "Simple Network Management Protocol", RFC 1067, 814 August 1988. 816 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 817 of management information for TCP/IP-based internets", 818 STD 16, RFC 1155, May 1990. 820 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 821 "Simple Network Management Protocol (SNMP)", RFC 1157, 822 DOI 10.17487/RFC1157, May 1990. 824 [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, 825 October 1996. 827 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 828 RFC 2131, March 1997. 830 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 831 Extensions", RFC 2132, March 1997. 833 [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 834 "Remote Authentication Dial In User Service (RADIUS)", 835 RFC 2058, January 1997. 837 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 838 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 839 October 1998. 841 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 842 Schoenwaelder, Ed., "Structure of Management Information 843 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 845 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 846 DOI 10.17487/RFC2822, April 2001, 847 . 849 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 850 "Remote Authentication Dial In User Service (RADIUS)", 851 RFC 2865, June 2000. 853 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 854 Organization-Specific Extensions", RFC 3115, April 2001. 856 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 857 "Uniform Resource Names (URN) Namespace Definition 858 Mechanisms", BCP 66, RFC 3406, October 2002. 860 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 861 IETF URN Sub-namespace for Registered Protocol 862 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, 863 June 2003, . 865 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 866 Considered Useful", BCP 82, RFC 3692, DOI 10.17487/ 867 RFC3692, January 2004, 868 . 870 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 871 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 872 RFC 3925, October 2004. 874 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 875 Protocol Assigned Numbers", RFC 4250, January 2006. 877 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 878 Protocol Architecture", RFC 4251, January 2006. 880 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 881 Connection Protocol", RFC 4254, January 2006. 883 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 884 DOI 10.17487/RFC5322, October 2008, 885 . 887 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 889 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 890 Documentation Use", RFC 5612, August 2009. 892 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 893 STD 69, RFC 5730, August 2009. 895 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 896 Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/ 897 RFC5731, August 2009, 898 . 900 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 901 Host Mapping", STD 69, RFC 5732, August 2009. 903 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 904 RFC 5944, November 2010. 906 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 907 Network Configuration Protocol (NETCONF)", RFC 6020, 908 October 2010. 910 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 911 Bierman, "Network Configuration Protocol (NETCONF)", 912 RFC 6241, June 2011. 914 [RFC7805] Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated 915 TCP Extensions and TCP-Related Documents to Historic or 916 Informational Status", RFC 7805, DOI 10.17487/RFC7805, 917 April 2016, . 919 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 920 Writing an IANA Considerations Section in RFCs", BCP 26, 921 RFC 8126, DOI 10.17487/RFC8126, June 2017, 922 . 924 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 925 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 926 . 928 [W3C.REC-xpath-19991116] 929 Clark, J. and S. DeRose, "XML Path Language (XPath) 930 Version 1.0", World Wide Web Consortium 931 Recommendation REC-xpath-19991116, November 1999, 932 . 934 Author's Address 936 Chris Lonvick 937 1307 Kent Oak Dr. 938 Houston, Texas 77077 939 US 941 Email: lonvick.ietf@gmail.com