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

[Amanda Baber via RT <[e-mail]>]

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