On Jan 7, 2025, at 11:07, Rebecca VanRheenen <rvanrhee...@amsl.com> wrote: > > Thank you for the quick reply! You mention that you provided "notes on the > visible changes” in addition to answers to our questions, but we only see > your answers to our questions. Let us know if we are missing anything.
This was a mistake on my part. I had two things from looking through the diffs, but then saw them in your questions and answered them there. > We updated the document (see list of files below) and have a few followup > questions/comments: > > 1) >>> b) Last sentence above - We see several registries mentioned in RFC 9157 >>> (see >>> notes below). Would it be helpful to specify which registries this sentence >>> refers to? We see references to RFC 4034 in some of these registries but not >>> all. >>> >>> These registry groups are mentioned in Section 4 of RFC 9157: >>> >>> - "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" >>> (https://www.iana.org/assignments/dnssec-nsec3-parameters) >>> - "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest >>> Algorithms" (https://www.iana.org/assignments/ds-rr-types/) >>> >>> These registries within the above registry groups are also mentioned: >>> >>> - DNSSEC NSEC3 Flags >>> - DNSSEC NSEC3 Hash Algorithms >>> - DNSSEC NSEC3PARAM Flags >>> - Digest Algorithms >>> >>> We also see that Section 3 of RFC 9157 includes a citation to the following >>> registry in the OLD/NEW text, but we had to look at RFC 8624 to see the name >>> of the registry: >>> >>> - [DNSKEY-IANA] - "Domain Name System Security (DNSSEC) Algorithm Numbers" >>> (http://www.iana.org/assignments/dns-sec-alg-numbers) >>> --> >> >> We only mean the Digest Algorithms registry. No reader would be confused >> about this, but you can specify it anyway. > > To clarify, which of the following is correct? Or do you prefer to leave the > original? You note that readers will not be confused by this. > > Original: > The IANA registries for these values are described in [RFC9157]. > > Perhaps: > The "Digest Algorithms" registry for these values is described in [RFC9157]. > > Or: > The “DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest > Algorithms” registry for these values is described in [RFC9157]. RFC 9157 only updates some of the DNSSEC-related IANA registries. The original sentence could instead say "The IANA registries for DNSSEC-related values are described in [RFC9157]. The sentence doesn't need to point to a single registry. > 4) >>> 14) <!-- [rfced] Sourcecode >>> >>> a) We see that type="Zone" is used for some sourcecode >>> elements. This type does not appear on the current list of preferred >>> values for the type attribute: >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!PtGJab4!6HibyQ2KHSR3yhUdmKkYm9zQa_NB1totFrlnKYAFiX_7TFwWVbokSTRGbCV0nDRHxBYTVmJ6W4PHLjAJ_0dzo6N8MZLf$ >>> [rfc-editor[.]org] >>> >>> Would you like to remove type="Zone"? It is acceptable to leave the "type" >>> attribute not set. Alternately, would you like to suggest type="Zone" be >>> considered as as addition to the list? If so, we can submit it for review by >>> the RPC team. >> >> This came up during the IETF discussion of the draft. We would like >> type="Zone" to be added to the list, given that there are many RFCs that >> show the contents of DNS zones. > > We submitted type=“Zone” for consideration as an addition to the list. We’ll > keep you posted on this. Just to be clear, and to reflect the RPAT discussion: we are fine with any notation that indicates DNS resource records as they appear in a zone. "Zone" is fine, but so are other names if they are preferable to the RPC. > 5) >>> 15) <!-- [rfced] The following terms are enclosed in <tt> in this document. >>> >>> id >>> source >>> TrustAnchor >>> validFrom >>> validUntil >>> >>> Some of these appear both with and without <tt>. For example, we see both >>> "TrustAnchor element" (no <tt>) and "<tt>TrustAnchor</tt> element" (with >>> <tt>). >>> >>> Also, some elements are enclosed in <tt> (e.g., "<tt>id</tt> element"), but >>> other elements are not (e.g., "KeyDigest element" and "Zone element"). >>> >>> Please review to ensure the usage of <tt> is correct and consistent. Let us >>> know if any updates are needed. >>> --> >> >> Choosing when to use <tt> is a personal decision, one that is rarely done >> consistently in the IETF. In looking back, all element names and attribute >> names should be in <tt> to be consistent. I doubt anyone will care much >> about inconsistencies here. > > Should “publickeyinfo” be in <tt>? Yes. XML named patterns are like elements or attributes. > 6) When making updates to the usage of <tt>, we noticed that the following > sentences use "id element”. Should these be updated to “id attribute”? Good catch! Yes. I see it four times in the current text. --Paul Hoffman -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
