idnits 2.17.1 draft-lonvick-private-tax-18.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 422: '...sent by a client MUST ignore it (altho...' RFC 2119 keyword, line 425: '... SHOULD make an attempt to operat...' RFC 2119 keyword, line 431: '... o It SHOULD be encoded as a sequen...' RFC 2119 keyword, line 434: '...le subattributes MAY be encoded within...' RFC 2119 keyword, line 458: '... extension MUST be silently disca...' (3 more instances...) 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 (October 17, 2019) is 1653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8415' is defined on line 941, but no explicit reference was found in the text -- 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 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick 3 Internet-Draft October 17, 2019 4 Intended status: Informational 5 Expires: April 19, 2020 7 A Taxonomy on Private Use Fields in Protocols 8 draft-lonvick-private-tax-18 10 Abstract 12 This document discusses how private use fields in IETF protocols are 13 used. 15 Status of This Memo 17 This Internet-Draft is submitted 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). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 19, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Note on References . . . . . . . . . . . . . . . . . . . 3 64 2. Origins of the Private Use Namespace . . . . . . . . . . . . 3 65 3. Observed Characteristics of Private Use Options . . . . . . . 4 66 3.1. Parts and Identification of the Authority . . . . . . . . 5 67 3.1.1. Authority . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.2. Path and Value . . . . . . . . . . . . . . . . . . . 6 69 3.2. Incomplete Understanding . . . . . . . . . . . . . . . . 7 70 3.3. Bounds and Extensibility . . . . . . . . . . . . . . . . 7 71 3.4. Use and Reuse . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Examples of Private Use Options . . . . . . . . . . . . . . . 7 73 4.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.6. Secure Shell . . . . . . . . . . . . . . . . . . . . . . 12 79 4.7. YANG and NETCONF . . . . . . . . . . . . . . . . . . . . 13 80 4.8. Extensible Provisioning Protocol . . . . . . . . . . . . 13 81 5. Observations . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6. Authoritative Guidance . . . . . . . . . . . . . . . . . . . 15 83 7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 Protocols having options reserved for testing and experimentation 95 have been found to be beneficial to the community as discussed in 96 "Assigning Experimental and Testing Numbers Considered Useful" 98 [RFC3692]. As with any protocol detail, the effectiveness of private 99 use fields depends upon a shared understanding of their syntax and 100 semantics by all participating implementations. For open use in the 101 Internet, this requires that such fields be fully specified in openly 102 available documents. 104 This taxonomy uses examples of some protocols to discuss how some 105 private use options are used. 107 1.1. Nomenclature 109 In this document, the following terms are defined to prevent 110 ambiguity. Some of these words have not been used in the referenced 111 works but their meanings can be ascertained and applied. 113 o Standard Option - a field in a protocol frame that may only use 114 values that are strictly defined within a specification. 116 o Private Use Option - a field in a protocol frame that is reserved 117 for private, experimental, testing, or local use only. 119 o Namespace - a fully qualified Standard Option or Private Use 120 Option. 122 1.2. Note on References 124 In many cases throughout this document, RFCs are referenced even 125 though they are not the most current version of their respective 126 protocol. This is only done to reference the first occurrence of a 127 private use option, or to point out a distinct feature in that 128 specification. When an RFC is referenced that is not the current 129 version, the reference will be followed by the RFC number of the 130 current version in curly braces. 132 2. Origins of the Private Use Namespace 134 Some standards permit private use options in different ways, while 135 others do not. The "Time Protocol" [RFC0868] is an example of a 136 protocol that only conveys standardized information; there is no way 137 to use private options and no way to add anything other than what is 138 specified in the document. In a more open way, "DOD STANDARD 139 TRANSMISSION CONTROL PROTOCOL" [RFC0761] {[RFC0793]} {[RFC7805]} does 140 have "options" but they must be registered through the IANA [IANAtcp] 141 before use, which does not leave any room for optional information 142 supplied by equipment vendors, network operators, or experimenters. 143 An even more open way may be seen in "Vendor-Identifying Vendor 144 Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)" 146 [RFC3925], which allows for vendor specific options that do not need 147 to be registered with anyone. 149 For the case of TCP [RFC0761] {[RFC0793]} {[RFC7805]}, standard 150 options are expected; senders may use them and receivers may be 151 configured to act upon that information, or to ignore it. If an 152 experimenter wants to add an option, they will have to create a new 153 IETF RFC with specific details, or obtain approval from the IESG to 154 have the IANA add to the registry [IANAtcp]. Similarly, if equipment 155 vendors Foo and Bar were to have a need for a similar option within 156 TCP, they would each have to go through the process to add to the 157 registry. They may then need to negotiate how they would interpret 158 each others options for some level of interoperability. On the other 159 hand, if a properly crafted multipurpose private use option were to 160 be registered, such as in the case of multiple vendor instances 161 within "DHCPv4" [RFC3925], then vendors and experimenters would each 162 be able to use it for their own purpose as long as all network 163 participants could easily differentiate between the entities using 164 the option. 166 "Guidelines for Writing an IANA Considerations Section in RFCs" 167 [RFC2434] {[RFC8126]} describes that values of specific namespaces 168 may either be registered with the IANA, or not. In most cases, there 169 are well defined values for their respective namespaces. However, as 170 the document explains, not all namespaces require centralized 171 administration. In that document, it seems to be assumed that 172 private use namespaces will be domain specific and it will be up to 173 the administrators of any domain to avoid conflicts. The first 174 example given about private use namespaces refers to "Dynamic Host 175 Configuration Protocol" [RFC2131] and presumably "DHCP Options and 176 BOOTP Vendor Extensions" [RFC2132]. In this the example states that 177 "site-specific options in DHCP have significance only within a single 178 site". As noted below this became a problem that was rectified in a 179 later revision of DHCP. 181 Later works identified a need to place a scope on private use 182 namespaces. Another example of private use namespace in the IANA 183 guidelines [RFC2434] {[RFC8126]} is from "STANDARD FOR THE FORMAT OF 184 ARPA INTERNET TEXT MESSAGES" [RFC0822] {[RFC5322]} which describes X- 185 headers. There was no effort made to control their scope, and the 186 use of the namespace was removed when the specification was updated 187 in 2001 in "Internet Message Format" [RFC2822] {[RFC5322]}. 189 3. Observed Characteristics of Private Use Options 191 This section summarizes the observed characteristics of some private 192 use options that have been developed and deployed. 194 3.1. Parts and Identification of the Authority 196 There appear to be three identifiable parts of private use 197 namespaces: 199 o Authority 201 o Path 203 o Value 205 3.1.1. Authority 207 A private use option requires an Authority that can create and 208 maintain the option. Presumably, the goal for an Authority is to 209 regulate, codify, and disambiguate each namespace. Therefore, the 210 referent most often seen has been globally unique, and not dependent 211 upon local interpretation. For example, several vendors have 212 published their RADIUS VSAs on web pages, which are easy to find. 213 From that, anyone creating or updating a RADIUS server would have 214 access to, and be able to incorporate the information available. 216 Likely, the first private use option with a globally unique source 217 was defined in the "Structure and Identification of Management 218 Information for TCP/IP-based Internets" [RFC1155] which was first 219 used in "A Simple Network Management Protocol" [RFC1067] {[RFC1157]} 220 (SNMP). The globally unique Authority in SNMP is the International 221 Standards Organization [ISO] which is accredited by the United 222 Nations to maintain this structure. 224 While SNMP used the entire OBJECT IDENTIFIER with the prefix, other 225 protocols truncated this to only used the Private Enterprise Number 226 [IANApen] (PEN) as an identification of an Authority. This reduced 227 the length of the identifier but continued to provide a unique 228 Authority through a globally managed scope. 230 The PEN is sourced by the Internet Assigned Numbers Authority (IANA). 231 PENs may be viewed as being similar to domain names in that they are 232 acquired by individuals, corporations, or other organizations. 233 However, a notable difference is that when domain names fall into 234 disuse they may be acquired and used by entirely different people or 235 organizations - as per the conditions set forth by the Internet 236 Corporation for Assigned Names and Numbers [ICANN]. The structure of 237 the PEN registry does not place any limits on the time that a PEN 238 will be active or associated with the requester. This is no 239 different from many other registries maintained by the IANA; they are 240 just a snapshot at the time of the reservation based on the 241 information required by the IANA and provided by the applicant. This 242 eternal association of the PEN, versus the ephemeral association of 243 domain names, has not been shown to present any problems to private 244 use options. This may, in fact, be a feature as this methodology 245 ensures that these namespaces will stay unique for the foreseeable 246 future. 248 Some additional information on the PEN may be found in "Enterprise 249 Number for Documentation Use" [RFC5612], and in "Private Enterprise 250 Number (PEN) practices and Internet Assigned Numbers Authority (IANA) 251 registration considerations" [I-D.liang-iana-pen]. 253 One observed alternative to using a numerical indicator such as the 254 OBJECT IDENTIFIER or PEN, is to use textual strings such as names. 256 In some cases, domain names have been used for this purpose. 257 However, as noted above, domain names may be more ephemeral than 258 eternal. Unlike PENs that usually become unserviceable when their 259 owning organization ceases operation, domain names that fall into 260 disuse may be acquired and used by entirely different organizations. 261 Similar to the use of PENs however, there have not been any problems 262 reported from this in normal use. 264 Uniform Resource Names (URNs) have also been used to convey options. 265 They seem to provide flexibility for many different needs. URNs were 266 first defined in "Uniform Resource Names (URN) Namespace Definition 267 Mechanisms" [RFC3406] {[RFC8141]}. "An IETF URN Sub-namespace for 268 Registered Protocol Parameters" [RFC3553] provides guidance for ways 269 to use URNs as protocol parameters and how to define an Authority. 271 3.1.2. Path and Value 273 Once the Authority is established as a globally unique source, an 274 actual option, or in some cases multiple options, may be specified. 275 This has usually been observed to be an indicator of what Value is 276 expected. Within the scope established by the Authority, the Path to 277 each Value has been seen to be unique. 279 In a very simple example, the namespace of a private use option may 280 consist of "Authority"+"Path"="Value". Since the Authority is 281 unique, each individual Path will be unique as long as the Authority 282 maintains that uniqueness; e.g., it would be poor form for an 283 Authority to define a namespace, then to redefine it in a conflicting 284 way at a later time. 286 3.2. Incomplete Understanding 288 Guidance has frequently been provided on how to deal with incomplete 289 understanding when private use options are not understood by a 290 receiver. Within the example protocol specifications given in this 291 discussion, some behavior has usually been established about what to 292 do if the receiver does not understand a namespace. Some protocols 293 have defined that a receiver will silently discard packets that 294 contain private use options they do not understand. Other protocols 295 have defined that they will only discard the private use option 296 rather than the entire packet. On the other hand some other 297 protocols have no need for the receiver to have any understanding of 298 any private use options when it receives any. 300 In some cases, guidance has given describing appropriate error 301 message responses for incomplete understanding or processing that 302 cannot be performed. 304 3.3. Bounds and Extensibility 306 The Values of private use options have frequently followed the same 307 guidance given for standard options in their respective 308 specifications. In most of the examples given, the Value of each 309 private use option has been well defined and bounded. 311 Private use options may be extensible if they are clearly designed to 312 be so. 314 3.4. Use and Reuse 316 In some cases, a unique option may only be used once within the 317 context of an exchange. This may define a Value of an option once 318 and will not change that Value during the remainder of the session. 319 RADIUS and DHCP seem to either state this or strongly imply it. 320 However, while it is not explicitly discussed, it appears that 321 nothing prevents this within Syslog, and it seems to be acceptable 322 behavior to resend unique options multiple times within EPP. 324 4. Examples of Private Use Options 326 This section contains a review of RFCs that allow the use of private 327 use options. 329 4.1. SNMP 331 SNMP is syntactically complex but has features in the GetRequest PDU 332 that are consistent with the observed characteristics of private use 333 options. The structure of management information (SMI) is currently 334 defined by the "Structure of Management Information Version 2 335 (SMIv2)" [RFC2578]. SMI is a well described tree of OBJECT 336 IDENTIFIERs (OIDs). OIDs have an Authority and Path for defined 337 object identifiers which this document describes as standard options. 338 The specification also allows for experimental and vendor specific 339 object identifiers, which are described as private use options in 340 this document. The IANA maintains a registry of these Network 341 Management Parameters [IANAsmi]. 343 As was noted, the globally unique Authority in SNMP is the 344 International Standards Organization [ISO]. 346 The Internet subtree of experimental OBJECT IDENTIFIERs starts with 347 the prefix: 1.3.6.1.3. 349 The Internet subtree of private enterprise OBJECT IDENTIFIERs starts 350 with the prefix: 1.3.6.1.4.1. and is followed by a Private Enterprise 351 Number [IANApen] (PEN) and then the objects defined by that 352 enterprise. After the vendor identifier (the PEN) in the management 353 information base (MIB), a vendor may create many different trees to 354 identify objects. This may result in a very large number of OBJECT 355 IDENTIFIERs, each of which is an identifier, or Value, of a Path. 356 Each of these are uniquely identified by the vendor and do not 357 require registration with any coordinating authority. 359 The last part of each OBJECT IDENTIFIER is the Path and a placeholder 360 for its Value; the varbind. In a GetRequest the SNMP Manager (the 361 client) fills the first part of the varbind with the object 362 identifier. The other portion is transmitted with an ASN.1 NULL 363 value. In a typical case, the SNMP Agent (the server) responds by 364 replacing the NULL with the actual Value in the response. Since this 365 namespae is defined by the vendor, it may actually be a concatenation 366 of Values. 368 The SetRequest PDU is similar to the GetRequest PDU in that it has an 369 OID and may use a PID to identify the objects, however, the varbind 370 is populated differently than in a GetRequest PDU. The other PDUs 371 also use the OID and may use a PID, but behave differently than the 372 GetRequest PID. 374 The SNMP namespace is extensible. A varbind may be considered to be 375 a TLV wherein the Value may be another TLV. 377 Specific codes, known as error-indexes, are used to indicate when a 378 request cannot be processed because a device does not understand a 379 request. 381 GetRequests and SetRequests may be sent repetitively, even with the 382 same Path and with the same or different Values. For GetRequests, a 383 client may be monitoring a server to chronologically record 384 parameters of interest. In some cases, the analysis of the Values 385 obtained by GetRequests may trigger an event that causes one or more 386 SetRequests to be sent. 388 4.2. RADIUS 390 There are many attributes defined in "The Remote Authentication Dial 391 In User Service (RADIUS)" [RFC2058] {[RFC2865]}, which may be 392 considered to be standard options. Each of these attributes is 393 specified within a "type length value" (TLV) container. For this 394 protocol, the "type" attribute is a specific numerical value, which 395 differentiates it other types. 397 [RFC2058] documented how to use just the PEN (without the rest of the 398 SMI path to the root) to allow "vendors" to articulate their own 399 options. In that document, these are called Vendor-Specific 400 Attributes (VSA). 402 One example of a RADIUS standard option is Type 26, which denotes the 403 Vendor Specified Attribute. It is "available to allow vendors to 404 support their own extended Attributes not suitable for general 405 usage". The PEN of the "vendor" is the Authority that starts the 406 namespace. The remainder of the namespace after the PEN is 407 deliberately undefined in the specification. It is practically 408 suggested that the field contain embedded TLVs. This may be seen as 409 the Path and Value. 411 The values for each RADIUS type are bounded by the length of the 412 attribute. In some cases, it is feasible that a value has no length. 413 In that case, the transmission of the type alone has been seen to be 414 a signal of some sort to the receiver. 416 The original specification of [RFC2058] {[RFC2865]} provided guidance 417 that invalid packets were to be silently discarded. That was 418 augmented in [RFC2865], along with guidance about reusing the 419 attributes. 421 o Servers not equipped to interpret the vendor-specific information 422 sent by a client MUST ignore it (although it may be reported). 424 o Clients which do not receive desired vendor-specific information 425 SHOULD make an attempt to operate without it, although they may do 426 so (and report they are doing so) in a degraded mode. 428 o The Attribute-Specific field is dependent on the vendor's 429 definition of that attribute. 431 o It SHOULD be encoded as a sequence of vendor type / vendor length 432 / value fields. 434 o Multiple subattributes MAY be encoded within a single Vendor- 435 Specific Attribute, although they do not have to be. 437 4.3. Mobile IP 439 "Mobile IP Vendor Specific Extensions" [RFC3115] defines two 440 extensions that can be used for making organization specific 441 extensions by vendors/organizations for their own specific purposes 442 for Mobile IP [RFC2002] {[RFC5944]}. These are the Critical Vendor/ 443 Organization Specific Extension (CVSE) and the Normal Vendor/ 444 Organization Specific Extension (NVSE). These are collectively 445 called Vendor/Organization Specific Extensions (VSE). 447 The structure of the namespace of the VSEs for "Mobile IP" [RFC3115] 448 is similar to that of RADIUS. The PEN is the Authority, and types 449 and values (the Path and Value) may be stacked in TLVs. The values 450 are constrained by the respective lengths of the types or subtypes. 452 Guidance is given for incomplete understanding in [RFC3115], which is 453 consistent with the guidance given in the original Mobile IP 454 specification [RFC2002] {[RFC5944]}. 456 o When the Critical Vendor/Organization Specific Extension (CVSE) is 457 encountered but not recognized, the message containing the 458 extension MUST be silently discarded. 460 o When a Normal Vendor/Organization Specific Extension (NVSE) is 461 encountered but not recognized, the extension SHOULD be ignored, 462 but the rest of the Extensions and message data MUST still be 463 processed. 465 Error codes are provided in responses to registration requests that 466 are denied because of incomplete understanding. 468 Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER 469 can be included in a message. RFC 3115 is silent on reusing the same 470 VSE in subsequent messages. 472 4.4. DHCP 474 "Dynamic Host Configuration Protocol" [RFC2131] specified that there 475 was to be a single instance of the vendor type, and the receiver was 476 to use that namespace to set and limit the scope for the fields in 477 the vendor-specific information option. This early version of DHCP 478 did not allow for multiple Authorities; only a single Authority was 479 permitted where the Path and Value were to be defined referring 480 exclusively to that scope. Evidently this was found to be unworkable 481 when different vendors needed to expand private use options in the 482 protocol. 484 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] 485 {[RFC8415]} was created to provide DHCP for IPv6. This used the PEN 486 as the way to identify the Authority of each private use option. 487 This methodology was subsequently adopted in "Vendor-Identifying 488 Vendor Options for Dynamic Host Configuration Protocol version 4 489 (DHCPv4)" [RFC3925], which provided for multiple vendors to identify 490 and set their own private use options. TLVs were used in this 491 instance with its inherent bounds and extensibility. 493 [RFC3925] provides guidance on actions to take if servers and clients 494 do not comprehend a request or a response: servers must ignore 495 options they are not equipped to comprehend and clients should make 496 an attempt to get along without any desired vendor specific response 497 they expect. 499 [RFC2131] allowed options to be sent only once. However, it 500 acknowledged that multiple values for an option may be transmitted. 501 This may be, for example, for a list of routers where the list is too 502 long to fit within a single option. Guidance is given that the 503 client must concatenate the values into a single list. This 504 sentiment is echoed in [RFC3925], which states that behavior is 505 undefined if a sequence of vendors options reuses the same PEN. 507 4.5. Syslog 509 "The Syslog Protocol" [RFC5424] also uses the PEN within structured 510 data (SD) to uniquely qualify the namespace for private use options. 511 The format for options, called SD-ELEMNENTs, consists of an SD-ID and 512 SD-PARAMs. For standard options the "@" character cannot be used in 513 the SD-ID. Private use options must have the PEN following the "@" 514 character in the SD-ID. This allows a vendor or experimenter to have 515 disambiguated Paths and Values. 517 Simply put, a standard option is an SD-ID that does not have the "@" 518 character in it, while a private use option is an SD-ID that does 519 contain the "@" character. 521 For example the standard option of the SD-ID timeQuality may only 522 have PARAM-VALUEs of "0" and "1" for the tzKnown PARAM-NAME. The SD- 523 ELEMENT Authority for the standard option timeQuality is then the 524 IANA. However the SD-ID timeQuality@32473 is a private use option 525 controlled by the Authority that controls enterprise number 32473. 526 Therefore, the tzKnown SD-PARAM may have any PARAM-VALUE assigned to 527 it by the owner of enterprise number 32473. 529 Syslog transport receivers are supposed to accept all correctly 530 formatted Syslog messages. Unlike RADIUS, the receiving Syslog 531 application does not have to have immediate knowledge of all variable 532 options to continue operations. If a private use option is not 533 immediately known to the receiving application, it may still store 534 the message and an Operator or Administrator may look it up at a 535 later time. 537 An SD-ID may not be reused within a Syslog message. 539 Bounds are given in [RFC5424]. 541 4.6. Secure Shell 543 "The Secure Shell (SSH) Protocol Architecture" [RFC4251] uses 544 character strings rather than PENs to establish Authority. Similar 545 to Syslog, but actually predating it, standard options must not have 546 the "@" character in them. Private use options will have an 547 Authority identifier preceding an "@" character followed by a Value 548 field. For example, in "The Secure Shell (SSH) Connection Protocol" 549 [RFC4254] SSH channels may be opened by specifying a channel type 550 when sending the SSH_MSG_CHANNEL_OPEN message. Standard options for 551 the channel type include "session" and "x11". A private use option 552 for a channel type could be "example_session@example.com". 554 The character strings are domain names as defined in [RFC1034] and 555 [RFC1035]. This is specified in "The Secure Shell (SSH) Protocol 556 Architecture" [RFC4251]. The rational for choosing the manner of 557 providing a format for private use options is given in Section 4.2 of 558 [RFC4251]. 560 We have chosen to identify algorithms, methods, formats, and 561 extension protocols with textual names that are of a specific 562 format. DNS names are used to create local Paths and Values where 563 experimental or classified extensions can be defined without fear 564 of conflicts with other implementations. 566 In the SSH protocol [RFC4250], the Authority is a domain name and the 567 path and value of the option is dependent upon context. For example, 568 ourcipher-cbc@example.com can only be used when negotiating ciphers, 569 while example_session@example.com can only be used when negotiating 570 channel types, per the examples in [RFC4250]. 572 Guidance is given throughout the SSH series of RFCs (4250 - 4254) for 573 incomplete understanding. The guidance differes based upon the 574 context; in some cases, the guidance is to ignore a private use 575 option when it cannot be understood, while in other cases, a negative 576 response must be sent to indicate that a received private use option 577 could not be understood. 579 Similarly, reuse of a private use option is dependent upon the 580 context. The same is true for checking bounds of any private use 581 option. 583 4.7. YANG and NETCONF 585 One example of a protocol utilizing URNs is "Network Configuration 586 Protocol (NETCONF)" [RFC6241]. NETCONF may utilize "YANG - A Data 587 Modeling Language for the Network Configuration Protocol (NETCONF)" 588 [RFC6020] as a means to describe and convey options. 590 "YANG - A Data Modeling Language for the Network Configuration 591 Protocol (NETCONF)" [RFC6020] and "Network Configuration Protocol 592 (NETCONF)" [RFC6241] use URIs to indicate private use Paths and 593 Values. 595 Section 8.3 of YANG [RFC6020] describes the parsing of the YANG 596 payload. It contains a good deal of information about how to process 597 elements or values that are not recognized. 599 Similarly, NETCONF [RFC6241] contains much information about 600 processing requests that cannot be completed because elements or 601 values are not recognized. 603 Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate 604 private use options of a device. The use of this comes from XPATH 605 [W3C.REC-xpath-19991116]. In both of these, the start of authority 606 is the domain name in the URI and the Authority is the full URI path. 607 Many private use options may be described within YANG. From that, 608 each private use option may be populated in NETCONF. 610 4.8. Extensible Provisioning Protocol 612 The "Extensible Provisioning Protocol (EPP)" [RFC5730] is another 613 example of a protocol that utilizes URN Path and Values. From the 614 Protocol Description section 2: 616 EPP uses XML namespaces to provide an extensible object management 617 framework and to identify schemas required for XML instance 618 parsing and validation. These namespaces and schema definitions 619 are used to identify both the base protocol schema and the schemas 620 for managed objects. 622 The specification provides clear guidance and an example on how to 623 extend the base protocol and how to map new objects through the use 624 of separate documents. However, commands and responses may be 625 extended through the use of an element. In this 626 protocol, and the extensions, the start of authority is the domain 627 name in the URI and the focus is the full URI path. 629 Guidance has been provided about incomplete understanding. First, a 630 section is provided on responses for received messages that are not 631 understandable, are beyond boundaries, or are not in compliance with 632 policy. Additionally, guidance is given about incomplete 633 understanding of a response: 635 Command success or failure MUST NOT be assumed if no response is 636 returned or if a returned response is malformed. Protocol 637 idempotency ensures the safety of retrying a command in cases of 638 response-delivery failure. 640 The associated RFCs of "Extensible Provisioning Protocol (EPP) Domain 641 Name Mapping" [RFC5731] and "Extensible Provisioning Protocol (EPP) 642 Host Mapping" [RFC5732] provide a mechanism to temporally bind 643 options. 645 5. Observations 647 Private use options are a way to allow vendors, network operators, 648 and experimenters to convey dynamic information without going through 649 any process to register each variable. However, there is no one size 650 fits all. The use of a very specific and fixed format works for 651 RADIUS which requires speed in processing. On the other hand, the 652 open nature of the private use options in Syslog are appropriate for 653 that protocol where all event messages need not be fully parsed at 654 the time of reception. 656 As with all good things, the use of private use options comes with a 657 cost. Adding any extra fields to a protocol will require additional 658 processing for both the sender and the receiver. Also, larger 659 packets will take up more bandwidth in transmission. In another 660 aspect, the code needed to deal with private use options may be 661 considered wasteful if it is not used. 663 Clear documentation has been seen to achieve uniformity and 664 interoperability in these features. Obviously implementers will need 665 to adhere closely to these standards for complete interoperability. 667 6. Authoritative Guidance 669 This document is not an encouragement or recommendation to define 670 private use fields in IETF protocols. Rather, since private use 671 options are being used by the community, this document is an attempt 672 to document the ways in which they have been used. 674 However, "Design Considerations for Protocol Extensions" [RFC6709] is 675 intended to provide guidance on designing protocol extensions. It 676 has several examples and pointers to other material that will aid in 677 the development of protocol extensions. 679 "Procedures for Protocol Extensions and Variations" [RFC4775] is a 680 companion document to [RFC6709] and provides the procedures for 681 review and standardization for extensions to be added to protocols. 683 Finally, the usage of any private use values on the wire before any 684 namespace is properly reserved with the IANA is entirely inadvisable. 686 7. Authors Notes 688 This section will be removed prior to publication. 690 This is version -18. I have received ISE feedback and am integrating 691 that into this document. Unfortunately, that's going to take a while 692 as life and the day job keep getting in the way. 694 I'm revising the flow of the document to be consistent and to 695 accomodate the feedback that I've received. 697 8. Security Considerations 699 This document reviews ways that options are being used in various 700 protocols. As such, there are no security considerations inherent in 701 this document. 703 While it is not a problem that can be technically addressed, 704 fraudulently purporting to be an owner of a domain name, a PEN, or 705 other identifier may allow the misuse of private namespaces. 707 Readers and implementers should be aware of the context of 708 implementing options in protocols they are using or that are being 709 developed. 711 9. IANA Considerations 713 This document does not propose a standard and does not require the 714 IANA to do anything. 716 10. Acknowledgments 718 The idea for documenting this came from questions asked in the SIP- 719 CLF Working Group and the author is grateful for the discussion 720 around this topic. 722 The following people have contributed to this document. Listing 723 their names here does not mean that they agree with or endorse the 724 document, but that they have contributed to its substance: 726 David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen 727 Schoenwalder, Nevil Brownlee, Klaas Wierenga, Brian Carpenter, Randy 728 Presuhn, and Dave Crocker. 730 11. References 732 11.1. Normative References 734 [RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, 735 "Procedures for Protocol Extensions and Variations", 736 BCP 125, RFC 4775, DOI 10.17487/RFC4775, December 2006, 737 . 739 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 740 Considerations for Protocol Extensions", RFC 6709, 741 DOI 10.17487/RFC6709, September 2012, 742 . 744 11.2. Informative References 746 [I-D.liang-iana-pen] 747 Liang, P., Melnikov, A., and D. Conrad, "Private 748 Enterprise Number (PEN) practices and Internet Assigned 749 Numbers Authority (IANA) registration considerations", 750 draft-liang-iana-pen-06 (work in progress), July 2015. 752 [IANApen] Authority, I. A. N., "IANA PRIVATE ENTERPRISE NUMBERS", 753 2011, 754 . 756 [IANAsmi] Authority, I. A. N., "Network Management Parameters", 757 2011, . 759 [IANAtcp] Authority, I. A. N., "IANA Transmission Control Protocol 760 (TCP) Parameters, TCP Option Kind Numbers", 2011, 761 . 764 [ICANN] ICANN, "Internet Corporation for Assigned Names and 765 Numbers", 2011, . 767 [ISO] ISO, "International Standards Organization", 2011, 768 . 770 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 771 RFC 761, DOI 10.17487/RFC0761, January 1980, 772 . 774 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 775 RFC 793, DOI 10.17487/RFC0793, September 1981, 776 . 778 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 779 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 780 August 1982, . 782 [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, 783 RFC 868, DOI 10.17487/RFC0868, May 1983, 784 . 786 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 787 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 788 . 790 [RFC1035] Mockapetris, P., "Domain names - implementation and 791 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 792 November 1987, . 794 [RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 795 "Simple Network Management Protocol", RFC 1067, 796 DOI 10.17487/RFC1067, August 1988, 797 . 799 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 800 of management information for TCP/IP-based internets", 801 STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, 802 . 804 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 805 "Simple Network Management Protocol (SNMP)", RFC 1157, 806 DOI 10.17487/RFC1157, May 1990, 807 . 809 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 810 DOI 10.17487/RFC2002, October 1996, 811 . 813 [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 814 "Remote Authentication Dial In User Service (RADIUS)", 815 RFC 2058, DOI 10.17487/RFC2058, January 1997, 816 . 818 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 819 RFC 2131, DOI 10.17487/RFC2131, March 1997, 820 . 822 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 823 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 824 . 826 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 827 IANA Considerations Section in RFCs", RFC 2434, 828 DOI 10.17487/RFC2434, October 1998, 829 . 831 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 832 Schoenwaelder, Ed., "Structure of Management Information 833 Version 2 (SMIv2)", STD 58, RFC 2578, 834 DOI 10.17487/RFC2578, April 1999, 835 . 837 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 838 DOI 10.17487/RFC2822, April 2001, 839 . 841 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 842 "Remote Authentication Dial In User Service (RADIUS)", 843 RFC 2865, DOI 10.17487/RFC2865, June 2000, 844 . 846 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization- 847 Specific Extensions", RFC 3115, DOI 10.17487/RFC3115, 848 April 2001, . 850 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 851 C., and M. Carney, "Dynamic Host Configuration Protocol 852 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 853 2003, . 855 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 856 "Uniform Resource Names (URN) Namespace Definition 857 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 858 . 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, June 863 2003, . 865 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 866 Considered Useful", BCP 82, RFC 3692, 867 DOI 10.17487/RFC3692, January 2004, 868 . 870 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 871 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 872 RFC 3925, DOI 10.17487/RFC3925, October 2004, 873 . 875 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 876 Protocol Assigned Numbers", RFC 4250, 877 DOI 10.17487/RFC4250, January 2006, 878 . 880 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 881 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 882 January 2006, . 884 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 885 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 886 January 2006, . 888 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 889 DOI 10.17487/RFC5322, October 2008, 890 . 892 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 893 DOI 10.17487/RFC5424, March 2009, 894 . 896 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 897 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 898 2009, . 900 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 901 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 902 . 904 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 905 Domain Name Mapping", STD 69, RFC 5731, 906 DOI 10.17487/RFC5731, August 2009, 907 . 909 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 910 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 911 August 2009, . 913 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 914 RFC 5944, DOI 10.17487/RFC5944, November 2010, 915 . 917 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 918 the Network Configuration Protocol (NETCONF)", RFC 6020, 919 DOI 10.17487/RFC6020, October 2010, 920 . 922 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 923 and A. Bierman, Ed., "Network Configuration Protocol 924 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 925 . 927 [RFC7805] Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated 928 TCP Extensions and TCP-Related Documents to Historic or 929 Informational Status", RFC 7805, DOI 10.17487/RFC7805, 930 April 2016, . 932 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 933 Writing an IANA Considerations Section in RFCs", BCP 26, 934 RFC 8126, DOI 10.17487/RFC8126, June 2017, 935 . 937 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 938 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 939 . 941 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 942 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 943 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 944 RFC 8415, DOI 10.17487/RFC8415, November 2018, 945 . 947 [W3C.REC-xpath-19991116] 948 Clark, J. and S. DeRose, "XML Path Language (XPath) 949 Version 1.0", World Wide Web Consortium Recommendation 950 REC-xpath-19991116, November 1999, 951 . 953 Author's Address 955 Chris Lonvick 956 1307 Kent Oak Dr. 957 Houston, Texas 77077 958 US 960 Email: lonvick.ietf@gmail.com