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

[Erik Nygren <[e-mail]>]

Another option for the reference for "ech" would be to
"draft-ietf-tls-svcb-ech-00" which is where that portion of the format
specification has moved to and where the TLS WG is working on it.

Thanks, Erik

On Thu, Oct 19, 2023 at 8:01 PM Amanda Baber via RT <
[e-mail]> wrote:

> Hi,
>
> We've completed these changes, but need to make a note about the second
> one:
>
> On Wed Oct 18 19:43:35 2023, [e-mail] wrote:
> > Dear IANA,
> >
> > We are preparing this document for publication.
> >
> > Please make the following updates to the "Resource Record (RR) TYPEs"
> > registry on
> >   <https://www.iana.org/assignments/dns-parameters/>:
> >
> > OLD:
> > General Purpose Service Binding
> > Service Binding type for use with HTTP
> >
> > NEW:
> > General-purpose service binding
> > SVCB-compatible type for use with HTTP
>
> This is complete:
>
> https://www.iana.org/assignments/dns-parameters
>
> > = = = = =
> >
> > Please make the following update to the "Service Parameter Keys
> > (SvcParamKeys)" registry on
> > <https://www.iana.org/assignments/dns-svcb/>:
> >
> > OLD (column name):
> > Format Reference
> >
> > NEW:
> > Reference
>
> The Service Parameter Keys (SvcParamKeys) registry originally had the
> "Format Reference" field populated by the document and a "Reference" field
> added by IANA. Aside from the entry for "ech", which was filled in with
> "N/A", the former contained either a more detailed version of IANA's
> reference or the same reference.
>
> We've removed IANA's "Reference" field and changed the name of the "Format
> Reference" field to "Reference," but we've also replaced "N/A" with
> "[RFC-ietf-dnsop-svcb-https-12]" for "ech", so as to avoid leaving that
> entry unreferenced:
>
> https://www.iana.org/assignments/dns-svcb
>
> thanks,
> Amanda
>
> > Thank you!
> >
> > RFC Editor/lb
> >
> >
> > > On Oct 18, 2023, at 12:31 PM, Lynne Bartholomew
> > > <[e-mail]> wrote:
> > >
> > > Hi, Ben.  Great; thanks!
> > >
> > > RFC Editor/lb
> > >
> > >> On Oct 18, 2023, at 12:26 PM, Ben Schwartz <[e-mail]> wrote:
> > >>
> > >> Correct.
> > >>
> > >>> On Oct 18, 2023, at 11:26 AM, Lynne Bartholomew
> > >>> <[e-mail]> wrote:
> > >>>
> > >>> 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]>; rfc-
> > >>>> [e-mail] <[e-mail]>; dnsop-
> > >>>> [e-mail] <[e-mail]>; [e-mail] <dnsop-
> > >>>> [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]; rfc-editor@rfc-
> > >>>>> editor.org; [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]; rfc-
> > >>>>>>>> [e-mail]; [e-mail]; dnsop-
> > >>>>>>>> [e-mail]; [e-mail]; auth48archive@rfc-
> > >>>>>>>> editor.org
> > >>>>>>>> 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] <rfc-
> > >>>>>>>>> [e-mail]>; [e-mail] <dnsop-
> > >>>>>>>>> [e-mail]>; [e-mail] <[e-mail]>;
> > >>>>>>>>> [e-mail]<[e-mail]>; auth48archive@rfc-
> > >>>>>>>>> editor.org <[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]; rfc-editor@rfc-
> > >>>>>>>>>> editor.org; [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>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>
>
>