draft-ietf-regext-epp-ttl-06.txt   draft-ietf-regext-epp-ttl-07.txt 
Registration Protocols Extensions (regext) G. Brown Registration Protocols Extensions (regext) G. Brown
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Standards Track 1 March 2024 Intended status: Standards Track 26 March 2024
Expires: 2 September 2024 Expires: 27 September 2024
Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live
(TTL) values (TTL) values
draft-ietf-regext-epp-ttl-06 draft-ietf-regext-epp-ttl-07
Abstract Abstract
This document describes an extension to the Extensible Provisioning This document describes an extension to the Extensible Provisioning
Protocol (EPP) that allows EPP clients to manage the Time-To-Live Protocol (EPP) that allows EPP clients to manage the Time-To-Live
(TTL) value for domain name delegation records. (TTL) value for domain name delegation records.
About this draft About this draft
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 2 September 2024. This Internet-Draft will expire on 27 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1.2. Extension elements . . . . . . . . . . . . . . . . . . . 4 1.2. Extension elements . . . . . . . . . . . . . . . . . . . 4
1.2.1. The <ttl:ttl> element . . . . . . . . . . . . . . . . 4 1.2.1. The <ttl:ttl> element . . . . . . . . . . . . . . . . 4
1.2.1.1. Element content . . . . . . . . . . . . . . . . . 5 1.2.1.1. Element content . . . . . . . . . . . . . . . . . 5
1.2.1.2. Supported DNS record types . . . . . . . . . . . 5 1.2.1.2. Supported DNS record types . . . . . . . . . . . 5
1.2.1.3. Examples . . . . . . . . . . . . . . . . . . . . 6 1.2.1.3. Examples . . . . . . . . . . . . . . . . . . . . 6
1.3. The <ttl:info> element . . . . . . . . . . . . . . . . . 6 1.3. The <ttl:info> element . . . . . . . . . . . . . . . . . 6
1.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7
2. EPP command mapping . . . . . . . . . . . . . . . . . . . . . 7 2. EPP command mapping . . . . . . . . . . . . . . . . . . . . . 7
2.1. EPP query commands . . . . . . . . . . . . . . . . . . . 7 2.1. EPP query commands . . . . . . . . . . . . . . . . . . . 7
2.1.1. EPP <info> command . . . . . . . . . . . . . . . . . 7 2.1.1. EPP <info> command . . . . . . . . . . . . . . . . . 7
2.1.1.1. Default mode . . . . . . . . . . . . . . . . . . 7 2.1.1.1. Default Mode . . . . . . . . . . . . . . . . . . 7
2.1.1.2. Policy mode . . . . . . . . . . . . . . . . . . . 11 2.1.1.2. Policy Mode . . . . . . . . . . . . . . . . . . . 11
2.1.1.3. Unextended <info> command . . . . . . . . . . . . 14 2.2. EPP transform commands . . . . . . . . . . . . . . . . . 14
2.2. EPP transform commands . . . . . . . . . . . . . . . . . 15 2.2.1. EPP <create> command . . . . . . . . . . . . . . . . 14
2.2.1. EPP <create> command . . . . . . . . . . . . . . . . 15 2.2.2. EPP <update> command . . . . . . . . . . . . . . . . 16
2.2.2. EPP <update> command . . . . . . . . . . . . . . . . 17 3. Server processing of TTL values . . . . . . . . . . . . . . . 18
3. Server processing of TTL values . . . . . . . . . . . . . . . 19 3.1. Permitted record types . . . . . . . . . . . . . . . . . 18
3.1. Permitted record types . . . . . . . . . . . . . . . . . 19 3.2. Use of TTL values in delegation records . . . . . . . . . 18
3.2. Use of TTL values in delegation records . . . . . . . . . 19 4. Out-of-band changes to TTL values . . . . . . . . . . . . . . 18
4. Out-of-band changes to TTL values . . . . . . . . . . . . . . 19 5. Operational considerations . . . . . . . . . . . . . . . . . 18
5. Operational considerations . . . . . . . . . . . . . . . . . 19 5.1. Operational impact of TTL values . . . . . . . . . . . . 18
5.1. Operational impact of TTL values . . . . . . . . . . . . 19 5.2. When TTL values should be changed . . . . . . . . . . . . 19
5.2. When TTL values should be changed . . . . . . . . . . . . 20 6. Security considerations . . . . . . . . . . . . . . . . . . . 19
6. Security considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. XML namespace . . . . . . . . . . . . . . . . . . . . . . 19
7.1. XML namespace . . . . . . . . . . . . . . . . . . . . . . 20 7.2. EPP extension registry . . . . . . . . . . . . . . . . . 20
7.2. EPP extension registry . . . . . . . . . . . . . . . . . 21 8. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Implementation status . . . . . . . . . . . . . . . . . . . . 24
9. Implementation status . . . . . . . . . . . . . . . . . . . . 25 9.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 24
9.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 25 9.2. Pepper EPP Client . . . . . . . . . . . . . . . . . . . . 24
9.2. Pepper EPP Client . . . . . . . . . . . . . . . . . . . . 25 10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 24
10.1. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 25 10.2. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 25
10.2. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 26 10.3. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 25
10.3. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 26 10.4. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 25
10.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 26 10.5. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 25
10.5. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26 10.6. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25
10.6. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26 10.7. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26
10.7. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 27 10.8. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative references . . . . . . . . . . . . . . . . . . 27 12.1. Normative references . . . . . . . . . . . . . . . . . . 27
12.2. Informative references . . . . . . . . . . . . . . . . . 28 12.2. Informative references . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The principal output of any domain name provisioning system is a DNS The principal output of any domain name provisioning system is a DNS
zone file, which contains the delegation record(s) for names zone file, which contains the delegation record(s) for names
registered within a zone (such as a top-level domain). These records registered within a zone (such as a top-level domain). These records
typically include one or more NS records, but may also include DS typically include one or more NS records, but may also include DS
records for domains secured with DNSSEC ([RFC9364]), and DNAME records for domains secured with DNSSEC ([RFC9364]), and DNAME
records for IDN variants ([RFC6927]). Where glue (see Section 7 of records for IDN variants ([RFC6927]). Where glue (see Section 7 of
[RFC8499]) is required, A and/or AAAA records may also be published [RFC8499]) is required, A and/or AAAA records may also be published
skipping to change at page 6, line 45 skipping to change at page 6, line 45
1.2.1.3.4. Custom record type (<create> or <update> command, <info> 1.2.1.3.4. Custom record type (<create> or <update> command, <info>
default mode) default mode)
<ttl:ttl <ttl:ttl
for="custom" for="custom"
custom="DELEG">3600<ttl:ttl> custom="DELEG">3600<ttl:ttl>
1.3. The <ttl:info> element 1.3. The <ttl:info> element
The <ttl:info> element is used to by clients to request that the The <ttl:info> element is used by clients to request that the server
server include additional information in <info> responses for domain include additional information in <info> responses for domain and
and host objects. host objects.
It has a single OPTIONAL attribute, policy, which takes a boolean It has a single OPTIONAL policy attribute, which takes a boolean
value with a default value of false. value with a default value of false.
The semantics of this element are described in Section 2.1.1. The semantics of this element are described in Section 2.1.1.
1.3.1. Example 1.3.1. Example
<ttl:info policy="true"/> <ttl:info policy="true"/>
2. EPP command mapping 2. EPP command mapping
2.1. EPP query commands 2.1. EPP query commands
2.1.1. EPP <info> command 2.1.1. EPP <info> command
This extension defines an additional element for EPP <info> commands This extension defines an additional element for EPP <info> commands
and responses for domain and host objects. and responses for domain and host objects.
The EPP <info> command is extended to support two different "modes". The EPP <info> command is extended to support two different modes:
The first "default" mode requests the inclusion of all non-default
TTL values in the response. The second "policy" mode requests the
inclusion of TTL information for all supported DNS record types in
the response, along with the minimum, default and maximum values for
those records.
2.1.1.1. Default mode 1. The Default Mode (Section 2.1.1.1), which requests the inclusion
of all non-default TTL values in the response; and
2. The Policy Mode (Section 2.1.1.2) which requests the inclusion of
TTL information for all supported DNS record types in the
response, along with the minimum, default and maximum values for
those records.
2.1.1.1. Default Mode
If a server receives an <info> command for a domain or host object If a server receives an <info> command for a domain or host object
which includes a <ttl:info> element without a policy attribute, or which includes a <ttl:info> element with a policy attribute that is 0
with a policy attribute that is 0 or false, then the response MUST or false, then the EPP response contain MUST contain in its
contain an <extension> element, which MUST contain a <ttl:infData> <extension> element a <ttl:infData> element, which MUST contain
element, which MUST contain <ttl> records for all DNS record types <ttl:ttl> records for all DNS record types that have non-default TTL
that have non-default TTL values. These elements SHOULD NOT have the values. These elements MUST NOT have the min, default and max
min, default and max attributes. attributes.
Example domain <info> command with a <ttl:info> element with a policy Example domain <info> command with a <ttl:info> element with a policy
attribute that is false: attribute that is false:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <info> C: <info>
C: <domain:info C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
skipping to change at page 10, line 22 skipping to change at page 10, line 22
C: </host:info> C: </host:info>
C: </info> C: </info>
C: <extension> C: <extension>
C: <ttl:info C: <ttl:info
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
C: policy="false"/> C: policy="false"/>
C: </extension> C: </extension>
C: </command> C: </command>
C:</epp> C:</epp>
Example domain <info> response to a command with a <ttl:info> element Example host <info> response to a command with a <ttl:info> element
with a policy attribute that is false: with a policy attribute that is false:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <host:infData S: <host:infData
skipping to change at page 11, line 27 skipping to change at page 11, line 27
S: <host:addr ip="v4">192.0.2.2</host:addr> S: <host:addr ip="v4">192.0.2.2</host:addr>
S: <host:addr ip="v6">1080::8:800:200C:417A</host:addr> S: <host:addr ip="v6">1080::8:800:200C:417A</host:addr>
S: <host:clID>ClientX</host:clID> S: <host:clID>ClientX</host:clID>
S: <host:crID>ClientX</host:crID> S: <host:crID>ClientX</host:crID>
S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate> S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>
S: </host:infData> S: </host:infData>
S: </resData> S: </resData>
S: <extension> S: <extension>
S: <ttl:infData S: <ttl:infData
S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
S: <ttl:ttl for="A">3600</ttl:ttl> S: <ttl:ttl for="A">172800</ttl:ttl>
S: <ttl:ttl for="AAAA">86400</ttl:ttl> S: <ttl:ttl for="AAAA">86400</ttl:ttl>
S: </ttl:infData> S: </ttl:infData>
S: </extension> S: </extension>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
2.1.1.2. Policy mode 2.1.1.2. Policy Mode
If a server receives an <info> command for a domain or host object If a server receives an <info> command for a domain or host object
which includes a <ttl:info> element with a policy attribute that is which includes a <ttl:info> element with a policy attribute is 1 or
present and is 1 or true, then the response MUST contain an true, then the EPP response contain MUST contain in its <extension>
<extension> element, which MUST contain a <ttl:infData> element, element a <ttl:infData> element, which MUST include <ttl:ttl> records
which MUST include <ttl:ttl> records for all supported DNS record for all supported DNS record types, irrespective of whether those
types, irrespective of whether those record types are actually in use record types are actually in use by the object in question. These
by the object in question. These elements MUST have the min, default elements MUST have the min, default and max attributes.
and max attributes.
Example domain <info> command requesting the server policies: Example domain <info> command requesting the server policies:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <info> C: <info>
C: <domain:info C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
skipping to change at page 14, line 44 skipping to change at page 14, line 44
S: max="172800">86400</ttl:ttl> S: max="172800">86400</ttl:ttl>
S: </ttl:infData> S: </ttl:infData>
S: </extension> S: </extension>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
2.1.1.3. Unextended <info> command
If a server receives an <info> command which does not contain a
<ttl:info> element, then the response MUST NOT contain a
<ttl:infData> element.
2.2. EPP transform commands 2.2. EPP transform commands
2.2.1. EPP <create> command 2.2.1. EPP <create> command
This extension defines an additional element for EPP <create> This extension defines an additional element for EPP <create>
commands for domain and host objects. commands for domain and host objects.
The <command> element of the <create> command frame MAY contain an The <command> element of the <create> command frame MAY contain an
<extension> element which MAY contain a <ttl:create> element. This <extension> element which MAY contain a <ttl:create> element. This
element MUST contain one or more <ttl:ttl> records as described in element MUST contain one or more <ttl:ttl> records as described in
skipping to change at page 25, line 51 skipping to change at page 24, line 51
*Licensing:* Perl Artistic License *Licensing:* Perl Artistic License
*Contact:* The author of this document. *Contact:* The author of this document.
*URL:* https://github.com/gbxyz/pepper *URL:* https://github.com/gbxyz/pepper
10. Change log 10. Change log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
10.1. Change from 05 to 06 10.1. Change from 06 to 07
1. Minor wording changes and nits reported by JG.
10.2. Change from 05 to 06
1. Changed how <info> commands work so that a <ttl:info> element is 1. Changed how <info> commands work so that a <ttl:info> element is
required in order for <ttl> elements to be included in the required in order for <ttl:ttl> elements to be included in the
response. Thanks to Jim Gould for this feedback. response. Thanks to JG for this feedback.
10.2. Change from 04 to 05 10.3. Change from 04 to 05
1. removed the erroneous required="true" attribute from the min, 1. removed the erroneous required="true" attribute from the min,
default and max attributes of the responseTTLType type (thanks default and max attributes of the responseTTLType type (thanks
JG). JG).
2. fixed the reference to RFC 6895 (thanks HS). 2. fixed the reference to RFC 6895 (thanks HS).
10.3. Change from 04 to 05 10.4. Change from 04 to 05
1. Add the the Verisign EPP SDK to Section 9. 1. Add the the Verisign EPP SDK to Section 9.
2. Add the <ttl:info> element and document how it affects server 2. Add the <ttl:info> element and document how it affects server
<info> responses. <info> responses.
3. Updated examples to exercise more of the schema. 3. Updated examples to exercise more of the schema.
4. Minor schema issue fixed. 4. Minor schema issue fixed.
10.4. Change from 03 to 04 10.5. Change from 03 to 04
1. Changed the for attribute to be an enumeration and added the 1. Changed the for attribute to be an enumeration and added the
custom attribute. custom attribute.
2. Added the min, default and max attributes. 2. Added the min, default and max attributes.
3. Apply feedback from Jim Gould. 3. Apply feedback from Jim Gould.
10.5. Change from 02 to 03 10.6. Change from 02 to 03
1. Rolled back the "straw man" syntax from 02. ttl:ttl now has a for 1. Rolled back the "straw man" syntax from 02. ttl:ttl now has a for
attribute which can be any DNS record type. Section 1.2.1.2 attribute which can be any DNS record type. Section 1.2.1.2
describes how the set of supported record types may be limited. describes how the set of supported record types may be limited.
2. Removed the global/explicit models and just use the explicit 2. Removed the global/explicit models and just use the explicit
model. model.
3. Removed the cascading effect where a TTL set on a domain affects 3. Removed the cascading effect where a TTL set on a domain affects
subordinate hosts. subordinate hosts.
10.6. Change from 01 to 02 10.7. Change from 01 to 02
1. Renamed the ttl:seconds XSD type to ttl:container, and the 1. Renamed the ttl:seconds XSD type to ttl:container, and the
ttl:nonNegativeInteger type to ttl:ttlType, to permit multiple ttl:nonNegativeInteger type to ttl:ttlType, to permit multiple
TTL values. TTL values.
2. Converted XML instances from artwork to source code. 2. Converted XML instances from artwork to source code.
10.7. Change from 00 to 01 10.8. Change from 00 to 01
1. Incorporate feedback from Jim Gould. 1. Incorporate feedback from Jim Gould.
2. Add wording to describe how TTL values are jointly managed by 2. Add wording to describe how TTL values are jointly managed by
both clients and servers. both clients and servers.
3. Fix minimum/maximum TTL value and schema namespace (thanks 3. Fix minimum/maximum TTL value and schema namespace (thanks
Patrick Mevzek). Patrick Mevzek).
4. Moved text on how the server should handle impermissible TTL 4. Moved text on how the server should handle impermissible TTL
skipping to change at page 27, line 37 skipping to change at page 26, line 40
6. Added discussion on EPP servers which use the host attribute 6. Added discussion on EPP servers which use the host attribute
model in Section 3.2 (thanks Hugo Salgado). model in Section 3.2 (thanks Hugo Salgado).
7. Added a Change Log (Section 10). 7. Added a Change Log (Section 10).
11. Acknowledgements 11. Acknowledgements
The author wishes to thank the following people for their advice and The author wishes to thank the following people for their advice and
feedback during the development of this document: feedback during the development of this document:
1. Hugo Salgado; 1. James Gould;
2. Patrick Mevzek; 2. Hugo Salgado;
3. Rick Wilhelm; 3. Patrick Mevzek;
4. James Gould; 4. Rick Wilhelm;
5. Marc Groeneweg; 5. Marc Groeneweg;
6. Ties de Kock. 6. Ties de Kock.
12. References 12. References
12.1. Normative references 12.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,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 28, line 45 skipping to change at page 27, line 46
February 2015, <https://www.rfc-editor.org/info/rfc7451>. February 2015, <https://www.rfc-editor.org/info/rfc7451>.
12.2. Informative references 12.2. Informative references
[RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names [RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names
Registered in Top-Level Domains", RFC 6927, Registered in Top-Level Domains", RFC 6927,
DOI 10.17487/RFC6927, May 2013, DOI 10.17487/RFC6927, May 2013,
<https://www.rfc-editor.org/info/rfc6927>. <https://www.rfc-editor.org/info/rfc6927>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", RFC 8499, DOI 10.17487/RFC8499, January
January 2019, <https://www.rfc-editor.org/info/rfc8499>. 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the [RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the
Extensible Provisioning Protocol (EPP)", RFC 8590, Extensible Provisioning Protocol (EPP)", RFC 8590,
DOI 10.17487/RFC8590, May 2019, DOI 10.17487/RFC8590, May 2019,
<https://www.rfc-editor.org/info/rfc8590>. <https://www.rfc-editor.org/info/rfc8590>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
 End of changes. 29 change blocks. 
86 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/