Hi, Éric, Ben, and Kevin. Happy New Year!
Éric, we have noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9704 Ben, we have updated this document per your notes below, except for this item; please advise: > Section 1: > "This specification expects that local DNS servers will be securely > identified ..." > -> This statement strikes me as more personifying than is necessary. It's > also strange because, leaving aside the specification's opinion, I don't > expect that most local DNS servers will be securely identified. The prior > text said "this specification relies on ...", in an attempt to convey the > idea that secure identification is a precondition, not a prediction (as > implied by the future tense "will be"). Other possible verbs for this > sentence would be "require" or "assume" (or "applies only to networks where > the local DNS server is securely identified", etc.). It's not clear to us how, and where, we should make updates. Please specify, using "OLD" and "NEW" text. = = = = = Kevin, we found that your notes referenced the original approved document and not the edited document. All items you listed had been resolved previously. Please review the edited files, and let us know if you have any questions. The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9704.txt https://www.rfc-editor.org/authors/rfc9704.pdf https://www.rfc-editor.org/authors/rfc9704.html https://www.rfc-editor.org/authors/rfc9704.xml https://www.rfc-editor.org/authors/rfc9704-diff.html https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html https://www.rfc-editor.org/authors/rfc9704-auth48diff.html https://www.rfc-editor.org/authors/rfc9704-lastdiff.html https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html Thank you! RFC Editor/lb > On Jan 2, 2025, at 9:19 AM, Kevin Smith, Vodafone <kevin.sm...@vodafone.com> > wrote: > > Dear Éric, all, > Many thanks for your review, and Ben for the follow-up. I have some Nits for > which I apologise for missing in my previous proof-read: > --- > 1. Introduction > "Networks usually offer clients a DNS resolver using means such as (e.g., > DHCP OFFER, IPv6 Router Advertisement)" --> parentheses should be removed. > 2. Terminology > The terms defined should have a colon appended, otherwise it may not be > clear to the reader where the term ends and the definition begins. > 8. Examples of Split-Horizon DNS Configuration > s/the internal servers resolves only/the internal servers resolve only > 9. Operational Efficiency in Split-Horizon Deployments > Missing word or period in the middle of "Verification Record, this document": > Although placing internal domains inside a child domain is > unnecessary to prevent leakage, such placement reduces the frequency > of changes to the Verification Record, this document recommends the > internal domains be kept in a child zone of the local domain hints > advertised by the network. > Changing to either "Verification Record. This document" or "Verification > Record, hence this document" fixes this. > --- > Many thanks, and Happy New Year to all! > All best, > Kevin > On Dec 20, 2024, at 7:28 AM, Ben Schwartz <bem...@meta.com> wrote: > > Thanks for these improvements! I approve the "dot-last" listing of > special-use domain names. > > Some further comments: > > Section 1: > "This specification expects that local DNS servers will be securely > identified ..." > -> This statement strikes me as more personifying than is necessary. It's > also strange because, leaving aside the specification's opinion, I don't > expect that most local DNS servers will be securely identified. The prior > text said "this specification relies on ...", in an attempt to convey the > idea that secure identification is a precondition, not a prediction (as > implied by the future tense "will be"). Other possible verbs for this > sentence would be "require" or "assume" (or "applies only to networks where > the local DNS server is securely identified", etc.). > > Section 5: > "If the local encrypted resolver is identified by name (e.g., DNR)," > -> Perhaps "(e.g., using DNR)" would be more correct. > > Section 8: > "Figure 2 shows discovery using DNR and PvD information." > -> "information from DNR and PvD" seems preferable to avoid ambiguity about > whether "information" applies to both "DNR" and "PvD". > > "The client determines the network's DNS server (dns.example.net) and PvD > information (pvd.example.com) using DNR [RFC9463] and PvDs [RFC8801], using > one of the following: DNR Router Solicitation, DHCPv4, or DHCPv6." > -> This sentence has a few problems: pvd.example.com is not really the "PvD > information", nothing in steps 1-2 actually uses PvDs, and "DNR Router > Solicitation" is not a logical alternative to "DHCPv4". I suggest this > replacement: "The client determines the network's DNS server > (dns.example.net) and PvD ID (pvd.example.com) using DNR and one of the > following: Router Solicitation, DHCPv4, or DHCPv6." > > "PvD JSON information ... The PvD contains:" > -> RFC 8801 consistently uses the term "PvD Additional Information" for this > JSON object. Referring to it as "JSON information" is clear enough but seems > informal, and calling it "the PvD" seems to compromise precision. I would > prefer "PvD Additional Information ... The JSON object contains:" > > General note: > The capitalization of "Option" in the context of DHCP and RA still seems > somewhat inconsistent. c.f. RFC 8801's consistent capitalization of "PvD > Option". > > --Ben > On Dec 20, 2024, at 6:40 AM, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > > Lynne, Ben, and other authors, > I have verified the diff between the I-D and RFC-to-be 9704 for section 8: > the changes are indeed editorial (and nice), so, I approve this change. > After looking at the other diffs, I also approve them. > Regards and, if applicable to you, I wish you all a Merry Christmas, and a > Happy New Year! > -éric > From: Lynne Bartholomew <lbartholo...@amsl.com> > Date: Thursday, 19 December 2024 at 20:24 > To: Ben Schwartz <bemasc=40meta....@dmarc.ietf.org>, Eric Vyncke (evyncke) > <evyn...@cisco.com> > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, kond...@gmail.com > <kond...@gmail.com>, danw...@gmail.com <danw...@gmail.com>, > kevin.sm...@vodafone.com <kevin.sm...@vodafone.com>, i...@bemasc.net > <i...@bemasc.net>, add-...@ietf.org <add-...@ietf.org>, > add-cha...@ietf.org<add-cha...@ietf.org>, mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com>, auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org> > Subject: *[AD] Re: AUTH48: RFC-to-be 9704 > <draft-ietf-add-split-horizon-authority-14> for your review > Hi, Ben and *Éric. > > * Éric, even though the restructuring of Section 8 (re. our question 15)) > appears to be editorial in nature, please review, and let us know if you > approve. > > > Ben, thank you for your replies to our questions! We have updated this > document per your notes below. > > A follow-up note for you: > > Re. our question 3) and your reply: > > > 3. The current text is clear but not consistent: ".home.arpa" and ".local" > > are written dot-first, and "resolver.arpa." and "ipv4only.arpa." are > > written dot-last. I don't have a strong preference but we should use a > > single form throughout this sentence. > > > We went with dot-last per RFC 9462. Please review, and let us know if > further changes are needed. > > The latest files are posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9704.txt > https://www.rfc-editor.org/authors/rfc9704.pdf > https://www.rfc-editor.org/authors/rfc9704.html > https://www.rfc-editor.org/authors/rfc9704.xml > https://www.rfc-editor.org/authors/rfc9704-diff.html > https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9704-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html > > Thanks again! > > RFC Editor/lb > > > > On Dec 18, 2024, at 2:56 PM, Ben Schwartz > > <bemasc=40meta....@dmarc.ietf.org> wrote: > > > > 1. Noted at > > https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/70 > > > > 2. Approved > > > > 3. The current text is clear but not consistent: ".home.arpa" and ".local" > > are written dot-first, and "resolver.arpa." and "ipv4only.arpa." are > > written dot-last. I don't have a strong preference but we should use a > > single form throughout this sentence. > > > > 4. Approved > > > > 5. This is not a list of definitions, so I am hesitant to use <dl>. > > > > 6. Do not change. The current quoting is correct. > > > > 7. I prefer option 2. > > > > 8. These references should both be changed to refer to the "ZONEMD Hash > > Algorithms" registry and Section 5.3 of RFC 8976. > > > > 9. Approved > > > > 10. It means "It can be accomplished in this way, which is as > > straightforward as one can reasonably hope for given the notoriously > > difficult technologies that are involved". I welcome improved language. > > > > 11. Approved > > > > 12. The type should be "dns-rr". > > > > 13. Approved > > > > 14. For the sake of consistency, we should probably apply <tt> whenever a > > DNS name is not in double-quotes. This would require two additional <tt> > > tags. > > > > 15. The two examples have since been combined. I propose to delete this > > text, delete the "Split Horizon Entire Zone" section header, and retitle > > Section 8, resulting in the following structure: > > > > 8. Example Split-Horizon DNS Configuration > > 8.1. Verification Using an External Resolver > > ... > > Figure 3: Verifying claims using an external resolver > > ... > > 8.2. Verification using DNSSEC > > ... > > Figure 4: An Example of Verifying Claims using DNSSEC --> > > > > 16. Yes, this spacing should be made consistent. > > > > 17. Let's change to ENCDNS_IP* for consistency. > > > > 18. Approved > > > > 19. Let's change to: > > > > 3. The old verification record needs to be maintained until the DHCP > > lease or PvD Additional Information expires. > > > > 20. Let's change the titles of Sections 13.1 and 13.2 as follows: > > > > 13.1. New DHCP Authentication Algorithm for Split DNS > > 13.2. New PvD Additional Information Type for Split DNS > > > > 21. No Action. > > > > 22a. No Objection > > 22b. I think the existing usage is appropriate. "ds=..." appears in the > > first usage in the section to remind the reader that this is a key-value > > pair", and "ds" is used afterward as a shorthand. > > 22c(?). The "Verification Record" is a new technical artifact invented for > > this specification. We should use consistent capitalization for it. I > > lean toward capitalizing. > > > > --Ben Schwartz > > >> On Dec 13, 2024, at 12:54 PM, rfc-edi...@rfc-editor.org wrote: > >> > >> 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] Section 1: This sentence read oddly, as it indicated > >> that this document checks each local domain hint against a globally > >> valid parent zone. We updated it as follows. If this is incorrect, > >> please clarify the text. > >> > >> Original: > >> This specification relies on securely identified local DNS servers, > >> and checks each local domain hint against a globally valid parent > >> zone. > >> > >> Currently: > >> This specification expects that local DNS servers will be securely > >> identified and that each local domain hint will be checked against a > >> globally valid parent zone. --> > >> > >> > >> 3) <!-- [rfced] Section 3: We see the following: > >> * RFC 6762 uses '".local."' and '".local" > >> * RFC 6763 uses '"local."' > >> * <https://www.iana.org/assignments/special-use-domain-names/> lists > >> 'local.' (per RFC 6762) > >> * Quite a few subsequent RFCs use '".local"' > >> > >> Are any clarifications required here, or will '".local"' be clear to > >> readers as is? > >> > >> Original: > >> All of the special-use domain names registered with IANA [RFC6761], > >> most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and > >> ".local", are never unique to a specific DNS server's authority. --> > >> > >> > >> 4) <!-- [rfced] Section 5: We see that > >> I-D.ietf-dnsop-domain-verification-techniques was restructured > >> (i.e., the section numbering changed) between versions -04 and -06. > >> As it appears that "5.1" should now be "5.2" and "5.2" should now be > >> "5.3", we updated this citation accordingly. Please review this > >> diff file and let us know if this update is accurate: > >> https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-domain-verification-techniques-04&url2=draft-ietf-dnsop-domain-verification-techniques-06 > >> > >> Original: > >> The zone operator then publishes a "Verification Record" with the > >> following structure, following the best practices outlined in > >> Sections 5.1 and 5.2 of > >> [I-D.ietf-dnsop-domain-verification-techniques]: > >> > >> Currently: > >> The zone operator then publishes a "Verification Record" with the > >> following structure, following the best practices outlined in > >> Sections 5.2 and 5.3 of [DOMAIN-VERIFICATION-TECHNIQUES]: --> > >> > >> > >> 5) <!-- [rfced] Sections 5 and 5.1: Are the lists with "=" correct as > >> they are (i.e., tagged as <ul>), or may we update them to use <dl>? > >> > >> Original: > >> * Type = TXT. > >> > >> * Owner Name = Concatenation of the ADN, "_splitdns-challenge", and > >> the parent zone name. > >> > >> * Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" > >> (without padding) > >> ... > >> * ADN = "resolver17.parent.example" > >> > >> * Parent = "parent.example" > >> > >> * Subdomains = "payroll.parent.example", > >> "secret.project.parent.example" > >> > >> * Hash Algorithm = SHA-384 [RFC6234] > >> > >> * Salt = "example salt octets (should be random)" > >> > >> Perhaps: > >> Type: TXT > >> > >> Owner Name: Concatenation of the ADN, "_splitdns-challenge", and > >> the parent zone name > >> > >> Contents: "key/value" pairs, e.g., "token=base64url($TOKEN)" > >> (without padding) > >> ... > >> ADN: "resolver17.parent.example" > >> > >> Parent: "parent.example" > >> > >> Subdomains: "payroll.parent.example", > >> "secret.project.parent.example" > >> > >> Hash Algorithm: SHA-384 [RFC6234] > >> > >> Salt: "example salt octets (should be random)" --> > >> > >> > >> 6) <!-- [rfced] Section 5.1: Should the "(should be random)" portion of > >> this entry be placed outside of the quotes? Please compare with the > >> "Contents =" entry in Section 5, where "(without padding)" is outside > >> of the quotes. > >> > >> Original: > >> * Salt = "example salt octets (should be random)" > >> > >> Possibly: > >> * Salt = "example salt octets" (should be random) --> > >> > >> > >> 7) <!-- [rfced] Section 5.1: We see the following note just before the > >> sourcecode in this section: > >> > >> NOTE: '\' line wrapping per [RFC8792] > >> > >> We also see that the sourcecode in Section 7 also seems to implement > >> line wrapping but does not include the note. Should this note also > >> appear before the sourcecode in Section 7? > >> > >> Two alternatives for you to consider: > >> > >> 1. Place the note inside of the sourcecode, per (for example) > >> rfc9645.xml (https://www.rfc-editor.org/info/rfc9645). > >> > >> 2. Remove the note and add text to the Terminology section explaining > >> the convention for line wrapping, as follows: > >> > >> Lone lines in examples are wrapped using a single backslash ("\") > >> per [RFC8792]. --> > >> > >> > >> 8) <!-- [rfced] Section 5.2.2: There appeared to be a conflict between > >> the following text in this section and some text in Section 12 (which > >> mentions "Section 5.2" in the context of the "ZONEMD Schemes" > >> registry). As it appears that in this section (5.2.2), "Section 5.2" > >> should be "Section 5.3" per the fourth bullet in Section 5, we > >> updated the citation in this section accordingly. If this is > >> incorrect, please provide text that resolves the conflicting > >> information. > >> > >> (Section 5.2 of RFC 8976 has the title "ZONEMD Scheme" and defines > >> the "ZONEMD Schemes" registry; Section 5.3 of RFC 8976 has the title > >> "ZONEMD Hash Algorithms" and defines the "ZONEMD Hash Algorithms" > >> registry.) > >> > >> Original: > >> * "algorithm": The hash algorithm is represented by its "Mnemonic" > >> string from the ZONEMD Hash Algorithms registry ([RFC8976], > >> Section 5.2). > >> ... > >> Algorithm Agility (see [RFC7696]) is achieved by providing > >> implementations with flexibility to choose hashing algorithms from > >> the ZONEMD Schemes registry ([RFC8976], Section 5.2). > >> > >> Currently: > >> "algorithm": The hash algorithm, represented by its "Mnemonic" > >> string from the "ZONEMD Hash Algorithms" registry (Section 5.3 of > >> [RFC8976]). --> > >> > >> > >> 9) <!-- [rfced] Section 5.2.2: Four registries are discussed in > >> Section 13, one of which is the new registry defined in Section 13.3. > >> Because Section 13.3 cites this section and this section defines the > >> parameters listed in Section 13.3, we clarified the citation in this > >> sentence accordingly. Please let us know any objections. > >> > >> Original: > >> Future specifications aiming to define new keys will need to add them > >> to the IANA registry defined in Section 13. > >> > >> Currently: > >> Future specifications aiming to define new keys will need to add them > >> to the IANA registry defined in Section 13.3. --> > >> > >> > >> 10) <!-- [rfced] Section 7: Does "can be accomplished simply by placing" > >> mean "can be accomplished easily by placing", "can be accomplished by > >> simply placing", or something else? > >> > >> Original: > >> When the local zone can be signed with globally trusted keys for the > >> parent zone, support for DNSSEC can be accomplished simply by placing > >> a zone cut at the parent zone and including a suitable DS record for > >> the local resolver's DNSKEY. --> > >> > >> > >> 11) <!-- [rfced] Section 7: As it appears that "RR" in this sentence > >> stands for "Resource Record" and "Resource Record" is not marked > >> well known on > >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list>, we > >> expanded it here for ease of the reader. If this expansion is > >> incorrect, please provide the correct definition. > >> > >> Original: > >> At least one resulting DNSKEY RR MUST match the > >> DS RDATA from the "ds" key in the Verification Record. > >> > >> Currently: > >> At least one resulting DNSKEY Resource Record > >> (RR) MUST match the DS RDATA from the "ds" key in the Verification > >> Record. --> > >> > >> > >> 12) <!-- [rfced] Section 7: Please review whether the "type" attribute > >> should be set for the following sourcecode element in the XML file. > >> (Other sourcecode elements have the "type" attribute set.) > >> > >> Original: > >> <sourcecode> > >> ;; Parent zone. > >> ... > >> > >> If the current list of preferred values for "type" > >> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) > >> does not contain an applicable type, please let us know. Also, it is > >> acceptable to leave the "type" attribute unset. --> > >> > >> > >> 13) <!-- [rfced] Section 7: The second and third lines of this > >> sourcecode were too long for the text output. We adjusted as > >> follows. Please review, and let us know any concerns. > >> > >> Original: > >> ; NSEC record indicating that unsigned delegations are permitted at > >> ; this subdomain. This is required for compatibility with non-split-aware > >> ; validating stub resolvers. If the claimed label is confidential, the > >> ; parent zone can conceal it using NSEC3 (with or without "opt-out"). > >> > >> Currently: > >> ; NSEC record indicating that unsigned delegations are permitted at > >> ; this subdomain. This is required for compatibility with > >> ; non-split-aware validating stub resolvers. If the claimed label is > >> ; confidential, the parent zone can conceal it using NSEC3 (with or > >> ; without "opt-out"). --> > >> > >> > >> 14) <!-- [rfced] It appears that <tt>s might be inconsistently applied in > >> this document. Some of the example URLs are enclosed in <tt>, while > >> others are not or are enclosed in quotation marks instead. Please > >> review the lists below, and let us know if any updates are needed. > >> > >> Terms enclosed with <tt>: > >> dns.example.net > >> *.example.com > >> example.com > >> *.internal.example.com > >> internal.example.com > >> pvd.example.com > >> www.example.com > >> > >> Similar terms without <tt>: > >> "example.com" > >> pvd.example.com > >> internal.example.com > >> "internal.example.com" > >> "ns1.internal.example.com" > >> "private1.internal.example.com" > >> "private2.internal.example.com" > >> "*.internal.example.com" --> > >> > >> > >> 15) <!-- [rfced] Section 8: We could not determine which example is the > >> second of the two examples in this section. Do Sections 8.1, 8.1.1, > >> and 8.1.2 show three examples, rather than two? Section 8.1 seems > >> straightforward, but Sections 8.1.1 and 8.1.2 are confusing in that > >> they seem to show two additional examples. Please review and clarify. > >> > >> Original: > >> Two examples are shown below. The first example shows a company with > >> an internal-only DNS server that claims the entire zone for that > >> company (e.g., *.example.com). In the second example, the internal > >> servers resolves only a subdomain of the company's zone (e.g., > >> *.internal.example.com). > >> > >> 8.1. Split-Horizon Entire Zone > >> ... > >> 8.1.1. Verification Using an External Resolver > >> ... > >> Figure 3: Verifying claims using an external resolver > >> ... > >> 8.1.2. Verification using DNSSEC > >> ... > >> Figure 4: An Example of Verifying Claims using DNSSEC --> > >> > >> > >> 16) <!-- [rfced] Figures 2 and 3: Would you like spacing between the > >> step descriptions and the step numbers to be consistent? For > >> example: > >> > >> Original: > >> ... > >> resolve pvd.example.com (4) > >> A or AAAA records (5) > >> ... > >> _splitdns-challenge.example.com (1) > >> TXT "token=ABC..." (2) > >> resolving example.com (3) > >> ... > >> > >> Possibly: > >> ... > >> resolve pvd.example.com (4) > >> A or AAAA records (5) > >> ... > >> _splitdns-challenge.example.com (1) > >> TXT "token=ABC..." (2) > >> resolving example.com (3) > >> ... --> > >> > >> > >> 17) <!-- [rfced] Section 10: We do not see "ENCDNS_IP*_*" or > >> "ENCDNS_IP*_" in RFC 9464. Will the use of the additional underscore > >> be clear to readers, or should "ENCDNS_IP*_*" be changed to > >> "ENCDNS_IP*" per RFC 9464? > >> > >> Original: > >> When the endpoint is using a VPN tunnel and the tunnel is IPsec, the > >> encrypted DNS resolver hosted by the VPN service provider can be > >> securely discovered by the endpoint using the ENCDNS_IP*_* IKEv2 > >> Configuration Payload Attribute Types defined in [RFC9464]. --> > >> > >> > >> 18) <!-- [rfced] Section 11: As it appears that "to prompt the DHCP > >> clients for dynamically requesting" means "to prompt the DHCP client > >> to dynamically request", we updated this sentence accordingly. If > >> this update is incorrect, please clarify "to prompt ... for ... > >> requesting". > >> > >> Original: > >> 1. DHCP reconfiguration can be initiated by a DHCP server that has > >> previously communicated with a DHCP client and negotiated for the > >> DHCP client to listen for Reconfigure messages, to prompt the > >> DHCP clients for dynamically requesting the updated Authorization > >> Claim. > >> > >> Currently: > >> 1. DHCP reconfiguration can be initiated by a DHCP server that has > >> previously communicated with a DHCP client and negotiated for the > >> DHCP client to listen for Reconfigure messages, to prompt the > >> DHCP client to dynamically request the updated authorization > >> claim. --> > >> > >> > >> 19) <!-- [rfced] Section 11: We had trouble following the meaning of > >> "until the DHCP lease time or PvD Additional Information expiry". > >> If the suggested text is not correct, please clarify. > >> > >> Original: > >> 3. The old verification record needs to be maintained until the DHCP > >> lease time or PvD Additional Information expiry. > >> > >> Suggested: > >> 3. The old verification record needs to be maintained until the DHCP > >> lease time or PvD Additional Information period expires. --> > >> > >> > >> 20) <!-- [rfced] Section 13.2: This title is difficult to interpret. > >> Does it mean "Provisioning Domains Using Split DNS Additional > >> Information", "Provisioning Domains: Split DNS Additional > >> Information", or something else? Please clarify. > >> > >> Original: > >> 13.2. Provisioning Domains Split DNS Additional Information --> > >> > >> > >> 21) <!-- [rfced] Please review the "Inclusive Language" portion of the > >> online Style Guide at > >> <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. --> > >> > >> > >> 22) <!-- [rfced] Please let us know if any changes are needed for the > >> following: > >> > >> a) The following terms were used inconsistently in this document. > >> We chose to use the latter forms. Please let us know any objections. > >> > >> Authorization Claim (13 instances in text) / > >> authorization claim (3 instances in text) (per post-6000 > >> published RFCs) > >> > >> Global DNS / global DNS (per RFC 9499 and other post-6000 > >> published RFCs, except for RFC 9526) > >> > >> PvD additional information (1 instance / > >> PvD Additional Information (2 instances) (per post-6000 > >> published RFCs) > >> > >> RRSet / RRset (per much more common usage in post-6000 > >> published RFCs) > >> > >> b) The following terms appear to be used inconsistently in this > >> document. Please let us know which form is preferred. > >> > >> "ds=..." (2 instances) / "ds" (4 instances) * > >> > >> * It is not clear whether these variations refer to the same > >> parameter or two distinct parameters. Please advise. > >> > >> Verification Record (15 instances in text) / > >> verification record (6 instances in text in Section 11) ** > >> > >> ** We could not find a precedent in published RFCs to date. > >> If this is not considered a proper term, we suggest the > >> lowercase form. --> > >> > >> > >> Thank you. > >> > >> RFC Editor/lb/ar > >> > >> On Dec 13, 2024, rfc-edi...@rfc-editor.org wrote: > >> > >> *****IMPORTANT***** > >> > >> Updated 2024/12/13 > >> > >> 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/rfc9704.xml > >> https://www.rfc-editor.org/authors/rfc9704.html > >> https://www.rfc-editor.org/authors/rfc9704.pdf > >> https://www.rfc-editor.org/authors/rfc9704.txt > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9704-diff.html > >> https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html (side by side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9704 > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC9704 (draft-ietf-add-split-horizon-authority-14) > >> > >> Title : Establishing Local DNS Authority in Validated > >> Split-Horizon Environments > >> Author(s) : T. Reddy.K, D. Wing, K. Smith, B. Schwartz > >> WG Chair(s) : David C Lawrence, Glenn Deen > >> Area Director(s) : Erik Kline, Éric Vyncke > >> > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
