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.
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 Schwartz
________________________________
From: 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
