idnits 2.17.1 draft-ietf-dnsop-attrleaf-fix-06.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 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 RFC2782, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3832, 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (November 3, 2018) is 2002 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5509' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC7671' is defined on line 599, 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: 1 error (**), 0 flaws (~~), 5 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, 3529, 3620, 3832, November 3, 2018 5 3887, 3958, 4120, 4227, 4386, 6 4387, 4976, 5026, 5328, 5389, 7 5415, 5518, 5555, 5617, 5679, 8 5766, 5780, 5804, 5864, 5928, 9 6120, 6186, 6376, 6733, 6763, 10 7208, 7489, 8145 (if approved) 11 Intended status: Standards Track 12 Expires: May 7, 2019 14 DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name 15 Use 16 draft-ietf-dnsop-attrleaf-fix-06 18 Abstract 20 Original uses of an underscore character as a domain node name 21 prefix, which creates a space for constrained interpretation of 22 resource records, were specified without the benefit of an IANA 23 registry. This produced an entirely uncoordinated set of name- 24 creation activities, all drawing from the same namespace. A registry 25 now has been defined. However the existing specifications that use 26 underscore naming need to be modified, to be in line with the new 27 registry. This document specifies those changes. The changes 28 preserve existing software and operational practice, while adapting 29 the specifications for those practices to the newer underscore 30 registry model. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 7, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Underscored RRset Use in Specifications . . . . . . . . . . . 3 68 2.1. TXT RRset Use . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. SRV RRset Use . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. URI RRset Use . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Underscored Template Specifications . . . . . . . . . . . . . 6 72 3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 6 73 3.2. URI Specification Changes . . . . . . . . . . . . . . . . 7 74 3.3. DNSSEC Signaling Specification Changes . . . . . . . . . 9 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 6.2. References -- Informative . . . . . . . . . . . . . . . . 10 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Underscored RRset Use in Specifications 129 The use of underscored node names is specific to each RRTYPE that is 130 being scoped. Each name defines a place, but does not define the 131 rules for what appears underneath that place, either as additional 132 underscored naming or as a leaf node with resource records. Details 133 for those rules are provided by specifications for individual 134 RRTYPEs. The sections below describe the way that existing 135 underscore labels are used with the RRTYPEs that they name. 137 2.1. TXT RRset Use 139 NOTE - Documents falling into this category include: 141 [RFC6763], [RFC6120], [RFC5518], [RFC5617], [RFC6376], 142 [RFC7208], and [RFC7489] 144 This section provides a generic approach for changes to existing 145 specifications that define straightforward use of underscored node 146 names, when scoping the use of a "TXT" RRset. The approach provides 147 the information needed for adapting such specifications to the use of 148 the IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. 149 Hence the approach is meant both as an update to these existing 150 specifications, and as guidance for changes when those documents are 151 revised. 153 For any document that specifies the use of a "TXT" RRset under one or 154 more underscored names, the 'global' name is expected to be 155 registered in the IANA DNS Underscore Global Scoped Entry Registry 156 [Attrleaf]. An effort has been made to locate existing drafts that 157 do this, register the global underscored names, and list them in the 158 initial set of names added to the registry. 160 If a public specification defines use of a TXT RRset and calls for 161 the use of an underscore-prefixed domain name, here is a template of 162 suggested text for registering the global underscored name -- the one 163 closest to the root -- through the IANA Considerations section of the 164 specification: 166 "Per" [Attrleaf] "please add the following entry to the DNS 167 Underscore Global Scoped Entry Registry:" 169 +--------+----------------+-----------------------------------------+ 170 | RR | _NODE NAME | REFERENCE | 171 | Type | | | 172 +--------+----------------+-----------------------------------------+ 173 | TXT | _{DNS node | {citation for the document making the | 174 | | name} | addition.} | 175 +--------+----------------+-----------------------------------------+ 177 Table 1: Underscore Global Registry Entry for TXT RR Use 179 2.2. SRV RRset Use 181 NOTE - Documents falling into this category include: 183 [RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887], 184 [RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387], 185 [RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415], 187 [RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804], 188 [RFC5864], [RFC5928], [RFC6186] 190 Specification of the SRV [RFC2782] resource record provides a 191 template for use of underscored node names. The global name is 192 characterised as referencing the 'protocol' that is associated with 193 "SRV" RRset usage. 195 This section provides a generic approach for changes to existing 196 specifications that define the use of an "SRV" RRset. The approach 197 provides the information needed for adapting such specifications to 198 the use of the IANA DNS Underscore Global Scoped Entry Registry 199 [Attrleaf]. Hence the approach is meant both as an update to these 200 existing specifications, and as guidance for changes when those 201 documents are revised. 203 For any document that specifies the use of an "SRV" RRset, the global 204 ('protocol') underscored name is expected to be registered in the 205 IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. An 206 effort has been made to locate existing drafts that do this, register 207 the global underscored names, and list them in the initial set of 208 names added to the registry. 210 If a public specification defines use of a SRV RRset and calls for 211 the use of an underscore-prefixed domain name, here is a template of 212 suggested text for registering the global underscored name -- the one 213 closest to the root -- through the IANA Considerations section of the 214 specification: 216 "Per" [Attrleaf] "please add the following entry to the DNS 217 Underscore Global Scoped Entry Registry:" 219 +--------+----------------------+-----------------------------------+ 220 | RR | _NODE NAME | REFERENCE | 221 | Type | | | 222 +--------+----------------------+-----------------------------------+ 223 | SRV | _{DNS 'protocol' | {citation for the document making | 224 | | node name} | the addition.} | 225 +--------+----------------------+-----------------------------------+ 227 Table 2: Underscore Global Registry Entry for SRV RR Use 229 2.3. URI RRset Use 231 Specification of the URI [RFC7553] resource record provides a 232 template for use of underscored node names. The global name is 233 characterised as naming the 'protocol' that is associated with "URI" 234 RR usage or by reversing an Enumservice sequence [RFC6117]. 236 This section provides a generic approach for changes to existing 237 specifications that define use of a "URI" RRset. The approach 238 provides the information needed for adapting such specifications to 239 the use of the IANA DNS Underscore Global Scoped Entry Registry 240 [Attrleaf]. Hence the approach is meant both as an update to these 241 existing specifications, and as guidance for changes when those 242 documents are revised. 244 For any document that specifies the use of a "URI" RRset, the global 245 ('protocol' or highest-level enumservice) underscored name is 246 expected to be registered in the IANA DNS Underscore Global Scoped 247 Entry Registry [Attrleaf]. An effort has been made to locate 248 existing drafts that do this, register the global underscored names, 249 and list them in the initial set of names added to the registry. 251 If a public specification defines use of a URI RRset and calls for 252 the use of an underscore-prefixed domain name, here is a template of 253 suggested text for registering the global underscored name -- the one 254 closest to the root -- through the IANA Considerations section of the 255 specification: 257 "Per" [Attrleaf] "please add the following entry to the DNS 258 Underscore Global Scoped Entry Registry:" 260 +-------+---------------------------+-------------------------------+ 261 | RR | _NODE NAME | REFERENCE | 262 | Type | | | 263 +-------+---------------------------+-------------------------------+ 264 | URI | _{DNS 'protocol' or | {citation for the document | 265 | | Enumservice node name} | making the addition.} | 266 +-------+---------------------------+-------------------------------+ 268 Table 3: Underscore Global Registry Entry for URI RR Use 270 3. Underscored Template Specifications 272 3.1. SRV Specification Changes 274 The specification for a domain name, under which an SRV [RFC2782] 275 resource record appears, provides a template for use of underscored 276 node names. The global underscored name is characterised as 277 indicating the 'protocol' that is associated with "SRV" RR usage. 279 Text of that existing specification is changed as follows: 281 OLD: 283 The format of the SRV RR 285 Here is the format of the SRV RR, whose DNS type code is 33: 286 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 287 ... 288 Proto 289 The symbolic name of the desired protocol, with an underscore 290 (_) prepended to prevent collisions with DNS labels that occur 291 in nature. _TCP and _UDP are at present the most useful values 292 for this field, though any name defined by Assigned Numbers or 293 locally may be used (as for Service). The Proto is case 294 insensitive. 296 NEW: 298 The format of the SRV RR 300 Here is the format of the SRV RR, whose DNS type code is 33: 302 "_Service._Proto.Name TTL Class SRV Priority Weight Port 303 Target" 305 _..._ 307 Proto 309 The symbolic name of the desired protocol, with an 310 underscore (_) prepended to prevent collisions with DNS 311 labels that occur in nature. _TCP and _UDP are at present 312 the most useful values for this field. The Proto is case 313 insensitive. 315 The SRV RRset protocol (global) underscored name SHOULD be 316 registered in the IANA DNS Underscore Global Scoped Entry 317 Registry [Attrleaf]. 319 3.2. URI Specification Changes 321 Specification for the domain name, under which a URI [RFC7553] 322 resource record occurs, is similar to that for the SRV [RFC2782] 323 resource record, although the text refers only to 'service' name, 324 rather than distinguishing 'service' from 'protocol'. Further, the 325 URI RR specification permits alternative underscored naming schemes: 327 One matches what is used for "SRV", with the global underscored 328 name called "protocol'. 330 The other is based on a reversing of an Enumservice [RFC6117] 331 sequence. 333 Text of that existing specification is changed as follows: 335 OLD: 337 4.1. Owner Name, Class, and Type 339 The URI owner name is subject to special conventions. 341 Just like the SRV RR [RFC2782], the URI RR has service information 342 encoded in its owner name. In order to encode the service for a 343 specific owner name, one uses service parameters. Valid service 344 parameters are those registered by IANA in the "Service Name and 345 Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice 346 --- 347 Registrations [RFC6117]. The Enumservice Registration parameters are 348 reversed (i.e., subtype(s) before type), prepended with an underscore 349 (_), and prepended to the owner name in separate labels. The 350 underscore is prepended to the service parameters to avoid collisions 351 with DNS labels that occur in nature, and the order is reversed to 352 make it possible to do delegations, if needed, to different zones 353 (and therefore providers of DNS). 355 For example, suppose we are looking for the URI for a service with 356 ENUM Service Parameter "A:B:C" for host example.com. Then we would 357 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 359 As another example, suppose we are looking for the URI for a service 360 with Service Name "A" and Transport Protocol "B" for host 361 example.com. Then we would query for 362 (QNAME,QTYPE)=("_A._B.example.com","URI"). 364 NEW: 366 4.1. Owner Name, Class, and Type 368 The URI owner name is subject to special conventions. 370 As for the SRV RRset [RFC2782], the URI RRset global (highest- 371 level) underscored name SHOULD be registered in the IANA DNS 372 Underscore Global Scoped Entry Registry [Attrleaf]. 374 Just like the SRV RRset, the URI RRset has service information 375 encoded in its owner name. In order to encode the service for 376 a specific owner name, one uses service parameters. Valid 377 service parameters are: 379 + Those registered by IANA in the "Service Name and Transport 380 Protocol Port Number Registry" [RFC6335] . The underscore is 381 prepended to the service parameters to avoid collisions with 382 DNS labels that occur in nature, and the order is reversed 383 to make it possible to do delegations, if needed, to 384 different zones (and therefore providers of DNS). 386 + Those listed in "Enumservice Registrations" [RFC6117]. The 387 Enumservice Registration parameters are reversed (i.e., 388 subtype(s) before type), prepended with an underscore (_), 389 and prepended to the owner name in separate labels. The 390 highest-level (global) underscored Enumservice name becomes 391 the global Attrleaf name to register. 393 For example, suppose we are looking for the URI for a service 394 with ENUM Service Parameter "A:B:C" for host example.com. Then 395 we would query for 396 (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 398 As another example, suppose we are looking for the URI for a 399 service with Service Name "A" and Transport Protocol "B" for 400 host example.com. Then we would query for 401 (QNAME,QTYPE)=("_A._B.example.com","URI"). 403 3.3. DNSSEC Signaling Specification Changes 405 "Signaling Trust Anchor Knowledge in DNS Security Extensions 406 (DNSSEC)" [RFC8145] defines a use of DNS node names that effectively 407 consumes all names beginning with the string ""_ta-"", when using the 408 NULL RR in the query. 410 Text of Section 5.1, "Query Format", of that existing specification, 411 is changed as follows: 413 OLD: 415 For example, a validating DNS resolver ... 416 QNAME=_ta-4444. 418 NEW: 420 For example, a validating DNS resolver ... "QNAME=_ta-4444". 422 Under the NULL RR, an entry is registered in the IANA DNS 423 Underscore Global Scoped Entry Registry [Attrleaf] for all node 424 names beginning with ""_ta-"". 426 4. IANA Considerations 428 Although this document makes reference to IANA registries, it 429 introduces no new IANA registries or procedures. 431 5. Security Considerations 433 This memo raises no security issues. 435 6. References 437 6.1. Normative References 439 [Attrleaf] 440 Crocker, D., "DNS Scoped Data Through 'Underscore' Naming 441 of Attribute Leaves", I-D draft-ietf-dnsop-attrleaf, 2018. 443 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 444 Registration of Enumservices: Guide, Template, and IANA 445 Considerations", RFC 6117, March 2011. 447 [RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S. 448 Cheshire, "Internet Assigned Numbers Authority (IANA) 449 Procedures for the Management of the Service Name and 450 Transport Protocol Port Number Registry", RFC 6335, Aug 451 2011. 453 [RFC7553] Falstrom, P. and O. Kolkman, "The Uniform Resource 454 Identifier (URI) DNS Resource Record", RFC 7553, 455 ISSN 2070-1721, June 2015. 457 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 458 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 459 RFC 8145, April 2017. 461 6.2. References -- Informative 463 [IANA-reg] 464 "Protocol Registries", URL https://www.iana.org/protocols, 465 2018. 467 [RFC1035] Mockapetris, P., "Domain names - implementation and 468 specification", STD 13, RFC 1035, November 1987. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 474 specifying the location of services (DNS SRV)", RFC 2782, 475 February 2000. 477 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 478 Protocol (SIP): Locating SIP Servers", RFC 3263, June 479 2002. 481 [RFC3529] Harold, W., "Using Extensible Markup Language-Remote 482 Procedure Calling (XML-RPC) in Blocks Extensible Exchange 483 Protocol (BEEP)", RFC 3529, April 2003. 485 [RFC3620] New, D., "The TUNNEL Profile", RFC 3620, October 2003. 487 [RFC3832] Columbia University, Columbia University, Sun 488 Microsystems, IBM, and IBM, "Remote Service Discovery in 489 the Service Location Protocol (SLP) via DNS SRV", 490 RFC 3832, July 2004. 492 [RFC3887] "Message Tracking Query Protocol", RFC 3887, September 493 2007. 495 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 496 Service Location Using SRV RRs and the Dynamic Delegation 497 Discovery Service (DDDS)", RFC 3958, January 2005. 499 [RFC4120] USC-ISI, MIT, MIT, and MIT, "The Kerberos Network 500 Authentication Service (V5)", RFC 4120, July 2005. 502 [RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object 503 Access Protocol (SOAP) in Blocks Extensible Exchange 504 Protocol (BEEP)", RFC 4227, January 2006. 506 [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key 507 Infrastructure: Repository Locator Service", RFC 4386, 508 February 2006. 510 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 511 Infrastructure Operational Protocols: Certificate Store 512 Access via HTTP", RFC 4387, February 2006. 514 [RFC4976] Jennings, C., Mahy, R., and Roach, "Relay Extensions for 515 the Message Session Relay Protocol (MSRP)", RFC 4976, 516 September 2007. 518 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., 519 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, 520 DOI 10.17487/RFC5026, October 2007, 521 . 523 [RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) 524 Namespace for the Digital Video Broadcasting Project 525 (DVB)", RFC 5328, September 2008. 527 [RFC5389] Rosenberg, Mahy, Matthews, and Wing, "Session Traversal 528 Utilities for NAT (STUN)", RFC 5389, October 2008. 530 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 531 Ed., "Control And Provisioning of Wireless Access Points 532 (CAPWAP) Protocol Specification", RFC 5415, March 2009. 534 [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) 535 Registration of Instant Messaging and Presence DNS SRV RRs 536 for the Session Initiation Protocol (SIP)", RFC 5509, 537 DOI 10.17487/RFC5509, April 2009, 538 . 540 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 541 Reference", RFC 5518, April 2009. 543 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 544 Hosts and Routers", RFC 5555, June 2009. 546 [RFC5617] Sendmail, Inc., Cisco Systems, Inc., Yahoo! Inc., and 547 Taughannock Networks, "DomainKeys Identified Mail (DKIM) 548 Author Domain Signing Practices (ADSP)", RFC 5617, August 549 2009. 551 [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using 552 DNS", RFC 5679, December 2009. 554 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 555 Relays around NAT (TURN): Relay Extensions to Session 556 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 558 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 559 Using Session Traversal Utilities for NAT (STUN)", 560 RFC 5780, May 2010. 562 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 563 Managing Sieve Scripts", RFC 5804, July 2010. 565 [RFC5864] Allbery, R., "NS SRV Resource Records for AFS", RFC 5864, 566 April 2010. 568 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 569 (TURN) Resolution Mechanism", RFC 5928, August 2010. 571 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 572 Protocol (XMPP): Core", RFC 6120, March 2011. 574 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 575 Submission/Access Services", RFC 6186, March 2011. 577 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 578 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 579 RFC 6376, DOI 10.17487/RFC6376, September 2011, 580 . 582 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 583 Ed., "Diameter Base Protocol", RFC 6733, 584 DOI 10.17487/RFC6733, October 2012, 585 . 587 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 588 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 589 . 591 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 592 Authorizing Use of Domains in E-Mail, Version 1", 593 RFC 7208, April 2014. 595 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 596 Message Authentication, Reporting, and Conformance 597 (DMARC)", RFC 7489, March 2015. 599 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 600 Authentication of Named Entities (DANE) Protocol: Updates 601 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 602 October 2015, . 604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 606 May 2017, . 608 Appendix A. Acknowledgements 610 Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf 611 Kolkman, and Andrew Sullivan for diligent review of the (much) 612 earlier drafts. For the later enhancements, thanks to: Tim Wicinski, 613 John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul 614 Wouters. 616 Special thanks to Ray Bellis for his persistent encouragement to 617 continue this effort, as well as the suggestion for an essential 618 simplification to the registration model. 620 Author's Address 622 Dave Crocker 623 Brandenburg InternetWorking 624 675 Spruce Dr. 625 Sunnyvale, CA 94086 626 USA 628 Phone: +1.408.246.8253 629 Email: dcrocker@bbiw.net 630 URI: http://bbiw.net/