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 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
