I think there was a small miscommunication here. I think we intended the following text:
OLD: "A compliant client MAY perform ..." NEW: "The client MAY perform ..." --Ben ________________________________ From: Eric Vyncke (evyncke) <evyn...@cisco.com> Sent: Thursday, January 16, 2025 1:25 AM To: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org>; tirumal reddy <kond...@gmail.com>; Ben Schwartz <bem...@meta.com> Cc: Dan Wing <danw...@gmail.com>; kevin.sm...@vodafone.com <kevin.sm...@vodafone.com>; Ben Schwartz <bem...@meta.com>; Ben Schwartz <bemasc=40meta....@dmarc.ietf.org>; rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; Ben Schwartz <i...@bemasc.net>; add-...@ietf.org <add-...@ietf.org>; add-cha...@ietf.org <add-cha...@ietf.org>; Mohamed Boucadair <mohamed.boucad...@orange.com>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9704 <draft-ietf-add-split-horizon-authority-14> for your review Hello Lynne, I only find a change in a MAY in section 6. 1 s/ Alternatively, a client might perform DNSSEC validation/A compliant client MAY perform DNSSEC validation/. Is it this one you are asking about ? It this is the case, then it is approved. Hello Lynne, I only find a change in a MAY in section 6.1 s/ Alternatively, a client might perform DNSSEC validation/A compliant client MAY perform DNSSEC validation/. Is it this one you are asking about ? It this is the case, then it is approved. Regards -éric From: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> Date: Wednesday, 15 January 2025 at 17:48 To: tirumal reddy <kond...@gmail.com>, Ben Schwartz <bem...@meta.com>, Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: Dan Wing <danw...@gmail.com>, kevin.sm...@vodafone.com <kevin.sm...@vodafone.com>, Ben Schwartz <bem...@meta.com>, Eric Vyncke (evyncke) <evyn...@cisco.com>, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org>, rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Ben Schwartz <i...@bemasc.net>, add-...@ietf.org <add-...@ietf.org>, add-cha...@ietf.org <add-cha...@ietf.org>, Mohamed Boucadair <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, Tiru, Ben, and Éric* * Éric, please let us know if you approve the change from "could" to "MAY". (We have to get AD approval for any changes related to key words from RFC 2119.) Tiru and Ben, we have updated this document per your notes below. Quick follow-up question: Because "PvD" stands for "Provisioning Domain", "using DNR and PvD" reads as "using DNR and Provisioning Domain", which reads a bit oddly. Should "and PvD" be "and PvDs" or "and a PvD"? The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9704.txt<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.txt__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxhI3JX-s$> https://www.rfc-editor.org/authors/rfc9704.pdf<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.pdf__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qx-4m7JHA$> https://www.rfc-editor.org/authors/rfc9704.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxMsVQ9Tk$> https://www.rfc-editor.org/authors/rfc9704.xml<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.xml__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qxi0sPE3M$> https://www.rfc-editor.org/authors/rfc9704-diff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-diff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qxg9eedj4$> https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxUwrYXpI$> https://www.rfc-editor.org/authors/rfc9704-auth48diff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-auth48diff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxMBjEupA$> https://www.rfc-editor.org/authors/rfc9704-lastdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxLPWotJ0$> https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxCdB7-sQ$> https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxhVP0HXk$> https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qx2-r8RFs$> Thank you! RFC Editor/lb > On Jan 15, 2025, at 7:21 AM, tirumal reddy <kond...@gmail.com> wrote: > > > On Wed, 15 Jan 2025 at 8:42 PM, Ben Schwartz <bem...@meta.com> wrote: > > The term "compliant" here seems to imply that the client is adhering to a > > particular specification but it doesn't add meaningful information in this > > context. > > Without "compliant", I think this sentence is potentially ambiguous as to > whether we are describing an acceptable behavior or an unacceptable behavior. > A simpler and clearer (but more invasive) change would be: > > NEW: > The client MAY perform ... > > Sounds good to me. > On Jan 15, 2025, at 7:12 AM, Ben Schwartz <bem...@meta.com> wrote: > >> The term "compliant" here seems to imply that the client is adhering to a >> particular specification but it doesn't add meaningful information in this >> context. > > Without "compliant", I think this sentence is potentially ambiguous as to > whether we are describing an acceptable behavior or an unacceptable behavior. > A simpler and clearer (but more invasive) change would be: > > NEW: > The client MAY perform ... > > --Ben > On Jan 15, 2025, at 1:58 AM, tirumal reddy <kond...@gmail.com> wrote: > > All of the changes look good except for the the following 2 issues: > > 1. > > To ensure that this assumption holds, clients MUST NOT relax the > acceptance rules they would otherwise apply when using this resolver. > For example, if the client would check the Authenticated Data (AD) > bit or validate RRSIGs locally when using this resolver, it must also > do so when resolving TXT records for this purpose. A compliant > client could perform DNSSEC validation for the verification query > even if it has disabled DNSSEC validation for other DNS queries. > > Comment> > > The term "compliant" here seems to imply that the client is adhering to a > particular specification but it doesn't add meaningful information in this > context. We are not explicitly talking about compliance with the DNSSEC > standard, but rather the behavior of the client in a specific situation. We > are proposing that clients who have disabled DNSSEC validation for some > reason (e.g, performance) could enable DNSSEC but only for the verification > query. > > 2. > > OLD: > *Steps 1-2*: The client determines the network's DNS server > (dns.example.net) and PvD ID (pvd.example.com) using DNR and one > of the following: DNR Router Solicitation, DHCPv4, or DHCPv6. > NEW: > *Steps 1-2*: The client determines the network's DNS server > (dns.example.net) and PvD ID (pvd.example.com) using DNR and PvD, along > with one of > the following: DNR Router Solicitation, DHCPv4, or DHCPv6. > > Cheers, > -Tiru > > On Tue, 14 Jan 2025 at 22:00, Lynne Bartholomew > <lbartholo...@staff.rfc-editor.org> wrote: > Hi, Dan and Kevin. > > Dan, we have updated your contact information per your note below. > > We have noted both of your approvals on the AUTH48 status page: > > > https://www.rfc-editor.org/auth48/rfc9704<https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9704__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxCRiqflE$> > > The latest files are posted here. Please refresh your browser: > > > https://www.rfc-editor.org/authors/rfc9704.txt<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.txt__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxhI3JX-s$> > > https://www.rfc-editor.org/authors/rfc9704.pdf<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.pdf__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qx-4m7JHA$> > > https://www.rfc-editor.org/authors/rfc9704.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxMsVQ9Tk$> > > https://www.rfc-editor.org/authors/rfc9704.xml<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.xml__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qxi0sPE3M$> > > https://www.rfc-editor.org/authors/rfc9704-diff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-diff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qxg9eedj4$> > > https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxUwrYXpI$> > > https://www.rfc-editor.org/authors/rfc9704-auth48diff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-auth48diff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxMBjEupA$> > > https://www.rfc-editor.org/authors/rfc9704-lastdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxLPWotJ0$> > > https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxCdB7-sQ$> > > > https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxhVP0HXk$> > > https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qx2-r8RFs$> > > Thank you! > > RFC Editor/lb > > > On Jan 14, 2025, at 2:29 AM, Kevin Smith, Vodafone > > <kevin.sm...@vodafone.com> wrote: > > > > Please also mark me as Approved – and thanks to all. > > Kevin > > > On Jan 13, 2025, at 2:45 PM, Dan Wing <danw...@gmail.com> wrote: > > > > One minor change -- please remove the street address for my contact > > information, as we just closed that building in Santa Clara, so: > > > > OLD: > > Dan Wing > > Citrix Systems, Inc. > > 4988 Great America Pkwy > > Santa Clara, CA 95054 > > United States of America > > Email: danw...@gmail.com > > > > NEW: > > Dan Wing > > Citrix Systems, Inc. > > United States of America > > Email: danw...@gmail.com > > > > > > > > The existing title page abbreviation for my employer is fine as-is > > ("Citrix"). > > > > With that, please mark me as Approved. > > > > Thanks! > > -d > > > > > >> On Jan 13, 2025, at 10:23 AM, Lynne Bartholomew > >> <lbartholo...@staff.rfc-editor.org> wrote: > >> > >> Hi, Ben and Éric. > >> > >> Ben, we have further updated this document per your note below. > >> > >> Éric, we have noted your approval for the updates to Section 7 on the > >> AUTH48 status page: > >> > >> > >> https://www.rfc-editor.org/auth48/rfc9704<https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9704__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxCRiqflE$> > >> > >> The latest files are posted here. Please refresh your browser: > >> > >> > >> https://www.rfc-editor.org/authors/rfc9704.txt<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.txt__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxhI3JX-s$> > >> > >> https://www.rfc-editor.org/authors/rfc9704.pdf<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.pdf__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qx-4m7JHA$> > >> > >> https://www.rfc-editor.org/authors/rfc9704.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxMsVQ9Tk$> > >> > >> https://www.rfc-editor.org/authors/rfc9704.xml<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704.xml__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qxi0sPE3M$> > >> > >> https://www.rfc-editor.org/authors/rfc9704-diff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-diff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qxg9eedj4$> > >> > >> https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxUwrYXpI$> > >> > >> https://www.rfc-editor.org/authors/rfc9704-auth48diff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-auth48diff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxMBjEupA$> > >> > >> https://www.rfc-editor.org/authors/rfc9704-lastdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxLPWotJ0$> > >> > >> https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxCdB7-sQ$> > >> > >> > >> https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6QxhVP0HXk$> > >> > >> https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html<https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9704-xmldiff2.html__;!!Bt8RZUm9aw!4WfLtmLvtFTJkDEu8YQK1dlhFBpHyiy6pO4T7MfwXwytjqJ7BNqXdbKaT1hMpzOPH6Qx2-r8RFs$> > >> > >> Thank you! > >> > >> RFC Editor/lb > >> > >> > >>> On Jan 10, 2025, at 8:24 AM, Eric Vyncke (evyncke) <evyn...@cisco.com> > >>> wrote: > >>> > >>> 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 > >> > >>> On Jan 10, 2025, at 7:31 AM, Ben Schwartz <bem...@meta.com> wrote: > >>> > >>>>> 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. > >>> > >>> Sentence-fragment style is fine, but I find the adjusted text hard to > >>> parse. Let's try this change: > >>> > >>> OLD: > >>> A split-horizon configuration that 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: > >>> A split-horizon configuration that is authorized by the parents of the > >>> affected names and confirmed by the client. > >>> > >>> --Ben > >> > >> > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
