Hi, Ben and *Éric. * Éric, please review the updates in Section 7, and let us know if you approve the removal of the 'If the "ds" key is not present ...' sentence, which contained a "MUST".
Ben, we have made further updates per your notes below. Please see "[rfced]" below re. the first change, and let us know if our update is incorrect. 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 8, 2025, at 1:15 PM, Ben Schwartz <bem...@meta.com> wrote: > > Some additional requested changes: > > Section 2: > > OLD: > Validated Split Horizon: Indicates that a split-horizon > configuration for some name is considered "validated" if the > client has confirmed that a parent of that name has authorized > this resolver to serve its own responses for that name. > > NEW: > Validated Split Horizon: A split-horizon > configuration for some name is considered "validated" if the > client has confirmed that a parent of that name has authorized > this resolver to serve its own responses for that name. [rfced] We added the word "that" in order to keep the sentence-fragment style used in all four list items. Please let us know if you would prefer your complete-sentence style for all four items. > > OLD: > Lone lines in examples are wrapped using a single backslash ("\") per > [RFC8792]. > > NEW: > Long lines in examples are wrapped using a single backslash ("\") per > [RFC8792]. > > Section 6: > > OLD: > If the client cannot obtain a response from the external resolver within a > reasonable timeout period, > > NEW: > If the client cannot obtain a response from the external resolver within a > reasonable timeframe, > > Section 6.1: > > OLD: > Alternatively, a client might perform DNSSEC validation for the > verification query even if it has disabled DNSSEC validation for other DNS > queries. > > NEW: > A compliant client could perform DNSSEC validation for the verification > query even if it has disabled DNSSEC validation for other DNS queries. > Section 7: > > I believe the last sentence of the fourth paragraph is confusing and should > be deleted. The fifth paragraph can be made more explicit. > > OLD: > If the "ds" key is not present in a valid Verification Record, the client > MUST disable DNSSEC validation when resolving the claimed subdomains via this > local encrypted resolver. > > Note that in this configuration, any claimed subdomains MUST be marked as > unsigned in the public DNS. Otherwise, resolution results would be rejected > by validating stubs that do not implement this specification. > > NEW: > > Note that when the local resolver does not have a globally trusted DNSKEY, > any claimed subdomains MUST be marked as unsigned in the public DNS. > Otherwise, local resolution results would be rejected by validating stubs > that do not implement this specification. > > Section 8: > > I thought we agreed that domains would be code-formatted when not in > quotation marks, but "dns.example.net" is not code-formatted in Steps 1-2 or > Steps 3-5. > > Section 9: > > OLD: > ...unnecessary to prevent leakage... > > NEW: > ...not necessary to prevent leakage... > > Section 11: > > OLD: > The sequence number in the RA PvD Option will be incremented, > > NEW: > The sequence number in the RA PvD Option can be incremented, > > --Ben SchwartzFrom: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> > Sent: Wednesday, January 8, 2025 11:29 AM > To: Ben Schwartz <bem...@meta.com> > Cc: Eric Vyncke (evyncke) <evyn...@cisco.com>; Ben Schwartz > <bemasc=40meta....@dmarc.ietf.org>; kevin.sm...@vodafone.com > <kevin.sm...@vodafone.com>; rfc-edi...@rfc-editor.org > <rfc-edi...@rfc-editor.org>; kond...@gmail.com <kond...@gmail.com>; > danw...@gmail.com <danw...@gmail.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: Re: AUTH48: RFC-to-be 9704 > <draft-ietf-add-split-horizon-authority-14> for your review > > > Hi, Ben. > > We have updated this document per your note below. > > The latest files are posted here. Please refresh your browser: > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.txt__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZutlaSoo$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.pdf__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZWPC2QPA$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZY3878GE$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.xml__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZVW-WnS8$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-diff.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZuH96_i4$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZVFJlCPc$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-auth48diff.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZBuJZcpU$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastdiff.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZlg6olwo$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZ9Y0gVfw$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZfbXlOaw$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html__;!!Bt8RZUm9aw!52D3C6VH_fDIPn3D39TUK_Xs7SipY1fWrJ1T-D07jmRFubmK2hGS4S8ivbIGWmINmyu1J47fC2XgWpWIe1DZHryc7UE$ > > > Please note that my email address has changed from <lbartholo...@amsl.com> to > <lbartholo...@staff.rfc-editor.org>. > > Thank you! > > RFC Editor/lb > > > On Jan 6, 2025, at 12:39 PM, Ben Schwartz <bem...@meta.com> wrote: > > > > > 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. > > > > draft-14: > > This specification relies on securely identified local DNS servers, > > and checks each local domain hint against a globally valid parent > > zone. > > > > OLD: > > 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. > > > > NEW: > > In this specification, network operators securely identify the local DNS > > servers, and clients check each local domain hint against a globally > > valid parent zone. -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
