Hello Lynne, The changes in section 7 are indeed borderline between technical and editorial, but they respect my view of the IETF/ADD WG consensus. I.e., I approve these changes.
Regards -éric From: Lynne Bartholomew <[email protected]> Date: Thursday, 9 January 2025 at 20:48 To: Ben Schwartz <[email protected]>, Eric Vyncke (evyncke) <[email protected]> Cc: Ben Schwartz <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: *[AD] Re: AUTH48: RFC-to-be 9704 <draft-ietf-add-split-horizon-authority-14> for your review 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 <[email protected]> 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 <[email protected]> > Sent: Wednesday, January 8, 2025 11:29 AM > To: Ben Schwartz <[email protected]> > Cc: Eric Vyncke (evyncke) <[email protected]>; Ben Schwartz > <[email protected]>; [email protected] > <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] > <[email protected]>; [email protected] > <[email protected]> > 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.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.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.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.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-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-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-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-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-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-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$<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 <[email protected]> to > <[email protected]>. > > Thank you! > > RFC Editor/lb > > > On Jan 6, 2025, at 12:39 PM, Ben Schwartz <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
