idnits 2.17.1 draft-ietf-dnsop-attrleaf-fix-00.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 138: '...e is revised, it SHOULD add an entry t...' RFC 2119 keyword, line 181: '...try for the name SHOULD be added to th...' RFC 2119 keyword, line 223: '...try for the name SHOULD be added to th...' RFC 2119 keyword, line 283: '... SHOULD be registered in the I...' RFC 2119 keyword, line 336: '...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 3, 2018) is 2184 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 411, but no explicit reference was found in the text == Unused Reference: 'RFC3404' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC3529' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC3620' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC3832' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC3861' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC3887' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC3958' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC4227' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC4386' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC4387' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC5026' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC5328' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC5415' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC5507' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC5509' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC5518' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC5555' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC5617' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5679' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC5780' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC5804' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC5864' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC5928' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC6011' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC6186' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC7489' is defined on line 533, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Attrleaf' ** 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 (==), 10 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 3, 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 4, 2018 13 DNS Attrleaf Changes: Fixing Specifications with _Underscored Node Name 14 Use 15 draft-ietf-dnsop-attrleaf-fix-00 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 4, 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. 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 . . . . . . . . . . . . . . . . . . 12 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. RRset Use in Specifications 120 2.1. TXT RRset Use 122 This section provides a generic approach for changes to existing 123 specifications that define straightforward use of _underscored node 124 names, when scoping the use of a "TXT" RR. The approach provides the 125 information needed for adapting such specifications to the use of the 126 IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. Hence 127 the approach is meant both as an update to these existing 128 specifications, and as guidance for changes when those documents are 129 revised. 131 For any document that specifies the use of a "TXT" RRset under an 132 underscored name, that name is expected to be registered in the IANA 133 DNS Underscore Global Scoped Entry Registry [Attrleaf]. An effort 134 has been made to locate existing drafts that do this, register the 135 global underscored name, and list them in this document. 137 If a specification that defines use of a "TXT" record within an 138 underscore-scoped name is revised, it SHOULD add an entry to the 139 global underscored name registry, if one does not already exist. 141 Here is a template of suggested text for this to appear in the IANA 142 Considerations section of the specification: 144 "Per" [Attrleaf] "please add the following entry to the DNS 145 Underscore Global Scoped Entry Registry:" 147 +--------+----------------+-----------------------------------------+ 148 | RR | _NODE NAME | REFERENCE | 149 | Type | | | 150 +--------+----------------+-----------------------------------------+ 151 | TXT | _{DNS node | {citation for the document making the | 152 | | name} | addition.} | 153 +--------+----------------+-----------------------------------------+ 155 Table 1: Underscore Global Registry Entry 157 2.2. SRV RRset Use 159 Specification for the SRV [RFC2782] resource record provides a 160 template for use of underscored node names. The global (right-most) 161 name, is characterised as naming the 'protocol' that is associated 162 with "SRV" RR usage. 164 This section provides a generic approach for changes to existing 165 specifications that define the use of an "SRV" RR. The approach 166 provides the information needed for adapting such specifications to 167 the use of the IANA DNS Underscore Global Scoped Entry Registry 168 [Attrleaf]. Hence the approach is meant both as an update to these 169 existing specifications, and as guidance for changes when those 170 documents are revised. 172 For any document that specifies the use of a "SRV" RRset, the global 173 ('protocol', right-most) underscored name is expected to be 174 registered in the IANA DNS Underscore Global Scoped Entry Registry 175 [Attrleaf]. An effort has been made to locate existing drafts that 176 do this, register the global underscored name, and list them in this 177 document. 179 If a specification that defines use of an "SRV" record is revised, 180 and the right-most underscored name above the record is not already 181 registered, an entry for the name SHOULD be added to the global 182 underscored name registry. 184 Here is a template of suggested text for this to appear in the IANA 185 Considerations section of the specification: 187 "Per" [Attrleaf] "please add the following entry to the DNS 188 Underscore Global Scoped Entry Registry:" 190 +--------+----------------------+-----------------------------------+ 191 | RR | _NODE NAME | REFERENCE | 192 | Type | | | 193 +--------+----------------------+-----------------------------------+ 194 | SRV | _{DNS 'protocol' | {citation for the document making | 195 | | node name} | the addition.} | 196 +--------+----------------------+-----------------------------------+ 198 Table 2: Underscore Global Registry Entry 200 2.3. URI RRset Use 202 Specification for the URI [RFC7553] resource record provides a 203 template for use of underscored node names. The global (right-most) 204 name, is characterised as naming the 'protocol' that is associated 205 with "URI" RR usage or by reversing an Enumservice sequence. 207 This section provides a generic approach for changes to existing 208 specifications that define use of a "URI" RRset. The approach 209 provides the information needed for adapting such specifications to 210 the use of the IANA DNS Underscore Global Scoped Entry Registry 211 [Attrleaf]. Hence the approach is meant both as an update to these 212 existing specifications, and as guidance for changes when those 213 documents are revised. 215 For any RFC that specifies the use of a "URI" RR, the global 216 ('protocol' or right-most enumservice) underscored name is expected 217 to be registered in the IANA DNS Underscore Global Scoped Entry 218 Registry [Attrleaf]. An effort has been made to locate existing 219 drafts that do this and register the associated 'protocol' name. 221 If a specification that defines use of a "URI" record is revised, 222 when the right-most underscored name used by it is not already 223 registered, an entry for the name SHOULD be added to the global 224 underscored name registry. 226 Here is a template of suggested text for this to appear in the IANA 227 Considerations section of the specification: 229 "Per" [Attrleaf] "please add the following entry to the DNS 230 Underscore Global Scoped Entry Registry:" 232 +-------+---------------------------+-------------------------------+ 233 | RR | _NODE NAME | REFERENCE | 234 | Type | | | 235 +-------+---------------------------+-------------------------------+ 236 | URI | _{DNS 'protocol' or | {citation for the document | 237 | | Enumservice node name} | making the addition.} | 238 +-------+---------------------------+-------------------------------+ 240 Table 3: Underscore Global Registry Entry 242 3. Underscored Template Specifications 244 3.1. SRV Specification Changes 246 The specification for a domain name under which an SRV [RFC2782] 247 resource record appears provides a template for use of underscored 248 node names. The global (right-most) underscored name, is 249 characterised as indicating the 'protocol' that is associated with 250 "SRV" RR usage. 252 The text of that specification is hereby updated from: 254 The format of the SRV RR 256 Here is the format of the SRV RR, whose DNS type code is 33: 257 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 258 ... 259 Proto 260 The symbolic name of the desired protocol, with an underscore 261 (_) prepended to prevent collisions with DNS labels that occur 262 in nature. _TCP and _UDP are at present the most useful values 263 for this field, though any name defined by Assigned Numbers or 264 locally may be used (as for Service). The Proto is case 265 insensitive. 267 The updated text is: 269 The format of the SRV RR 271 Here is the format of the SRV RR, whose DNS type code is 33: 273 "_Service._Proto.Name TTL Class SRV Priority Weight Port 274 Target" _..._ 276 Proto 277 The symbolic name of the desired protocol, with an underscore 278 (_) prepended to prevent collisions with DNS labels that occur 279 in nature. _tcp and _udp are at present the most useful values 280 for this field. The Proto is case insensitive. 282 The SRV RRset protocol (global, right-most) underscored name 283 SHOULD be registered in the IANA DNS Underscore Global Scoped 284 Entry Registry [Attrleaf]. 286 3.2. URI Specification Changes 288 Specification for the domain name under which a URI [RFC7553] 289 resource record occurs is similar to that for the SRV [RFC2782] 290 resource record, although the text refers only to 'service' name, 291 rather than distinguishing 'service' from 'protocol'. Further, the 292 URI RR specification permits alternative underscored naming schemes: 294 One matches what is used for "SRV", with the global (right-most) 295 underscored name calls "protocol'. 297 The other is based on a reversing of an Enumservice [RFC6117] 298 sequence. 300 The text to be updated is: 302 4.1. Owner Name, Class, and Type 304 The URI owner name is subject to special conventions. 306 Just like the SRV RR [RFC2782], the URI RR has service information 307 encoded in its owner name. In order to encode the service for a 308 specific owner name, one uses service parameters. Valid service 309 parameters are those registered by IANA in the "Service Name and 310 Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice 311 --- 312 Registrations [RFC6117]. The Enumservice Registration parameters are 313 reversed (i.e., subtype(s) before type), prepended with an underscore 314 (_), and prepended to the owner name in separate labels. The 315 underscore is prepended to the service parameters to avoid collisions 316 with DNS labels that occur in nature, and the order is reversed to 317 make it possible to do delegations, if needed, to different zones 318 (and therefore providers of DNS). 320 For example, suppose we are looking for the URI for a service with 321 ENUM Service Parameter "A:B:C" for host example.com. Then we would 322 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 324 As another example, suppose we are looking for the URI for a service 325 with Service Name "A" and Transport Protocol "B" for host 326 example.com. Then we would query for 327 (QNAME,QTYPE)=("_A._B.example.com","URI"). 329 The updated text is: 331 4.1. Owner Name, Class, and Type 333 The URI owner name is subject to special conventions. 335 As for the SRV RRset [RFC2782], the URI RRset global (right-most) 336 underscored name SHOULD be registered in the IANA DNS Underscore 337 Global Scoped Entry Registry [Attrleaf]. 339 Just like the SRV RRset, the URI RRset has service information 340 encoded in its owner name. In order to encode the service for a 341 specific owner name, one uses service parameters. Valid service 342 parameters are: 344 * Those registered by IANA in the "Service Name and Transport 345 Protocol Port Number Registry [RFC6335]" The underscore is 346 prepended to the service parameters to avoid collisions with 347 DNS labels that occur in nature, and the order is reversed to 348 make it possible to do delegations, if needed, to different 349 zones (and therefore providers of DNS). 351 * Those listed in "Enumservice Registrations [RFC6117]. The 352 Enumservice Registration parameters are reversed (i.e., 353 subtype(s) before type), prepended with an underscore (_), and 354 prepended to the owner name in separate labels. The right-most 355 underscored Enumservice name becomes the global Attrleaf name 356 to register. 358 For example, suppose we are looking for the URI for a service with 359 ENUM Service Parameter "A:B:C" for host example.com. Then we 360 would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 362 As another example, suppose we are looking for the URI for a 363 service with Service Name "A" and Transport Protocol "B" for host 364 example.com. Then we would query for 365 (QNAME,QTYPE)=("_A._B.example.com","URI"). 367 4. IANA Considerations 369 Although this document makes reference to IANA registries, it 370 introduces no new IANA registries or procedures. 372 5. Security Considerations 374 This memo raises no security issues. 376 6. References 378 6.1. Normative References 380 [Attrleaf] 381 Crocker, D., "DNS Scoped Data Through '_Underscore' Naming 382 of Attribute Leaves", 2018. 384 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 385 Registration of Enumservices: Guide, Template, and IANA 386 Considerations", RFC 6117, March 2011. 388 [RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S. 389 Cheshire, "Internet Assigned Numbers Authority (IANA) 390 Procedures for the Management of the Service Name and 391 Transport Protocol Port Number Registry", RFC 6335, Aug 392 2011. 394 [RFC7553] Falstrom, P. and O. Kolkman, "The Uniform Resource 395 Identifier (URI) DNS Resource Record", RFC 7553, 396 ISSN 2070-1721, June 2015. 398 6.2. References -- Informative 400 [IANA-reg] 401 "Protocol Registries", URL https://www.iana.org/protocols, 402 2018. 404 [RFC1035] Mockapetris, P., "Domain names - implementation and 405 specification", STD 13, RFC 1035, November 1987. 407 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 408 specifying the location of services (DNS SRV)", RFC 2782, 409 February 2000. 411 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 412 Protocol (SIP): Locating SIP Servers", RFC 3263, June 413 2002. 415 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 416 Part Four: The Uniform Resource Identifiers (URI) 417 Resolution Application", RFC 3404, October 2002. 419 [RFC3529] Harold, W., "Using Extensible Markup Language-Remote 420 Procedure Calling (XML-RPC) in Blocks Extensible Exchange 421 Protocol (BEEP)", RFC 3529, April 2003. 423 [RFC3620] New, D., "The TUNNEL Profile", RFC 3620, October 2003. 425 [RFC3832] Columbia University, Columbia University, Sun 426 Microsystems, IBM, and IBM, "Remote Service Discovery in 427 the Service Location Protocol (SLP) via DNS SRV", 428 RFC 3832, July 2004. 430 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 431 and Presence", RFC 3861, August 2004. 433 [RFC3887] "Message Tracking Query Protocol", RFC 3887, September 434 2007. 436 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 437 Service Location Using SRV RRs and the Dynamic Delegation 438 Discovery Service (DDDS)", RFC 3958, January 2005. 440 [RFC4120] USC-ISI, MIT, MIT, and MIT, "The Kerberos Network 441 Authentication Service (V5)", RFC 4120, July 2005. 443 [RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object 444 Access Protocol (SOAP) in Blocks Extensible Exchange 445 Protocol (BEEP)", RFC 4227, January 2006. 447 [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key 448 Infrastructure: Repository Locator Service", RFC 4386, 449 February 2006. 451 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 452 Infrastructure Operational Protocols: Certificate Store 453 Access via HTTP", RFC 4387, February 2006. 455 [RFC4976] Jennings, C., Mahy, R., and Roach, "Relay Extensions for 456 the Message Session Relay Protocol (MSRP)", RFC 4976, 457 September 2007. 459 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., 460 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, 461 October 2007. 463 [RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) 464 Namespace for the Digital Video Broadcasting Project 465 (DVB)", RFC 5328, September 2008. 467 [RFC5389] Rosenberg, Mahy, Matthews, and Wing, "Session Traversal 468 Utilities for NAT (STUN)", RFC 5389, October 2008. 470 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 471 Ed., "Control And Provisioning of Wireless Access Points 472 (CAPWAP) Protocol Specification", RFC 5415, March 2009. 474 [RFC5507] Faltstrom, P., Ed. and R. Austein, Ed., "Design Choices 475 When Expanding the DNS", RFC 5507, April 2009. 477 [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) 478 Registration of Instant Messaging and Presence DNS SRV RRs 479 for the Session Initiation Protocol (SIP)", RFC 5509, 480 April 2009. 482 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 483 Reference", RFC 5518, April 2009. 485 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 486 Hosts and Routers", RFC 5555, June 2009. 488 [RFC5617] Sendmail, Inc., Cisco Systems, Inc., Yahoo! Inc., and 489 Taughannock Networks, "DomainKeys Identified Mail (DKIM) 490 Author Domain Signing Practices (ADSP)", RFC 5617, August 491 2009. 493 [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using 494 DNS", RFC 5679, December 2009. 496 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 497 Relays around NAT (TURN): Relay Extensions to Session 498 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 500 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 501 Using Session Traversal Utilities for NAT (STUN)", 502 RFC 5780, May 2010. 504 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 505 Managing Sieve Scripts", RFC 5804, July 2010. 507 [RFC5864] Allbery, R., "NS SRV Resource Records for AFS", RFC 5864, 508 April 2010. 510 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 511 (TURN) Resolution Mechanism", RFC 5928, August 2010. 513 [RFC6011] Lawrence, S., Ed. and J. Elwell, "Session Initiation 514 Protocol (SIP) User Agent Configuration", RFC 6011, 515 October 2010. 517 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 518 Protocol (XMPP): Core", RFC 6120, March 2011. 520 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 521 Submission/Access Services", RFC 6186, March 2011. 523 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 524 Identified Mail (DKIM) Signatures", RFC 6376, Sept 2011. 526 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 527 "Diameter Base Protocol", RFC 6733, October 2012. 529 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 530 Authorizing Use of Domains in E-Mail, Version 1", 531 RFC 7208, April 2014. 533 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 534 Message Authentication, Reporting, and Conformance 535 (DMARC)", RFC 7489, March 2015. 537 Appendix A. Acknowledgements 539 Thanks go to Bill Fenner, Tony Hansen, Peter Koch, Olaf Kolkman, and 540 Andrew Sullivan for diligent review of the (much) earlier drafts. 541 For the later enhancements, thanks to: Tim Wicinski, John Levine, Bob 542 Harold, Joel Jaeggli, Ondřej Sury and Paul Wouters. 544 Special thanks to Ray Bellis for more than 10 years of persistent 545 encouragement to continue this effort, as well as the suggestion for 546 an essential simplification to the registration model. 548 Author's Address 550 Dave Crocker 551 Brandenburg InternetWorking 552 675 Spruce Dr. 553 Sunnyvale, CA 94086 554 USA 556 Phone: +1.408.246.8253 557 Email: dcrocker@bbiw.net 558 URI: http://bbiw.net/