Re: [DNSOP] Fwd: FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-07.txt

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+ietf@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
>