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

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

Gunter Van de Velde has entered the following ballot position for
draft-ietf-dnsop-rfc8624-bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-rfc8624-bis-09

#
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8624-bis-09.txt

# General Review
# ==============

# as a general comment i found the draft reasonable easy to read and understand.

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?

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/

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?

It might be helpful to include a note or reference about how these
recommendations are expected to evolve over time, just to give readers a sense
of their long-term relevance.

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.