[email protected] writes: [inline]
> Do we need to touch these parts from the abstract to better align with the > new approach: > > CURRENT: > > This > document updates RFC8624 by moving the canonical source of algorithm > implementation requirements and usage guidance for DNSSEC from > RFC8624 to an IANA registry. good point, fixed > > The document does not change the status (MUST, MAY, RECOMMENDED, > etc.) of the algorithms listed in RFC8624; that is the work of future > documents. That's still ok, IMHO. We didn't change the algorithms statuses, we only moved them. > (2) Check "A.12. Changes since RFC8624" > > Also, please add a sentence to the abstract to indicate explicitly that this > doc obsoletes 8624. Done (but really done in the fix above). > > Technically, the documents could be combined but the history is > > much cleaner as 3 separate documents. In our humble opinion, of > > course, and is what the consensus was as well. > > [Med] Thanks for the background. The issue here is that 8624bis will > be published with a table that does not reflect what do have now in > IANA. I'm not sure what you mean here. The document sets the initial values in the table, which other documents will later update. That's how all IANA tables work. > > > ## Modification policy > > > > > > The registration policy for the two registries is "RFC Required", > > > while the deprecated values were modified with a status-change in > > the > > > past. Should be update the policy to be consistent with the > > practice? > > > > This was intentional and was discussed in the WG and is what we > > came to consensus on. We (the WG) wanted to require RFC updates > > for any change to the requirements. > > > > [Med] I'm still missing something here. The registration policy for > this registry is "RFC Required" since 2010 if my checks are > correct. Although we have that policy, the registry was changed last > year without an RFC. A simple fix here is to update the registration > policy to also cover IESG Approval. Regardless of the past: the DNSOP WG came to consensus that from this document forward the policy should be "RFC Required". > > > ## Normative language for IANA considerations > > > > > > Section 2 contains many statements that usually fall under an > > IANA > > > considerations section. Example of such text is (but there are > > other > > > occurrences): > > > > Yes, fair point... most of the document is essentially an IANA > > updates document. > > Some of the text targets implementers/operators but the IANA > > considerations really is targeting just what IANA has to do. > > > > [Med] Maybe I missed it but I don't see this reflected in the new > version. FWWI, refer also to > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ > (Inappropriate Uses of Key Words) [XXX: TBD -- we'll talk about this. Many of the statements aren't talking to IANA, they're talking to operators and implementers (or general readers). We'll have to review if we think any of the statements should also apply to IANA and copy them to the IANA section.] > > > CURRENT: > > > "Implement for DNSSSEC Validation" columns SHALL follow the > > > "Specification Required" policy as defined in [RFC8126] in > > order to > > > promote continued evolution of DNSSEC algorithms and DNSSEC > > agility. > > > New entries added through the "Specification Required" process > > will > > > have the value of "MAY" for all columns. > > > > > > When such text is in an IANA cons section, the use of the > > normative > > > language > > > (SHALL) is avoided. > > > > This is text targeting the reader (aka implementers and operators) > > though. > > [Med] Hmm. I re-read and don't see how this is targeting > users/implementers. "...target DNSSEC operators and implementers" is pretty clear to me? The document audience section has paragraphs for both groups of people. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
