draft-ietf-regext-bundling-registration-05.txt | draft-ietf-regext-bundling-registration-06.txt | |||
---|---|---|---|---|
Internet Engineering Task Force N. Kong | Internet Engineering Task Force N. Kong | |||
Internet-Draft Consultant | Internet-Draft Consultant | |||
Intended status: Informational J. Yao, Ed. | Intended status: Informational J. Yao, Ed. | |||
Expires: March 3, 2019 L. Zhou | Expires: April 14, 2019 L. Zhou | |||
CNNIC | CNNIC | |||
W. Tan | W. Tan | |||
Cloud Registry | Cloud Registry | |||
J. Xie | J. Xie | |||
August 30, 2018 | October 11, 2018 | |||
Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for | Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for | |||
Strict Bundling Registration | Strict Bundling Registration | |||
draft-ietf-regext-bundling-registration-05 | draft-ietf-regext-bundling-registration-06 | |||
Abstract | Abstract | |||
This document describes an extension of Extensible Provisioning | This document describes an extension of Extensible Provisioning | |||
Protocol (EPP) domain name mapping for the provisioning and | Protocol (EPP) domain name mapping for the provisioning and | |||
management of strict bundling registration of domain names. | management of strict bundling registration of domain names. | |||
Specified in XML, this mapping extends the EPP domain name mapping to | Specified in XML, this mapping extends the EPP domain name mapping to | |||
provide additional features required for the provisioning of bundled | provide additional features required for the provisioning of bundled | |||
domain names. | domain names. | |||
skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 3, 2019. | This Internet-Draft will expire on April 14, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 44 ¶ | skipping to change at page 2, line 44 ¶ | |||
7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 | 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 | |||
7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 | 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 | |||
7.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 7 | 7.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 7 | |||
7.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 8 | 7.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 8 | |||
7.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 10 | 7.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 10 | |||
7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 | 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 | |||
7.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 11 | 7.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 11 | |||
7.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 12 | 7.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 12 | |||
7.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 13 | 7.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 13 | |||
7.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 14 | 7.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 14 | |||
7.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 14 | 7.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 15 | |||
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. Internationalization Considerations . . . . . . . . . . . . . 16 | 9. Internationalization Considerations . . . . . . . . . . . . . 18 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 | 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 | |||
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | |||
14. Change History . . . . . . . . . . . . . . . . . . . . . . . 18 | 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 18 | 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 20 | |||
14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 18 | 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 20 | |||
14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 18 | 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 20 | |||
14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 18 | 14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 20 | |||
14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 18 | 14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 20 | |||
14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 18 | 14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 21 | |||
14.7. draft-ietf-regext-bundle-mapping: Version 03 . . . . . . 18 | 14.7. draft-ietf-regext-bundle-mapping: Version 03 . . . . . . 21 | |||
14.8. draft-ietf-regext-bundle-mapping: Version 04 . . . . . . 18 | 14.8. draft-ietf-regext-bundle-mapping: Version 04 . . . . . . 21 | |||
14.9. draft-ietf-regext-bundle-mapping: Version 05 . . . . . . 19 | 14.9. draft-ietf-regext-bundle-mapping: Version 05 . . . . . . 21 | |||
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 14.10. draft-ietf-regext-bundle-mapping: Version 06 . . . . . . 21 | |||
15.1. Normative References . . . . . . . . . . . . . . . . . . 19 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
15.2. Informative References . . . . . . . . . . . . . . . . . 20 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | 15.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
1. Introduction | 1. Introduction | |||
Bundled domain names are those which share the same TLD but whose | Bundled domain names are those which share the same TLD but whose | |||
second level labels are variants, or those which has identical second | second level labels are variants, or those which has identical second | |||
level labels for which certain parameters are shared in different | level labels for which certain parameters are shared in different | |||
TLDs. For example, Public Interest Registry, request to implement | TLDs. For example, Public Interest Registry, request to implement | |||
technical bundling of second level domains for .NGO and .ONG. So we | technical bundling of second level domains for .NGO and .ONG. So we | |||
have two kinds of bundled domain names. First one is in the form of | have two kinds of bundled domain names. First one is in the form of | |||
"V-label.TLD" in which the second level labels (V-label) are variants | "V-label.TLD" in which the second level labels (V-label) are variants | |||
skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 34 ¶ | |||
understanding of the IDNs for Application (IDNA, described in | understanding of the IDNs for Application (IDNA, described in | |||
[RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of | [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of | |||
variant approach discussed in [RFC4290] are both required. | variant approach discussed in [RFC4290] are both required. | |||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
uLable is defined in [RFC 5890]. uLabel is expressed in this document | uLabel in this document is used to express U-label of the | |||
as a number of characters with the format of U+XXXX where XXXX is a | internationalized domain name into series of characters where non- | |||
UNICODE point. | ASCII characters will be represented with the format of U+XXXX where | |||
XXXX is a UNICODE point. U-Label is defined in [RFC5890]. | ||||
"b-dn-1.0" in this document is used as an abbreviation for | "b-dn-1.0" in this document is used as an abbreviation for | |||
urn:ietf:params:xml:ns:epp:b-dn-1.0. | urn:ietf:params:xml:ns:epp:b-dn-1.0. | |||
In examples, "C:" represents lines sent by a protocol client and "S:" | In examples, "C:" represents lines sent by a protocol client and "S:" | |||
represents lines returned by a protocol server. Indentation and | represents lines returned by a protocol server. Indentation and | |||
white space in examples are provided only to illustrate element | white space in examples are provided only to illustrate element | |||
relationships and are not a REQUIRED feature of this specification. | relationships and are not a REQUIRED feature of this specification. | |||
XML is case sensitive. Unless stated otherwise, XML specifications | XML is case sensitive. Unless stated otherwise, XML specifications | |||
skipping to change at page 13, line 43 ¶ | skipping to change at page 13, line 43 ¶ | |||
An EPP error response MUST be returned if a <delete> command cannot | An EPP error response MUST be returned if a <delete> command cannot | |||
be processed for any reason. | be processed for any reason. | |||
7.2.3. EPP <renew> Command | 7.2.3. EPP <renew> Command | |||
This extension does not add any element to the EPP <renew> command | This extension does not add any element to the EPP <renew> command | |||
described in the EPP domain name mapping [RFC5731]. However, when | described in the EPP domain name mapping [RFC5731]. However, when | |||
either RDN or BDN is sent for renew, response SHOULD contain both RDN | either RDN or BDN is sent for renew, response SHOULD contain both RDN | |||
and BDN information. When the command has been processed | and BDN information. When the command has been processed | |||
successfully, the EPP <resData> element MUST contain child elements | successfully, the EPP <extension> element SHOULD be contained in the | |||
as described in the EPP domain mapping [RFC5731]. This EPP | resoponse if the domain object has data associated with bundled | |||
<extension> element SHOULD contain the <b-dn:renData> which contains | names. This EPP <extension> element SHOULD contain the | |||
<b-dn:bundle> element. | <b-dn:renData> which contains <b-dn:bundle> element. | |||
Example <renew> Response for an authorized client: | ||||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | ||||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | ||||
S: <response> | ||||
S: <result code="1000"> | ||||
S: <msg>Command completed successfully</msg> | ||||
S: </result> | ||||
S: <resData> | ||||
S: <domain:renData | ||||
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> | ||||
S: <domain:name>xn--fsq270a.example</domain:name> | ||||
S: <domain:exDate>2012-04-03T22:00:00.0Z</domain:exDate> | ||||
S: </domain:renData> | ||||
S: </resData> | ||||
S: <extension> | ||||
S: <b-dn:renData | ||||
S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn-1.0"> | ||||
S: <b-dn:bundle> | ||||
S: <b-dn:rdn uLabel="U+5B9E""U+4F8B".example | ||||
S: >xn--fsq270a.example</b-dn:rdn> | ||||
S: <b-dn:bdn uLabel="U+5BE6""U+4F8B".example | ||||
S: >xn--fsqz41a.example</b-dn:bdn> | ||||
S: </b-dn:bundle> | ||||
S: </b-dn:renData> | ||||
S: </extension> | ||||
S: <trID> | ||||
S: <clTRID>ABC-12345</clTRID> | ||||
S: <svTRID>54322-XYZ</svTRID> | ||||
S: </trID> | ||||
S: </response> | ||||
S:</epp> | ||||
7.2.4. EPP <transfer> Command | 7.2.4. EPP <transfer> Command | |||
This extension does not add any element to the EPP <transfer> command | This extension does not add any element to the EPP <transfer> command | |||
described in the EPP domain name mapping [RFC5731]. When the command | described in the EPP domain name mapping [RFC5731]. However, | |||
has been processed successfully, the EPP <resData> element MUST | additional elements are defined for the <transfer> response in the | |||
contain child elements as described in the EPP domain mapping | EPP object mapping. When the command has been processed | |||
[RFC5731]. This EPP <extension> element SHOULD contain the | successfully, the EPP <extension> element SHOULD be contained in the | |||
resoponse if the domain object has data associated with bundled | ||||
names. This EPP <extension> element SHOULD contain the | ||||
<b-dn:trnData> which contains <b-dn:bundle> element. | <b-dn:trnData> which contains <b-dn:bundle> element. | |||
Example <transfer> Response for an authorized client: | ||||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | ||||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | ||||
S: <response> | ||||
S: <result code="1001"> | ||||
S: <msg>Command completed successfully; action pending</msg> | ||||
S: </result> | ||||
S: <resData> | ||||
S: <domain:trnData | ||||
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> | ||||
S: <domain:name>xn--fsq270a.example</domain:name> | ||||
S: <domain:trStatus>pending</domain:trStatus> | ||||
S: <domain:reID>ClientX</domain:reID> | ||||
S: <domain:reDate>2011-04-03T22:00:00.0Z</domain:reDate> | ||||
S: <domain:acID>ClientY</domain:acID> | ||||
S: <domain:acDate>2011-04-08T22:00:00.0Z</domain:acDate> | ||||
S: <domain:exDate>2012-04-03T22:00:00.0Z</domain:exDate> | ||||
S: </domain:trnData> | ||||
S: </resData> | ||||
S: <extension> | ||||
S: <b-dn:trnData | ||||
S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn-1.0"> | ||||
S: <b-dn:bundle> | ||||
S: <b-dn:rdn uLabel="U+5B9E""U+4F8B".example | ||||
S: >xn--fsq270a.example</b-dn:rdn> | ||||
S: <b-dn:bdn uLabel="U+5BE6""U+4F8B".example | ||||
S: >xn--fsqz41a.example</b-dn:bdn> | ||||
S: </b-dn:bundle> | ||||
S: </b-dn:trnData> | ||||
S: </extension> | ||||
S: <trID> | ||||
S: <clTRID>ABC-12345</clTRID> | ||||
S: <svTRID>54322-XYZ</svTRID> | ||||
S: </trID> | ||||
S: </response> | ||||
S:</epp> | ||||
7.2.5. EPP <update> Command | 7.2.5. EPP <update> Command | |||
This extension does not add any element to the EPP <update> command | This extension does not add any element to the EPP <update> command | |||
described in the EPP domain name mapping [RFC5731]. When the command | described in the EPP domain name mapping [RFC5731]. However, | |||
has been processed successfully, the EPP <resData> element MUST | additional elements are defined for the <update> response in the EPP | |||
contain child elements as described in the EPP domain mapping | object mapping. When the command has been processed successfully, | |||
[RFC5731]. This EPP <extension> element SHOULD contain the | the EPP <extension> element SHOULD be contained in the resoponse if | |||
<b-dn:upData> which contains <b-dn:bundle> element. | the domain object has data associated with bundled names. This EPP | |||
<extension> element SHOULD contain the <b-dn:upData> which contains | ||||
<b-dn:bundle> element. | ||||
Example <update> Response for an authorized client: | ||||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | ||||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | ||||
S: <response> | ||||
S: <result code="1000"> | ||||
S: <msg>Command completed successfully</msg> | ||||
S: </result> | ||||
S: <extension> | ||||
S: <b-dn:upData | ||||
S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn-1.0"> | ||||
S: <b-dn:bundle> | ||||
S: <b-dn:rdn uLabel="U+5B9E""U+4F8B".example | ||||
S: >xn--fsq270a.example</b-dn:rdn> | ||||
S: <b-dn:bdn uLabel="U+5BE6""U+4F8B".example | ||||
S: >xn--fsqz41a.example</b-dn:bdn> | ||||
S: </b-dn:bundle> | ||||
S: </b-dn:upData> | ||||
S: </extension> | ||||
S: <trID> | ||||
S: <clTRID>ABC-12345</clTRID> | ||||
S: <svTRID>54322-XYZ</svTRID> | ||||
S: </trID> | ||||
S: </response> | ||||
S:</epp> | ||||
8. Formal Syntax | 8. Formal Syntax | |||
An EPP object name mapping extension for bundled names is specified | An EPP object name mapping extension for bundled names is specified | |||
in XML Schema notation. The formal syntax presented here is a | in XML Schema notation. The formal syntax presented here is a | |||
complete schema representation of the object mapping suitable for | complete schema representation of the object mapping suitable for | |||
automated validation of EPP XML instances. The BEGIN and END tags | automated validation of EPP XML instances. The BEGIN and END tags | |||
are not part of the schema; they are used to note the beginning and | are not part of the schema; they are used to note the beginning and | |||
ending of the schema for URI registration purposes. | ending of the schema for URI registration purposes. | |||
skipping to change at page 17, line 20 ¶ | skipping to change at page 19, line 31 ¶ | |||
o URI: urn:ietf:params:xml:schema:epp:b-dn-1.0 | o URI: urn:ietf:params:xml:schema:epp:b-dn-1.0 | |||
o Registrant Contact: See the "Author's Address" section of this | o Registrant Contact: See the "Author's Address" section of this | |||
document. | document. | |||
o XML: See the "Formal Syntax" section of this document. | o XML: See the "Formal Syntax" section of this document. | |||
11. Security Considerations | 11. Security Considerations | |||
The object mapping extension described in this document does not | Some registries and registrars have more than 15 years of the bundled | |||
provide any other security services or introduce any additional | registration of domain names (especially Chinese domain names). They | |||
considerations beyond those described by [RFC5730] or those caused by | have not found some significant security issues. One principle that | |||
the protocol layers used by EPP. | the registry and registrar should let the registrants know is that | |||
bundled registered domain names will be created, transfered, updated, | ||||
and deleted together as a group. The registrants for bundled domain | ||||
names should remember this principle when doing some operations to | ||||
these domain names. [RFC5730] also introduces some security | ||||
consideration. | ||||
12. Implementation Status | 12. Implementation Status | |||
Note to RFC Editor: Please remove this section before publication. | Note to RFC Editor: Please remove this section before publication. | |||
o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, | o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, | |||
HKIRC, MONIC, SGNIC and more have followed the principles defined | HKIRC, MONIC, SGNIC and more have followed the principles defined | |||
in this document for many years. | in this document for many years. | |||
o CNNIC and TELEINFO have implemented this extension in their EPP | o CNNIC and TELEINFO have implemented this extension in their EPP | |||
skipping to change at page 17, line 49 ¶ | skipping to change at page 20, line 18 ¶ | |||
example, the NGO registrant is also registering and purchasing the | example, the NGO registrant is also registering and purchasing the | |||
corresponding name in the .ong TLD (and vice-versa for | corresponding name in the .ong TLD (and vice-versa for | |||
registrations in .ong). | registrations in .ong). | |||
o Patrick Mevzek has released a new version of Net::DRI, an EPP | o Patrick Mevzek has released a new version of Net::DRI, an EPP | |||
client (Perl library, free software) implementing this extension. | client (Perl library, free software) implementing this extension. | |||
13. Acknowledgements | 13. Acknowledgements | |||
The authors especially thank the authors of [RFC5730] and [RFC5731] | The authors especially thank the authors of [RFC5730] and [RFC5731] | |||
and the following ones of CNNIC: Weiping Yang, Chao Qi. This draft | and the following ones of CNNIC: Weiping Yang, Chao Qi. | |||
extends the draft draft-kong-epp-idn-variants-mapping to support both | ||||
forms of bundled names: V-label.TLD and LABEL.V-tld. | ||||
Useful comments were made by John Klensin, Scott Hollenbeck, Patrick | Useful comments were made by John Klensin, Scott Hollenbeck, Patrick | |||
Mevzek and Edward Lewis. | Mevzek and Edward Lewis. | |||
14. Change History | 14. Change History | |||
RFC Editor: Please remove this section. | RFC Editor: Please remove this section. | |||
14.1. draft-kong-epp-bundle-mapping: Version 00 | 14.1. draft-kong-epp-bundle-mapping: Version 00 | |||
skipping to change at page 19, line 9 ¶ | skipping to change at page 21, line 25 ¶ | |||
14.8. draft-ietf-regext-bundle-mapping: Version 04 | 14.8. draft-ietf-regext-bundle-mapping: Version 04 | |||
o Update the implementation section. | o Update the implementation section. | |||
o Refine the text. | o Refine the text. | |||
14.9. draft-ietf-regext-bundle-mapping: Version 05 | 14.9. draft-ietf-regext-bundle-mapping: Version 05 | |||
o Scope the XML namespaces to include 'epp'. | o Scope the XML namespaces to include 'epp'. | |||
14.10. draft-ietf-regext-bundle-mapping: Version 06 | ||||
o add some examples for the transfer, update and renew command | ||||
o add some text to security consideration | ||||
15. References | 15. References | |||
15.1. Normative References | 15.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
End of changes. 14 change blocks. | ||||
49 lines changed or deleted | 161 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |