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