On Aug 21, 2024, at 18:12, Warren Kumari <war...@kumari.net> wrote:
> My initial email in this thread said:
> 
> The IANA is eagerly awaiting this becoming a standard so that they can update 
> their trust anchor with the DNSKEY material - so, if you have any strong 
> objections to these changes, please let me know by end of day (anywhere!) on 
> Aug 18th."

Apologies for only replying now, I missed this message in my in-box until I saw 
Petr’s.

The way that quote is worded makes it sound like a quick approval is important 
and that this would make something a standard.

Even if this is just a document of how IANA publishes information about its 
trust anchors for the root zone it administers[1], there ought to be no 
ambiguity in the meaning of the fields or even the presence/absence of the 
fields.  Nothing should be left to the imagination of the reader.  There’s no 
underlying standard regarding trust anchors that supplies default assumptions.  
This document then has to stand on its own.

I am a bit surprised that this is a WG document, as it pertains to one 
operator’s approach in filling an undefined gap in the management of the 
protocol.  WG review of this is beneficial, arguably the best means to address 
risks involved and a worthy use of WG time.  Nevertheless, if IANA’s operations 
are to be defined by IANA, and they should be, then this document is “owned” by 
IANA and not by DNSOP.

I’m writing this to encourage consideration of Mike St. John’s and Petr 
Spacek’s comments as opposed to pushing this through because “IANA is eagerly 
awaiting this becoming a standard.

[1] qualification recognizing that the DNS protocol can be instantiated in 
different environments, IANA is administering the root zone for the global 
public Internet.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to