Hi, Thanks for the feed backs. We discussed your feed backs at the IETF meeting and ... delayed your response. I apology for it.
Please see my comments inline. Yours, Daniel On Sun, Mar 24, 2019 at 10:41 AM S Moonesamy <sm+i...@elandsys.com> wrote: > Hi Daniel, > At 07:10 AM 23-03-2019, Daniel Migault wrote: > >We would particularly appreciate to share your thoughts and discuss > >the requirements to operate DNSSEC validators. In particular, feed > >backs from operators or implementers would be more than welcome. > >Please feel free to share your thoughts on the mailing list, > > I took a quick look at the draft. The reference for RFC 7598 might > be a typo [1]. > > Section 6.1.1: > > "Because of this, it is recommended that implementations make the root > zone trust anchor obvious to the operator while still enabling > configuration of general trust points." > > The meaning of "obvious" in the above sentence might not be that obvious. > <mglt> I understand your comment as our use of obvious is misleading. What we meant here is that the root zone TA is a by default configuration. <mglt> > > Section 6.2 discusses about a data store and references RFC 5011 as a > requirement [2]. I read a comment [3] about RFC 5011 in which one of > the assumptions of that RFC is mentioned: "The resolver has access to > persistent writeable storage that will work across reboots". I am > not sure whether that is usually the case for unmanaged devices. > > <mglt> Thanks for the pointer. You are correct we should also mention that the storage be updated with new keys. I guess the issue is not only for unmanaged devices. </mglt> > Section 8: > > "In order to anticipate the sunset of one of the signature scheme, > a DNSSEC validator may willing to estimate the impact of deprecating > one signature scheme." > > The sentence is not clear. > <mglt> The purpose was to provide means to enable old cryptography to be removed from the resolvers. In other words, resolvers are not expected to keep all legacy crypto. </mglt> > > As an overall comment, I suggest considering whether the audience is > the average working group participant only. If that is not the case, > the draft could do with an editorial pass. > > <mglt> Thanks! we will do. Rather than discussing about requirements, we will move this to operational practises I believe that will make the document clearer. </mglt> > Regards, > S. Moonesamy > > 1. I assume that it is RFC 7958. > 2. The sentence actually makes a recommendation. > 3. > > https://blog.cloudflare.com/its-hard-to-change-the-keys-to-the-internet-and-it-involves-destroying-hsms/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
