Hi Paul, 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.
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]. 2) >> 6) <!-- [rfced] FYI - A normative reference to the XML specification has been >> added because this document contains XML. We placed the citation in the >> following sentence in Section 2.3. Please review and let us know if you >> prefer a different phrasing or placement. >> >> Original: >> The following is an example of what the trust anchor file might look >> like. >> >> Updated: >> The following is an example of what an XML [W3C.REC-xml11-20060816] document >> for a trust anchor might look like. >> >> Note: For more information, please see the IESG statement on "Guidelines for >> the Use of Formal Languages in IETF Specifications" >> (https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/, >> specifically, the following: "The use of a language requires a reference to >> the specification for that language. This reference is normative, and needs >> to >> fulfil the usual requirements for normative references (Section 7 of RFC >> 2026)." >> --> > > Shouldn't that reference be at the first use of "XML", namely the first > paragraph of section 2? We moved the citation to Section 2 as you suggest (and reverted the sentence above to the original phrasing). Thank you. 3) >> 11) <!-- [rfced] Please verify that no IANA actions are needed. For example, >> confirm that no action is needed per the following text (e.g., listing >> this document as an additional reference for id-mod-dns-resource-record >> or marking the registration as obsolete). >> >> Original: >> [RFC7958] defined id-mod-dns-resource-record, value 70, which was >> added to the the "SMI Security for PKIX Module Identifier" registry. >> This document no longer uses that identifier. >> --> > > This question is confusing. There is a long IANA Considerations section that > lists IANA actions. > > No action is needed for the fifth paragraph because, as it says, the document > no longer uses that identifier. Apologies for not being clear. We wanted to confirm that no changes were needed to any IANA registry. The datatracker says “IANA OK - No Actions Needed”, but we were not sure about the fifth paragraph. Thank you for confirming no action is needed for that. 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types >> >> 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. 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>? We added <tt> for the following attributes and elements: validFrom validUntil id source TrustAnchor KeyDigest KeyTag Algorithm DigestType Digest Zone PublicKey Flags 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”? Current: Note that the id element in the TrustAnchor element is different than the id element in the KeyDigest element described below. ... Note that the id element in the KeyDigest element is different than the id element in the TrustAnchor element described above. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9718.xml Updated output files: https://www.rfc-editor.org/authors/rfc9718.txt https://www.rfc-editor.org/authors/rfc9718.pdf https://www.rfc-editor.org/authors/rfc9718.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9718-auth48diff.html Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9718-diff.html https://www.rfc-editor.org/authors/rfc9718-rfcdiff.html (side-by-side diff) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9718 Thank you, RFC Editor/rv > On Jan 6, 2025, at 6:32 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: > > Thanks for the edit on our document. Here are my notes on the visible > changes, then answers to your questions. The other authors will chime in on > their own. > > --Paul Hoffman > > On Jan 6, 2025, at 15:46, rfc-edi...@rfc-editor.org wrote: > > >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> > > KSK > >> 2) <!-- [rfced] The following sentence appeared in RFC 7958, but we question >> if >> "can be used by [RFC5011]" could be improved. Please review. >> >> Original: >> This document describes one way to establish an >> initial trust anchor that can be used by [RFC5011]. >> >> Perhaps: >> This document describes one way to establish an >> initial trust anchor that can be used by the mechanism defined >> in [RFC5011]. >> --> > > Thanks, that's better. > >> 3) <!-- [rfced] How may we update the text starting with "but the basic >> idea.." >> to improve clarity? >> >> Original: >> The format of the entity differs in different systems, but >> the basic idea, the decision to trust this entity is made outside of >> the system that relies on it, is common to all the common uses of the >> term "trust anchor". >> >> Perhaps: >> The format of the entity differs in different systems, but >> the basic idea that the decision to trust this entity is made outside of >> the system that relies on it is shared by all the common uses of the >> term "trust anchor". >> >> Or: >> The format of the entity differs in different systems, but >> all common uses of the term "trust anchor" share the basic idea that >> the decision to trust this entity is made outside of the system that >> relies on it. >> --> > > The second option ("Or:") is much better. > >> 4) <!-- [rfced] In the second sentence below, would it be helpful to specify >> which element is in presentation format? The first sentence mentions two >> elements (Zone and TrustAnchor). >> >> Original: >> The Zone element in the TrustAnchor element states to which DNS zone >> this container applies. The element is in presentation format as >> specified in [RFC1035], including the trailing dot. The root zone is >> indicated by a single period (.) character without any quotation >> marks. >> --> > > Good catch. The second sentence should start "The Zone element is in...". > > >> 5) <!-- [rfced] We have a couple of questions about this text: >> >> Original: >> Each KeyDigest element represents the digest of a past, current, or >> potential future DNSKEY record of the zone defined in the Zone >> element. The values for the elements in the KeyDigest element are >> defined in [RFC4034]. The IANA registries for these values are >> described in [RFC9157]. >> >> a) Second sentence above - RFC 4034 mentions "DNSKEY", and we see a number of >> values mentioned throughout that document; however, we do not see >> "KeyDigest". Will readers know which values/elements in the KeyDigest element >> are defined in RFC 4034? Would it be helpful to specify these or point to a >> specific section in RFC 4034? > > KeyDigest is a term in this document, not in RFC 4034. I think readers will > understand that the values in KeyDigest comes from the definition of the > DNSKEY in RFC 4034. I don't see a way to make this clearer without making it > much longer. > >> 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. > > >> 6) <!-- [rfced] FYI - A normative reference to the XML specification has been >> added because this document contains XML. We placed the citation in the >> following sentence in Section 2.3. Please review and let us know if you >> prefer a different phrasing or placement. >> >> Original: >> The following is an example of what the trust anchor file might look >> like. >> >> Updated: >> The following is an example of what an XML [W3C.REC-xml11-20060816] document >> for a trust anchor might look like. >> >> Note: For more information, please see the IESG statement on "Guidelines for >> the Use of Formal Languages in IETF Specifications" >> (https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/, >> specifically, the following: "The use of a language requires a reference to >> the specification for that language. This reference is normative, and needs >> to >> fulfil the usual requirements for normative references (Section 7 of RFC >> 2026)." >> --> > > Shouldn't that reference be at the first use of "XML", namely the first > paragraph of section 2? > >> 7) <!-- [rfced] Please confirm that "ttime" (rather than "time") is correct >> here. >> >> Original: >> The full public key is only given for the trust anchor that >> does not have a validFrom ttime in the past. >> --> > > That was a typo on our part. It should indeed be "time". > >> 8) <!-- [rfced] FYI - We updated "the one that would have" as follows in >> these >> sentences. Let us know any concerns. >> >> Original: >> The potential >> third record, the one that would have included the key tag 19036, is >> already invalid based on the validUntil attribute's value and is thus >> not part of the trust anchor set. >> ... >> One potential >> second record, the one that would have been based on the key tag >> 19036, is already invalid based on the validUntil attribute's value >> and is thus not part of the trust anchor set. >> ... >> The other potential >> second record, the one that would have been based on the key tag >> 38696, does not contain the optional publickeyinfo named pattern and >> therefore the DNSKEY record for it cannot be calculated. >> >> Updated: >> A potential >> third record, one that includes the key tag 19036, is >> already invalid based on the validUntil attribute's value and is thus >> not part of the trust anchor set. >> ... >> A potential >> second record, one based on the key tag >> 19036, is already invalid based on the validUntil attribute's value >> and is thus not part of the trust anchor set. >> ... >> Another potential >> second record, one based on the key tag >> 38696, does not contain the optional publickeyinfo named pattern; >> therefore, the DNSKEY record for it cannot be calculated. >> --> > > Those are fine and easier to read than what we had. > >> 9) <!-- [rfced] FYI - We added <eref> to the URLs in the following sentences, >> which means that they are now hyperlinked in the html and pdf outputs. Please >> let us know any concerns. >> >> Original: >> The URL for retrieving the set of hashes in the XML file described in >> Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>. >> ... >> The URL for a detached CMS signature for the XML file is >> <https://data.iana.org/root-anchors/root-anchors.p7s>. >> --> > > Those are OK. However, I still hate the fact that the URLs get split across > lines in the text output. Windmill-tilting, I know. > >> 10) <!-- [rfced] In these sentences, "data.iana.org" appears both with and >> without >> quotation marks. We updated to use quotation marks for both >> instances. Also, should "data.iana.org" be a hyperlink (i.e., use >> <eref>)? We see that it resolves to https://www.iana.org/. >> >> Original: >> Currently, the CA used for data.iana.org is well known, >> that is, one that is a WebTrust-accredited CA. If a system >> retrieving the trust anchors trusts the CA that IANA uses for the >> "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in >> order to have assurance of data origin. >> >> Updated: >> Currently, the CA used for "data.iana.org" is well known, >> that is, one that is a WebTrust-accredited CA. If a system >> retrieving the trust anchors trusts the CA that IANA uses for the >> "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in >> order to have assurance of data origin. >> --> > > Quotation marks are fine. It **absolutely must not** be changed to a URL. > Certificates are given for domain names, not for URLs. > >> 11) <!-- [rfced] Please verify that no IANA actions are needed. For example, >> confirm that no action is needed per the following text (e.g., listing >> this document as an additional reference for id-mod-dns-resource-record >> or marking the registration as obsolete). >> >> Original: >> [RFC7958] defined id-mod-dns-resource-record, value 70, which was >> added to the the "SMI Security for PKIX Module Identifier" registry. >> This document no longer uses that identifier. >> --> > > This question is confusing. There is a long IANA Considerations section that > lists IANA actions. > > No action is needed for the fifth paragraph because, as it says, the document > no longer uses that identifier. > >> 12) <!-- [rfced] For the following reference entry, would it be helpful to >> include >> the direct URL and date for the practice statement? >> >> Original: >> [DPS] Root Zone KSK Operator Policy Management Authority, >> "DNSSEC Practice Statement for the Root Zone KSK >> Operator", n.d., <https://www.iana.org/dnssec/procedures>. >> >> Perhaps: >> [DPS] Root Zone KSK Operator Policy Management Authority, >> "DNSSEC Practice Statement for the Root Zone KSK >> Operator", March 2024, >> <https://www.iana.org/dnssec/procedures/ksk-operator/ksk- >> dps-20240315.html>. >> --> > > No, please don't. The DPS is updated regularly, and giving a date could make > a reader think that the information is no longer valid in newer versions of > the DPS. > >> 13) <!-- [rfced] FYI - We made a few changes to the list in Appendix A >> ("Changes >> from RFC 7958") to create parallel structure. Let us know any concerns. >> --> > > Yep, those were great, thanks. > >> 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types >> >> 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. > >> b) For the RELAX NG schema in Section 2.1, we updated <artwork> to >> <sourcecode> >> with type="rnc". Note that this was used for the RELAX NG schema in RFC 9457. >> Let us know any concerns. >> --> > > That seems fine. > > >> 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. > >> 16) <!-- [rfced] The following forms used in the document. Would you like to >> update to one form, or is the current okay? >> >> trust anchor document vs. trust anchor file >> >> XML document vs. XML file >> --> > > Good catch! It should always be "trust anchor file" (change one instance of > "document"), but it should always be "XML document" (change four instances of > "XML file"). > >> 17) <!-- [rfced] FYI - We have added expansions for the following >> abbreviations >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Pretty Good Privacy (PGP) >> Key Signing Key (KSK) >> --> > > Yes to both. > >> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online >> Style Guide https://www.rfc-editor.org/styleguide/part2/*inclusive_language >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > No changes here. -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
