Top reply to my own post, sorry. Even if *THIS* document is in DPRIVE (which I think it should be), it does not necessarily imply that ADoT development itself has to be done in DPRIVE; I think where ADoT development actually happens is a separate question/discussion.
Brian On Wed, Aug 28, 2019 at 11:20 AM Brian Dickson < [email protected]> wrote: > > > On Wed, Aug 14, 2019 at 1:40 PM Brian Haberman <[email protected]> > wrote: > >> This starts a Call for Adoption for >> draft-hal-adot-operational-considerations >> >> The draft is available here: >> >> https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DPRIVE, and comment to the list, clearly stating your view. >> >> > I am in favor of adoption of this draft by DPRIVE. > > My view is as follows: > - DNS is an ecosystem which by definition requires interoperability. > - Authority operators are a distinct subset of the participants in the DNS > ecosystem > - Authority operators of registered domains (as distinct from > delegation-only domains) have operational concerns (including scaling > issues and performance issues) that are appropriate to consider BEFORE the > development of ADoT itself. > - I.e. The draft should be input to the ADoT development process, similar > to a requirements document. > - Doing development of ADoT without this would be another example of IETF > "paper engineering", which while attractive to some participants, is very > harmful to reasonably mature ecosystems. (The "paper engineering" practice > is harmful even in green-field, IMHO.) > - Operational considerations != deployment guidelines. This is basically a > pre-emptive feedback to the standards design, based on known issues that > will affect any flavor of ADoT, no matter what it looks like. > - Deployment guidelines to operators would follow implementations, which > would follow standard development, which *should* take into consideration a > variety of factors, which this document covers. > - There is work to be done on the document, but it is a great start. > > >> Please also indicate if you are willing to contribute text, review, etc. >> > > All of the above. > > Brian Dickson > (Speaking for myself, but with the viewpoint of someone doing both > authority server operation and software development on authority server > software, intending to implement ADoT.) > > >> >> This call for adoption ends: 28 August 2019 >> >> Thanks, >> Brian & Tim >> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy >> >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
