Re: [auth48] AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Ben.  Great; thanks!

RFC Editor/lb

> On Oct 18, 2023, at 12:26 PM, Ben Schwartz <[e-mail]> wrote:
> 
> Correct.
> 
> From: Lynne Bartholomew <[e-mail]>
> Sent: Wednesday, October 18, 2023 2:26 PM
> To: Ben Schwartz <[e-mail]>
> Cc: Mike Bishop <[e-mail]>; Erik Nygren <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
>  !-------------------------------------------------------------------|
>   This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> Hi, Ben.
> 
> Just to confirm -- 'replace the "Reference" column that IANA added' means 'change IANA's "Format Reference" column heading to "Reference"; correct?
> 
> Thank you!
> 
> RFC Editor/lb
> 
> > On Oct 18, 2023, at 11:17 AM, Ben Schwartz <[e-mail]> wrote:
> > 
> > That's correct.  This will replace the "Reference" column that IANA added for compliance with their usual processes.
> > 
> > --Ben SchwartzFrom: Lynne Bartholomew <[e-mail]>
> > Sent: Wednesday, October 18, 2023 1:34 PM
> > To: Mike Bishop <[e-mail]>
> > Cc: Erik Nygren <[e-mail]>; Ben Schwartz <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]<[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> > Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
> >  !-------------------------------------------------------------------|
> >   This Message Is From an External Sender
> > 
> > |-------------------------------------------------------------------!
> > 
> > Hi, Mike.  So noted:
> > 
> >    https://www.rfc-editor.org/auth48/rfc9460  
> > 
> > Before we ask IANA to make updates per changes made to this document, we first want to confirm that, per AUTH48 XML updates that you sent us on 26 September, we also need to ask for the following change on <https://www.iana.org/assignments/dns-svcb/ >:
> > 
> > OLD (column name):
> > Format Reference
> > 
> > NEW:
> > Reference
> > 
> > Please let us know about the above.  We will wait to hear from you before proceeding.
> > 
> > Thank you!
> > 
> > RFC Editor/lb
> > 
> > > On Oct 17, 2023, at 12:52 PM, Mike Bishop <[e-mail]> wrote:
> > > 
> > > Approved -- thanks to everyone for their work on this.
> > > 
> > > -----Original Message-----
> > > From: Lynne Bartholomew <[e-mail]> 
> > > Sent: Monday, October 16, 2023 11:30 AM
> > > To: Erik Nygren <[e-mail]>
> > > Cc: Ben Schwartz <[e-mail]>; Mike Bishop <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> > > Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
> > > 
> > > Hi, Erik.  Thank you for confirming your approval!
> > > 
> > > RFC Editor/lb
> > > 
> > >> On Oct 15, 2023, at 6:45 AM, Erik Nygren <[e-mail]> wrote:
> > >> 
> > >> I just looked at the latest and it looks good to me.
> > >> 
> > >> Thanks!  Erik
> > >> 
> > >> On Fri, Oct 13, 2023 at 5:53 PM Lynne Bartholomew <[e-mail]> wrote:
> > >> Hi, Erik, Ben, and Mike.
> > >> 
> > >> Ben and Mike, we have made further updates to this document per your notes below.
> > >> 
> > >> The latest files are posted here (please refresh your browser):
> > >> 
> > >>   https://www.rfc-editor.org/authors/rfc9460.txt  
> > >>   https://www.rfc-editor.org/authors/rfc9460.pdf  
> > >>   https://www.rfc-editor.org/authors/rfc9460.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460.xml  
> > >>   https://www.rfc-editor.org/authors/rfc9460-diff.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460-auth48diff.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460-lastdiff.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460-lastrfcdiff.html  
> > >> 
> > >>   https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html  
> > >>   https://www.rfc-editor.org/authors/rfc9460-alt-diff.html  
> > >> 
> > >> Erik and Ben, we have noted your approvals on the AUTH48 status page.  Please note, however, that if you object to any subsequent updates to this document you will let us know:
> > >> 
> > >>   https://www.rfc-editor.org/auth48/rfc9460  
> > >> 
> > >> Thank you!
> > >> 
> > >> RFC Editor/lb
> > >> 
> > >>> On Oct 12, 2023, at 2:05 PM, Mike Bishop <[e-mail]> wrote:
> > >>> 
> > >>> I’ve finished my final read-through.  These are minor issues, and everything else looks fine.
> > >>> 
> > >>> I caught a few uses of the first-person through the document.  I suggest:
> > >>> 
> > >>> • Section 1.3: “Our terminology…” => “Terminology in this document…”
> > >>> 
> > >>> • Section 2.3:  “We term this behavior "Port Prefix Naming" and use it in the examples throughout this document.” => “This document terms this behavior "Port Prefix Naming" and uses it in the examples throughout.”
> > >>> 
> > >>> • Appendix A: “Here, we summarize…” => “The following summarizes…”
> > >>> 
> > >>> • Appendix C: “…by providing an extensible solution that solves multiple problems we will overcome this inertia…” => “…an extensible solution that solves multiple problems will overcome this inertia…”
> > >>> 
> > >>> There is a nested parenthetical in 2.3.  I suggest the following:
> > >>> 
> > >>> Current:
> > >>> (Parentheses are used to ignore a line break in DNS zone-file presentation format ([RFC1035], Section 5.1).)
> > >>> 
> > >>> Proposed:
> > >>> (Parentheses are used to ignore a line break in DNS zone-file presentation format, per Section 5.1 of [RFC1035].)
> > >> 
> > >> 
> > >>> On Oct 11, 2023, at 10:51 AM, Ben Schwartz <[e-mail]> wrote:
> > >>> 
> > >>> The caption of Figure 10 is 'An alpn Value with ...'.  I believe "alpn" should be quoted for consistency, resulting in 'An "alpn" Value with ...".
> > >>> 
> > >>> Apart from that suggestion, I approve this version for publication.
> > >>> 
> > >>> --Ben Schwartz
> > >> 
> > >>> On Oct 11, 2023, at 10:34 AM, Erik Nygren <[e-mail]> wrote:
> > >>> 
> > >>> Approved from my perspective!  (Assuming no objections from Mike or Ben.)
> > >>> 
> > >>> Best, Erik
> > >>> 
> > >>> 
> > >>> On Wed, Oct 11, 2023 at 12:11 PM Lynne Bartholomew <[e-mail]> wrote:
> > >>> Hi, Erik.
> > >>> 
> > >>> We have updated this document per your note below.
> > >>> 
> > >>> The latest files are posted here (please refresh your browser):
> > >>> 
> > >>>   https://www.rfc-editor.org/authors/rfc9460.txt  
> > >>>   https://www.rfc-editor.org/authors/rfc9460.pdf  
> > >>>   https://www.rfc-editor.org/authors/rfc9460.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460.xml  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-diff.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-auth48diff.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-lastdiff.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-lastrfcdiff.html  
> > >>> 
> > >>>   https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html  
> > >>>   https://www.rfc-editor.org/authors/rfc9460-alt-diff.html  
> > >>> 
> > >>> We will wait to hear from your coauthors regarding any subsequent changes before noting anyone's approval.
> > >>> 
> > >>> Thank you!
> > >>> 
> > >>> RFC Editor/lb
> > >>> 
> > >>>> On Oct 10, 2023, at 2:13 PM, Erik Nygren <[e-mail]> wrote:
> > >>>> 
> > >>>> I took a final reading pass through and the only thing that jumped out would be to change this:
> > >>>> 
> > >>>> - "," and "\" characters instead of implementing the <tt>value-list</tt> escaping
> > >>>> + "," and "\" characters in ALPN IDs instead of implementing the <tt>value-list</tt> escaping
> > >>>> 
> > >>>> The current text is ambiguous as to whether those characters are prohibited in ALPN IDs or prohibited in value-list.
> > >>>> It is clear that the intent is for them to only be prohibited in ALPN IDs so that value-list can contain commas, 
> > >>>> but inserting the "in ALPN IDs" would reduce risk of misreading.
> > >>>> Everything else looks good.
> > >>>> 
> > >>>> I believe Mike and Ben are making similar read-throughs.
> > >>>> 
> > >>>> Thanks, Erik
> > >>>> 
> > >>>> 
> > >>>> 
> > >>>> 
> > >>>> 
> > >>>> On Fri, Oct 6, 2023 at 4:30 PM Mike Bishop <[e-mail]> wrote:
> > >>>> Ben proposed this text on GitHub:
> > >>>> 
> > >>>> In this document, this algorithm is referred to as "character-string decoding", because
> > >>>> <xref target="RFC1035" sectionFormat="of" section="5.1"/> uses this
> > >>>> algorithm to produce a <tt>&lt;character-string&gt;</tt>.
> > >>>> 
> > >>>> (And a corresponding "the allowed input" => "some allowed inputs".)
> > >>>> 
> > >>>> The attached XML incorporates this proposal, if that works for everyone.
> > >>>> 
> > >>>> -----Original Message-----
> > >>>> From: Lynne Bartholomew <[e-mail]> 
> > >>>> Sent: Thursday, October 5, 2023 12:32 PM
> > >>>> To: Erik Nygren <[e-mail]>; Ben Schwartz <[e-mail]>
> > >>>> Cc: Mike Bishop <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> > >>>> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
> > >>>> 
> > >>>> Hi, Erik and Ben.
> > >>>> 
> > >>>> Erik, thank you for the suggestion.  Ben, is Erik's suggestion acceptable, and may we update accordingly?
> > >>>> 
> > >>>> Thank you!
> > >>>> 
> > >>>> RFC Editor/lb
> > >>>> 
> > >>>>> On Oct 5, 2023, at 6:12 AM, Erik Nygren <[e-mail]> wrote:
> > >>>>> 
> > >>>>> What about "described in" (instead of just "in" or "per") ?  
> > >>>>> So:
> > >>>>> 
> > >>>>> -it is used to produce a <tt>&lt;character-string&gt;</tt> in
> > >>>>> +it is used to produce the <tt>&lt;character-string&gt;</tt> described in
> > >>>>> 
> > >>>>> ?
> > >>>>> 
> > >>>>> On Wed, Oct 4, 2023 at 11:58 AM Ben Schwartz <[e-mail]> wrote:
> > >>>>> Re: "We made the additional update (changed "in" to "per") per your note for 1) below."
> > >>>>> 
> > >>>>> I think we need to give that section another look.  I believe that "per" may not be correct here.
> > >>>>> 
> > >>>>> --Ben Schwartz
> > >>>>> 
> > >>>>> From: Lynne Bartholomew <[e-mail]>
> > >>>>> Sent: Tuesday, October 3, 2023 12:29 PM
> > >>>>> To: Mike Bishop <[e-mail]>
> > >>>>> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]<[e-mail]>; [e-mail] <[e-mail]>
> > >>>>> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review   !-------------------------------------------------------------------|
> > >>>>>  This Message Is From an External Sender
> > >>>>> 
> > >>>>> |-------------------------------------------------------------------!
> > >>>>> 
> > >>>>> Hi, Mike.
> > >>>>> 
> > >>>>> Thank you for the latest updated XML file!
> > >>>>> 
> > >>>>> We made the additional update (changed "in" to "per") per your note for 1) below.
> > >>>>> 
> > >>>>> FYI that the new line breaks in the list in Section 1.2 constitute a bug (https://github.com/ietf-tools/xml2rfc/issues/1045).  We hope that this issue will be resolved soon.
> > >>>>> 
> > >>>>> The latest files are posted here (please refresh your browser):
> > >>>>> 
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460.txt   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460.pdf   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460.xml   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-diff.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-auth48diff.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-lastdiff.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-lastrfcdiff.html   
> > >>>>> 
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html   
> > >>>>>   https://www.rfc-editor.org/authors/rfc9460-alt-diff.html   
> > >>>>> 
> > >>>>> Thanks again!
> > >>>>> 
> > >>>>> RFC Editor/lb
> > >>>>> 
> > >>>>>> On Sep 29, 2023, at 11:52 AM, Mike Bishop <[e-mail]> wrote:
> > >>>>>> 
> > >>>>>> 1) This is fine.
> > >>>>>> 
> > >>>>>> 2) All reasonable, but we'd prefer to avoid nested parentheses.  In the attached, we've changed this to "supported protocols" in 3.2 and moved the expansion back to 7.1.
> > >>>>>> 
> > >>>>>> We also noted in reviewing the change to the title of Figure 1 that this URL was not quoted, so we've added those.
> > >>>>>> 
> > >>>>>> -----Original Message-----
> > >>>>>> From: Lynne Bartholomew <[e-mail]> 
> > >>>>>> Sent: Thursday, September 28, 2023 11:48 AM
> > >>>>>> To: Mike Bishop <[e-mail]>
> > >>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> > >>>>>> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
> > >>>>>> 
> > >>>>>> Hi, Mike.
> > >>>>>> 
> > >>>>>> Thank you very much for the updated XML file!
> > >>>>>> 
> > >>>>>> Thanks also for the detailed list of updates after your "late-arriving review from the DNS Directorate" note; your note informed us that we would not need to ask for AD approval for any of those updates; very helpful and much appreciated!
> > >>>>>> 
> > >>>>>> A couple follow-up items for you:
> > >>>>>> 
> > >>>>>> 1) "used to produce a <character-string> in Section 5.1 of [RFC1035]" reads a bit oddly.  May we change it to "used to produce a <character-string> per Section 5.1 of [RFC1035]"?
> > >>>>>> 
> > >>>>>> 2) Please note that per our style guidelines we made the following updates to your copy:
> > >>>>>> 
> > >>>>>> * Moved the expansion of "ALPN" from Section 7.1 to Section 3.2.
> > >>>>>> * Changed "Section 2.4.2 and Section 3" to "Sections 2.4.2 and 3" in Section 9.1.
> > >>>>>> * Changed "At" to "at" in the title of Figure 1.
> > >>>>>> 
> > >>>>>> The latest files are posted here:
> > >>>>>> 
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460.txt   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460.pdf   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460.xml   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-diff.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-auth48diff.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-lastdiff.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-lastrfcdiff.html   
> > >>>>>> 
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html   
> > >>>>>>  https://www.rfc-editor.org/authors/rfc9460-alt-diff.html   
> > >>>>>> 
> > >>>>>> Again, many thanks for your help with this document!
> > >>>>>> 
> > >>>>>> RFC Editor/lb
> > >>>>>> 
> > >>>>>> 
> > >>>>>>> On Sep 26, 2023, at 11:40 AM, Mike Bishop <[e-mail]> wrote:
> > >>>>>>> 
> > >>>>>>> Hi, Lynne -
> > >>>>>>> Please see attached an updated XML from our side, with the following changes in response to your questions.
> > >>>>>>> 
> > >>>>>>>   • We expanded "RR" in the document title.  Please let us know any objections.
> > >>>>>>> We have adjusted the title to expand the initialism while avoiding nested parentheses.
> > >>>>>>> Original:
> > >>>>>>> Service Binding and Parameter Specification via the DNS (DNS SVCB and 
> > >>>>>>> HTTPS Resource Records (RRs))
> > >>>>>>> Current:
> > >>>>>>> Service Binding and Parameter Specification via the DNS (SVCB and 
> > >>>>>>> HTTPS Resource Records)
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 2.               Please insert any keywords…
> > >>>>>>> We have added various relevant keywords.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 3.               Datatracker "idnits" output for the original approved document included the following warning … There are 2 instances of lines with non-RFC2606-compliant FQDNs
> > >>>>>>> These instances are false positives.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 4.               Section 1.1:  We changed this section title, as it did not match the contents of the section.  If this update is incorrect, perhaps some text is missing?  If so, please clarify "goal" vs. "goals".
> > >>>>>>> We have accepted the new section title, and also corrected an obsolete reference to statements that were previously “mentioned above” but now appear later in the document. 
> > >>>>>>> Original:
> > >>>>>>> (As mentioned above, this all
> > >>>>>>> applies equally to the HTTPS RR, which shares the same encoding, 
> > >>>>>>> format, and high-level semantics.)
> > >>>>>>> Current:
> > >>>>>>> (As discussed in <xref target="svcb-compatible"/>, this all applies 
> > >>>>>>> equally to the HTTPS RR, which shares the same encoding, format, and 
> > >>>>>>> high-level semantics.)
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 5.               Please review the "type" attribute of each sourcecode element…
> > >>>>>>> We have added types and converted “artwork” tags to “sourcecode” as appropriate.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 6.               Section 2.4.2:  As it appears that "multiple" means "multiple RRs" (as opposed to "multiple RRSets"), we updated this sentence accordingly.  If this is incorrect, please provide clarifying text.
> > >>>>>>> We have adjusted this to “multiple AliasMode RRs”.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 7.                Section 4.2:  Is resolution of unknown RR types the only type of normal response construction, or should "i.e." ("that is") be "e.g." ("for example") here?
> > >>>>>>> Yes.  For clarity, we’ve removed this use of “i.e.” entirely.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 8.               Section 4.3:  Does "even if the contents are invalid" refer to the "MUST" clause, the "MAY" clause, or both?
> > >>>>>>> It refers to the “MAY” clause.  To improve clarity, we’ve restructured this sentence and the following one.
> > >>>>>>> Original:
> > >>>>>>> Recursive resolvers <bcp14>MUST</bcp14> be able to convey SVCB records 
> > >>>>>>> with unrecognized SvcParamKeys, and <bcp14>MAY</bcp14> treat the 
> > >>>>>>> entire SvcParams portion of the record as opaque, even if the contents 
> > >>>>>>> are invalid.  Alternatively, recursive resolvers <bcp14>MAY</bcp14> 
> > >>>>>>> report an error such as SERVFAIL to avoid returning a SvcParamValue that is invalid according to the SvcParam's specification.
> > >>>>>>> Current:
> > >>>>>>> Recursive resolvers <bcp14>MUST</bcp14> be able to convey SVCB records 
> > >>>>>>> with unrecognized SvcParamKeys.  Resolvers <bcp14>MAY</bcp14> 
> > >>>>>>> accomplish this by treating the entire SvcParams portion of the record 
> > >>>>>>> as opaque, even if the contents are invalid.  If a recognized 
> > >>>>>>> SvcParamKey is followed by a value that is invalid according to the 
> > >>>>>>> SvcParam's specification, a recursive resolver <bcp14>MAY</bcp14> 
> > >>>>>>> report an error such as SERVFAIL instead of returning the record.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 9.               Section 7.2:  Should "this SvcParam" be "this SvcParamValue" here?
> > >>>>>>> Yes.  (Corrected.)
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 10.            Section 9.1:  Please clarify the meaning of "Following of".
> > >>>>>>> We’ve clarified by reformulating this sentence and including references to the relevant sections where the behavior is defined.
> > >>>>>>> Original: 
> > >>>>>>>           Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB.
> > >>>>>>> Current:
> > >>>>>>>           The procedure for following HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB (as described in <xref target="alias-mode"/> and <xref target="client-behavior"/>).
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 11.            Should the instances of "9443" be "8443" here?
> > >>>>>>> No, this distinction is intentional.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 12.            Section 9.4 and Table 1:  Does "ECH" refer to citations for draft-ietf-tls-esni and not to "Encrypted ClientHello" in general, or does it refer to some (unknown) future specification related to ECH (in which case the text should be clarified)?
> > >>>>>>> For clarity, we’ve replaced “ECH” here with that reference, and expanded the acronym where it appears in the IANA instructions. The assignment is currently captured in draft-sbn-tls-svcb-ech-00, which was extracted from this document. The TLS WG has adopted that document, and will need to decide whether to fold it into draft-ietf-tls-esni or advance it separately.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 13.            Section 9.6: Should 'HTTP URL' be '"http" URL'?  … Also, we could not find any instances of "requestURL" in [WebSocket], any other published RFC, or [FETCH].
> > >>>>>>> We’ve replaced ‘HTTP URL” with the formal term defined in RFC 9110: “HTTP-related URI scheme”.
> > >>>>>>> Since we wrote this text, WHATWG has moved the definition of “requestURL” to a new document.  We’ve fixed the problem by adding that reference here.
> > >>>>>>> Original:
> > >>>>>>> All HTTP connections to named origins are eligible to use HTTPS RRs, 
> > >>>>>>> even when HTTP is used as part of another protocol or without an 
> > >>>>>>> explicit HTTP URL.  For example, clients that support HTTPS RRs and 
> > >>>>>>> implement the altered WebSocket <xref target="RFC6455"/> opening 
> > >>>>>>> handshake from the W3C Fetch specification <xref target="FETCH"/> 
> > >>>>>>> <bcp14>SHOULD</bcp14> use HTTPS RRs for the <tt>requestURL</tt>.
> > >>>>>>> Current:
> > >>>>>>> All HTTP connections to named origins are eligible to use HTTPS RRs, 
> > >>>>>>> even when HTTP is used as part of another protocol or without an 
> > >>>>>>> explicit HTTP-related URI scheme (<relref target="RFC9110" 
> > >>>>>>> section="4.2"/>).  For example, clients that support HTTPS RRs and 
> > >>>>>>> implement <xref target="RFC6455"/> using the altered opening handshake 
> > >>>>>>> from <xref target="FETCH-WEBSOCKETS"/> <bcp14>SHOULD</bcp14> use HTTPS RRs for the <tt>requestURL</tt>.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 14.            Section 10.3:  We had trouble following "various interpretations of RFCs" in the first sentence…
> > >>>>>>> We’ve replaced this vague statement by a reference to the BIND documentation for the behavior in question.
> > >>>>>>> Original:
> > >>>>>>> Note that some implementations may not allow A or AAAA records on 
> > >>>>>>> names starting with an underscore due to various interpretations of RFCs.
> > >>>>>>> This could be an operational issue when the TargetName contains an 
> > >>>>>>> Attrleaf label, as well as using a TargetName of "." when the owner name contains an Attrleaf label.
> > >>>>>>> Current:
> > >>>>>>> Some authoritative DNS servers may not allow A or AAAA records on 
> > >>>>>>> names starting with an underscore (e.g., <xref target="BIND-CHECK-NAMES"/>).
> > >>>>>>> This could create an operational issue when the TargetName contains an 
> > >>>>>>> Attrleaf label, or when using a TargetName of "." if the owner name contains an Attrleaf label.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 15.            Section 11:  We do not see the word "stapling" or "staple" in RFC 6066.  Please confirm that this citation will be clear to readers.
> > >>>>>>> We’ve adjusted this sentence to expand “OCSP” and mention 
> > >>>>>>> “Certificate Status Request”, which is the formal name from RFC 6066.  
> > >>>>>>> (We’ve preserved the term “stapling” because it is much more widely 
> > >>>>>>> understood and commonly used than the formal name.)
> > >>>>>>> Original:
> > >>>>>>> Server operators implementing this standard <bcp14>SHOULD</bcp14> also 
> > >>>>>>> implement TLS 1.3 <xref target="RFC8446"/> and Online
> > >>>>>>>     Certificate Status Protocol (OCSP) Stapling <xref 
> > >>>>>>> target="RFC6066"/>, both of which confer substantial performance and 
> > >>>>>>> privacy benefits when used in combination with SVCB records.
> > >>>>>>> Current:
> > >>>>>>> Server operators implementing this standard <bcp14>SHOULD</bcp14> also 
> > >>>>>>> implement TLS 1.3 <xref target="RFC8446"/> and Online Certificate 
> > >>>>>>> Status Protocol (OCSP) Stapling (i.e., Certificate Status Request in 
> > >>>>>>> <xref target="RFC6066" section="8" sectionFormat="of"/>), both of 
> > >>>>>>> which confer substantial performance and privacy benefits when used in 
> > >>>>>>> combination with SVCB records.</t>
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 16.            Section 12:  "unintended access" reads oddly here.  If the suggested text is not correct, should the word "unintended" be removed?
> > >>>>>>> We’ve rephrased this in a way that avoids the word “unintended” and improves specificity.
> > >>>>>>> Original:
> > >>>>>>> If the attacker can influence the
> > >>>>>>> client's payload (e.g., TLS session ticket contents) and an internal 
> > >>>>>>> service has a sufficiently lax parser, it's possible that the attacker 
> > >>>>>>> could gain unintended access.
> > >>>>>>> Current:
> > >>>>>>> If the attacker can influence the
> > >>>>>>> client's payload (e.g., TLS session ticket contents) and an internal 
> > >>>>>>> service has a sufficiently lax parser, the attacker could gain access 
> > >>>>>>> to the internal service.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 17.            FYI, we have changed two instances of "Service Binding" to "service binding" because it written in lowercase where used generally in this document. We will ask IANA…
> > >>>>>>> We’ve changed the description in the IANA instructions to use the 
> > >>>>>>> more precise term “SVCB-compatible” instead.  (The original IANA 
> > >>>>>>> instructions may predate this term.)
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 18.            The following ACTION text indicates that the "Service Parameter Keys (SvcParamKeys)" registry should appear on the "Domain Name System (DNS) Parameters" page.  However, the registry appears on a page under the heading "DNS Service Bindings (SVCB)"
> > >>>>>>> This disparity may have occurred because IANA reorganized their website after the original instructions were written.  The current location of the registry correctly reflects the authors’ intent, and we have updated the draft to describe the new location.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 19.            Because the IANA registry does not include a "Meaning" column, we have updated the text as shown below.  Please let us know if any updates are required.
> > >>>>>>> This change is correct.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 20.             Appendix A:  Because Section 3.3 of RFC 1035 says "<character-string> is treated as binary information, and can be up to 256 characters in length (including the length octet)", we updated this sentence to clarify the meaning of "same as". If this is incorrect, please provide text that clarifies the meaning of "same as".
> > >>>>>>> This change is not correct.  We have adjusted the text to provide a clearer distinction between “<character-string>” (which is binary) and the textual representation used to generate it.
> > >>>>>>> Original:
> > >>>>>>> DNS zone files are capable of representing arbitrary octet sequences 
> > >>>>>>> in basic ASCII text, using various delimiters and encodings.  The 
> > >>>>>>> algorithm for decoding these character strings is defined in <xref section="5.1" sectionFormat="of" target="RFC1035"/>.
> > >>>>>>> Current:
> > >>>>>>> DNS zone files are capable of representing arbitrary octet sequences 
> > >>>>>>> in basic ASCII text, using various delimiters and encodings, according 
> > >>>>>>> to an algorithm defined in <xref section="5.1" sectionFormat="of" target="RFC1035"/>.
> > >>>>>>> Original:
> > >>>>>>> In this document, this algorithm is referred to as "character-string decoding".
> > >>>>>>> The algorithm is the same as the guideline for 
> > >>>>>>> <tt>&lt;character-string&gt;</tt> provided in <xref target="RFC1035" sectionFormat="of" section="3.3"/>, except that in this document the output length is not limited to 255 octets.
> > >>>>>>> Current:
> > >>>>>>> In this document, this algorithm is referred to as "character-string 
> > >>>>>>> decoding", because it is used to produce a 
> > >>>>>>> <tt>&lt;character-string&gt;</tt> in <xref target="RFC1035" 
> > >>>>>>> sectionFormat="of" section="5.1"/>.  Note that while the length of a 
> > >>>>>>> <tt>&lt;character-string&gt;</tt> is limited to 255 octets, the 
> > >>>>>>> character-string decoding algorithm can produce output of any 
> > >>>>>>> length.</t>
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 21.            Appendix C.4:  We changed "the authoritative" at the end of this sentence to "the authoritative DNS server".
> > >>>>>>> This change is correct.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 22.            Appendix D.2:  Do "target (root label)" and "target, root label" mean the same thing?  If yes, should they both be expressed in the same way (i.e., either parentheses or comma)? Also, should "length: 2 bytes" be "length 2", per the format of all other "# length" and "; length" entries?
> > >>>>>>> Yes, these carry the same meaning.  We have incorporated these changes to improve consistency.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 23.            The example.com line in Figure 8 extends beyond the 72-character limit.
> > >>>>>>> 24.            Figure 8:  The "example.com." line is too long…
> > >>>>>>> We have adjusted this figure as suggested to fit within the 72-character limit.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 25.            Figures 14 and 15:  Should "mandatory" be written in the same way in both titles (i.e., either lowercase and quoted or initial-capitalized and unquoted)?
> > >>>>>>> No.  In one case, it refers to an item that must be present; in the other it refers to the literal 9-character sequence “mandatory”.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 26.            "Acknowledgments and Related Proposals" reads oddly, in that the two ideas seem unrelated.  "... proposed solutions ...challenge proposed" reads oddly as well. May we make a new Section 15 ("Related Proposals") … ?
> > >>>>>>> We’ve reformulated this paragraph to make clear that the related proposals are mentioned by way of acknowledgement and gratitude.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 27.            Please review the "Inclusive Language" portion of the online Style Guide …
> > >>>>>>> We have reviewed this guidance but did not find any changes that could be made on this basis.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 28.            Please let us know if any changes are needed for the following [capitalization consistency issues]
> > >>>>>>> We have attempted to correct these issues to improve consistency.  In the case of ALPN, we have clarified some uses as “ALPN protocol” or “ALPN ID”.
> > >>>>>>> ------------
> > >>>>>>> Additionally, we made several edits in response to a late-arriving review from the DNS Directorate, as Warren indicated.  These are highlighted below, in no particular order.
> > >>>>>>> # Positive and negative DNSSEC (Section 4.1)
> > >>>>>>> Original:
> > >>>>>>> If the zone is signed, the server SHOULD also include positive or 
> > >>>>>>> negative DNSSEC responses for these records in the Additional section.
> > >>>>>>> Current:
> > >>>>>>> If the zone is signed, the server SHOULD also include DNSSEC records 
> > >>>>>>> authenticating the existence or nonexistence of these records in the 
> > >>>>>>> Additional section.
> > >>>>>>> # Use of “origin” for concepts other than HTTP origins
> > >>>>>>> - In 1.1, “an origin within the DNS” => “a service identified by a domain name”
> > >>>>>>> - In 3.1, “origin’s SVCB record” => “service’s SVCB record”
> > >>>>>>> - In 7.3, “origin hostname” => “service name”
> > >>>>>>> - In 9.3, “origin endpoint” => “authority endpoint”
> > >>>>>>> - In 12, “origin” => “authoritative server”
> > >>>>>>> # Use of “delegation” outside the sense of DNS zone delegation
> > >>>>>>> - In 1, “delegating the origin” => “aliasing the origin”
> > >>>>>>> - In 1.1, “delegation of operational authority for an origin within 
> > >>>>>>> the DNS to an alternate name.” => “extending operational authority for 
> > >>>>>>> a service identified by a domain name to other instances with 
> > >>>>>>> alternate names.” (overlap with previous set)
> > >>>>>>> - In 1.1, “apex delegation” => “apex aliasing”
> > >>>>>>> - In 3.2, “It allows the service to delegate the apex domain.” => “It allows a service on an apex domain to use aliasing.”
> > >>>>>>> - In Figure 1 (caption), “Is Delegated to” => “Is Available At”
> > >>>>>>> # Inconsistency of terms for list and sorting in Section 3
> > >>>>>>> - “enumerating the priority-ordered endpoints” => “enumerating and ordering the available endpoints”
> > >>>>>>> - Addition of “Sort the records by ascending SvcPriority.” to step 4.
> > >>>>>>> - “known endpoints” => “available endpoints”
> > >>>>>>> - “priority list” => “list of endpoints”
> > >>>>>>> - “the resolved list” => “this list”
> > >>>>>>> # Vague performance statements
> > >>>>>>> In 2.4.2, removed “which would likely improve performance”
> > >>>>>>> # No such thing as empty RRset
> > >>>>>>> Original:
> > >>>>>>> If the SVCB RRset contains no compatible RRs, the client will generally act as if the RRset is empty.
> > >>>>>>> Current:
> > >>>>>>> Incompatible RRs are ignored (see step 5 of the procedure defined in <xref target="client-behavior"/>).
> > >>>>>>> ------------
> > >>>>>>> Finally, with regard to the changes from our previous e-mail: The attached file incorporates your proposed changes. We have made one adjustment, where <tt> was already being used around a hostname which is now quoted.  The combination is probably not necessary; for consistency, we can align on quotes.
> > >>>>>>> Original:
> > >>>>>>> When using the generic SVCB RR type with aliasing, zone owners 
> > >>>>>>> <bcp14>SHOULD</bcp14> choose alias target names that indicate the 
> > >>>>>>> scheme in use (e.g., <tt>"foosvc.example.net"</tt> for 
> > >>>>>>> <tt>"foo://"</tt> schemes).  This will help to avoid confusion when 
> > >>>>>>> another scheme needs to be added to the configuration.  When multiple 
> > >>>>>>> port numbers are in use, it may be helpful to repeat the prefix labels in the alias target name (e.g., <tt>"_1234._foo.svc.example.net"</tt>).
> > >>>>>>> Current:
> > >>>>>>> When using the generic SVCB RR type with aliasing, zone owners 
> > >>>>>>> <bcp14>SHOULD</bcp14> choose alias target names that indicate the 
> > >>>>>>> scheme in use (e.g., "foosvc.example.net" for "foo" schemes).  This 
> > >>>>>>> will help to avoid confusion when another scheme needs to be added to 
> > >>>>>>> the configuration.  When multiple port numbers are in use, it may be 
> > >>>>>>> helpful to repeat the prefix labels in the alias target name (e.g., "_1234._foo.svc.example.net").
> > >>>>>>> We have also removed the “://”, which is not properly part of the scheme.
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Lynne Bartholomew <[e-mail]>
> > >>>>>>> Sent: Friday, September 22, 2023 2:39 PM
> > >>>>>>> To: Mike Bishop <[e-mail]>; [e-mail]; 
> > >>>>>>> [e-mail]
> > >>>>>>> Cc: [e-mail]; [e-mail]; 
> > >>>>>>> [e-mail]; [e-mail]; 
> > >>>>>>> [e-mail]
> > >>>>>>> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> 
> > >>>>>>> for your review  Hi, Mike and coauthors.
> > >>>>>>> Mike, apologies for our confusion with the emails yesterday.  We have updated this document per your notes below.  Please see our "[rfced]" notes inline.
> > >>>>>>> Also, apologies for an issue regarding an update to Section 14.4.  The updated section is now correct.  We also removed a duplicate question regarding Figure 8.
> > >>>>>>> The latest files are posted here.  Please refresh your browser to view the latest updates and the updated list of questions:
> > >>>>>>>   https://www.rfc-editor.org/authors/rfc9460.txt   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460.pdf   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460.html   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460.xml   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460-diff.html   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460-auth48diff.html   
> > >>>>>>>   https://www.rfc-editor.org/authors/rfc9460-alt-diff.html   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html   
> > >>>>>>>  https://www.rfc-editor.org/authors/rfc9460-alt-diff.html   
> > >>>>>>> Thank you, and again, apologies for our confusion.
> > >>>>>>> RFC Editor/lb
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>>> On Sep 20, 2023, at 1:33 PM, Mike Bishop <[e-mail]> wrote:
> > >>>>>>>>> A couple points from the copy-edits I wanted to discuss as we go through these….
> > >>>>>>>>> Under SVC Query Names, I see this change:
> > >>>>>>>>> Original:
> > >>>>>>>> When querying the SVCB RR, a service is translated into a QNAME by 
> > >>>>>>>> prepending the service name with a label indicating the scheme, 
> > >>>>>>>> prefixed with an underscore, resulting in a domain name like "_examplescheme.api.example.com.".
> > >>>>>>>>> Current:
> > >>>>>>>> When querying the SVCB RR, a service is translated into a QNAME by 
> > >>>>>>>> prepending the service name with a label indicating the scheme, 
> > >>>>>>>> prefixed with an underscore, resulting in a domain name like "_examplescheme.api.example.com."
> > >>>>>>>>> In this instance, however, the literal domain name ends with a period.  Given the general rule in American English that the period goes inside the quotation marks and not outside, the absence of the explicit exterior period might cause some readers to apply that rule and not expect the actual domain name to contain the trailing dot; hence the separate period in the original.
> > >>>>>>>>> Could we revert this change, or is there a different way we could word this to avoid any confusion?
> > >>>>>>> [rfced] Reverted.  Thank you for the explanation.
> > >>>>>>>>> Under AliasMode, quotes were added to offset “https://example.com ”, but similar quotes were not added around “foo://example.com:8080”.  Should all URIs be quoted, if this one is?
> > >>>>>>>> [rfced] We added quotes to URIs listed in text.  Please review and let us know if any of the new quotes are incorrect (e.g., we added quotes for 'owner of "example.com"' because we found 'the operator of "https://example.com "', but is this update  correct?).
> > >>>>>>>> Regarding the hyphenation of “SVCB-optional” and “SVCB-reliant”:
> > >>>>>>>>> Original:
> > >>>>>>>> A client is called "SVCB-optional" if it can connect without the use 
> > >>>>>>>> of ServiceMode records, and "SVCB-reliant" otherwise.
> > >>>>>>>>> Current:
> > >>>>>>>> A client is called "SVCB optional" if it can connect without the use 
> > >>>>>>>> of ServiceMode records; otherwise, it is called "SVCB reliant".
> > >>>>>>>>> These terms are used primarily as adjectives before a noun (and therefore hyphenated) and in a few instances with a verb in between.  It seems unclear not to hyphenate the definition of the terms when that’s primarily how they’re used, for ease of searching. For uniformity, could we hyphenate these terms throughout?  If I understand the rule correctly, a compound adjective is *generally* not hyphenated when not before a noun, but some are.
> > >>>>>>>>> (The same applies to “SVCB-compatible” later.)
> > >>>>>>> [rfced] We restored the hyphens.
> > >>>>>>> Updated list of questions:
> > >>>>>>> 1) <!-- [rfced] We expanded "RR" in the document title.  Please let us know any objections.
> > >>>>>>> Original:
> > >>>>>>> Service binding and parameter specification via the DNS (DNS SVCB and
> > >>>>>>>                              HTTPS RRs)
> > >>>>>>> Currently:
> > >>>>>>> Service Binding and Parameter Specification via the DNS (DNS SVCB and
> > >>>>>>>                    HTTPS Resource Records (RRs)) -->
> > >>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear 
> > >>>>>>> in the
> > >>>>>>> title) for use on <https://www.rfc-editor.org/search >. -->
> > >>>>>>> 3) <!-- [rfced] Datatracker "idnits" output for the original approved document included the following warning.  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. -->
> > >>>>>>> 4) <!-- [rfced] Section 1.1:  We changed this section title, as it did not match the contents of the section.  If this update is incorrect, perhaps some text is missing?  If so, please clarify "goal" vs.
> > >>>>>>> "goals".
> > >>>>>>> Original (excerpts from this section are included for context):
> > >>>>>>> 1.1.  Goals of the SVCB RR
> > >>>>>>>   The goal of the SVCB RR is to allow clients to resolve a single
> > >>>>>>>  additional DNS RR in a way that:
> > >>>>>>> ...
> > >>>>>>>  Additional goals specific to HTTPS RRs and the HTTP use-cases
> > >>>>>>>  include:
> > >>>>>>> Currently:
> > >>>>>>> 1.1.  Goals -->
> > >>>>>>> 5) <!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness.  If the current list of preferred values for "type"
> > >>>>>>> (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.
> > >>>>>>> In addition, review each artwork element.  Specifically, should any artwork element be tagged as sourcecode (e.g., "dns-rr", "pseudocode", or "test-vectors" for some or all of the figures in the appendices)? -->
> > >>>>>>> 6) <!-- [rfced] Section 2.4.2:  As it appears that "multiple" means "multiple RRs" (as opposed to "multiple RRSets"), we updated this sentence accordingly.  If this is incorrect, please provide clarifying text.
> > >>>>>>> Original (the previous sentence is included for context):
> > >>>>>>> In AliasMode, the SVCB record aliases a service to a TargetName.
> > >>>>>>> SVCB RRSets SHOULD only have a single resource record in AliasMode.
> > >>>>>>> If multiple are present, clients or recursive resolvers SHOULD pick  one at random.
> > >>>>>>> Currently:
> > >>>>>>> If multiple
> > >>>>>>> RRs are present, clients or recursive resolvers SHOULD pick one at  random. -->
> > >>>>>>> 7) <!-- [rfced] Section 4.2:  Is resolution of unknown RR types the only type of normal response construction, or should "i.e." ("that is") be "e.g." ("for example") here?
> > >>>>>>> Original:
> > >>>>>>> Whether the recursive resolver is aware of SVCB or not, the normal  
> > >>>>>>> response construction process (i.e. unknown RR type resolution under
> > >>>>>>> [RFC3597]) generates the Answer section of the response. -->
> > >>>>>>> 8) <!-- [rfced] Section 4.3:  Does "even if the contents are invalid"
> > >>>>>>> refer to the "MUST" clause, the "MAY" clause, or both?
> > >>>>>>> Original:
> > >>>>>>> Recursive resolvers MUST be able to convey SVCB records with  unrecognized SvcParamKeys, and MAY treat the entire SvcParams portion  of the record as opaque, even if the contents are invalid.
> > >>>>>>> (A) Perhaps (both):
> > >>>>>>> Recursive resolvers MUST be able to convey SVCB records with  unrecognized SvcParamKeys and MAY treat the entire SvcParams portion  of the record as opaque, even if the contents are invalid.
> > >>>>>>> (B) Or possibly (only the "MAY" clause):
> > >>>>>>> Recursive resolvers MUST be able to convey SVCB records with  unrecognized SvcParamKeys, and the resolvers MAY treat the entire  SvcParams portion of the record as opaque even if the contents are  invalid.
> > >>>>>>> (C) Or to be specific (instead of rely only on the comma):
> > >>>>>>> Recursive resolvers MUST be able to convey SVCB records with
> > >>>>>>> unrecognized SvcParamKeys, and the resolvers MAY treat the entire
> > >>>>>>> SvcParams portion of the record as opaque even if the contents
> > >>>>>>> (of that portion) are invalid. -->
> > >>>>>>> 9) <!-- [rfced] Section 7.2:  Should "this SvcParam" be "this 
> > >>>>>>> SvcParamValue" here?  We ask because we see two instances of 
> > >>>>>>> "SvcParamValue MUST NOT contain escape sequences" later in this 
> > >>>>>>> document.
> > >>>>>>> Original:
> > >>>>>>> To enable simpler parsing, this SvcParam MUST NOT contain escape 
> > >>>>>>> sequences. -->
> > >>>>>>> 10) <!-- [rfced] Section 9.1:  Please clarify the meaning of 
> > >>>>>>> "Following of".
> > >>>>>>> Original:
> > >>>>>>> Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 
> > >>>>>>> SVCB. -->
> > >>>>>>> 11) <!--[rfced] Should the instances of "9443" be "8443" here?
> > >>>>>>> Original:
> > >>>>>>>  Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"            
> > >>>>>>>                                                                                  The client would retrieve the following HTTPS records:                      
> > >>>>>>>                                                                                  alt.example.              IN HTTPS 1 . alpn=h2,h3 foo=...                   
> > >>>>>>>  alt2.example.             IN HTTPS 1 alt2b.example. alpn=h3 foo=...         
> > >>>>>>>  _8443._https.example.com. IN HTTPS 1 alt3.example. (                        
> > >>>>>>>      port=9443 alpn=h2,h3 foo=... )                                                                                  [...]
> > >>>>>>>                                                                                 *  HTTP/3 to alt3.example:9443    -->
> > >>>>>>> 12) <!-- [rfced] Section 9.4 and Table 1:  Does "ECH" refer to 
> > >>>>>>> citations for draft-ietf-tls-esni and not to "Encrypted ClientHello" 
> > >>>>>>> in general, or does it refer to some (unknown) future specification 
> > >>>>>>> related to ECH (in which case the text should be clarified)?
> > >>>>>>> Please note that we could not find any indication in 
> > >>>>>>> draft-ietf-tls-esni that the parameter in question will be reserved 
> > >>>>>>> for it.
> > >>>>>>> Original:
> > >>>>>>> Clients MUST NOT use an HTTPS RR response unless the client supports 
> > >>>>>>> TLS Server Name Indication (SNI) and indicates the origin name in the 
> > >>>>>>> TLS ClientHello (which might be encrypted via a future specification 
> > >>>>>>> such as ECH).
> > >>>>>>> ...
> > >>>>>>> | 5           | ech             | RESERVED    |N/A      |IETF      |
> > >>>>>>> |             |                 | (will be    |         |          |
> > >>>>>>> |             |                 | used for    |         |          |
> > >>>>>>> |             |                 | ECH)        |         |          | -->
> > >>>>>>> 13) <!-- [rfced] Section 9.6:
> > >>>>>>> Should 'HTTP URL' be '"http" URL'?  We ask because we do not see 
> > >>>>>>> 'HTTP URL' used anywhere else in this document or in this cluster of 
> > >>>>>>> documents (https://www.rfc-editor.org/cluster_info.php?cid=C461 ).
> > >>>>>>> Also, we could not find any instances of "requestURL" in [WebSocket], 
> > >>>>>>> any other published RFC, or [FETCH].  However, we see "Request-URI"
> > >>>>>>> in [WebSocket].  Will the use of "requestURL" be clear to readers?
> > >>>>>>> Original:
> > >>>>>>> All HTTP connections to named origins are eligible to use HTTPS RRs, 
> > >>>>>>> even when HTTP is used as part of another protocol or without an 
> > >>>>>>> explicit HTTP URL.  For example, clients that support HTTPS RRs and 
> > >>>>>>> implement the altered WebSocket [WebSocket] opening handshake from the 
> > >>>>>>> W3C Fetch specification [FETCH] SHOULD use HTTPS RRs for the 
> > >>>>>>> requestURL. -->
> > >>>>>>> 14) <!-- [rfced] Section 10.3:  We had trouble following "various 
> > >>>>>>> interpretations of RFCs" in the first sentence, as it appears to 
> > >>>>>>> indicate that the RFCs themselves are being interpreted.  Also, the 
> > >>>>>>> second sentence does not parse.  Would the "Perhaps" text below be 
> > >>>>>>> helpful?  If not, please provide clarifying text.
> > >>>>>>> Original ("an TargetName" has been fixed):
> > >>>>>>> Note that some implementations may not allow A or AAAA records on 
> > >>>>>>> names starting with an underscore due to various interpretations of 
> > >>>>>>> RFCs.  This could be an operational issue when the TargetName contains 
> > >>>>>>> an attrleaf label, as well as using an TargetName of "."
> > >>>>>>> when the owner name contains an attrleaf label.
> > >>>>>>> Perhaps:
> > >>>>>>> Note that some implementations may not allow A or AAAA records on 
> > >>>>>>> names that start with an underscore, due to various interpretations in 
> > >>>>>>> other RFCs.  This could be an operational issue when the TargetName 
> > >>>>>>> contains an Attrleaf label, as well as when a TargetName of "." is 
> > >>>>>>> used when the owner name contains an Attrleaf label. -->
> > >>>>>>> 15) <!-- [rfced] Section 11:  We do not see the word "stapling" or 
> > >>>>>>> "staple" in RFC 6066.  Please confirm that this citation will be clear 
> > >>>>>>> to readers.
> > >>>>>>> Original:
> > >>>>>>> Server operators implementing this standard SHOULD also implement TLS 
> > >>>>>>> 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of which confer 
> > >>>>>>> substantial performance and privacy benefits when used in combination 
> > >>>>>>> with SVCB records. -->
> > >>>>>>> 16) <!-- [rfced] Section 12:  "unintended access" reads oddly here.
> > >>>>>>> If the suggested text is not correct, should the word "unintended"
> > >>>>>>> be removed?  Please provide alternative text if you'd like to 
> > >>>>>>> rephrase.
> > >>>>>>> Original:
> > >>>>>>> If the attacker can influence the client's payload (e.g.
> > >>>>>>> TLS session ticket contents), and an internal service has a 
> > >>>>>>> sufficiently lax parser, it's possible that the attacker could gain 
> > >>>>>>> unintended access.
> > >>>>>>> Suggested:
> > >>>>>>> If the attacker can influence the client's payload (e.g., TLS session 
> > >>>>>>> ticket contents) and an internal service has a sufficiently lax 
> > >>>>>>> parser, it's possible that, as an unintended consequence, the attacker 
> > >>>>>>> could gain access. -->
> > >>>>>>> 17) <!-- [rfced] FYI, we have changed two instances of "Service Binding"
> > >>>>>>> to "service binding" because it written in lowercase where used 
> > >>>>>>> generally in this document. We will ask IANA to update 
> > >>>>>>> <https://www.iana.org/assignments/dns-parameters/ > accordingly, unless you let us know you prefer otherwise.
> > >>>>>>> Original:
> > >>>>>>>  *  Meaning: General Purpose Service Binding    Current:
> > >>>>>>>  Meaning:  General-purpose service binding
> > >>>>>>> Original:
> > >>>>>>>  *  Meaning: Service Binding type for use with HTTP  Current:
> > >>>>>>>  Meaning:  Service binding type for use with HTTP
> > >>>>>>> -->
> > >>>>>>> 18) <!-- [rfced] The following ACTION text indicates that the 
> > >>>>>>> "Service Parameter Keys (SvcParamKeys)" registry should appear on the 
> > >>>>>>> "Domain Name System (DNS) Parameters" page.  However, the registry 
> > >>>>>>> appears on a page under the heading "DNS Service Bindings (SVCB)"
> > >>>>>>> (see https://www.iana.org/assignments/dns-svcb/   ).  Please review and 
> > >>>>>>> let us know if the location of the "DNS Service Bindings (SVCB)"
> > >>>>>>> registry is correct.
> > >>>>>>> Original:
> > >>>>>>> ACTION: create this registry, on a new page entitled "DNS Service 
> > >>>>>>> Bindings (SVCB)" under the "Domain Name System (DNS) Parameters"
> > >>>>>>> category. -->
> > >>>>>>> 19) <!-- [rfced] Section 14.4:  Because the "Underscored and 
> > >>>>>>> Globally Scoped DNS Node Names" IANA registry does not include a "Meaning"
> > >>>>>>> column, we have updated the table as shown below.  Please let us know 
> > >>>>>>> if any other updates are required.
> > >>>>>>> Original (to avoid the issue of double dashes and XML comments, the
> > >>>>>>>  bottom line of the table is not included):
> > >>>>>>> Per [Attrleaf], please add the following entry to the DNS Underscore 
> > >>>>>>> Global Scoped Entry Registry:
> > >>>>>>>     +=========+============+=================+=================+
> > >>>>>>>    | RR TYPE | _NODE NAME | Meaning         | Reference       |
> > >>>>>>>    +=========+============+=================+=================+
> > >>>>>>>    | HTTPS   | _https     | HTTPS SVCB info | (This document) |
> > >>>>>>>                                Table 2
> > >>>>>>> Currently:
> > >>>>>>> Per [Attrleaf], the following entry has been added to the DNS 
> > >>>>>>> "Underscored and Globally Scoped DNS Node Names" registry:
> > >>>>>>>                 +=========+============+===========+
> > >>>>>>>                | RR Type | _NODE NAME | Reference |
> > >>>>>>>                +=========+============+===========+
> > >>>>>>>                | HTTPS   | _https     | RFC 9460  |
> > >>>>>>>                                Table 2 -->
> > >>>>>>> 20) <!-- [rfced] Appendix A:  Because Section 3.3 of RFC 1035 says 
> > >>>>>>> "<character-string> is treated as binary information, and can be up to 
> > >>>>>>> 256 characters in length (including the length octet)", we updated 
> > >>>>>>> this sentence to clarify the meaning of "same as".
> > >>>>>>> If this is incorrect, please provide text that clarifies the meaning 
> > >>>>>>> of "same as".
> > >>>>>>> Original:
> > >>>>>>> The algorithm is the same as used by
> > >>>>>>> <character-string> in RFC 1035, although the output length in this 
> > >>>>>>> document is not limited to 255 octets.
> > >>>>>>> Currently:
> > >>>>>>> The algorithm is the same as the
> > >>>>>>> guideline for <character-string> in [RFC1035], except that in this  
> > >>>>>>> document the output length is not limited to 255 octets.
> > >>>>>>> -->
> > >>>>>>> 21) <!-- [rfced] Appendix C.4:  We changed "the authoritative" at 
> > >>>>>>> the end of this sentence to "the authoritative DNS server".  If this 
> > >>>>>>> is incorrect, please clarify the meaning of "the authoritative".
> > >>>>>>> Original:
> > >>>>>>> Recursive resolvers that implement the specification would, upon 
> > >>>>>>> receipt of a ServiceMode query, emit both a ServiceMode and an 
> > >>>>>>> AliasMode query to the authoritative.
> > >>>>>>> Currently:
> > >>>>>>> Recursive resolvers that implement the specification would, upon 
> > >>>>>>> receipt of a ServiceMode query, emit both a ServiceMode query and an 
> > >>>>>>> AliasMode query to the authoritative DNS server. -->
> > >>>>>>> 22) <!-- [rfced] Appendix D.2:  Do "target (root label)" and 
> > >>>>>>> "target, root label" mean the same thing?  If yes, should they both be 
> > >>>>>>> expressed in the same way (i.e., either parentheses or comma)?
> > >>>>>>> Also, should "length: 2 bytes" be "length 2", per the format of all 
> > >>>>>>> other "# length" and "; length" entries?
> > >>>>>>> Original:
> > >>>>>>> 00         ; target (root label)
> > >>>>>>> ...
> > >>>>>>> \x00       # target, root label
> > >>>>>>> ...
> > >>>>>>> \x00\x02                                           # length: 2 bytes
> > >>>>>>> ...
> > >>>>>>> \x00\x05                                           # length 5
> > >>>>>>> ...
> > >>>>>>> \x00\x09                                           # length 9
> > >>>>>>> ...
> > >>>>>>> \x00\x20                                           # length 32
> > >>>>>>> ...
> > >>>>>>> \x00\x10                                           # length 16 -->
> > >>>>>>> 23) <!-- [rfced] Figure 8:  The "example.com." line is too long and 
> > >>>>>>> yields the following warning:
> > >>>>>>> Warning: Too long line found (L2319), 4 characters longer than 72 characters:
> > >>>>>>> example.com.   SVCB   1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33"
> > >>>>>>> We see a similar type of line at the top of Figure 7, although that 
> > >>>>>>> line uses parentheses before and after the line break around 
> > >>>>>>> "ipv6hint".  Would it be syntactically correct to format this line 
> > >>>>>>> (i.e., with parentheses and line breaks) per Figure 7?
> > >>>>>>> Original:
> > >>>>>>> example.com.   SVCB   1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33"
> > >>>>>>> Possibly:
> > >>>>>>> example.com.   SVCB   1 example.com. (
> > >>>>>>>                     ipv6hint="2001:db8:122:344::192.0.2.33"
> > >>>>>>>                     ) -->
> > >>>>>>> 24) <!-- [rfced] Figures 14 and 15:  Should "mandatory" be written 
> > >>>>>>> in the same way in both titles (i.e., either lowercase and quoted or 
> > >>>>>>> initial-capitalized and unquoted)?
> > >>>>>>> Original:
> > >>>>>>> Figure 14: A mandatory SvcParam is missing ...
> > >>>>>>> Figure 15: The "mandatory" SvcParamKey must not be included in
> > >>>>>>>                      the mandatory list -->
> > >>>>>>> 25) <!-- [rfced] "Acknowledgments and Related Proposals" reads 
> > >>>>>>> oddly, in that the two ideas seem unrelated.  "... proposed solutions ...
> > >>>>>>> challenge proposed" reads oddly as well.
> > >>>>>>> May we make a new Section 15 ("Related Proposals") and rephrase some 
> > >>>>>>> text as suggested below?
> > >>>>>>> Original:
> > >>>>>>> 15.  Acknowledgments and Related Proposals  There have been a wide 
> > >>>>>>> range of proposed solutions over the years to the "CNAME at the Zone 
> > >>>>>>> Apex" challenge proposed.  These include 
> > >>>>>>> [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others.
> > >>>>>>> Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 
> > >>>>>>> Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 
> > >>>>>>> Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 
> > >>>>>>> Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, 
> > >>>>>>> Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many 
> > >>>>>>> others for their feedback and suggestions on this draft.
> > >>>>>>> Suggested:
> > >>>>>>> 15.  Related Proposals
> > >>>>>>> Over the years, there has been a wide range of proposed solutions to 
> > >>>>>>> the zone-apex CNAME challenge.  These include [HTTP-DNS-RR], 
> > >>>>>>> [ANAME-DNS-RR], and others.
> > >>>>>>> ...
> > >>>>>>> Acknowledgments
> > >>>>>>> Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 
> > >>>>>>> Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 
> > >>>>>>> Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 
> > >>>>>>> Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, 
> > >>>>>>> Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many 
> > >>>>>>> others for their feedback and suggestions on this document. -->
> > >>>>>>> 26) <!-- [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.
> > >>>>>>> For example, please consider whether the following should be updated:
> > >>>>>>> whitespace (whitespace-separated list, internal whitespace)
> > >>>>>>> -->
> > >>>>>>> 27) <!-- [rfced] Please let us know if any changes are needed for 
> > >>>>>>> the
> > >>>>>>> following:
> > >>>>>>> a) The following terms were used inconsistently in this document.
> > >>>>>>> We chose to use the latter forms.  Please let us know any objections.
> > >>>>>>> Alt-Svc Field Value / Alt-Svc field value (per [AltSvc])  attrleaf 
> > >>>>>>> label / Attrleaf label (per [Attrleaf])
> > >>>>>>> IPv6 hint / ipv6hint (per three of the four companion documents)
> > >>>>>>>  (https://www.rfc-editor.org/cluster_info.php?cid=C461 ))
> > >>>>>>> key Name / key name
> > >>>>>>> RRType (titles of Sections 14.1 and 14.2) / RR Type (per
> > >>>>>>>  approx. 40 instances of "RR type" in text)  wire-format  / 
> > >>>>>>> wireformat / wire format (noun)
> > >>>>>>>  (per "wire format" in companion document draft-ietf-add-svcb-dns)  
> > >>>>>>> zone file (adj.) / zone-file (adj.)
> > >>>>>>> b) The following terms appear to be used inconsistently in this 
> > >>>>>>> document.  Please let us know which form is preferred.
> > >>>>>>> Additional record / additional record (We also see
> > >>>>>>>  "Additionals" and "Additional A records" in Section 4.2.1.)  
> > >>>>>>> additional section / Additional section / Additional Section  mode / 
> > >>>>>>> Mode ("two modes", "same Mode", "connection modes")  Multi-CDN ("A 
> > >>>>>>> Multi-CDN customer domain") /
> > >>>>>>>  multi-CDN ("a multi-CDN configuration")
> > >>>>>>>  (We suggest lowercase, based on past usage in RFCs.)  Name MUST / 
> > >>>>>>> name MUST (Section 14.3.1)
> > >>>>>>> c) Should lowercase "alpn" be written in text with or without quotes?
> > >>>>>>> alpn / "alpn" ('e.g., alpn', 'e.g., URIs or "alpn"')  Also, should 
> > >>>>>>> 'non-default alpn' be 'non-default ALPN' or
> > >>>>>>>  perhaps 'non-default "alpn"'?
> > >>>>>>> d) May we change the instances of "RRSet" to "RRset"?  We see that 
> > >>>>>>> the latter form is used much more often in RFCs from RFC 6000 
> > >>>>>>> onwards.-->
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>>>> On Sep 8, 2023, [e-mail] wrote:
> > >>>>>>>> *****IMPORTANT*****
> > >>>>>>>> Updated 2023/09/08
> > >>>>>>>> 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/rfc9460.xml   
> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9460.html   
> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9460.pdf   
> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9460.txt   
> > >>>>>>>> Diff file of the text:
> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9460-diff.html   
> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html    (side by side)
> > >>>>>>>> Diff of the XML:   https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html   
> > >>>>>>>> This diff file compares an altered original and the RFC (in order to make the changes in moved text viewable):
> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9460-alt-diff.html   
> > >>>>>>>> Tracking progress
> > >>>>>>>> -----------------
> > >>>>>>>> The details of the AUTH48 status of your document are here:
> > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9460   
> > >>>>>>>> Please let us know if you have any questions.   Thank you for your cooperation,
> > >>>>>>>> RFC Editor
> > >>>>>>>> --------------------------------------
> > >>>>>>>> RFC9460 (draft-ietf-dnsop-svcb-https-12)
> > >>>>>>>> Title            : Service Binding and Parameter Specification via the DNS (DNS SVCB and HTTPS Resource Records (RRs))
> > >>>>>>>> Author(s)        : B. Schwartz, M. Bishop, E. Nygren
> > >>>>>>>> WG Chair(s)      : Suzanne Woolf, Benno Overeinder, Tim Wicinski
> > >>>>>>>> Area Director(s) : Warren Kumari, Robert Wilton
> > >>>>>>> <rfc9460.xml>
> > >>>>>> 
> > >>>>>> <rfc9460.xml>
> > >>>>> 
> > >>>> 
> > >>> 
> > >> 
> > >