idnits 2.17.1 draft-ietf-dnsop-attrleaf-fix-01.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 146: '...e is revised, it MUST add an entry to ...' RFC 2119 keyword, line 189: '...try for the name MUST be added to the ...' RFC 2119 keyword, line 231: '...try for the name MUST be added to the ...' RFC 2119 keyword, line 293: '... SHOULD be registered in th...' RFC 2119 keyword, line 346: '...underscored name SHOULD be registered ...' -- The draft header indicates that this document updates RFC3529, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3404, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2782, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3620, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3263, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2782, updated by this document, for RFC5378 checks: 1998-09-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 22, 2018) is 2166 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3263' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC3404' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC3529' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC3620' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC3832' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC3861' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC3887' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC3958' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC4227' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC4386' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC4387' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC5026' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC5328' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC5415' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC5507' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC5509' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5518' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC5555' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC5617' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC5679' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC5780' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC5804' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC5864' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC5928' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC6011' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC6186' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'RFC7489' is defined on line 544, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7553 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 36 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Updates: 2782, 3263, 3404, 3529, 3620, May 22, 2018 5 3832, 3887, 3958, 4120, 4227, 6 4386, 4387, 4976, 5026, 5328, 7 5389, 5415, 5555, 5679, 5766, 8 5780, 5804, 6011, 6120, 6186, 9 6733 (if approved) 10 Intended status: Best Current Practice 11 Expires: November 23, 2018 13 DNS Attrleaf Changes: Fixing Specifications with _Underscored Node Name 14 Use 15 draft-ietf-dnsop-attrleaf-fix-01 17 Abstract 19 Original uses of an _underscore character as a domain node name 20 prefix, which creates a space for constrained interpretation of 21 resource records, were specified without the benefit of an IANA 22 registry. This produced an entirely uncoordinated set of name- 23 creation activities, all drawing from the same namespace. A registry 24 now has been defined. However the existing specifications that use 25 _underscore naming need to be modified, to be in line with the new 26 registry. This document specifies those changes. The changes 27 preserve existing software and operational practice, while adapting 28 the specifications for those practices to the newer _underscore 29 registry model. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 23, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Underscored RRset Use in Specifications . . . . . . . . . . . 3 67 2.1. TXT RRset Use . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. SRV RRset Use . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3. URI RRset Use . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Underscored Template Specifications . . . . . . . . . . . . . 6 71 3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 6 72 3.2. URI Specification Changes . . . . . . . . . . . . . . . . 7 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 6.2. References -- Informative . . . . . . . . . . . . . . . . 10 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 Original uses of an _underscore character as a domain node name 84 [RFC1035] prefix, which creates a space for constrained 85 interpretation of resource records, were specified without the 86 benefit of an [IANA-reg] registry. This produced an entirely 87 uncoordinated set of name-creation activities, all drawing from the 88 same namespace. A registry has been now defined, and that document 89 discusses the background for _underscore domain name use [Attrleaf]. 91 The basic model for underscored name registration, as specified in 92 [Attrleaf], is to have each registry entry be unique in terms of the 93 combination of a resource record type and a 'global' (ie, right-most) 94 underscore name. 96 The existing uses of _underscore naming have specifications that do 97 not reflect the existence of this integrated registry. For the new 98 reader or the new editor of one of those documents, there is 99 currently nothing signaling that the underscore name(s) defined in 100 the document are now processed through an IANA registry. This 101 document remedies that, by marking such a published document with an 102 update, indicating the nature of the change. 104 The documents that define the SRV [RFC2782] and URI [RFC7553] DNS 105 resource records provide a meta-template for underscore assignments, 106 partially based on separate registries [RFC6335]. For the portion 107 that selects the global (right-most) underscore name, this 108 perpetuates uncoordinated assignment activities by separate technical 109 specifications, out of the same name space. This document remedies 110 that by providing detail for revisions to the SRV and URI 111 specifications, to bring their use in line with the single, 112 integrated global underscore registry. 114 The result of these changes preserves existing software and 115 operations practices, while adapting the technical specifications to 116 the newer _underscore registry model. 118 2. Underscored RRset Use in Specifications 120 The use of underscored node names is specific to each RRTYPE that is 121 being scoped. Each name defines a place, but does not define the 122 rules for what appears underneath that place, either as additional 123 underscored naming or as a leaf node with resource records. Details 124 for those rules are provided by specifications for individual 125 RRTYPEs. The sections below describe the way that existing 126 underscore labels are used with the RRTYPEs that they name. 128 2.1. TXT RRset Use 130 This section provides a generic approach for changes to existing 131 specifications that define straightforward use of _underscored node 132 names, when scoping the use of a "TXT" RR. The approach provides the 133 information needed for adapting such specifications to the use of the 134 IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. Hence 135 the approach is meant both as an update to these existing 136 specifications, and as guidance for changes when those documents are 137 revised. 139 For any document that specifies the use of a "TXT" RRset under an 140 underscored name, that name is expected to be registered in the IANA 141 DNS Underscore Global Scoped Entry Registry [Attrleaf]. An effort 142 has been made to locate existing drafts that do this, register the 143 global underscored name, and list them in this document. 145 If a public specification that defines use of a "TXT" record within 146 an underscore-scoped name is revised, it MUST add an entry to the 147 global underscored name registry, if one does not already exist. 149 Here is a template of suggested text for this to appear in the IANA 150 Considerations section of the specification: 152 "Per" [Attrleaf] "please add the following entry to the DNS 153 Underscore Global Scoped Entry Registry:" 155 +--------+----------------+-----------------------------------------+ 156 | RR | _NODE NAME | REFERENCE | 157 | Type | | | 158 +--------+----------------+-----------------------------------------+ 159 | TXT | _{DNS node | {citation for the document making the | 160 | | name} | addition.} | 161 +--------+----------------+-----------------------------------------+ 163 Table 1: Underscore Global Registry Entry 165 2.2. SRV RRset Use 167 Specification for the SRV [RFC2782] resource record provides a 168 template for use of underscored node names. The global (right-most) 169 name, is characterised as naming the 'protocol' that is associated 170 with "SRV" RR usage. 172 This section provides a generic approach for changes to existing 173 specifications that define the use of an "SRV" RR. The approach 174 provides the information needed for adapting such specifications to 175 the use of the IANA DNS Underscore Global Scoped Entry Registry 176 [Attrleaf]. Hence the approach is meant both as an update to these 177 existing specifications, and as guidance for changes when those 178 documents are revised. 180 For any document that specifies the use of a "SRV" RRset, the global 181 ('protocol', right-most) underscored name is expected to be 182 registered in the IANA DNS Underscore Global Scoped Entry Registry 183 [Attrleaf]. An effort has been made to locate existing drafts that 184 do this, register the global underscored name, and list them in this 185 document. 187 If a public specification that defines use of an "SRV" record is 188 revised, and the right-most underscored name above the record is not 189 already registered, an entry for the name MUST be added to the global 190 underscored name registry. 192 Here is a template of suggested text for this to appear in the IANA 193 Considerations section of the specification: 195 "Per" [Attrleaf] "please add the following entry to the DNS 196 Underscore Global Scoped Entry Registry:" 198 +--------+----------------------+-----------------------------------+ 199 | RR | _NODE NAME | REFERENCE | 200 | Type | | | 201 +--------+----------------------+-----------------------------------+ 202 | SRV | _{DNS 'protocol' | {citation for the document making | 203 | | node name} | the addition.} | 204 +--------+----------------------+-----------------------------------+ 206 Table 2: Underscore Global Registry Entry 208 2.3. URI RRset Use 210 Specification for the URI [RFC7553] resource record provides a 211 template for use of underscored node names. The global (right-most) 212 name, is characterised as naming the 'protocol' that is associated 213 with "URI" RR usage or by reversing an Enumservice sequence. 215 This section provides a generic approach for changes to existing 216 specifications that define use of a "URI" RRset. The approach 217 provides the information needed for adapting such specifications to 218 the use of the IANA DNS Underscore Global Scoped Entry Registry 219 [Attrleaf]. Hence the approach is meant both as an update to these 220 existing specifications, and as guidance for changes when those 221 documents are revised. 223 For any RFC that specifies the use of a "URI" RR, the global 224 ('protocol' or right-most enumservice) underscored name is expected 225 to be registered in the IANA DNS Underscore Global Scoped Entry 226 Registry [Attrleaf]. An effort has been made to locate existing 227 drafts that do this and register the associated 'protocol' name. 229 If a public specification that defines use of a "URI" record is 230 revised, when the right-most underscored name used by it is not 231 already registered, an entry for the name MUST be added to the global 232 underscored name registry. 234 Here is a template of suggested text for this to appear in the IANA 235 Considerations section of the specification: 237 "Per" [Attrleaf] "please add the following entry to the DNS 238 Underscore Global Scoped Entry Registry:" 240 +-------+---------------------------+-------------------------------+ 241 | RR | _NODE NAME | REFERENCE | 242 | Type | | | 243 +-------+---------------------------+-------------------------------+ 244 | URI | _{DNS 'protocol' or | {citation for the document | 245 | | Enumservice node name} | making the addition.} | 246 +-------+---------------------------+-------------------------------+ 248 Table 3: Underscore Global Registry Entry 250 3. Underscored Template Specifications 252 3.1. SRV Specification Changes 254 The specification for a domain name under which an SRV [RFC2782] 255 resource record appears provides a template for use of underscored 256 node names. The global (right-most) underscored name, is 257 characterised as indicating the 'protocol' that is associated with 258 "SRV" RR usage. 260 The text of that existing specification is hereby updated from: 262 The format of the SRV RR 264 Here is the format of the SRV RR, whose DNS type code is 33: 265 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 266 ... 267 Proto 268 The symbolic name of the desired protocol, with an underscore 269 (_) prepended to prevent collisions with DNS labels that occur 270 in nature. _TCP and _UDP are at present the most useful values 271 for this field, though any name defined by Assigned Numbers or 272 locally may be used (as for Service). The Proto is case 273 insensitive. 275 And is to be updated to the new text: 277 The format of the SRV RR 279 Here is the format of the SRV RR, whose DNS type code is 33: 281 "_Service._Proto.Name TTL Class SRV Priority Weight Port 282 Target" _..._ 284 Proto 286 The symbolic name of the desired protocol, with an 287 underscore (_) prepended to prevent collisions with DNS 288 labels that occur in nature. _tcp and _udp are at present 289 the most useful values for this field. The Proto is case 290 insensitive. 292 The SRV RRset protocol (global, right-most) underscored name 293 SHOULD be registered in the IANA DNS Underscore Global 294 Scoped Entry Registry [Attrleaf]. 296 3.2. URI Specification Changes 298 Specification for the domain name under which a URI [RFC7553] 299 resource record occurs is similar to that for the SRV [RFC2782] 300 resource record, although the text refers only to 'service' name, 301 rather than distinguishing 'service' from 'protocol'. Further, the 302 URI RR specification permits alternative underscored naming schemes: 304 One matches what is used for "SRV", with the global (right-most) 305 underscored name calls "protocol'. 307 The other is based on a reversing of an Enumservice [RFC6117] 308 sequence. 310 The text of the existing specification is hereby updated from: 312 4.1. Owner Name, Class, and Type 314 The URI owner name is subject to special conventions. 316 Just like the SRV RR [RFC2782], the URI RR has service information 317 encoded in its owner name. In order to encode the service for a 318 specific owner name, one uses service parameters. Valid service 319 parameters are those registered by IANA in the "Service Name and 320 Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice 321 --- 322 Registrations [RFC6117]. The Enumservice Registration parameters are 323 reversed (i.e., subtype(s) before type), prepended with an underscore 324 (_), and prepended to the owner name in separate labels. The 325 underscore is prepended to the service parameters to avoid collisions 326 with DNS labels that occur in nature, and the order is reversed to 327 make it possible to do delegations, if needed, to different zones 328 (and therefore providers of DNS). 330 For example, suppose we are looking for the URI for a service with 331 ENUM Service Parameter "A:B:C" for host example.com. Then we would 332 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 334 As another example, suppose we are looking for the URI for a service 335 with Service Name "A" and Transport Protocol "B" for host 336 example.com. Then we would query for 337 (QNAME,QTYPE)=("_A._B.example.com","URI"). 339 And is to be updated to the new text: 341 4.1. Owner Name, Class, and Type 343 The URI owner name is subject to special conventions. 345 As for the SRV RRset [RFC2782], the URI RRset global (right- 346 most) underscored name SHOULD be registered in the IANA DNS 347 Underscore Global Scoped Entry Registry [Attrleaf]. 349 Just like the SRV RRset, the URI RRset has service information 350 encoded in its owner name. In order to encode the service for 351 a specific owner name, one uses service parameters. Valid 352 service parameters are: 354 + Those registered by IANA in the "Service Name and Transport 355 Protocol Port Number Registry [RFC6335]" The underscore is 356 prepended to the service parameters to avoid collisions with 357 DNS labels that occur in nature, and the order is reversed 358 to make it possible to do delegations, if needed, to 359 different zones (and therefore providers of DNS). 361 + Those listed in "Enumservice Registrations [RFC6117]. The 362 Enumservice Registration parameters are reversed (i.e., 363 subtype(s) before type), prepended with an underscore (_), 364 and prepended to the owner name in separate labels. The 365 right-most underscored Enumservice name becomes the global 366 Attrleaf name to register. 368 For example, suppose we are looking for the URI for a service 369 with ENUM Service Parameter "A:B:C" for host example.com. Then 370 we would query for 371 (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 373 As another example, suppose we are looking for the URI for a 374 service with Service Name "A" and Transport Protocol "B" for 375 host example.com. Then we would query for 376 (QNAME,QTYPE)=("_A._B.example.com","URI"). 378 4. IANA Considerations 380 Although this document makes reference to IANA registries, it 381 introduces no new IANA registries or procedures. 383 5. Security Considerations 385 This memo raises no security issues. 387 6. References 389 6.1. Normative References 391 [Attrleaf] 392 Crocker, D., "DNS Scoped Data Through '_Underscore' Naming 393 of Attribute Leaves", I-D draft-ietf-dnsop-attrleaf, 2018. 395 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 396 Registration of Enumservices: Guide, Template, and IANA 397 Considerations", RFC 6117, March 2011. 399 [RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S. 400 Cheshire, "Internet Assigned Numbers Authority (IANA) 401 Procedures for the Management of the Service Name and 402 Transport Protocol Port Number Registry", RFC 6335, Aug 403 2011. 405 [RFC7553] Falstrom, P. and O. Kolkman, "The Uniform Resource 406 Identifier (URI) DNS Resource Record", RFC 7553, 407 ISSN 2070-1721, June 2015. 409 6.2. References -- Informative 411 [IANA-reg] 412 "Protocol Registries", URL https://www.iana.org/protocols, 413 2018. 415 [RFC1035] Mockapetris, P., "Domain names - implementation and 416 specification", STD 13, RFC 1035, November 1987. 418 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 419 specifying the location of services (DNS SRV)", RFC 2782, 420 February 2000. 422 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 423 Protocol (SIP): Locating SIP Servers", RFC 3263, June 424 2002. 426 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 427 Part Four: The Uniform Resource Identifiers (URI) 428 Resolution Application", RFC 3404, October 2002. 430 [RFC3529] Harold, W., "Using Extensible Markup Language-Remote 431 Procedure Calling (XML-RPC) in Blocks Extensible Exchange 432 Protocol (BEEP)", RFC 3529, April 2003. 434 [RFC3620] New, D., "The TUNNEL Profile", RFC 3620, October 2003. 436 [RFC3832] Columbia University, Columbia University, Sun 437 Microsystems, IBM, and IBM, "Remote Service Discovery in 438 the Service Location Protocol (SLP) via DNS SRV", 439 RFC 3832, July 2004. 441 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 442 and Presence", RFC 3861, August 2004. 444 [RFC3887] "Message Tracking Query Protocol", RFC 3887, September 445 2007. 447 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 448 Service Location Using SRV RRs and the Dynamic Delegation 449 Discovery Service (DDDS)", RFC 3958, January 2005. 451 [RFC4120] USC-ISI, MIT, MIT, and MIT, "The Kerberos Network 452 Authentication Service (V5)", RFC 4120, July 2005. 454 [RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object 455 Access Protocol (SOAP) in Blocks Extensible Exchange 456 Protocol (BEEP)", RFC 4227, January 2006. 458 [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key 459 Infrastructure: Repository Locator Service", RFC 4386, 460 February 2006. 462 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 463 Infrastructure Operational Protocols: Certificate Store 464 Access via HTTP", RFC 4387, February 2006. 466 [RFC4976] Jennings, C., Mahy, R., and Roach, "Relay Extensions for 467 the Message Session Relay Protocol (MSRP)", RFC 4976, 468 September 2007. 470 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., 471 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, 472 October 2007. 474 [RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) 475 Namespace for the Digital Video Broadcasting Project 476 (DVB)", RFC 5328, September 2008. 478 [RFC5389] Rosenberg, Mahy, Matthews, and Wing, "Session Traversal 479 Utilities for NAT (STUN)", RFC 5389, October 2008. 481 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 482 Ed., "Control And Provisioning of Wireless Access Points 483 (CAPWAP) Protocol Specification", RFC 5415, March 2009. 485 [RFC5507] Faltstrom, P., Ed. and R. Austein, Ed., "Design Choices 486 When Expanding the DNS", RFC 5507, April 2009. 488 [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) 489 Registration of Instant Messaging and Presence DNS SRV RRs 490 for the Session Initiation Protocol (SIP)", RFC 5509, 491 April 2009. 493 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 494 Reference", RFC 5518, April 2009. 496 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 497 Hosts and Routers", RFC 5555, June 2009. 499 [RFC5617] Sendmail, Inc., Cisco Systems, Inc., Yahoo! Inc., and 500 Taughannock Networks, "DomainKeys Identified Mail (DKIM) 501 Author Domain Signing Practices (ADSP)", RFC 5617, August 502 2009. 504 [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using 505 DNS", RFC 5679, December 2009. 507 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 508 Relays around NAT (TURN): Relay Extensions to Session 509 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 511 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 512 Using Session Traversal Utilities for NAT (STUN)", 513 RFC 5780, May 2010. 515 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 516 Managing Sieve Scripts", RFC 5804, July 2010. 518 [RFC5864] Allbery, R., "NS SRV Resource Records for AFS", RFC 5864, 519 April 2010. 521 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 522 (TURN) Resolution Mechanism", RFC 5928, August 2010. 524 [RFC6011] Lawrence, S., Ed. and J. Elwell, "Session Initiation 525 Protocol (SIP) User Agent Configuration", RFC 6011, 526 October 2010. 528 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 529 Protocol (XMPP): Core", RFC 6120, March 2011. 531 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 532 Submission/Access Services", RFC 6186, March 2011. 534 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 535 Identified Mail (DKIM) Signatures", RFC 6376, Sept 2011. 537 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 538 "Diameter Base Protocol", RFC 6733, October 2012. 540 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 541 Authorizing Use of Domains in E-Mail, Version 1", 542 RFC 7208, April 2014. 544 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 545 Message Authentication, Reporting, and Conformance 546 (DMARC)", RFC 7489, March 2015. 548 Appendix A. Acknowledgements 550 Thanks go to Bill Fenner, Tony Hansen, Peter Koch, Olaf Kolkman, and 551 Andrew Sullivan for diligent review of the (much) earlier drafts. 552 For the later enhancements, thanks to: Tim Wicinski, John Levine, Bob 553 Harold, Joel Jaeggli, Ondřej Sury and Paul Wouters. 555 Special thanks to Ray Bellis for more than 10 years of persistent 556 encouragement to continue this effort, as well as the suggestion for 557 an essential simplification to the registration model. 559 Author's Address 561 Dave Crocker 562 Brandenburg InternetWorking 563 675 Spruce Dr. 564 Sunnyvale, CA 94086 565 USA 567 Phone: +1.408.246.8253 568 Email: dcrocker@bbiw.net 569 URI: http://bbiw.net/