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

[Warren Kumari <[e-mail]>]

LGTM

Thank you!
W


On Fri, Oct 27, 2023 at 5:44 PM, Lynne Bartholomew <[e-mail]>
wrote:

> 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- ads@
> ietf.org; [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- ads@ietf.
> org <[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- editor@
> rfc-editor.org <[e-mail]>; [e-mail]<ietf@bemasc.
> net>; 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]>; auth48archive@
> rfc-editor.org <[e-mail]>; TLS Chairs <tls-chairs@
> ietf.org>
> 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: iana-matrix-comment@
> iana.org; 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- chairs@ietf.
> org>; 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- editor@
> rfc-editor.org <[e-mail]>; dnsop- [e-mail]<dnsop-ads@
> ietf.org>; [e-mail] <dnsop- [e-mail]>;tjw.ietf@gmail.
> com <[e-mail]>; [e-mail]<auth48archive@
> rfc-editor.org> 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- editor@
> rfc-editor.org; [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- editor@rfc-editor.
> org>; [e-mail] <[e-mail]>; [e-mail]
> <dnsop-
> [e-mail]>;[e-mail]<[e-mail]>; auth48archive@
> rfc-editor.org <[e-mail]> Subject: Re: AUTH48:
> RFC-to-be 9460 <draft-ietf-dnsop-svcb- https-12> for your review
> !-------------------------------------------------------------------
> |
> This Message Is From an External Sender
> |-------------------------------------------------------------------
> ! Hi, Mike. Thank you for the latest updated XML file! We made the
> additional update (changed "in" to "per") per your note for
> 1) below.
> FYI that the new line breaks in the list in Section 1.2 constitute a bug (
> https://github.com/ietf-
> tools/xml2rfc/issues/1045). We hope that this issue will be resolved soon.
> The latest files are posted here (please refresh your browser):
> https://www.rfc-editor.org/authors/rfc9460.txt
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html https://www.rfc-editor.org/
> authors/rfc9460-
> auth48diff.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];tjw.
> [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
>
>