Warren Kumari <[email protected]> writes: I'm following up with some additional comments but any items I didn't respond to I agreed with Warren (which was generally: good suggestions and thank you).
> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for > use on https://www.rfc-editor.org/search. > --> > > DNS, rollover, agility Again, add DNSSEC too please. > Also, please clarify "incremental update RFCs". Is the intended meaning > that future > extensions can be made under new, incremental RFCs that update this > document? > > TBD Yes, and since that's common terminology maybe just "future RFCs" instead and we'll just stop trying to add "incremental" as it's confusing and doesn't really help anyway. > 8) <!--[rfced] Section 3. Since there are multiple registries under the > "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group, > we added the > registry name for clarity as shown below. [...] > Perhaps A: > Initial values for the use and implementation recommendation columns in > the "DNS > Security Algorithm Numbers" registry under the "Domain Name System > Security (DNSSEC) > Algorithm Numbers" registry group are shown in Table 2. > > Either is fine with me - whatever y'all and my co-author think…. I think A is a bit clearer IMHO. Thanks! > 10) <!--[rfced] Questions about Table 2 > > a) In Table 2, some of the values in the "Use for" and > "Implement for" columns are different than what is listed in "DNS > Security Algorithm > Numbers" registry (specifically, see numbers 5, 7, and 12). Should Table > 2 be updated > to match the IANA registry as shown below, or should the IANA registry be > updated to > match Table 2? > > The IANA Registry should be updated (which kicked this off); my co-author and > I will > discuss…. So these ended up becoming different because we added more columns in the long run than was originally specified. > b) In Table 2, numbers 17, 23, 253, and 254 use terms from the > Description column in > the registry whereas the rest of the numbers use terms from the > Mnemonic column. Agreed, we should be consistent and mnemonic values should be used. > 12) <!--[rfced] We note differences between Table 3 and the "Digest > Algorithms" > registry. Should this document be updated to match the registry as shown > below, or > should the registry be updated to match this document? So I believe that the confusion here is that: 1. this document defines the values at the time the RFC is to be published, but the other two related documents immediately change the values to more restrictive. Hence, for example, the MUST NOT values for GOST in the current table exist because IANA has already taken the actions defined in these algorithms. So in steps they: 1. took the values from this document (rfc8624-bis-13) and made columns for them. THEN 2. took the values from the must-not-gost document and applied the new values. Thus, the values in the original table are correct because they document what existed before any of the tables changed as a result of all our documents. So the history is properly preserved by leaving our values in the bis document the same, as it's the later must-not-gost and must-not-sha1 documents that create the new values that have already been placed into the document. Clear as mud? In other words: > Perhaps (to match the IANA registry): > > 0 Reserved MUST NOT | MUST NOT | MUST NOT | MUST NOT > > 3 GOST R > 34.11-94 MUST NOT | MUST NOT | MUST NOT | MUST NOT This is wrong, because those values come from a later-numbered RFC that changes the values to MUST NOT from the values in this table. > 15) <!-- [rfced] FYI: We have added an expansion for the following > abbreviation per > Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review this and each > expansion in > the document carefully to ensure correctness. > > DNS Public Key (DNSKEY) > --> > > Huh. Yes, that looks right — in my brain it is just "DNS Key", but RFC 4034, > etc show you > to be correct. Yep, DNSKEY is correct. thanks. -- Wes Hardaker Google -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
