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
