idnits 2.17.1 draft-bortzmeyer-regext-epp-dname-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 57 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2018) is 2229 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) -- Looks like a reference, but probably isn't: '1' on line 601 -- Looks like a reference, but probably isn't: '2' on line 603 -- Looks like a reference, but probably isn't: '3' on line 650 -- Looks like a reference, but probably isn't: '4' on line 651 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Standards Track March 19, 2018 5 Expires: September 20, 2018 7 EPP Mapping for DNAME delegation of domain names 8 draft-bortzmeyer-regext-epp-dname-02 10 Abstract 12 This document describes an Extensible Provisioning Protocol (EPP) 13 extension mapping for the provisioning and management of Domain Name 14 System for domain names stored in a shared central repository. 15 Specified in XML, this mapping extends the EPP domain name mapping to 16 provide the ability to delegate a domain names through DNAME resource 17 records, thus making the new domain an alias of a previous domain. 19 REMOVE BEFORE PUBLICATION This document should be discussed on the 20 Registration Protocols Extensions (regext) mailing list. The source 21 of this document is kept on a Gitlab at Framagit [1]. A list of open 22 issues is there as well [2]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 20, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 60 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Presentation . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 65 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 66 5.1.2. EPP Command . . . . . . . . . . . . . . . . . 5 67 5.2. EPP Command . . . . . . . . . . . . . . . . . 7 68 6. EPP Transform Commands . . . . . . . . . . . . . . . . . . . 7 69 6.1. EPP Command . . . . . . . . . . . . . . . . . . 7 70 6.2. EPP Command . . . . . . . . . . . . . . . . . . 8 71 6.3. EPP Command . . . . . . . . . . . . . . . . . . . 8 72 6.4. EPP Command . . . . . . . . . . . . . . . . . 8 73 6.5. EPP Command . . . . . . . . . . . . . . . . . . 9 74 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Internationalization Considerations . . . . . . . . . . . . . 10 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 12.2. Informative References . . . . . . . . . . . . . . . . . 13 82 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Appendix A. Generic Resource Records type . . . . . . . . . . . 15 84 Appendix B. Implementation status . . . . . . . . . . . . . . . 15 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 This document describes an extension mapping for version 1.0 of the 90 Extensible Provisioning Protocol (EPP) described in RFC 5730 91 [RFC5730]. This mapping, an extension of the domain name mapping 92 described in RFC 5731 [RFC5731], is specified using the Extensible 93 Markup Language (XML) 1.0 [W3C.REC-xml-20001006] and XML Schema 94 notation ([W3C.REC-xmlschema-1-20041028] 95 [W3C.REC-xmlschema-2-20041028]). 97 The EPP core protocol specification [RFC5730] provides a complete 98 description of EPP command and response structures. A thorough 99 understanding of the base protocol specification is necessary to 100 understand the mapping described in this document. Familiarity with 101 the Domain Name System (DNS) described in RFC 1034 [RFC1034] and 102 RFC 1035 [RFC1035] and with the DNS DNAME Resource Record type 103 described in RFC 6672 [RFC6672] is required to understand the DNS 104 concepts described in this document. (DNAME have properties that may 105 be surprising at first; for instance, it aliases only the subdomains, 106 not the owner name of the DNAME record itself.) 108 The EPP mapping described in this document specifies a mechanism for 109 the provisioning and management of domain names in a shared central 110 repository. Today, most registries allow only delegation of domain 111 names to name servers specified in NS resource records. DNAME 112 [RFC6672] allow another type of delegation, which can be useful for 113 instance for the new AS 112 [RFC7535], as proposed in 114 [I-D.bortzmeyer-dname-root]. Information exchanged via this mapping 115 can be extracted from the repository and used to publish DNAME 116 resource records. 118 1.1. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14, RFC 2119 123 [RFC2119]. 125 In examples, "C:" represents lines sent by a protocol client, and 126 "S:" represents lines returned by a protocol server. "////" is used 127 to note element values that have been shortened to better fit page 128 boundaries. Indentation and white space in examples is provided only 129 to illustrate element relationships and is not a mandatory feature of 130 this protocol. 132 XML is case sensitive. Unless stated otherwise, XML specifications 133 and examples provided in this document MUST be interpreted in the 134 character case presented in order to develop a conforming 135 implementation. 137 dnameDeleg-1.0 is used as an abbreviation for 138 urn:ietf:params:xml:ns:dnameDeleg-1.0. 140 2. Object Attributes 142 This extension adds additional elements to the EPP domain name 143 mapping [RFC5731]. Only those new elements are described here. 145 DNAME information is published by a DNS server to indicate that a 146 child zone is actually an alias of another zone. A DNAME resource 147 record (RR) contains a single field named target. See RFC 6672 148 [RFC6672] for the specific field format. 150 3. Presentation 152 It is the server policy to allow DNAME delegations or not. It is 153 also the server policy to allow (or not) a domain to switch between 154 these two types of delegation with a EPP . 156 The interface relies on the use of the 157 element for creates, adds, removes, and responses. The 158 data is provided by the client. If the DNAME target is in a zone 159 managed by the server, the server operator MAY checks its existence 160 in its database and the fact that it is not itself a DNAME. 161 Otherwise, the server operator MAY issue out-of-band DNS queries to 162 check if the target really exists. 164 The element contains a domain name, as 165 described in Section 2.1 of RFC 6672 [RFC6672]. The value of the 166 element is represented as a eppcom:labelType 167 ([RFC5730], section 4.4, and [W3C.REC-xmlschema-2-20041028]). 169 4. Examples 171 Example use of the dnameDeleg:dnameTarget, for instance for an EPP 172 : 174 foo.bar.example 176 5. EPP Command Mapping 178 A detailed description of the EPP syntax and semantics can be found 179 in the EPP core protocol specification [RFC5730]. The command 180 mappings described here are specifically for use in provisioning and 181 managing DNAME delegations via EPP. 183 5.1. EPP Query Commands 185 EPP provides three commands to retrieve object information: 186 to determine if an object is known to the server, to retrieve 187 detailed information associated with an object, and to 188 retrieve object transfer status information. 190 5.1.1. EPP Command 192 This extension does not add any elements to the EPP command 193 or response described in the EPP domain mapping [RFC5731]. 194 Note that an EPP client cannot use to find out if a server 195 authorizes DNAME delegation for this specific domain (EPP login 196 information is not sufficient because the fact that the server 197 supports the extension does not mean it is authorized for all names.) 198 [REMOVE BEFORE PUBLICATION: issue #3 discussed the case.] 200 5.1.2. EPP Command 202 This extension does not add any elements to the EPP command 203 described in the EPP domain mapping [RFC5731]. [REMOVE BEFORE 204 PUBLICATION: issue #6 discussed whether or not it would be a good 205 idea.] However, additional elements are defined for the 206 response. 208 When an command has been processed successfully, the EPP 209 element MUST contain child elements as described in the EPP 210 domain mapping [RFC5731]. In addition, the EPP element 211 SHOULD contain a child element that 212 identifies the extension namespace if the domain object has data 213 associated with this extension, based on server policy and depending 214 on support of the client for dnameDeleg, based on the EPP login 215 services it provided. The element contains 216 a domain name as its value. A server MUST NOT return both a 217 and a ([RFC5731], section 218 3.1.2). 220 Example Response 222 S: 223 S: 225 S: 226 S: 227 S: Command completed successfully 228 S: 229 S: 230 S: 232 S: example.com 233 S: EXAMPLE1-REP 234 S: 235 S: jd1234 236 S: sh8013 237 S: sh8013 238 S: ClientX 239 S: ClientY 240 S: 1999-04-03T22:00:00.0Z 241 S: ClientX 242 S: 1999-12-03T09:00:00.0Z 243 S: 2005-04-03T22:00:00.0Z 244 S: 2000-04-08T09:00:00.0Z 245 S: 246 S: 2fooBAR 247 S: 248 S: 249 S: 250 S: 251 S: 252 S: foo.bar.example 253 S: 254 S: 255 S: 256 S: ABC-12345 257 S: 54322-XYZ 258 S: 259 S: 260 S: 262 An EPP error response MUST be returned if an command cannot be 263 processed for any reason. 265 5.2. EPP Command 267 This extension does not add any elements to the EPP 268 command or response described in the EPP domain mapping 269 [RFC5731]. A domain cannot be switched from NS delegation to DNAME 270 delegation (or vice-versa) through a transfer. 272 Note that this may be one additional reason for a transfer to fail: 273 if the gaining registrar does not support DNAME delegation. The 274 server MUST return error code 2106. 276 6. EPP Transform Commands 278 EPP provides five commands to transform objects: to create 279 an instance of an object, to delete an instance of an 280 object, to extend the validity period of an object, 281 to manage object sponsorship changes, and to 282 change information associated with an object. 284 6.1. EPP Command 286 This extension defines an additional element for the EPP 287 command described in the EPP domain mapping [RFC5731]. No additional 288 elements are defined for the EPP response. 290 The EPP command provides a transform operation that allows a 291 client to create a domain object. In addition to the EPP command 292 elements described in the EPP domain mapping [RFC5731], the command 293 MUST contain an element, and the element MUST 294 contain a child element that identifies the 295 extension namespace if the client wants to associate data defined in 296 this extension to the domain object. The 297 has a domain name as value. A client MUST NOT send both a 298 and elements. TODO See issue #4 299 for the choice of the error code(s). 301 Example Command: 303 C: 304 C: 306 C: 307 C: 308 C: 310 C: example.com 311 C: 2 312 C: jd1234 313 C: sh8013 314 C: sh8013 315 C: 316 C: 2fooBAR 317 C: 318 C: 319 C: 320 C: 321 C: foo.bar.example 322 C: 323 C: ABC-12345 324 C: 325 C: 327 When a command has been processed successfully, the EPP 328 response is as described in the EPP domain mapping [RFC5731]. 330 6.2. EPP Command 332 This extension does not add any elements to the EPP command 333 or response described in the EPP domain mapping [RFC5731]. 335 6.3. EPP Command 337 This extension does not add any elements to the EPP command 338 or response described in the EPP domain mapping [RFC5731]. 340 6.4. EPP Command 342 This extension does not add any elements to the EPP 343 command or response described in the EPP domain mapping 344 [RFC5731]. 346 6.5. EPP Command 348 This extension defines additional elements for the EPP 349 command described in the EPP domain mapping [RFC5731]. No additional 350 elements are defined for the EPP response. 352 The EPP command provides a transform operation that allows a 353 client to modify the attributes of a domain object. In addition to 354 the EPP command elements described in the EPP domain mapping, the 355 command MUST contain an element, and the 356 element MUST contain a child element that 357 identifies the extension namespace if the client wants to update the 358 domain object with data defined in this extension. The 359 element has a domain name as its value. If 360 present, it updates the DNAME delegation to the new target, if the 361 domain was already DNAME-delegated, or it switches the domain to a 362 DNAME delegation, if it was previously a NS delegation. A server MAY 363 refuse such a switch, per its policy. In the same way, a RFC 5731 364 [RFC5731] update with NS information, without the extension decribed 365 here, switches to NS delegation if the domain was previously DNAME- 366 delegated. 368 TODO there is an issue with the switch from NS to DNAME delegation if 369 the domain had in-bailiwick name servers. See issue #7. 371 Example Command, Adding and Removing: 373 C: 374 C: 376 C: 377 C: 378 C: 380 C: example.com 381 C: 382 C: 383 C: 384 C: foo.bar.example 385 C: 386 C: 387 C: ABC-12345 388 C: 389 C: 391 When an extended command has been processed successfully, 392 the EPP response is as described in the EPP domain mapping [RFC5731]. 394 7. Formal Syntax 396 An EPP object mapping is specified in XML Schema notation. The 397 formal syntax presented here is a complete schema representation of 398 the object mapping suitable for automated validation of EPP XML 399 instances. The BEGIN and END tags are not part of the schema; they 400 are used to note the beginning and ending of the schema for URI 401 registration purposes. 403 BEGIN 404 405 411 412 413 Extensible Provisioning Protocol v1.0 414 domain name extension schema 415 for provisioning DNAME domain names. 416 417 419 422 424 425 END 427 8. Internationalization Considerations 429 EPP is represented in XML, which provides native support for encoding 430 information using the Unicode character set and its more compact 431 representations including UTF-8 [RFC3629]. Conformant XML processors 432 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 433 provisions to identify and use other character encodings through use 434 of an "encoding" attribute in an declaration, use of UTF-8 is 435 RECOMMENDED in environments where parser encoding support 436 incompatibility exists. 438 As an extension of the EPP domain mapping [RFC5731], the 439 internationalization requirements in the EPP domain mapping [RFC5731] 440 are followed by this extension. This extension does not override any 441 of the EPP domain mapping [RFC5731] internationalization features. 443 9. IANA Considerations 445 This document uses URNs to describe XML namespaces and XML schemas 446 conforming to a registry mechanism described in RFC 3688 [RFC3688]. 447 Two URI assignments have been completed by the IANA. 449 Registration request for the extension namespace: 451 URI: urn:ietf:params:xml:ns:dnameDeleg-1.0 453 Registrant Contact: IESG 455 XML: None. Namespace URIs do not represent an XML specification. 457 Registration request for the extension XML schema: 459 URI: urn:ietf:params:xml:schema:dnameDeleg-1.0 461 Registrant Contact: IESG 463 XML: See the "Formal Syntax" section of this document. 465 10. Security Considerations 467 The mapping extensions described in this document do not provide any 468 security services beyond those described by EPP [RFC5730], the EPP 469 domain name mapping [RFC5731], and protocol layers used by EPP. The 470 security considerations described in these other specifications apply 471 to this specification as well. 473 As with other domain object transforms, the EPP transform operations 474 described in this document MUST be restricted to the sponsoring 475 client as authenticated using the mechanisms described in 476 Sections 2.9.1.1 and 7 of RFC 5730 [RFC5730]. Any attempt to perform 477 a transform operation on a domain object by any client other than the 478 sponsoring client MUST be rejected with an appropriate EPP 479 authorization error. 481 The provisioning service described in this document involves the 482 exchange of information that can have an operational impact on the 483 DNS. A trust relationship MUST exist between the EPP client and 484 server, and provisioning of DNAME delegation MUST only be done after 485 the identities of both parties have been confirmed using a strong 486 authentication mechanism. This is just a repeat of [RFC5734], 487 section 8. 489 An EPP client might be acting as an agent for a zone administrator 490 who wants to send DNAME delegation information to be published by the 491 server operator. Man-in-the-middle attacks are thus possible as a 492 result of direct client activity or inadvertent client data 493 manipulation. 495 11. Acknowledgements 497 Most of the text has been copied from [RFC5910], so thanks to its 498 authors. 500 Thanks to James Gould for a detailed review and for John Levine and 501 Patrick Mevzek for good remarks. Thanks to Patrick Mevzek for the 502 first implementation. 504 12. References 506 12.1. Normative References 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 514 DOI 10.17487/RFC3688, January 2004, 515 . 517 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 518 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 519 . 521 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 522 Domain Name Mapping", STD 69, RFC 5731, 523 DOI 10.17487/RFC5731, August 2009, 524 . 526 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 527 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 528 . 530 [W3C.REC-xml-20001006] 531 Bray, T., Paoli, J., Sperberg-McQueen, M., and E. Maler, 532 "Extensible Markup Language (XML) 1.0 (Second Edition)", 533 World Wide Web Consortium Recommendation REC-xml-20001006, 534 October 2000, 535 . 537 [W3C.REC-xmlschema-1-20041028] 538 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 539 "XML Schema Part 1: Structures Second Edition", World Wide 540 Web Consortium Recommendation REC-xmlschema-1-20041028, 541 October 2004, 542 . 544 [W3C.REC-xmlschema-2-20041028] 545 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 546 Second Edition", World Wide Web Consortium Recommendation 547 REC-xmlschema-2-20041028, October 2004, 548 . 550 12.2. Informative References 552 [I-D.bortzmeyer-dname-root] 553 Bortzmeyer, S., "Using DNAME in the DNS root zone for 554 sinking of special-use TLDs", draft-bortzmeyer-dname- 555 root-05 (work in progress), January 2018. 557 [I-D.hildebrand-deth] 558 Hildebrand, J. and P. Hoffman, "DNS Editing Through HTTPS 559 (DETH)", draft-hildebrand-deth-00 (work in progress), 560 March 2016. 562 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 563 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 564 . 566 [RFC1035] Mockapetris, P., "Domain names - implementation and 567 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 568 November 1987, . 570 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 571 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, 572 . 574 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 575 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 576 2003, . 578 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 579 Transport over TCP", STD 69, RFC 5734, 580 DOI 10.17487/RFC5734, August 2009, 581 . 583 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 584 Security Extensions Mapping for the Extensible 585 Provisioning Protocol (EPP)", RFC 5910, 586 DOI 10.17487/RFC5910, May 2010, 587 . 589 [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 590 "AS112 Redirection Using DNAME", RFC 7535, 591 DOI 10.17487/RFC7535, May 2015, 592 . 594 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 595 Code: The Implementation Status Section", BCP 205, 596 RFC 7942, DOI 10.17487/RFC7942, July 2016, 597 . 599 12.3. URIs 601 [1] https://framagit.org/bortzmeyer/ietf-epp-dname 603 [2] https://framagit.org/bortzmeyer/ietf-epp-dname/issues 605 [3] https://metacpan.org/pod/Net::DRI 607 [4] https://metacpan.org/source/PMEVZEK/Net-DRI- 608 0.96_10/lib/Net/DRI/Protocol/EPP/Extensions/DNAME.pm 610 Appendix A. Generic Resource Records type 612 The goal of this document is not to allow arbitrary DNS Resource 613 record types (such as TXT or LOC). Such a mapping would require the 614 ability to add, update and remove individual records, but it would 615 allow the EPP server to implement a "delegation-less" registry. An 616 example of such attempt to define a standard protocol for 617 provisioning a lot of resource record types is [I-D.hildebrand-deth]. 618 But we don't follow that path. Instead, we keep the idea that the 619 EPP server registers only delegations, either through NS records or, 620 as here, a DNAME record. This keeps the mapping much simpler. 622 For this reason, the possibility to add other resource records 623 together with the DNAME ([RFC6672], section 2.4) is out-of-scope 624 here. 626 Appendix B. Implementation status 628 RFC-EDITOR: REMOVE BEFORE PUBLICATION 630 This section records the status of known implementations of the 631 protocol defined by this specification at the time of posting of this 632 Internet-Draft, and is based on a proposal described in [RFC7942]. 633 The description of implementations in this section is intended to 634 assist the IETF in its decision processes in progressing drafts to 635 RFCs. Please note that the listing of any individual implementation 636 here does not imply endorsement by the IETF. Furthermore, no effort 637 has been spent to verify the information presented here that was 638 supplied by IETF contributors. This is not intended as, and must not 639 be construed to be, a catalog of available implementations or their 640 features. Readers are advised to note that other implementations may 641 exist. 643 According to [RFC7942], "this will allow reviewers and working groups 644 to assign due consideration to documents that have the benefit of 645 running code, which may serve as evidence of valuable experimentation 646 and feedback that have made the implemented protocols more mature. 647 It is up to the individual working groups to use this information as 648 they see fit". 650 This EPP extension is implemented in the Net::DRI EPP client [3], 651 written in Perl. The specific part of Net::DRI is DNAME.pm [4]. 653 Author's Address 654 Stephane Bortzmeyer 655 AFNIC 656 1, rue Stephenson 657 Montigny-le-Bretonneux 78180 658 France 660 Phone: +33 1 39 30 83 46 661 EMail: bortzmeyer+ietf@nic.fr 662 URI: http://www.afnic.fr/