[DNSOP] Re: Gunter Van de Velde's No Objection on draft-ietf-dnsop-rfc8624-bis-09: (with COMMENT)

[Wes Hardaker <[e-mail]>]

Gunter Van de Velde via Datatracker <[e-mail]> writes:

Thanks for the review Gunter,

Comments/Responses inline:

> 21         RFC8624 to an IANA registry.  This is done both to allow the list to
> 22         be more easily updated, and to allow the list to be more easily
> 23         referenced.  Future extensions to this registry can be made under
> 24         new, incremental update RFCs.  This document also incorporates the
> 25         revised IANA DNSSEC considerations from [RFC9157].
> 
> GV> The text here mentions a 'list'. The list was not mentioned before and made
> me wonder what 'list' is intended?

Good point, I changed the first "list" to "list of requirements" which
is really what was being talked about (technically it was referring to
the list of requirements).

> 124        Implementations need to meet both high security expectations as well
> 125        as provide interoperability between various vendors and with
> 126        different versions.
> 
> GV> Maybe swap the word vendor with implementations? one vendor can have
> multiple procedure implementations that may not interop well together.. been
> there and done that :-/
> 
> s/vendors/implementations/

Done

> 142        algorithm.  As such this document also adds new recommendations about
> 143        which algorithms should be deployed regardless of implementation
> 144        status.
> 
> GV> Just a quick question, is it fair to assume that the current recommendation
> is based on existing operational experience? In other words, do we expect these
> recommendations to hold up well as deployment matures and stronger
> cryptographic options become available?

I would expect that to be the case generally, but don't think we should
explicitly state that it will always be the case.  I can see corner
cases where sudden algorithm weaknesses cause the need for a rapid shift
regardless of current deployment/implementations/etc.

> 358        This document makes no modifications to the security of the existing
> 359        protocol or recommendations described in [RFC8624].  Thus, the
> 360        security considerations remain the same, which we quote below.
> 
> GV>  Just a personal and minor stylistic comment. I tend to avoid using the
> word "we" in formal procedure specifications, as it can be a bit ambiguous.
> It’s not always clear who "we" refers to, the authors, the working group, or
> perhaps the IETF as a whole. Feel free to disregard this if you prefer, but you
> might consider rephrasing slightly to remove "we" and give the text a more
> specification-style tone.

I changed this to:

   This document makes no modifications to the security of the
   existing protocol or recommendations described in [RFC8624].  Thus,
   the security considerations remain the same.  The remainder of this
   section restates that document's text.

Hopefully this works?
-- 
Wes Hardaker                                     
USC/ISI