Thank you for the changes. The update looks good to me and I approve the publication.
Cheers, -Tiru On Thu, 16 Jan 2025 at 22:29, Lynne Bartholomew < lbartholo...@staff.rfc-editor.org> wrote: > Hi, Tiru, Ben, and Éric. > > Tiru and Ben, we have further updated this document per your notes below. > Ben, no miscommunication; apologies for missing the change from "A > compliant" to "The" earlier. > > Éric, yes, we were asking about the last sentence in Section 6.1. > Apologies for not being clearer. We have noted your renewed approval on > the AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9704 > > 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 (side by side) > https://www.rfc-editor.org/authors/rfc9704-auth48diff.html > https://www.rfc-editor.org/authors/rfc9704-auth48rfcdiff.html (side by > side) > https://www.rfc-editor.org/authors/rfc9704-lastdiff.html > https://www.rfc-editor.org/authors/rfc9704-lastrfcdiff.html (side by > side) > > 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 16, 2025, at 5:51 AM, Ben Schwartz <bem...@meta.com> wrote: > > > > 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 > > > > On Jan 15, 2025, at 10:25 PM, Eric Vyncke (evyncke) <evyn...@cisco.com> > wrote: > > > > 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 > > > On Jan 15, 2025, at 9:57 PM, tirumal reddy <kond...@gmail.com> wrote: > > > > On Wed, 15 Jan 2025 at 22:18, Lynne Bartholomew < > lbartholo...@staff.rfc-editor.org> wrote: > >> 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"? > > > > Please proceed with "a PvD". > > > >> 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 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 > > > > > > 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 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 > > > >> > > > >> 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 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
