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