On Tue, Apr 24, 2018, at 21:02, Matthew Pounsett wrote: > On 7 January 2018 at 18:28, Patrick Mevzek <p...@dotandco.com> wrote: > > > > > > > On Fri, Dec 22, 2017, at 07:03, Patrick Mevzek wrote: > > > Hello authors, > > > > > > Please find below my review of your draft. > > > > Please also have a look at > > https://tools.ietf.org/id/draft-hildebrand-deth-00.txt > > as it covers related goals (it is more generic than just NS/DS needs) > > > > I do not know where it is discussed nor its current status. > > > > It may however be of interest to this WG. > > > > I've seen that draft before. It's a sort of "DNS UPDATE over HTTPS" > system. While there may be some overlap in what it provides, it doesn't > have the same goals or applicability of our draft. We're trying to write > something that can be inserted into the existing ecosystem with limited > overhead. Something like draft-hildebrand-deth requires authentication, > whereas this scheme doesn't. > > We've also received a fair bit of push-back to any suggestion that we might > expand this protocol to allow updates of NS records.
I still think that at soon as you have a mechanism to be able to change something, like DNSSEC related materials in your case, people will ask to be able to change other things. This does not mean that all should be covered by a single mechanism but you may always find other ideas in other proposals that could help or not, and at least include some working in your own specification to clearly say: this is suitable to do X, but could be extended to do Z but probably not to do W. BTW, see how they use the "_deth" label in the DNS to identify the endpoint, as suggested in your case to defend against any hardcoding and having to name precisely the endpoint for everyone, as anyone knows that the naming is the hardest part of computer science. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
