Thanks Wes. Looks all good to me. Be well, G/
-----Original Message----- From: Wes Hardaker <[email protected]> Sent: Tuesday, May 20, 2025 10:10 PM To: Gunter Van de Velde via Datatracker <[email protected]> Cc: The IESG <[email protected]>; Gunter van de Velde (Nokia) <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] 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 [email protected]. 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 <[email protected]> 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
