Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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]. --> 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. --> 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. --> 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? 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) --> 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)." --> 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. --> 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. --> 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>. --> 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. --> 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. --> 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>. --> 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. --> 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. 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. --> 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. --> 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 --> 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) --> 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. --> Thank you. RFC Editor/rv On Jan 6, 2025, at 3:40 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/01/06 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9718.xml https://www.rfc-editor.org/authors/rfc9718.html https://www.rfc-editor.org/authors/rfc9718.pdf https://www.rfc-editor.org/authors/rfc9718.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9718-diff.html https://www.rfc-editor.org/authors/rfc9718-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9718-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9718 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9718 (draft-ietf-dnsop-rfc7958bis-06) Title : DNSSEC Trust Anchor Publication for the Root Zone Author(s) : J. Abley, J. Schlyter, G. Bailey, P. Hoffman WG Chair(s) : Suzanne Woolf, Benno Overeinder, Tim Wicinski Area Director(s) : Warren Kumari, Mahesh Jethanandani -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
