Wes Hardaker <[email protected]> wrote: > 10 years has passed (!) since the publication of RFC7706 (later > followed by RFC8806), which specified how resolvers can integrate a > copy of the root zone into their local operational environment. A lot > of experience has been gained since then, from a fair amount of > implementation and deployment. A number of observations during this > period have been made surrounding the feasibility of running an > authoritative engine on the loopback like the current RFCs suggest, > along with improvements to use other protocols like HTTP(S) for > collecting data.
Good. I'm glad we are moving in this direction.
> - https://datatracker.ietf.org/doc/draft-wkumari-dnsop-localroot-bcp/
> This document name is a misnomer at the moment as based on discussions
> the authors have had to date we have actually targeted it as proposed
> standard instead. This document is functionally a complete replacement
While a search of "LocalRoot" mostly gives me points to 7706, 8806, and
https://localroot.isi.edu/ there is also a Boston Knife shapener, and then it
devolves into *Local* *Root* exploits/discussion/etc. I fear that the term
might confuse the weak minded PHB. Yes, I think we should bikeshed the
term; maybe there is a context-free nonsense word that we could use.
> -
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-publication-points/
...
> Note: the format in this draft is just a starting point for discussion
> – I honestly expect something like signed json to win in the end.
Fair enough.
> - https://datatracker.ietf.org/doc/draft-hardaker-dnsop-dns-xfr-scheme/
> If we have URLs for publication points, then we need to be able to
> refer to targets of axfr, ixfr, and xot appropriately. Thus this short
> document specifies new URLs schemes for zone transfers over DNS.
Good.
> -
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-publ-list-guidelines
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-pub-list-guidelines/
> This document may or may not be needed based on WG and IANA opinions.
> Fundamentally, it outlines guidelines for what the minimum operational
> requirements are for being listed on the IANA publication point list
> above. It may be that if all these documents go forward in one way or
> another, this one gets dropped to letting IANA just do whatever it
> deems best, or the IETF may want to provide some minimal guidance.
It seems like a useful discussion I-D, but I don't see it useful to publish.
It can go into another document.
> We look forward to the discussion within DNSOP about each of these
> topics. I’d suggest for now that we concentrate on whether or not each
> is needed, and not whether or not they’re best kept in 4 documents vs a
> smaller number. And certainly the author/editors list of all documents
> is likely to change as well as time goes on.
Fewer number. Maybe one.
I am worried about a cold start situation.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
