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

[Lynne Bartholomew <[e-mail]>]

Hi, Tiru.

We have noted your approval on the AUTH48 status page:

   https://www.rfc-editor.org/auth48/rfc9540

As we have approvals from both of you, we will prepare this document for publication shortly.

Thank you!

RFC Editor/lb

> On Feb 6, 2024, at 8:50 PM, tirumal reddy <[e-mail]> wrote:
> 
> 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
> >>>> 
> >>>> 
> >>> 
> >> 
> > 
>