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

[Lynne Bartholomew <[e-mail]>]

Hi, Rob and Warren.

Rob, thanks for the email, and sorry for the misdirect.  We've updated <https://www.rfc-editor.org/auth48/rfc9460> to list Warren as the RAD.

Warren, could you please review the 24 Oct. emails below (and the latest files, if you want) and let us know if you approve?  At this point, we want to confirm that the reference mismatch ("N/A" in this document versus "[RFC-ietf-dnsop-svcb-https-12]" (to be changed to "[RFC9460]" after publication) on <https://www.iana.org/assignments/dns-svcb>) is acceptable. 

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 Oct 27, 2023, at 3:35 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Lynne, Warren,
> 
> Having checked, the proposed change looks fine to me, but I'm not sure if we actually need Warren's approval instead (he is the RAD for this document).
> 
> Regards,
> Rob
> 
> 
>> -----Original Message-----
>> From: Lynne Bartholomew <[e-mail]>
>> Sent: Tuesday, October 24, 2023 11:35 PM
>> To: [e-mail]
>> Cc: Ben Schwartz <[e-mail]>; Warren Kumari
>> <[e-mail]>; [e-mail]; [e-mail]; Rob Wilton
>> (rwilton) <[e-mail]>; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]; dnsop-
>> [e-mail]; [e-mail]
>> Subject: Re: [IANA #1284364] [IANA] Re: AUTH48: RFC-to-be 9460 <draft-ietf-
>> dnsop-svcb-https-12> for your review
>> 
>> Hi, Amanda.  Thank you for the quick turnaround!
>> 
>> RFC Editor/lb
>> 
>>> On Oct 24, 2023, at 11:05 AM, Amanda Baber via RT <[e-mail]>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> We've updated the registration to read as follows:
>>> 
>>> Number: 5
>>> Name: ech
>>> Meaning: RESERVED (held for Encrypted ClientHello)
>>> Change Controller: IETF
>>> Reference: [RFC-ietf-dnsop-svcb-https-12]
>>> 
>>> Please see
>>> https://www.iana.org/assignments/dns-svcb
>>> 
>>> Amanda
>>> 
>>> On Tue Oct 24 16:19:04 2023, [e-mail] wrote:
>>>> Hi, Ben, *IANA, and **Rob.
>>>> 
>>>> IANA, please update <https://www.iana.org/assignments/dns-svcb/> per
>>>> per Ben's note below.
>>>> 
>>>> **Rob and Ben, please confirm that the reference mismatch ("N/A" in
>>>> this document versus "[RFC-ietf-dnsop-svcb-https-12]" (to be changed
>>>> to "[RFC9460]" after publication) on the IANA page) is acceptable.
>>>> 
>>>> Thank you!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>>> On Oct 24, 2023, at 8:36 AM, Ben Schwartz <[e-mail]> wrote:
>>>>> 
>>>>> The requested change in the IANA registry is:
>>>>> 
>>>>> OLD
>>>>> RESERVED (will be used for ECH)
>>>>> 
>>>>> NEW
>>>>> RESERVED (held for Encrypted ClientHello)
>>>>> 
>>>>> --Ben SchwartzFrom: Lynne Bartholomew <[e-mail]>
>>>>> Sent: Monday, October 23, 2023 5:10 PM
>>>>> To: Ben Schwartz <[e-mail]>
>>>>> Cc: Erik Nygren <[e-mail]>; Mike Bishop
>>>>> <[e-mail]>; Warren Kumari <[e-mail]>; iana-
>>>>> [e-mail] <[e-mail]>; dnsop-
>>>>> [e-mail] <[e-mail]>; Rob Wilton <[e-mail]>;
>>>>> Tim Wicinski <[e-mail]>; [e-mail] <rfc-
>>>>> [e-mail]>; [e-mail] <[e-mail]>; dnsop-
>>>>> chairs <[e-mail]>; [e-mail]
>>>>> <[e-mail]>; TLS Chairs <[e-mail]>
>>>>> Subject: Re: *[AD] Re: [IANA #1284364] [IANA] Re: AUTH48: RFC-to-be
>>>>> 9460 <draft-ietf-dnsop-svcb-https-12> for your review
>>>>> !-------------------------------------------------------------------
>>>>> |
>>>>> This Message Is From an External Sender
>>>>> 
>>>>> |-------------------------------------------------------------------!
>>>>> 
>>>>> Hi, Ben.
>>>>> 
>>>>> Can you please clarify what that update to the document might be,
>>>>> using "OLD" and "NEW" text?
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On Oct 23, 2023, at 9:26 AM, Ben Schwartz <[e-mail]> wrote:
>>>>>> 
>>>>>> RFC-to-be 9460 does request a change to the "Meaning" field that
>>>>>> has not yet been implemented on iana.org, so I think it's fair to
>>>>>> say that the IANA registry is not "in sync" with that document, and
>>>>>> an update is requested.
>>>>>> 
>>>>>> --BenFrom: Lynne Bartholomew <[e-mail]>
>>>>>> Sent: Monday, October 23, 2023 12:22 PM
>>>>>> To: Erik Nygren <[e-mail]>; Mike Bishop
>>>>>> <[e-mail]>; Warren Kumari <[e-mail]>; Ben
>>>>>> Schwartz <[e-mail]>
>>>>>> Cc: [e-mail] <[e-mail]>;
>>>>>> [e-mail] <[e-mail]>; Rob Wilton
>>>>>> <[e-mail]>; Tim Wicinski <[e-mail]>; rfc-
>>>>>> [e-mail] <[e-mail]>;
>>>>>> [e-mail]<[e-mail]>; dnsop-chairs <dnsop-
>>>>>> [e-mail]>; [e-mail] <auth48archive@rfc-
>>>>>> editor.org>; TLS Chairs <[e-mail]>
>>>>>> Subject: Re: *[AD] Re: [IANA #1284364] [IANA] Re: AUTH48: RFC-to-be
>>>>>> 9460 <draft-ietf-dnsop-svcb-https-12> for your review
>>>>>> !-------------------------------------------------------------------
>>>>>> |
>>>>>> This Message Is From an External Sender
>>>>>> 
>>>>>> |-------------------------------------------------------------------
>>>>>> !
>>>>>> 
>>>>>> Hello, all.
>>>>>> 
>>>>>> It is not clear to us whether or not further changes are required
>>>>>> for this document.
>>>>>> Currently (best viewed with a fixed-point font):
>>>>>> 
>> +===========+=================+================+=========+======
>> ====+
>>>>>>  |Number     | Name            | Meaning        |Reference|Change
>>>>>> |
>>>>>>  |           |                 |                |
>>>>>> |Controller|
>>>>>> 
>> +===========+=================+================+=========+======
>> ====+
>>>>>> ...
>>>>>>  +-----------+-----------------+----------------+---------
>>>>>> +----------+
>>>>>>  |5          | ech             | RESERVED       |N/A      |IETF
>>>>>> |
>>>>>>  |           |                 | (held for      |         |
>>>>>> |
>>>>>>  |           |                 | Encrypted      |         |
>>>>>> |
>>>>>>  |           |                 | ClientHello)   |         |
>>>>>> |
>>>>>>  +-----------+-----------------+----------------+---------
>>>>>> +----------+
>>>>>> 
>>>>>> The corresponding IANA entry (which would normally match) on
>>>>>> <https://www.iana.org/assignments/dns-svcb/ >:
>>>>>>   Number  Name  Meaning                          Change
>>>>>> Controller   Reference
>>>>>> ...
>>>>>>  5       ech   RESERVED (will be used for ECH)  IETF
>>>>>> [RFC-ietf-dnsop-svcb-https-12]
>>>>>> 
>>>>>> Please let us know if this mismatch is acceptable.
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/lb
>>>>>> 
>>>>>> 
>>>>>>> On Oct 23, 2023, at 8:31 AM, Ben Schwartz <[e-mail]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Given the large-scale rollout of ECH, and the fact that ECHConfig
>>>>>>> is internally versioned, there's simply no scenario in which we
>>>>>>> change this codepoint.  "ech" is and will be codepoint 5.
>>>>>>> 
>>>>>>> There are some process questions about which document owns that
>>>>>>> row during this awkward interim period, but the current registry
>>>>>>> contents look great [1] and I think our best strategy for now is
>>>>>>> to declare victory and move on.
>>>>>>> 
>>>>>>> --Ben
>>>>>>> 
>>>>>>> [1] https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml
>>>>>>> From: Erik Nygren <[e-mail]>
>>>>>> 
>>>>>>> Sent: Monday, October 23, 2023 11:19 AM
>>>>>>> To: Mike Bishop <[e-mail]>
>>>>>>> Cc: Warren Kumari <[e-mail]>; Lynne Bartholomew
>>>>>>> <[e-mail]>; [e-mail] <iana-
>>>>>>> [e-mail]>; [e-mail]<[e-mail]>;
>>>>>>> Rob Wilton <[e-mail]>; Tim Wicinski
>>>>>>> <[e-mail]>; [e-mail] <rfc-editor@rfc-
>>>>>>> editor.org>; [e-mail]<[e-mail]>; dnsop-chairs
>>>>>>> <[e-mail]>; Ben Schwartz <[e-mail]>;
>>>>>>> [e-mail] <[e-mail]>; TLS
>>>>>>> Chairs <[e-mail]>
>>>>>>> Subject: Re: *[AD] Re: [IANA #1284364] [IANA] Re: AUTH48: RFC-to-
>>>>>>> be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
>>>>>>> This Message Is From an External Sender
>>>>>>> 
>>>>>>> + TLS Chairs
>>>>>>> 
>>>>>>> There are also implementations using this codepoint so if major
>>>>>>> changes are needed that don't fit into the versioning supported
>>>>>>> in ECHConfig then we might already need to switch to a new
>>>>>>> codepoint.  As Mike mentioned, the TLS WG was also discussing
>>>>>>> requesting a SvcParam codepoint for this so we might be at the
>>>>>>> right point for that.
>>>>>>> 
>>>>>>> On Mon, Oct 23, 2023, 5:05 PM Mike Bishop <[e-mail]>
>>>>>>> wrote:
>>>>>>> This entry was originally used by this document; when that was
>>>>>>> extracted out, this document “Reserved” it for the future use of
>>>>>>> ECH to ensure the codepoint doesn’t get allocated elsewhere. I
>>>>>>> don’t see why we really care where the reservation points, so
>>>>>>> long as it’s reserved.  It would be formally allocated when some
>>>>>>> ECH document is published to make use of it.
>>>>>>> 
>>>>>>> Frankly, I think we’d also be fine to drop the reservation –
>>>>>>> there’s already an adopted document that requests the assignment
>>>>>>> of this codepoint, so as a practical matter I don’t think it will
>>>>>>> get stomped on.
>>>>>> 
>>>>>>> From: Warren Kumari <[e-mail]>
>>>>>>> Sent: Saturday, October 21, 2023 3:49 PM
>>>>>>> To: Lynne Bartholomew <[e-mail]>
>>>>>>> Cc: [e-mail]; Erik Nygren <[e-mail]>;
>>>>>>> [e-mail]; Rob Wilton <[e-mail]>; Tim Wicinski
>>>>>>> <[e-mail]>; [e-mail]; Mike Bishop
>>>>>>> <[e-mail]>; [e-mail]; dnsop-chairs <dnsop-
>>>>>>> [e-mail]>; Ben Schwartz <[e-mail]>;
>>>>>>> [e-mail]
>>>>>>> Subject: Re: *[AD] Re: [IANA #1284364] [IANA] Re: AUTH48: RFC-to-
>>>>>>> be 9460 <draft-ietf-dnsop-svcb-https-12> for your review
>>>>>>> 
>>>>>>> On Fri, Oct 20, 2023 at 11:59 PM, Lynne Bartholomew
>>>>>>> <[e-mail]> wrote:
>>>>>>> Hi, Amanda, Erik, and *AD (Warren or Rob). Amanda, thank you for
>>>>>>> making the updates! All looks good (but we're asking the AD about
>>>>>>> the updated "ech" entry).
>>>>>>> Erik, thank you for your suggestion. * Warren or Rob, please see
>>>>>>> Erik's suggestion re. a reference for the "ech" entry, and let us
>>>>>>> know if that suggested update in this document and on
>>>>>>> <https://www.iana.org/assignments/dns-svcb > would be acceptable.
>>>>>>> Please see <https://www.rfc-
>>>>>>> editor.org/authors/rfc9460.html#table-1 > and IANA's note below.
>>>>>>> 
>>>>>>> Erm, I think I got lost somewhere in the (many) levels of
>>>>>>> quoting…
>>>>>>> Doesn't that mean that the reference would be to a (currently in
>>>>>>> progress) draft? Is this OK? What if the draft significantly
>>>>>>> changes?
>>>>>>> W
>>>>>>> 
>>>>>>> Thanks again! RFC Editor/lb On Oct 19, 2023, at 5:09 PM, Erik
>>>>>>> Nygren <[e-mail]> wrote:
>>>>>>> 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 on26 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.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> rfcdiff.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> auth48diff.html   https://www.rfc-editor.org/authors/rfc9460-
>>>>>>> lastdiff.htmlhttps://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.htmlhttps://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.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> auth48diff.html   https://www.rfc-editor.org/authors/rfc9460-
>>>>>>> lastdiff.htmlhttps://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.htmlhttps://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] <[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. 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.htmlhttps://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.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> rfcdiff.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> auth48diff.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> lastdiff.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> lastrfcdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9460-
>>>>>>> xmldiff1.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> xmldiff2.htmlhttps://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.comline 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];dnsop-
>>>>>>> [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.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> rfcdiff.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> auth48diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9460-alt-
>>>>>>> diff.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> xmldiff1.htmlhttps://www.rfc-editor.org/authors/rfc9460-
>>>>>>> xmldiff2.htmlhttps://www.rfc-editor.org/authors/rfc9460-alt-
>>>>>>> diff.htmlThank   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 1example.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 1example.com.
>>>>>>> ipv6hint="2001:db8:122:344::192.0.2.33"
>>>>>>> Possibly:
>>>>>>> example.com. SVCB 1example.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" S
>>> 
>