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

[Lynne Bartholomew <[e-mail]>]

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
>