idnits 2.17.1 draft-ietf-dnsop-attrleaf-fix-03.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 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 21, 2018) is 2099 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 432, but no explicit reference was found in the text == Unused Reference: 'RFC3404' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC3529' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC3620' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC3832' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC3861' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC3887' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC3958' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC4227' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC4386' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC4387' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC5026' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC5328' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5415' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC5518' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC5555' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC5617' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC5679' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC5780' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC5804' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC5864' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC5928' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC6011' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC6186' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC7489' is defined on line 546, 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 (~~), 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 21, 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 22, 2019 15 DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name 16 Use 17 draft-ietf-dnsop-attrleaf-fix-03 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 22, 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Underscored RRset Use in Specifications 127 The use of underscored node names is specific to each RRTYPE that is 128 being scoped. Each name defines a place, but does not define the 129 rules for what appears underneath that place, either as additional 130 underscored naming or as a leaf node with resource records. Details 131 for those rules are provided by specifications for individual 132 RRTYPEs. The sections below describe the way that existing 133 underscore labels are used with the RRTYPEs that they name. 135 2.1. TXT RRset Use 137 This section provides a generic approach for changes to existing 138 specifications that define straightforward use of underscored node 139 names, when scoping the use of a "TXT" RRset. The approach provides 140 the information needed for adapting such specifications to the use of 141 the IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. 142 Hence the approach is meant both as an update to these existing 143 specifications, and as guidance for changes when those documents are 144 revised. 146 For any document that specifies the use of a "TXT" RRset under one or 147 more underscored names, that 'global' name is expected to be 148 registered in the IANA DNS Underscore Global Scoped Entry Registry 149 [Attrleaf]. An effort has been made to locate existing drafts that 150 do this, register the global underscored names, and list them in this 151 document. 153 If a public specification that defines use of a "TXT" calls for the 154 use of an underscore-prefixed domain name, the global underscored 155 name -- the one closest to the root -- MUST be entered into this 156 registry, if it is not already registered. 158 Here is a template of suggested text for this to appear in the IANA 159 Considerations section of the specification: 161 "Per" [Attrleaf] "please add the following entry to the DNS 162 Underscore Global Scoped Entry Registry:" 164 +--------+----------------+-----------------------------------------+ 165 | RR | _NODE NAME | REFERENCE | 166 | Type | | | 167 +--------+----------------+-----------------------------------------+ 168 | TXT | _{DNS node | {citation for the document making the | 169 | | name} | addition.} | 170 +--------+----------------+-----------------------------------------+ 172 Table 1: Underscore Global Registry Entry 174 2.2. SRV RRset Use 176 Specification for the SRV [RFC2782] resource record provides a 177 template for use of underscored node names. The global name is 178 characterised as referencing the 'protocol' that is associated with 179 "SRV" RRset usage. 181 This section provides a generic approach for changes to existing 182 specifications that define the use of an "SRV" RRset. The approach 183 provides the information needed for adapting such specifications to 184 the use of the IANA DNS Underscore Global Scoped Entry Registry 185 [Attrleaf]. Hence the approach is meant both as an update to these 186 existing specifications, and as guidance for changes when those 187 documents are revised. 189 For any document that specifies the use of an "SRV" RRset, the global 190 ('protocol') underscored name is expected to be registered in the 191 IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. An 192 effort has been made to locate existing drafts that do this, register 193 the global underscored names, and list them in this document. 195 If a public specification that defines use of a "SRV" calls for the 196 use of an underscore-prefixed domain name, the global underscored 197 name -- the one closest to the root -- MUST be entered into this 198 registry, if it is not already registered. 200 Here is a template of suggested text for this to appear in the IANA 201 Considerations section of the specification: 203 "Per" [Attrleaf] "please add the following entry to the DNS 204 Underscore Global Scoped Entry Registry:" 206 +--------+----------------------+-----------------------------------+ 207 | RR | _NODE NAME | REFERENCE | 208 | Type | | | 209 +--------+----------------------+-----------------------------------+ 210 | SRV | _{DNS 'protocol' | {citation for the document making | 211 | | node name} | the addition.} | 212 +--------+----------------------+-----------------------------------+ 214 Table 2: Underscore Global Registry Entry 216 2.3. URI RRset Use 218 Specification for the URI [RFC7553] resource record provides a 219 template for use of underscored node names. The global name is 220 characterised as naming the 'protocol' that is associated with "URI" 221 RR usage or by reversing an Enumservice sequence [RFC6117]. 223 This section provides a generic approach for changes to existing 224 specifications that define use of a "URI" RRset. The approach 225 provides the information needed for adapting such specifications to 226 the use of the IANA DNS Underscore Global Scoped Entry Registry 227 [Attrleaf]. Hence the approach is meant both as an update to these 228 existing specifications, and as guidance for changes when those 229 documents are revised. 231 For any document that specifies the use of a "URI" RRset, the global 232 ('protocol' or highest-level enumservice) underscored name is 233 expected to be registered in the IANA DNS Underscore Global Scoped 234 Entry Registry [Attrleaf]. An effort has been made to locate 235 existing drafts that do this and register the associated 'protocol' 236 names. 238 If a public specification that defines use of a "URI" calls for the 239 use of an underscore-prefixed domain name, the global underscored 240 name -- the one closest to the root -- MUST be entered into this 241 registry, if it is not already registered. 243 Here is a template of suggested text for this to appear in the IANA 244 Considerations section of the specification: 246 "Per" [Attrleaf] "please add the following entry to the DNS 247 Underscore Global Scoped Entry Registry:" 249 +-------+---------------------------+-------------------------------+ 250 | RR | _NODE NAME | REFERENCE | 251 | Type | | | 252 +-------+---------------------------+-------------------------------+ 253 | URI | _{DNS 'protocol' or | {citation for the document | 254 | | Enumservice node name} | making the addition.} | 255 +-------+---------------------------+-------------------------------+ 257 Table 3: Underscore Global Registry Entry 259 3. Underscored Template Specifications 261 3.1. SRV Specification Changes 263 The specification for a domain name under, which an SRV [RFC2782] 264 resource record appears, provides a template for use of underscored 265 node names. The global underscored name, is characterised as 266 indicating the 'protocol' that is associated with "SRV" RR usage. 268 The text of that existing specification is hereby updated from: 270 The format of the SRV RR 272 Here is the format of the SRV RR, whose DNS type code is 33: 273 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 274 ... 275 Proto 276 The symbolic name of the desired protocol, with an underscore 277 (_) prepended to prevent collisions with DNS labels that occur 278 in nature. _TCP and _UDP are at present the most useful values 279 for this field, though any name defined by Assigned Numbers or 280 locally may be used (as for Service). The Proto is case 281 insensitive. 283 And is to be updated to the new text: 285 The format of the SRV RR 286 Here is the format of the SRV RR, whose DNS type code is 33: 288 "_Service._Proto.Name TTL Class SRV Priority Weight Port 289 Target" _..._ 291 Proto 293 The symbolic name of the desired protocol, with an 294 underscore (_) prepended to prevent collisions with DNS 295 labels that occur in nature. _TCP and _UDP are at present 296 the most useful values for this field. The Proto is case 297 insensitive. 299 The SRV RRset protocol (global) underscored name SHOULD be 300 registered in the IANA DNS Underscore Global Scoped Entry 301 Registry [Attrleaf]. 303 3.2. URI Specification Changes 305 Specification for the domain name under which a URI [RFC7553] 306 resource record occurs is similar to that for the SRV [RFC2782] 307 resource record, although the text refers only to 'service' name, 308 rather than distinguishing 'service' from 'protocol'. Further, the 309 URI RR specification permits alternative underscored naming schemes: 311 One matches what is used for "SRV", with the global underscored 312 name called "protocol'. 314 The other is based on a reversing of an Enumservice [RFC6117] 315 sequence. 317 The text of the existing specification is hereby updated from: 319 4.1. Owner Name, Class, and Type 321 The URI owner name is subject to special conventions. 323 Just like the SRV RR [RFC2782], the URI RR has service information 324 encoded in its owner name. In order to encode the service for a 325 specific owner name, one uses service parameters. Valid service 326 parameters are those registered by IANA in the "Service Name and 327 Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice 328 --- 329 Registrations [RFC6117]. The Enumservice Registration parameters are 330 reversed (i.e., subtype(s) before type), prepended with an underscore 331 (_), and prepended to the owner name in separate labels. The 332 underscore is prepended to the service parameters to avoid collisions 333 with DNS labels that occur in nature, and the order is reversed to 334 make it possible to do delegations, if needed, to different zones 335 (and therefore providers of DNS). 337 For example, suppose we are looking for the URI for a service with 338 ENUM Service Parameter "A:B:C" for host example.com. Then we would 339 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 341 As another example, suppose we are looking for the URI for a service 342 with Service Name "A" and Transport Protocol "B" for host 343 example.com. Then we would query for 344 (QNAME,QTYPE)=("_A._B.example.com","URI"). 346 And is to be updated to the new text: 348 4.1. Owner Name, Class, and Type 350 The URI owner name is subject to special conventions. 352 As for the SRV RRset [RFC2782], the URI RRset global (highest- 353 level) underscored name SHOULD be registered in the IANA DNS 354 Underscore Global Scoped Entry Registry [Attrleaf]. 356 Just like the SRV RRset, the URI RRset has service information 357 encoded in its owner name. In order to encode the service for 358 a specific owner name, one uses service parameters. Valid 359 service parameters are: 361 + Those registered by IANA in the "Service Name and Transport 362 Protocol Port Number Registry [RFC6335]" The underscore is 363 prepended to the service parameters to avoid collisions with 364 DNS labels that occur in nature, and the order is reversed 365 to make it possible to do delegations, if needed, to 366 different zones (and therefore providers of DNS). 368 + Those listed in "Enumservice Registrations [RFC6117]. The 369 Enumservice Registration parameters are reversed (i.e., 370 subtype(s) before type), prepended with an underscore (_), 371 and prepended to the owner name in separate labels. The 372 highest-level (global) underscored Enumservice name becomes 373 the global Attrleaf name to register. 375 For example, suppose we are looking for the URI for a service 376 with ENUM Service Parameter "A:B:C" for host example.com. Then 377 we would query for 378 (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 380 As another example, suppose we are looking for the URI for a 381 service with Service Name "A" and Transport Protocol "B" for 382 host example.com. Then we would query for 383 (QNAME,QTYPE)=("_A._B.example.com","URI"). 385 4. IANA Considerations 387 Although this document makes reference to IANA registries, it 388 introduces no new IANA registries or procedures. 390 5. Security Considerations 392 This memo raises no security issues. 394 6. References 396 6.1. Normative References 398 [Attrleaf] 399 Crocker, D., "DNS Scoped Data Through 'Underscore' Naming 400 of Attribute Leaves", I-D draft-ietf-dnsop-attrleaf, 2018. 402 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 403 Registration of Enumservices: Guide, Template, and IANA 404 Considerations", RFC 6117, March 2011. 406 [RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S. 407 Cheshire, "Internet Assigned Numbers Authority (IANA) 408 Procedures for the Management of the Service Name and 409 Transport Protocol Port Number Registry", RFC 6335, Aug 410 2011. 412 [RFC7553] Falstrom, P. and O. Kolkman, "The Uniform Resource 413 Identifier (URI) DNS Resource Record", RFC 7553, 414 ISSN 2070-1721, June 2015. 416 6.2. References -- Informative 418 [IANA-reg] 419 "Protocol Registries", URL https://www.iana.org/protocols, 420 2018. 422 [RFC1035] Mockapetris, P., "Domain names - implementation and 423 specification", STD 13, RFC 1035, November 1987. 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 429 specifying the location of services (DNS SRV)", RFC 2782, 430 February 2000. 432 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 433 Protocol (SIP): Locating SIP Servers", RFC 3263, June 434 2002. 436 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 437 Part Four: The Uniform Resource Identifiers (URI) 438 Resolution Application", RFC 3404, October 2002. 440 [RFC3529] Harold, W., "Using Extensible Markup Language-Remote 441 Procedure Calling (XML-RPC) in Blocks Extensible Exchange 442 Protocol (BEEP)", RFC 3529, April 2003. 444 [RFC3620] New, D., "The TUNNEL Profile", RFC 3620, October 2003. 446 [RFC3832] Columbia University, Columbia University, Sun 447 Microsystems, IBM, and IBM, "Remote Service Discovery in 448 the Service Location Protocol (SLP) via DNS SRV", 449 RFC 3832, July 2004. 451 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 452 and Presence", RFC 3861, August 2004. 454 [RFC3887] "Message Tracking Query Protocol", RFC 3887, September 455 2007. 457 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 458 Service Location Using SRV RRs and the Dynamic Delegation 459 Discovery Service (DDDS)", RFC 3958, January 2005. 461 [RFC4120] USC-ISI, MIT, MIT, and MIT, "The Kerberos Network 462 Authentication Service (V5)", RFC 4120, July 2005. 464 [RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object 465 Access Protocol (SOAP) in Blocks Extensible Exchange 466 Protocol (BEEP)", RFC 4227, January 2006. 468 [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key 469 Infrastructure: Repository Locator Service", RFC 4386, 470 February 2006. 472 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 473 Infrastructure Operational Protocols: Certificate Store 474 Access via HTTP", RFC 4387, February 2006. 476 [RFC4976] Jennings, C., Mahy, R., and Roach, "Relay Extensions for 477 the Message Session Relay Protocol (MSRP)", RFC 4976, 478 September 2007. 480 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., 481 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, 482 October 2007. 484 [RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) 485 Namespace for the Digital Video Broadcasting Project 486 (DVB)", RFC 5328, September 2008. 488 [RFC5389] Rosenberg, Mahy, Matthews, and Wing, "Session Traversal 489 Utilities for NAT (STUN)", RFC 5389, October 2008. 491 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 492 Ed., "Control And Provisioning of Wireless Access Points 493 (CAPWAP) Protocol Specification", RFC 5415, March 2009. 495 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 496 Reference", RFC 5518, April 2009. 498 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 499 Hosts and Routers", RFC 5555, June 2009. 501 [RFC5617] Sendmail, Inc., Cisco Systems, Inc., Yahoo! Inc., and 502 Taughannock Networks, "DomainKeys Identified Mail (DKIM) 503 Author Domain Signing Practices (ADSP)", RFC 5617, August 504 2009. 506 [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using 507 DNS", RFC 5679, December 2009. 509 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 510 Relays around NAT (TURN): Relay Extensions to Session 511 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 513 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 514 Using Session Traversal Utilities for NAT (STUN)", 515 RFC 5780, May 2010. 517 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 518 Managing Sieve Scripts", RFC 5804, July 2010. 520 [RFC5864] Allbery, R., "NS SRV Resource Records for AFS", RFC 5864, 521 April 2010. 523 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 524 (TURN) Resolution Mechanism", RFC 5928, August 2010. 526 [RFC6011] Lawrence, S., Ed. and J. Elwell, "Session Initiation 527 Protocol (SIP) User Agent Configuration", RFC 6011, 528 October 2010. 530 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 531 Protocol (XMPP): Core", RFC 6120, March 2011. 533 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 534 Submission/Access Services", RFC 6186, March 2011. 536 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 537 Identified Mail (DKIM) Signatures", RFC 6376, Sept 2011. 539 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 540 "Diameter Base Protocol", RFC 6733, October 2012. 542 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 543 Authorizing Use of Domains in E-Mail, Version 1", 544 RFC 7208, April 2014. 546 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 547 Message Authentication, Reporting, and Conformance 548 (DMARC)", RFC 7489, March 2015. 550 Appendix A. Acknowledgements 552 Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf 553 Kolkman, and Andrew Sullivan for diligent review of the (much) 554 earlier drafts. For the later enhancements, thanks to: Tim Wicinski, 555 John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul 556 Wouters. 558 Special thanks to Ray Bellis for his persistent encouragement to 559 continue this effort, as well as the suggestion for an essential 560 simplification to the registration model. 562 Author's Address 564 Dave Crocker 565 Brandenburg InternetWorking 566 675 Spruce Dr. 567 Sunnyvale, CA 94086 568 USA 570 Phone: +1.408.246.8253 571 Email: dcrocker@bbiw.net 572 URI: http://bbiw.net/