Re: [auth48] AUTH48: RFC-to-be 9540 <draft-ietf-ohai-svcb-config-07> for your review

[tirumal reddy <[e-mail]>]

Update looks good. I approve publication of the document.

Best Regards,
-Tiru

On Wed, 7 Feb 2024 at 05:37, Lynne Bartholomew <[e-mail]>
wrote:

> Hi, Tommy.
>
> We have made the two updates indicated in your note below.  The latest
> files are here; please refresh your browser:
>
>    https://www.rfc-editor.org/authors/rfc9540.txt
>    https://www.rfc-editor.org/authors/rfc9540.pdf
>    https://www.rfc-editor.org/authors/rfc9540.html
>    https://www.rfc-editor.org/authors/rfc9540.xml
>    https://www.rfc-editor.org/authors/rfc9540-diff.html
>    https://www.rfc-editor.org/authors/rfc9540-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9540-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9540-lastdiff.html
>    https://www.rfc-editor.org/authors/rfc9540-lastrfcdiff.html
>
>    https://www.rfc-editor.org/authors/rfc9540-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9540-xmldiff2.html
>
> Thank you!
>
> RFC Editor/lb
>
> > On Feb 6, 2024, at 10:17 AM, Tommy Pauly <[e-mail]> wrote:
> >
> >
> >
> >> On Feb 6, 2024, at 9:59 AM, Lynne Bartholomew <[e-mail]>
> wrote:
> >>
> >> Hi, Tommy.
> >>
> >> Thank you for your replies to our questions!
> >>
> >> A follow-up question for you:
> >>
> >> Apologies for not spotting this earlier.  Do the two instances of
> "gateway and target resources" mean "Gateway Resources and Target
> Resources"?  With the latest updates, we now have two instances of "gateway
> and Target Resources".  (We also see the more general "gateway and target"
> in Sections 1 and 4.2.1.)
> >
> > Saying "gateway and target resources” does expand to "Gateway Resources
> and Target Resources”, yes. I would still prefer to say "Gateway and Target
> Resources”, with that capitalization.
> >
> > Thanks,
> > Tommy
> >>
> >> The latest files are posted here.  Please refresh your browser:
> >>
> >>  https://www.rfc-editor.org/authors/rfc9540.txt
> >>  https://www.rfc-editor.org/authors/rfc9540.pdf
> >>  https://www.rfc-editor.org/authors/rfc9540.html
> >>  https://www.rfc-editor.org/authors/rfc9540.xml
> >>  https://www.rfc-editor.org/authors/rfc9540-diff.html
> >>  https://www.rfc-editor.org/authors/rfc9540-rfcdiff.html
> >>  https://www.rfc-editor.org/authors/rfc9540-auth48diff.html
> >>
> >>  https://www.rfc-editor.org/authors/rfc9540-xmldiff1.html
> >>  https://www.rfc-editor.org/authors/rfc9540-xmldiff2.html
> >>
> >> Thanks again!
> >>
> >> RFC Editor/lb
> >>
> >>
> >>> On Feb 5, 2024, at 3:39 PM, Tommy Pauly <tpauly=
> [e-mail]> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Thank you for the edits!
> >>>
> >>> Looking at the changes, please revert the addition of “<“ and “>”
> around "svc.example.com" and "
> https://svc.example.com/.well-known/ohttp-gateway”. These can be quoted
> or put in code-font instead. The other changes look good to me.
> >>>
> >>> Responses to your questions are inline below:
> >>>
> >>>> On Feb 1, 2024, at 4:23 PM, [e-mail] wrote:
> >>>>
> >>>> Authors,
> >>>>
> >>>> While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >>>>
> >>>> 1) <!-- [rfced] Datatracker "idnits" output for the original approved
> >>>> document included the following warning.  Although an author recently
> >>>> referred to the lines indicated in this warning as "false positives",
> >>>> please let us know if any changes are needed as related to this
> >>>> warning:
> >>>>
> >>>> == There are 2 instances of lines with non-RFC2606-compliant FQDNs in
> >>>>  the document. -->
> >>>
> >>> I don’t see any actual issues here. This looks like a false positive.
> >>>
> >>>>
> >>>>
> >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear
> in the
> >>>> title) for use on <https://www.rfc-editor.org/search>. -->
> >>>
> >>> We can add:
> >>>
> >>> - DNS
> >>> - Oblivious HTTP
> >>> - SVCB
> >>>
> >>>>
> >>>>
> >>>> 3) <!-- [rfced] Abstract and Introduction:  Would you like to expand
> >>>> "SVCB" as "Service Binding (SVCB)" per RFCs 9462 and 9463?
> >>>>
> >>>> Original:
> >>>> This document defines a parameter that can be included in SVCB and
> >>>> HTTPS DNS resource records to denote that a service is accessible
> >>>> using Oblivious HTTP, by offering an Oblivious Gateway Resource
> >>>> through which to access the target.
> >>>> ...
> >>>> This
> >>>> advertisement is a parameter that can be included in SVCB and HTTPS
> >>>> DNS RRs [SVCB] (Section 4). -->
> >>>
> >>> Yes, please expand these cases as suggested.
> >>>>
> >>>>
> >>>> 4) <!-- [rfced] Sections 1 and subsequent:  We see that this document
> >>>> lists draft-ietf-ohai-ohttp (RFC 9458) as a Normative Reference.
> >>>> RFC 9458 uses "Target Resource" throughout, even when used generally.
> >>>> Should the instances of "target resource" in this document be changed
> >>>> to "Target Resource"?
> >>>>
> >>>> Original:
> >>>> This means that for deployments that support
> >>>> this kind of discovery, the gateway and target resources need to be
> >>>> located on the same host.
> >>>> ...
> >>>> The service that is queried by the client hosts one or more
> >>>> target resources.
> >>>>
> >>>> In order to access the service's target resources using Oblivious
> >>>> HTTP, the client needs to send encapsulated messages to the gateway
> >>>> resource and the gateway's key configuration (both of which can be
> >>>> retrieved using the method described in Section 6).
> >>>> ...
> >>>> Since the gateway and target resources for discovered
> >>>> oblivious services need to be on the same host, this means that the
> >>>> client needs to verify that the certificate presented by the gateway
> >>>> passes the required checks.
> >>>> ...
> >>>> This document defines a well-known resource ([WELLKNOWN]), "/.well-
> >>>> known/ohttp-gateway", which is an Oblivious Gateway Resource
> >>>> available on the same host as the target resource. -->
> >>>
> >>> Yes, please capitalize instances of “Target Resource”. Please do the
> same for “Gateway Resource”.
> >>>>
> >>>>
> >>>> 5) <!-- [rfced] Section 3:  We only see two models listed after this
> >>>> sentence.  Although we see that "multiple" can mean "more than one",
> >>>> are only two models possible here (in which case "two models" might
> >>>> be clearer), or do the two models here provide two examples among
> >>>> several other possible models?
> >>>>
> >>>> Original:
> >>>> There are multiple models in which the discovery mechanism defined in
> >>>> this document can be used.
> >>>> ...
> >>>> In both deployment models, the client is configured with a relay that
> >>>> it trusts for Oblivious HTTP transactions.
> >>>>
> >>>> Perhaps (if more than two models are possible):
> >>>> There are multiple models in which the discovery mechanism defined in
> >>>> this document can be used.  For example:
> >>>> ...
> >>>> In both example deployment models, the client is configured with a
> >>>> relay that it trusts for Oblivious HTTP transactions. -->
> >>>
> >>> How about this:
> >>>
> >>> There are multiple models in which the discovery mechanism defined in
> >>> this document can be used.  These include:
> >>> ...
> >>> In both of these deployment models, the client is configured with a
> >>> relay that it trusts for Oblivious HTTP transactions.
> >>>
> >>>>
> >>>>
> >>>> 6) <!-- [rfced] Sections 4.1 and 6:  Should instances of "example.com
> "
> >>>> be "example.net"?  We ask because we see "doh.example.net" in
> >>>> Section 4.2.1.
> >>>>
> >>>> Original:
> >>>> For example, an HTTPS service RR for svc.example.com that supports
> >>>> Oblivious HTTP could look like this:
> >>>>
> >>>> svc.example.com. 7200  IN HTTPS 1 . ( alpn=h2 ohttp )
> >>>>
> >>>> A similar RR for a service that only supports Oblivious HTTP could
> >>>> look like this:
> >>>>
> >>>> svc.example.com. 7200  IN HTTPS 1 . ( mandatory=ohttp ohttp )
> >>>> ...
> >>>> For example, if the client knows an oblivious gateway URI,
> >>>> "https://svc.example.com/.well-known/ohttp-gateway", it could fetch
> >>>> the key configuration with the following request:
> >>>>
> >>>> GET /.well-known/ohttp-gateway HTTP/1.1
> >>>> Host: svc.example.com
> >>>> Accept: application/ohttp-keys -->
> >>>
> >>> No, there isn’t any need to change any of these. Please leave the
> example hostnames as they are.
> >>> There is intentionally not a relationship between those two examples.
> >>>>
> >>>>
> >>>> 7) <!-- [rfced] Please review each artwork element.  Should any of the
> >>>> artwork elements be tagged as sourcecode?  Please see
> >>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.
> >>>>
> >>>> If the current list of preferred values for "type" on
> >>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt> does not
> >>>> contain an applicable type, please let us know.  Also, it is
> >>>> acceptable to leave the "type" attribute not set. -->
> >>>
> >>> None of these types are source code. We can leave these all as not set.
> >>>>
> >>>>
> >>>> 8) <!-- [rfced] Section 4.2:  As RFC 8484 defines DoH as "DNS over
> >>>> HTTPS" and discusses "DNS over HTTP" in terms of "previous work", we
> >>>> changed "HTTP" to "HTTPS" in this sentence accordingly (hyphenated,
> >>>> as the term is in attributive position).  Please let us know any
> >>>> objections.
> >>>>
> >>>> Original:
> >>>> For the "dns" scheme, as defined in [DNS-SVCB], the presence of the
> >>>> "ohttp" parameter means that the DNS server being described has a DNS
> >>>> over HTTP (DoH) [DOH] service that can be accessed using Oblivious
> >>>> HTTP.
> >>>>
> >>>> Currently:
> >>>> For the "dns" scheme, as defined in [DNS-SVCB], the presence of the
> >>>> "ohttp" parameter means that the DNS server being described has a
> >>>> DNS-over-HTTPS (DoH) service [DOH] that can be accessed using
> >>>> Oblivious HTTP. -->
> >>>
> >>> This change looks correct, thanks.
> >>>>
> >>>>
> >>>> 9) <!-- [rfced] Section 4.2.1:  Should "a DoH recursive resolvers
> >>>> support" be "a DoH recursive resolver supports" or "DoH recursive
> >>>> resolvers support"?
> >>>>
> >>>> Original:
> >>>> Clients can discover that a DoH recursive resolvers support Oblivious
> >>>> HTTP using DDR, either by querying _dns.resolver.arpa to a locally
> >>>> configured resolver or by querying using the name of a resolver
> >>>> [DDR]. -->
> >>>
> >>> This should be "a DoH recursive resolver supports”.
> >>>>
> >>>>
> >>>>
> >>>> 10) <!-- [rfced] Section 4.2.1:
> >>>>
> >>>> a) Should "oblivious DoH" be "Oblivious DoH" per RFC 9230 and per
> >>>> "Oblivious HTTP" used elsewhere in this document?  Although this
> >>>> document does not cite RFC 9230, we ask because we could not find
> >>>> "oblivious DoH" in any published RFC.
> >>>>
> >>>> This question also applies to one instance each of "oblivious DoH" in
> >>>> Sections 7 and 7.2.
> >>>>
> >>>> Original:
> >>>> Clients still need to perform verification of oblivious DoH servers,
> >>>> specifically the TLS certificate checks described in Section 4.2 of
> >>>> [DDR].
> >>>
> >>> No, this should not be capitalized and does not refer to RFC 9230.
> These are DoH servers that are available over Oblivious HTTP. If anything,
> they would be “DoOH” (DNS-over-Oblivious-HTTP) servers.
> >>>>
> >>>> b) Does "which" in this sentence refer to the checks or the
> >>>> configuration lookup?
> >>>>
> >>>> Original:
> >>>> These checks can be performed when
> >>>> looking up the configuration on the gateway as described in
> >>>> Section 6, which can either be done directly or via the relay or
> >>>> another proxy to avoid exposing client IP addresses. -->
> >>>
> >>> It refers to the checks, since a check can be “done”/“performed”, but
> a configuration cannot.
> >>>>
> >>>>
> >>>> 11) <!-- [rfced] Section 4.2.1:  Does "but cannot use
> >>>> certificate-based validation" refer to the configuration or the
> >>>> resolver?
> >>>>
> >>>> Original:
> >>>> If a configuration occurs where the resolver is accessible,
> >>>> but cannot use certificate-based validation, the client MUST ensure
> >>>> that the relay only accesses the gateway and target using the
> >>>> unencrypted resolver's original IP address.
> >>>>
> >>>> Perhaps (if the resolver, remove the comma):
> >>>> If a configuration occurs where the resolver is accessible
> >>>> but cannot use certificate-based validation, the client MUST ensure
> >>>> that the relay only accesses the gateway and target using the
> >>>> unencrypted resolver's original IP address.
> >>>>
> >>>> Or possibly (if the configuration, rephrase):
> >>>> If a configuration occurs where the resolver is accessible
> >>>> but the configuration cannot use certificate-based validation, the
> >>>> client MUST ensure that the relay only accesses the gateway and
> >>>> target using the unencrypted resolver's original IP address. -->
> >>>
> >>> It refers to the resolver, not the configuration. We can remove the
> comma, like the middle option suggests.
> >>>>
> >>>>
> >>>> 12) <!-- [rfced] Section 4.2.2:  We only see one SvcParamKey - the
> >>>> "ohttp" SvcParamKey - defined in this document.  Should
> >>>> "SvcParamKeys" be "SvcParamKey"?
> >>>>
> >>>> Original:
> >>>> The SvcParamKeys defined in this document also can be used with
> >>>> Discovery of Network-designated Resolvers (DNR) [DNR]. -->
> >>>
> >>> Yes, please change!
> >>>>
> >>>>
> >>>> 13) <!-- [rfced] Section 6:  Should "oblivious gateway URI" be
> "Oblivious
> >>>> Gateway URI", per "Oblivious Gateway Resource" used elsewhere in this
> >>>> document?
> >>>>
> >>>> Original:
> >>>> For example, if the client knows an oblivious gateway URI,
> >>>> "https://svc.example.com/.well-known/ohttp-gateway", it could fetch
> >>>> the key configuration with the following request: -->
> >>>
> >>> Yes, this should be capitalized.
> >>>>
> >>>>
> >>>> 14) <!--[rfced] Section 8.1: FYI, we have added the "Change
> Controller"
> >>>> column with "IETF" as the entry in Table 1 to match what appears in
> >>>> the IANA registry at <https://www.iana.org/assignments/dns-svcb/>.
> >>>> -->
> >>>
> >>> Thanks, that looks good.
> >>>>
> >>>>
> >>>> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the
> >>>> online Style Guide at
> >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> >>>> and let us know if any changes are needed.
> >>>>
> >>>> Note that our script did not flag any words in particular, but this
> >>>> should still be reviewed as a best practice. -->
> >>>
> >>> No changes needed, thanks.
> >>>
> >>> Best,
> >>> Tommy
> >>>>
> >>>>
> >>>> Thank you.
> >>>>
> >>>> RFC Editor/lb/ap
> >>>>
> >>>>
> >>>> On Feb 1, 2024, at 4:22 PM, [e-mail] wrote:
> >>>>
> >>>> *****IMPORTANT*****
> >>>>
> >>>> Updated 2024/02/01
> >>>>
> >>>> RFC Author(s):
> >>>> --------------
> >>>>
> >>>> Instructions for Completing AUTH48
> >>>>
> >>>> Your document has now entered AUTH48.  Once it has been reviewed and
> >>>> approved by you and all coauthors, it will be published as an RFC.
> >>>> If an author is no longer available, there are several remedies
> >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>
> >>>> You and you coauthors are responsible for engaging other parties
> >>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>> your approval.
> >>>>
> >>>> Planning your review
> >>>> ---------------------
> >>>>
> >>>> Please review the following aspects of your document:
> >>>>
> >>>> *  RFC Editor questions
> >>>>
> >>>> Please review and resolve any questions raised by the RFC Editor
> >>>> that have been included in the XML file as comments marked as
> >>>> follows:
> >>>>
> >>>> <!-- [rfced] ... -->
> >>>>
> >>>> These questions will also be sent in a subsequent email.
> >>>>
> >>>> *  Changes submitted by coauthors
> >>>>
> >>>> Please ensure that you review any changes submitted by your
> >>>> coauthors.  We assume that if you do not speak up that you
> >>>> agree to changes submitted by your coauthors.
> >>>>
> >>>> *  Content
> >>>>
> >>>> Please review the full content of the document, as this cannot
> >>>> change once the RFC is published.  Please pay particular attention to:
> >>>> - IANA considerations updates (if applicable)
> >>>> - contact information
> >>>> - references
> >>>>
> >>>> *  Copyright notices and legends
> >>>>
> >>>> Please review the copyright notice and legends as defined in
> >>>> RFC 5378 and the Trust Legal Provisions
> >>>> (TLP – https://trustee.ietf.org/license-info/).
> >>>>
> >>>> *  Semantic markup
> >>>>
> >>>> Please review the markup in the XML file to ensure that elements of
> >>>> content are correctly tagged.  For example, ensure that <sourcecode>
> >>>> and <artwork> are set correctly.  See details at
> >>>> <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>>
> >>>> *  Formatted output
> >>>>
> >>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>> formatted output, as generated from the markup in the XML file, is
> >>>> reasonable.  Please note that the TXT will have formatting
> >>>> limitations compared to the PDF and HTML.
> >>>>
> >>>>
> >>>> Submitting changes
> >>>> ------------------
> >>>>
> >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
> all
> >>>> the parties CCed on this message need to see your changes. The
> parties
> >>>> include:
> >>>>
> >>>> *  your coauthors
> >>>>
> >>>> *  [e-mail] (the RPC team)
> >>>>
> >>>> *  other document participants, depending on the stream (e.g.,
> >>>>    IETF Stream participants are your working group chairs, the
> >>>>    responsible ADs, and the document shepherd).
> >>>>
> >>>> *  [e-mail], which is a new archival mailing
> list
> >>>>    to preserve AUTH48 conversations; it is not an active discussion
> >>>>    list:
> >>>>
> >>>>   *  More info:
> >>>>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>>>
> >>>>   *  The archive itself:
> >>>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>>
> >>>>   *  Note: If only absolutely necessary, you may temporarily opt out
> >>>>      of the archiving of messages (e.g., to discuss a sensitive
> matter).
> >>>>      If needed, please add a note at the top of the message that you
> >>>>      have dropped the address. When the discussion is concluded,
> >>>>      [e-mail] will be re-added to the CC list
> and
> >>>>      its addition will be noted at the top of the message.
> >>>>
> >>>> You may submit your changes in one of two ways:
> >>>>
> >>>> An update to the provided XML file
> >>>> — OR —
> >>>> An explicit list of changes in this format
> >>>>
> >>>> Section # (or indicate Global)
> >>>>
> >>>> OLD:
> >>>> old text
> >>>>
> >>>> NEW:
> >>>> new text
> >>>>
> >>>> You do not need to reply with both an updated XML file and an
> explicit
> >>>> list of changes, as either form is sufficient.
> >>>>
> >>>> We will ask a stream manager to review and approve any changes that
> seem
> >>>> beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> >>>> and technical changes.  Information about stream managers can be
> found in
> >>>> the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >>>>
> >>>>
> >>>> Approving for publication
> >>>> --------------------------
> >>>>
> >>>> To approve your RFC for publication, please reply to this email
> stating
> >>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> >>>> as all the parties CCed on this message need to see your approval.
> >>>>
> >>>>
> >>>> Files
> >>>> -----
> >>>>
> >>>> The files are available here:
> >>>> https://www.rfc-editor.org/authors/rfc9540.xml
> >>>> https://www.rfc-editor.org/authors/rfc9540.html
> >>>> https://www.rfc-editor.org/authors/rfc9540.pdf
> >>>> https://www.rfc-editor.org/authors/rfc9540.txt
> >>>>
> >>>> Diff file of the text:
> >>>> https://www.rfc-editor.org/authors/rfc9540-diff.html
> >>>> https://www.rfc-editor.org/authors/rfc9540-rfcdiff.html (side by
> side)
> >>>>
> >>>> Diff of the XML:
> >>>> https://www.rfc-editor.org/authors/rfc9540-xmldiff1.html
> >>>>
> >>>>
> >>>> Tracking progress
> >>>> -----------------
> >>>>
> >>>> The details of the AUTH48 status of your document are here:
> >>>> https://www.rfc-editor.org/auth48/rfc9540
> >>>>
> >>>> Please let us know if you have any questions.
> >>>>
> >>>> Thank you for your cooperation,
> >>>>
> >>>> RFC Editor
> >>>>
> >>>> --------------------------------------
> >>>> RFC9540 (draft-ietf-ohai-svcb-config-07)
> >>>>
> >>>> Title            : Discovery of Oblivious Services via Service
> Binding Records
> >>>> Author(s)        : T. Pauly, T. Reddy.K
> >>>> WG Chair(s)      : Richard Barnes, Shivan Kaul Sahib
> >>>> Area Director(s) : Roman Danyliw, Paul Wouters
> >>>>
> >>>>
> >>>
> >>
> >
>
>