Skip to main content

Early Review of draft-ietf-regext-epp-ttl-09
review-ietf-regext-epp-ttl-09-dnsdir-early-somerset-2024-05-15-00

Request Review of draft-ietf-regext-epp-ttl-08
Requested revision 08 (document currently at 10)
Type Early Review
Team DNS Directorate (dnsdir)
Deadline 2024-05-20
Requested 2024-05-13
Requested by James Galvin
Authors Gavin Brown
I-D last updated 2024-05-15
Completed reviews Dnsdir Early review of -09 by Anthony Somerset (diff)
Comments
This document is currently in WGLC, ending on 13 May 2024.  It is primarily focused on providing a standard EPP mechanism for managing the TTL value of NS and DS records in a TLD zone.  Today, most registries set this value according to local policy.  There is some interest in the domain name industry to support registrants being able to manage this value.

Does the DNS Directorate have any insight to be included or concerns to be addressed regarding use of such a standard?
Assignment Reviewer Anthony Somerset
State Completed
Request Early review on draft-ietf-regext-epp-ttl by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/cKD0VTL2NxHXAWG0lj2YKSKeleU
Reviewed revision 09 (document currently at 10)
Result Ready w/nits
Completed 2024-05-15
review-ietf-regext-epp-ttl-09-dnsdir-early-somerset-2024-05-15-00
Hi,

I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

This document is well written and clear enough even with all the XML 
references :) I believe all DNS related standards are respected here and this 
would be a valuable extension to EPP. I believe this document is Ready but 
with 1 important NIT and one clarification

NIT

While the IPv4 addresses referenced in the examples uses the documentation 
prefix as per RFC5737 i note that IPv6 addresses are not following the same 
principle as per RFC3849 - I recommend that IPv6 addresses in the document be 
updated accordingly, from what i can see a simple find and replace on "1080::" 
with "2001:DB8::" should do the trick.

CLARIFICATION

I do have one clarifying query though with regards to section 3.1 on Permitted 
record types. How does a server signal to a client which record types are 
permitted beyond returning an error to an update command. After reading the 
<ttl:info policy="true"/> section again more carefully it says that supported 
record types would be returned by the server - perhaps one could be more 
explicit in section 3.1 to make reference to the ttl:info portion of the info 
response?

Thanks for your hard work on this draft

Best Regards

Anthony