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

["Gunter van de Velde (Nokia)" <[e-mail]>]

Thanks Wes. Looks all good to me.

Be well,
G/

-----Original Message-----
From: Wes Hardaker <[e-mail]> 
Sent: Tuesday, May 20, 2025 10:10 PM
To: Gunter Van de Velde via Datatracker <[e-mail]>
Cc: The IESG <[e-mail]>; Gunter van de Velde (Nokia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Gunter Van de Velde's No Objection on draft-ietf-dnsop-rfc8624-bis-09: (with COMMENT)

[You don't often get email from [e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



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 
> GV> 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 
> GV> 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 
> GV> 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 
> GV> 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