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 From: Ben Schwartz <bem...@meta.com> Sent: 20 December 2024 15:29 To: Eric Vyncke (evyncke) <evyn...@cisco.com>; Lynne Bartholomew <lbartholo...@amsl.com>; Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> Cc: rfc-edi...@rfc-editor.org; kond...@gmail.com; danw...@gmail.com; Kevin Smith, Vodafone <kevin.sm...@vodafone.com>; i...@bemasc.net; add-...@ietf.org; add-cha...@ietf.org; mohamed.boucad...@orange.com; auth48archive@rfc-editor.org Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9704 <draft-ietf-add-split-horizon-authority-14> for your review This email originated from outside of the organisation: Verify the sender and content before clicking or downloading. Report this email using Report Message button if unsure. 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 C2 General
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
