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]>]

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 <iana-matrix-comment@
> iana.org> 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] <
> [e-mail]>; [e-mail] <dnsop- [e-mail]>; tjw.
> [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]> Subject: Re: AUTH48: RFC-to-be 9460
> <draft-ietf-dnsop-svcb-https- 12> for your review
> !-------------------------------------------------------------------
> |
> This Message Is From an External Sender
>
> |-------------------------------------------------------------------
> !
>
> Hi, Mike. So noted:
>
> https://www.rfc-editor.org/auth48/rfc9460
>
> Before we ask IANA to make updates per changes made to this document, we
> first want to confirm that, per AUTH48 XML updates that you sent us on 26
> September, we also need to ask for the following change on <https://www.
> iana.org/assignments/dns-svcb/ >:
>
> OLD (column name):
> Format Reference
>
> NEW:
> Reference
>
> Please let us know about the above. We will wait to hear from you before
> proceeding.
>
> Thank you!
>
> RFC Editor/lb
>
> On Oct 17, 2023, at 12:52 PM, Mike Bishop <[e-mail]> wrote:
>
> Approved -- thanks to everyone for their work on this.
>
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]> Sent: Monday, October 16,
> 2023 11:30 AM
> To: Erik Nygren <[e-mail]>
> Cc: Ben Schwartz <[e-mail]>; Mike Bishop
> <[e-mail]>; [e-mail]; rfc-editor@rfc- editor.org;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https- 12> for
> your review
>
> Hi, Erik. Thank you for confirming your approval!
>
> RFC Editor/lb
>
> On Oct 15, 2023, at 6:45 AM, Erik Nygren <[e-mail]> wrote:
>
> I just looked at the latest and it looks good to me.
>
> Thanks! Erik
>
> On Fri, Oct 13, 2023 at 5:53 PM Lynne Bartholomew
> <[e-mail]> wrote:
> Hi, Erik, Ben, and Mike.
>
> Ben and Mike, we have made further updates to this document per your notes
> below.
>
> The latest files are posted here (please refresh your browser):
>
> https://www.rfc-editor.org/authors/rfc9460.txt
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html https://www.rfc-editor.org/
> authors/rfc9460-auth48diff.html https://www.rfc-editor.org/authors/
> rfc9460-lastdiff.html https://www.rfc-editor.org/authors/
> rfc9460-lastrfcdiff.html
>
> https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html https://www.
> rfc-editor.org/authors/rfc9460-xmldiff2.html https://www.rfc-editor.org/
> authors/rfc9460-alt-diff.html
>
> Erik and Ben, we have noted your approvals on the AUTH48 status page.
> Please note, however, that if you object to any subsequent updates to this
> document you will let us know:
>
> https://www.rfc-editor.org/auth48/rfc9460
>
> Thank you!
>
> RFC Editor/lb
>
> On Oct 12, 2023, at 2:05 PM, Mike Bishop <[e-mail]> wrote:
>
> I’ve finished my final read-through. These are minor issues, and
> everything else looks fine.
>
> I caught a few uses of the first-person through the document. I suggest:
>
> • Section 1.3: “Our terminology…” => “Terminology in this document…”
>
> • Section 2.3: “We term this behavior "Port Prefix Naming" and use it in
> the examples throughout this document.” => “This document terms this
> behavior "Port Prefix Naming" and uses it in the examples throughout.”
>
> • Appendix A: “Here, we summarize…” => “The following summarizes…”
>
> • Appendix C: “…by providing an extensible solution that solves multiple
> problems we will overcome this inertia…” => “…an extensible solution that
> solves multiple problems will overcome this inertia…”
>
> There is a nested parenthetical in 2.3. I suggest the following:
>
> Current:
> (Parentheses are used to ignore a line break in DNS zone-file presentation
> format ([RFC1035], Section 5.1).)
>
> Proposed:
> (Parentheses are used to ignore a line break in DNS zone-file presentation
> format, per Section 5.1 of [RFC1035].)
>
> On Oct 11, 2023, at 10:51 AM, Ben Schwartz <[e-mail]> wrote:
>
> The caption of Figure 10 is 'An alpn Value with ...'. I believe "alpn"
> should be quoted for consistency, resulting in
> 'An "alpn" Value with ...".
>
> Apart from that suggestion, I approve this version for publication.
>
> --Ben Schwartz
>
> On Oct 11, 2023, at 10:34 AM, Erik Nygren <[e-mail]> wrote:
>
> Approved from my perspective! (Assuming no objections from Mike or Ben.)
>
> Best, Erik
>
> On Wed, Oct 11, 2023 at 12:11 PM Lynne Bartholomew
> <[e-mail]> wrote:
> Hi, Erik.
>
> We have updated this document per your note below.
>
> The latest files are posted here (please refresh your browser):
>
> https://www.rfc-editor.org/authors/rfc9460.txt
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html https://www.rfc-editor.org/
> authors/rfc9460-auth48diff.html https://www.rfc-editor.org/authors/
> rfc9460-lastdiff.html https://www.rfc-editor.org/authors/
> rfc9460-lastrfcdiff.html
>
> https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html https://www.
> rfc-editor.org/authors/rfc9460-xmldiff2.html https://www.rfc-editor.org/
> authors/rfc9460-alt-diff.html
>
> We will wait to hear from your coauthors regarding any subsequent changes
> before noting anyone's approval.
>
> Thank you!
>
> RFC Editor/lb
>
> On Oct 10, 2023, at 2:13 PM, Erik Nygren <[e-mail]> wrote:
>
> I took a final reading pass through and the only thing that jumped out
> would be to change this:
>
> - "," and "\" characters instead of implementing the
> <tt>value-list</tt> escaping
> + "," and "\" characters in ALPN IDs instead of implementing the
> <tt>value-list</tt> escaping
>
> The current text is ambiguous as to whether those characters are
> prohibited in ALPN IDs or prohibited in value-list. It is clear that the
> intent is for them to only be prohibited in ALPN IDs so that value-list can
> contain commas, but inserting the "in ALPN IDs" would reduce risk of
> misreading.
> Everything else looks good.
>
> I believe Mike and Ben are making similar read-throughs.
>
> Thanks, Erik
>
> On Fri, Oct 6, 2023 at 4:30 PM Mike Bishop
> <[e-mail]> wrote:
> Ben proposed this text on GitHub:
>
> In this document, this algorithm is referred to as "character- string
> decoding", because
> <xref target="RFC1035" sectionFormat="of" section="5.1"/> uses this
> algorithm to produce a <tt>&lt;character-string&gt;</tt>.
>
> (And a corresponding "the allowed input" => "some allowed inputs".)
>
> The attached XML incorporates this proposal, if that works for everyone.
>
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]> Sent: Thursday, October
> 5, 2023 12:32 PM
> To: Erik Nygren <[e-mail]>; Ben Schwartz
> <[e-mail]>
> Cc: Mike Bishop <[e-mail]>; [e-mail]; rfc- 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] <dnsop- [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail]<[e-mail]>;
> auth48archive@rfc- editor.org <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb- https-12> for
> your review
> !-------------------------------------------------------------------
> |
> This Message Is From an External Sender
>
> |-------------------------------------------------------------------
> !
>
> Hi, Mike.
>
> Thank you for the latest updated XML file!
>
> We made the additional update (changed "in" to "per") per your note for 1)
> below.
>
> FYI that the new line breaks in the list in Section 1.2 constitute a bug (
> https://github.com/ietf-
> tools/xml2rfc/issues/1045). We hope that this issue will be resolved soon.
>
> The latest files are posted here (please refresh your browser):
>
> https://www.rfc-editor.org/authors/rfc9460.txt
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html https://www.rfc-editor.org/
> authors/rfc9460-auth48diff.html https://www.rfc-editor.org/authors/
> rfc9460-lastdiff.html https://www.rfc-editor.org/authors/
> rfc9460-lastrfcdiff.html
>
> https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html https://www.
> rfc-editor.org/authors/rfc9460-xmldiff2.html https://www.rfc-editor.org/
> authors/rfc9460-alt-diff.html
>
> Thanks again!
>
> RFC Editor/lb
>
> On Sep 29, 2023, at 11:52 AM, Mike Bishop
> <[e-mail]> wrote:
>
> 1) This is fine.
>
> 2) All reasonable, but we'd prefer to avoid nested parentheses. In the
> attached, we've changed this to
> "supported protocols" in 3.2 and moved the expansion back to
> 7.1.
>
> We also noted in reviewing the change to the title of Figure 1 that this
> URL was not quoted, so we've added those.
>
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]> Sent: Thursday, September
> 28, 2023 11:48 AM
> To: Mike Bishop <[e-mail]>
> Cc: [e-mail]; [e-mail]; rfc-editor@rfc- editor.org;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb- https-12> for
> your review
>
> Hi, Mike.
>
> Thank you very much for the updated XML file!
>
> Thanks also for the detailed list of updates after your
> "late-arriving review from the DNS Directorate" note; your note informed
> us that we would not need to ask for AD approval for any of those updates;
> very helpful and much appreciated!
>
> A couple follow-up items for you:
>
> 1) "used to produce a <character-string> in Section 5.1 of
> [RFC1035]" reads a bit oddly. May we change it to "used to produce a
> <character-string> per Section 5.1 of [RFC1035]"?
>
> 2) Please note that per our style guidelines we made the following updates
> to your copy:
>
> * Moved the expansion of "ALPN" from Section 7.1 to Section
> 3.2.
> * Changed "Section 2.4.2 and Section 3" to "Sections 2.4.2 and 3" in
> Section 9.1.
> * Changed "At" to "at" in the title of Figure 1.
>
> The latest files are posted here:
>
> https://www.rfc-editor.org/authors/rfc9460.txt
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html https://www.rfc-editor.org/
> authors/rfc9460-auth48diff.html https://www.rfc-editor.org/authors/
> rfc9460-lastdiff.html https://www.rfc-editor.org/authors/
> rfc9460-lastrfcdiff.html
>
> https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html https://www.
> rfc-editor.org/authors/rfc9460-xmldiff2.html https://www.rfc-editor.org/
> authors/rfc9460-alt-diff.html
>
> Again, many thanks for your help with this document!
>
> RFC Editor/lb
>
> On Sep 26, 2023, at 11:40 AM, Mike Bishop
> <[e-mail]> wrote:
>
> Hi, Lynne -
> Please see attached an updated XML from our side, with the following
> changes in response to your questions.
>
> • We expanded "RR" in the document title. Please let us know any
> objections.
> We have adjusted the title to expand the initialism while avoiding nested
> parentheses.
> Original:
> Service Binding and Parameter Specification via the DNS
> (DNS SVCB and
> HTTPS Resource Records (RRs))
> Current:
> Service Binding and Parameter Specification via the DNS
> (SVCB and
> HTTPS Resource Records)
>
> 2. Please insert any keywords…
> We have added various relevant keywords.
>
> 3. Datatracker "idnits" output for the original approved document included
> the following warning … There are 2 instances of lines with
> non-RFC2606-compliant FQDNs
> These instances are false positives.
>
> 4. Section 1.1: We changed this section title, as it did not match the
> contents of the section. If this update is incorrect, perhaps some text is
> missing? If so, please clarify "goal" vs. "goals". We have accepted the new
> section title, and also corrected an obsolete reference to statements that
> were previously
> “mentioned above” but now appear later in the document. Original:
> (As mentioned above, this all
> applies equally to the HTTPS RR, which shares the same encoding,
> format, and high-level semantics.)
> Current:
> (As discussed in <xref target="svcb-compatible"/>, this all applies
> equally to the HTTPS RR, which shares the same encoding, format, and
> high-level semantics.)
>
> 5. Please review the "type" attribute of each sourcecode element…
> We have added types and converted “artwork” tags to
> “sourcecode” as appropriate.
>
> 6. Section 2.4.2: As it appears that
> "multiple" means "multiple RRs" (as opposed to "multiple RRSets"), we
> updated this sentence accordingly. If this is incorrect, please provide
> clarifying text.
> We have adjusted this to “multiple AliasMode RRs”.
>
> 7. Section 4.2: Is resolution of unknown RR types the only type of normal
> response construction, or should "i.e." ("that is") be "e.g." ("for
> example") here? Yes. For clarity, we’ve removed this use of “i.e.”
> entirely.
>
> 8. Section 4.3: Does "even if the contents are invalid" refer to the
> "MUST" clause, the "MAY" clause, or both?
> It refers to the “MAY” clause. To improve clarity, we’ve restructured this
> sentence and the following one.
> Original:
> Recursive resolvers <bcp14>MUST</bcp14> be able to convey SVCB records
> with unrecognized SvcParamKeys, and <bcp14>MAY</bcp14> treat the
> entire SvcParams portion of the record as opaque, even if the contents
> are invalid. Alternatively, recursive resolvers
> <bcp14>MAY</bcp14>
> report an error such as SERVFAIL to avoid returning a SvcParamValue that
> is invalid according to the SvcParam's specification.
> Current:
> Recursive resolvers <bcp14>MUST</bcp14> be able to convey SVCB records
> with unrecognized SvcParamKeys. Resolvers
> <bcp14>MAY</bcp14>
> accomplish this by treating the entire SvcParams portion of the record
> as opaque, even if the contents are invalid. If a recognized
> SvcParamKey is followed by a value that is invalid according to the
> SvcParam's specification, a recursive resolver
> <bcp14>MAY</bcp14>
> report an error such as SERVFAIL instead of returning the record.
>
> 9. Section 7.2: Should "this SvcParam" be
> "this SvcParamValue" here?
> Yes. (Corrected.)
>
> 10. Section 9.1: Please clarify the meaning of
> "Following of".
> We’ve clarified by reformulating this sentence and including references to
> the relevant sections where the behavior is defined.
> Original:
> Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB.
> Current:
> The procedure for following HTTPS AliasMode RRs
> and CNAME aliases is unchanged from SVCB (as described in
> <xref target="alias-mode"/> and <xref target="client- behavior"/>).
>
> 11. Should the instances of "9443" be "8443" here?
> No, this distinction is intentional.
>
> 12. Section 9.4 and Table 1: Does "ECH" refer to citations for
> draft-ietf-tls-esni and not to "Encrypted ClientHello" in general, or does
> it refer to some (unknown) future specification related to ECH (in which
> case the text should be clarified)?
> For clarity, we’ve replaced “ECH” here with that reference, and expanded
> the acronym where it appears in the IANA instructions. The assignment is
> currently captured in draft-sbn-tls-svcb-ech-00, which was extracted from
> this document. The TLS WG has adopted that document, and will need to
> decide whether to fold it into draft-ietf-tls-esni or advance it
> separately.
>
> 13. Section 9.6: Should 'HTTP URL' be '"http" URL'? … Also, we could not
> find any instances of
> "requestURL" in [WebSocket], any other published RFC, or
> [FETCH].
> We’ve replaced ‘HTTP URL” with the formal term defined in RFC 9110:
> “HTTP-related URI scheme”.
> Since we wrote this text, WHATWG has moved the definition of “requestURL”
> to a new document. We’ve fixed the problem by adding that reference here.
> Original:
> All HTTP connections to named origins are eligible to use HTTPS RRs,
> even when HTTP is used as part of another protocol or without an
> explicit HTTP URL. For example, clients that support HTTPS RRs and
> implement the altered WebSocket <xref target="RFC6455"/> opening
> handshake from the W3C Fetch specification <xref target="FETCH"/>
> <bcp14>SHOULD</bcp14> use HTTPS RRs for the
> <tt>requestURL</tt>.
> Current:
> All HTTP connections to named origins are eligible to use HTTPS RRs,
> even when HTTP is used as part of another protocol or without an
> explicit HTTP-related URI scheme (<relref target="RFC9110"
> section="4.2"/>). For example, clients that support HTTPS RRs and
> implement <xref target="RFC6455"/> using the altered opening handshake
> from <xref target="FETCH-WEBSOCKETS"/>
> <bcp14>SHOULD</bcp14> use HTTPS RRs for the
> <tt>requestURL</tt>.
>
> 14. Section 10.3: We had trouble following
> "various interpretations of RFCs" in the first sentence… We’ve replaced
> this vague statement by a reference to the BIND documentation for the
> behavior in question.
> Original:
> Note that some implementations may not allow A or AAAA records on
> names starting with an underscore due to various
> interpretations of RFCs.
> This could be an operational issue when the TargetName contains an
> Attrleaf label, as well as using a TargetName of "." when the owner name
> contains an Attrleaf label.
> Current:
> Some authoritative DNS servers may not allow A or AAAA records on
> names starting with an underscore (e.g., <xref
> target="BIND-CHECK-NAMES"/>).
> This could create an operational issue when the TargetName contains an
> Attrleaf label, or when using a TargetName of "." if the owner name
> contains an Attrleaf label.
>
> 15. Section 11: We do not see the word
> "stapling" or "staple" in RFC 6066. Please confirm that this citation will
> be clear to readers.
> We’ve adjusted this sentence to expand “OCSP” and mention
> “Certificate Status Request”, which is the formal name from RFC 6066.
> (We’ve preserved the term “stapling” because it is much more widely
> understood and commonly used than the formal name.) Original:
> Server operators implementing this standard
> <bcp14>SHOULD</bcp14> also
> implement TLS 1.3 <xref target="RFC8446"/> and Online Certificate Status
> Protocol (OCSP) Stapling <xref target="RFC6066"/>, both of which confer
> substantial performance and
> privacy benefits when used in combination with SVCB records.
> Current:
> Server operators implementing this standard
> <bcp14>SHOULD</bcp14> also
> implement TLS 1.3 <xref target="RFC8446"/> and Online Certificate
> Status Protocol (OCSP) Stapling (i.e., Certificate Status Request in
> <xref target="RFC6066" section="8" sectionFormat="of"/>), both of
> which confer substantial performance and privacy benefits when used in
> combination with SVCB records.</t>
>
> 16. Section 12: "unintended access" reads oddly here. If the suggested
> text is not correct, should the word "unintended" be removed?
> We’ve rephrased this in a way that avoids the word
> “unintended” and improves specificity.
> Original:
> If the attacker can influence the
> client's payload (e.g., TLS session ticket contents) and an internal
> service has a sufficiently lax parser, it's possible that the attacker
> could gain unintended access.
> Current:
> If the attacker can influence the
> client's payload (e.g., TLS session ticket contents) and an internal
> service has a sufficiently lax parser, the attacker could gain access
> to the internal service.
>
> 17. FYI, we have changed two instances of
> "Service Binding" to "service binding" because it written in lowercase
> where used generally in this document. We will ask IANA…
> We’ve changed the description in the IANA instructions to use the
> more precise term “SVCB-compatible” instead. (The original IANA
> instructions may predate this term.)
>
> 18. The following ACTION text indicates that the
> "Service Parameter Keys (SvcParamKeys)" registry should appear on the
> "Domain Name System (DNS) Parameters" page. However, the registry appears
> on a page under the heading
> "DNS Service Bindings (SVCB)"
> This disparity may have occurred because IANA reorganized their website
> after the original instructions were written. The current location of the
> registry correctly reflects the authors’ intent, and we have updated the
> draft to describe the new location.
>
> 19. Because the IANA registry does not include a
> "Meaning" column, we have updated the text as shown below. Please let us
> know if any updates are required.
> This change is correct.
>
> 20. Appendix A: Because Section 3.3 of RFC 1035 says "<character-string>
> is treated as binary information, and can be up to 256 characters in length
> (including the length octet)", we updated this sentence to clarify the
> meaning of "same as". If this is incorrect, please provide text that
> clarifies the meaning of "same as".
> This change is not correct. We have adjusted the text to provide a clearer
> distinction between “<character-string>”
> (which is binary) and the textual representation used to generate it.
> Original:
> DNS zone files are capable of representing arbitrary octet sequences
> in basic ASCII text, using various delimiters and
> encodings. The
> algorithm for decoding these character strings is defined in <xref
> section="5.1" sectionFormat="of" target="RFC1035"/>.
> Current:
> DNS zone files are capable of representing arbitrary octet sequences
> in basic ASCII text, using various delimiters and
> encodings, according
> to an algorithm defined in <xref section="5.1" sectionFormat="of"
> target="RFC1035"/>. Original:
> In this document, this algorithm is referred to as
> "character-string decoding".
> The algorithm is the same as the guideline for
> <tt>&lt;character-string&gt;</tt> provided in <xref target="RFC1035"
> sectionFormat="of" section="3.3"/>, except that in this document the output
> length is not limited to 255 octets.
> Current:
> In this document, this algorithm is referred to as
> "character-string
> decoding", because it is used to produce a
> <tt>&lt;character-string&gt;</tt> in <xref target="RFC1035"
> sectionFormat="of" section="5.1"/>. Note that while the length of a
> <tt>&lt;character-string&gt;</tt> is limited to 255 octets, the
> character-string decoding algorithm can produce output of any
> length.</t>
>
> 21. Appendix C.4: We changed "the authoritative" at the end of this
> sentence to "the authoritative DNS server".
> This change is correct.
>
> 22. Appendix D.2: Do "target (root label)" and
> "target, root label" mean the same thing? If yes, should they both be
> expressed in the same way (i.e., either parentheses or comma)? Also, should
> "length: 2 bytes" be
> "length 2", per the format of all other "# length" and "; length" entries?
> Yes, these carry the same meaning. We have incorporated these changes to
> improve consistency.
>
> 23. The example.com line in Figure 8 extends beyond the 72-character
> limit.
> 24. Figure 8: The "example.com." line is too long…
> We have adjusted this figure as suggested to fit within the 72-character
> limit.
>
> 25. Figures 14 and 15: Should "mandatory" be written in the same way in
> both titles (i.e., either lowercase and quoted or initial-capitalized and
> unquoted)? No. In one case, it refers to an item that must be present; in
> the other it refers to the literal 9-character sequence “mandatory”.
>
> 26. "Acknowledgments and Related Proposals" reads oddly, in that the two
> ideas seem unrelated. "... proposed solutions ...challenge proposed" reads
> oddly as well. May we make a new Section 15 ("Related Proposals") …
> ?
> We’ve reformulated this paragraph to make clear that the related proposals
> are mentioned by way of acknowledgement and gratitude.
>
> 27. Please review the "Inclusive Language" portion of the online Style
> Guide …
> We have reviewed this guidance but did not find any changes that could be
> made on this basis.
>
> 28. Please let us know if any changes are needed for the following
> [capitalization consistency issues] We have attempted to correct these
> issues to improve consistency. In the case of ALPN, we have clarified some
> uses as “ALPN protocol” or “ALPN ID”.
> ------------
> Additionally, we made several edits in response to a late- arriving review
> from the DNS Directorate, as Warren indicated. These are highlighted below,
> in no particular order.
> # Positive and negative DNSSEC (Section 4.1)
> Original:
> If the zone is signed, the server SHOULD also include positive or
> negative DNSSEC responses for these records in the Additional section.
> Current:
> If the zone is signed, the server SHOULD also include DNSSEC records
> authenticating the existence or nonexistence of these records in the
> Additional section.
> # Use of “origin” for concepts other than HTTP origins
> - In 1.1, “an origin within the DNS” => “a service identified by a domain
> name”
> - In 3.1, “origin’s SVCB record” => “service’s SVCB record”
> - In 7.3, “origin hostname” => “service name”
> - In 9.3, “origin endpoint” => “authority endpoint”
> - In 12, “origin” => “authoritative server”
> # Use of “delegation” outside the sense of DNS zone delegation
> - In 1, “delegating the origin” => “aliasing the origin”
> - In 1.1, “delegation of operational authority for an origin within
> the DNS to an alternate name.” => “extending operational authority for
> a service identified by a domain name to other instances with
> alternate names.” (overlap with previous set)
> - In 1.1, “apex delegation” => “apex aliasing”
> - In 3.2, “It allows the service to delegate the apex domain.” => “It
> allows a service on an apex domain to use aliasing.”
> - In Figure 1 (caption), “Is Delegated to” => “Is Available At”
> # Inconsistency of terms for list and sorting in Section 3
> - “enumerating the priority-ordered endpoints” =>
> “enumerating and ordering the available endpoints”
> - Addition of “Sort the records by ascending SvcPriority.” to step 4.
> - “known endpoints” => “available endpoints”
> - “priority list” => “list of endpoints”
> - “the resolved list” => “this list”
> # Vague performance statements
> In 2.4.2, removed “which would likely improve performance”
> # No such thing as empty RRset
> Original:
> If the SVCB RRset contains no compatible RRs, the client will generally
> act as if the RRset is empty.
> Current:
> Incompatible RRs are ignored (see step 5 of the procedure defined in <xref
> target="client-behavior"/>).
> ------------
> Finally, with regard to the changes from our previous e- mail: The
> attached file incorporates your proposed changes. We have made one
> adjustment, where <tt> was already being used around a hostname which is
> now quoted. The
> combination is probably not necessary; for consistency, we can align on
> quotes.
> Original:
> When using the generic SVCB RR type with aliasing, zone owners
> <bcp14>SHOULD</bcp14> choose alias target names that indicate the
> scheme in use (e.g., <tt>"foosvc.example.net"</tt> for
> <tt>"foo://"</tt> schemes). This will help to avoid confusion when
> another scheme needs to be added to the configuration. When multiple
> port numbers are in use, it may be helpful to repeat the prefix labels in
> the alias target name (e.g.,
> <tt>"_1234._foo.svc.example.net"</tt>). Current:
> When using the generic SVCB RR type with aliasing, zone owners
> <bcp14>SHOULD</bcp14> choose alias target names that indicate the
> scheme in use (e.g., "foosvc.example.net" for "foo" schemes). This
> will help to avoid confusion when another scheme needs to be added to
> the configuration. When multiple port numbers are in use, it may be
> helpful to repeat the prefix labels in the alias target name (e.g., "
> _1234._foo.svc.example.net"). We have also removed the “://”, which is
> not properly part of the scheme.
>
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]> Sent: Friday, September
> 22, 2023 2:39 PM
> To: Mike Bishop <[e-mail]>; [e-mail]; erik+ietf@nygren.
> org
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail];
> [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop- svcb-https-12>
> for your review Hi, Mike and coauthors.
> Mike, apologies for our confusion with the emails
> yesterday. We have updated this document per your notes below. Please see
> our "[rfced]" notes inline. Also, apologies for an issue regarding an
> update to Section 14.4. The updated section is now correct. We also removed
> a duplicate question regarding Figure 8.
> The latest files are posted here. Please refresh your browser to view the
> latest updates and the updated list of questions:
> https://www.rfc-editor.org/authors/rfc9460.txt
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html https://www.rfc-editor.org/
> authors/rfc9460-
> auth48diff.html
> https://www.rfc-editor.org/authors/rfc9460-alt-diff.html https://www.
> rfc-editor.org/authors/rfc9460-xmldiff1.html https://www.rfc-editor.org/
> authors/rfc9460-xmldiff2.html https://www.rfc-editor.org/authors/
> rfc9460-alt-diff.html Thank you, and again, apologies for our confusion.
> RFC Editor/lb
>
> On Sep 20, 2023, at 1:33 PM, Mike Bishop
> <[e-mail]> wrote:
>
> A couple points from the copy-edits I wanted to discuss as we go through
> these….
> Under SVC Query Names, I see this change:
> Original:
>
> When querying the SVCB RR, a service is translated into a QNAME by
> prepending the service name with a label indicating the scheme,
> prefixed with an underscore, resulting in a domain name like "
> _examplescheme.api.example.com.".
>
> Current:
>
> When querying the SVCB RR, a service is translated into a QNAME by
> prepending the service name with a label indicating the scheme,
> prefixed with an underscore, resulting in a domain name like "
> _examplescheme.api.example.com."
>
> In this instance, however, the literal domain name ends with a period.
> Given the general rule in American English that the period goes inside the
> quotation marks and not outside, the absence of the explicit exterior
> period might cause some readers to apply that rule and not expect the
> actual domain name to contain the trailing dot; hence the separate period
> in the original.
> Could we revert this change, or is there a different way we could word
> this to avoid any confusion?
>
> [rfced] Reverted. Thank you for the explanation.
>
> Under AliasMode, quotes were added to offset
> “https://example.com ”, but similar quotes were not added around
> “foo://example.com:8080”. Should all URIs be quoted, if this one is?
>
> [rfced] We added quotes to URIs listed in text. Please review and let us
> know if any of the new quotes are incorrect (e.g., we added quotes for
> 'owner of
> "example.com"' because we found 'the operator of
> "https://example.com "', but is this update correct?). Regarding the
> hyphenation of “SVCB-optional” and “SVCB- reliant”:
>
> Original:
>
> A client is called "SVCB-optional" if it can connect without the use
> of ServiceMode records, and "SVCB-reliant" otherwise.
>
> Current:
>
> A client is called "SVCB optional" if it can connect without the use
> of ServiceMode records; otherwise, it is called "SVCB reliant".
>
> These terms are used primarily as adjectives before a noun (and therefore
> hyphenated) and in a few instances with a verb in between. It seems unclear
> not to
> hyphenate the definition of the terms when that’s
> primarily how they’re used, for ease of searching. For uniformity, could
> we hyphenate these terms throughout? If I understand the rule correctly, a
> compound adjective is *generally* not hyphenated when not before a noun,
> but some are.
> (The same applies to “SVCB-compatible” later.)
>
> [rfced] We restored the hyphens.
> Updated list of questions:
> 1) <!-- [rfced] We expanded "RR" in the document title. Please let us know
> any objections.
> Original:
> Service binding and parameter specification via the DNS
> (DNS SVCB and
> HTTPS RRs)
> Currently:
> Service Binding and Parameter Specification via the DNS
> (DNS SVCB and
> HTTPS Resource Records (RRs)) -->
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear
> in the
> title) for use on <https://www.rfc-editor.org/search >. -->
> 3) <!-- [rfced] Datatracker "idnits" output for the original approved
> document included the following warning. Please let us know if any changes
> are needed as related to this warning:
> == There are 2 instances of lines with non-RFC2606- compliant FQDNs in the
> document. -->
> 4) <!-- [rfced] Section 1.1: We changed this section title, as it did not
> match the contents of the section. If this update is incorrect, perhaps
> some text is missing? If so, please clarify "goal" vs.
> "goals".
> Original (excerpts from this section are included for context):
> 1.1. Goals of the SVCB RR
> The goal of the SVCB RR is to allow clients to resolve a single
> additional DNS RR in a way that:
> ...
> Additional goals specific to HTTPS RRs and the HTTP use- cases
> include:
> Currently:
> 1.1. Goals -->
> 5) <!-- [rfced] Please review the "type" attribute of each sourcecode
> element in the XML file to ensure correctness. If the current list of
> preferred values for "type"
> (https://www.rfc-editor.org/materials/sourcecode-types.txt
> ) does not contain an applicable type, please let us know. Also, it is
> acceptable to leave the "type" attribute not set.
> In addition, review each artwork element. Specifically, should any artwork
> element be tagged as sourcecode (e.g.,
> "dns-rr", "pseudocode", or "test-vectors" for some or all of the figures
> in the appendices)? -->
> 6) <!-- [rfced] Section 2.4.2: As it appears that
> "multiple" means "multiple RRs" (as opposed to "multiple RRSets"), we
> updated this sentence accordingly. If this is incorrect, please provide
> clarifying text.
> Original (the previous sentence is included for context): In AliasMode,
> the SVCB record aliases a service to a TargetName.
> SVCB RRSets SHOULD only have a single resource record in AliasMode.
> If multiple are present, clients or recursive resolvers SHOULD pick one at
> random.
> Currently:
> If multiple
> RRs are present, clients or recursive resolvers SHOULD pick one at random.
> -->
> 7) <!-- [rfced] Section 4.2: Is resolution of unknown RR types the only
> type of normal response construction, or should "i.e." ("that is") be
> "e.g." ("for example") here? Original:
> Whether the recursive resolver is aware of SVCB or not, the normal
> response construction process (i.e. unknown RR type resolution under
> [RFC3597]) generates the Answer section of the response.
> -->
> 8) <!-- [rfced] Section 4.3: Does "even if the contents are invalid"
> refer to the "MUST" clause, the "MAY" clause, or both? Original:
> Recursive resolvers MUST be able to convey SVCB records with unrecognized
> SvcParamKeys, and MAY treat the entire SvcParams portion of the record as
> opaque, even if the contents are invalid.
> (A) Perhaps (both):
> Recursive resolvers MUST be able to convey SVCB records with unrecognized
> SvcParamKeys and MAY treat the entire SvcParams portion of the record as
> opaque, even if the contents are invalid.
> (B) Or possibly (only the "MAY" clause): Recursive resolvers MUST be able
> to convey SVCB records with unrecognized SvcParamKeys, and the resolvers
> MAY treat the entire SvcParams portion of the record as opaque even if the
> contents are invalid.
> (C) Or to be specific (instead of rely only on the comma): Recursive
> resolvers MUST be able to convey SVCB records with
> unrecognized SvcParamKeys, and the resolvers MAY treat the entire
> SvcParams portion of the record as opaque even if the contents
> (of that portion) are invalid. -->
> 9) <!-- [rfced] Section 7.2: Should "this SvcParam" be
> "this
> SvcParamValue" here? We ask because we see two instances of
> "SvcParamValue MUST NOT contain escape sequences" later in this
> document.
> Original:
> To enable simpler parsing, this SvcParam MUST NOT contain escape
> sequences. -->
> 10) <!-- [rfced] Section 9.1: Please clarify the meaning of
> "Following of".
> Original:
> Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from
> SVCB. -->
> 11) <!--[rfced] Should the instances of "9443" be "8443" here?
> Original:
> Alt-Svc: h2="alt.example:443",
> h2="alt2.example:443", h3=":8443" The
> client would retrieve the following HTTPS records: alt.example.
> IN HTTPS 1 . alpn=h2,h3 foo=...
> alt2.example. IN HTTPS 1
> alt2b.example. alpn=h3 foo=...
> _8443._https.example.com. IN HTTPS
> 1 alt3.example. (
> port=9443 alpn=h2,h3 foo=... )
> [...]
> *
> HTTP/3 to alt3.example:9443 -->
> 12) <!-- [rfced] Section 9.4 and Table 1: Does "ECH" refer to
> citations for draft-ietf-tls-esni and not to "Encrypted ClientHello"
> in general, or does it refer to some (unknown) future specification
> related to ECH (in which case the text should be
> clarified)?
> Please note that we could not find any indication in draft-ietf-tls-esni
> that the parameter in question will be reserved
> for it.
> Original:
> Clients MUST NOT use an HTTPS RR response unless the client supports
> TLS Server Name Indication (SNI) and indicates the origin name in the
> TLS ClientHello (which might be encrypted via a future specification
> such as ECH).
> ...
> | 5 | ech | RESERVED |N/A
> |IETF |
> | | | (will be | |
> |
> | | | used for | |
> |
> | | | ECH) | |
> | -->
> 13) <!-- [rfced] Section 9.6:
> Should 'HTTP URL' be '"http" URL'? We ask because we do not see
> 'HTTP URL' used anywhere else in this document or in this cluster of
> documents (https://www.rfc-
> editor.org/cluster_info.php?cid=C461 ).
> Also, we could not find any instances of "requestURL" in
> [WebSocket],
> any other published RFC, or [FETCH]. However, we see
> "Request-URI"
> in [WebSocket]. Will the use of "requestURL" be clear to readers?
> Original:
> All HTTP connections to named origins are eligible to use HTTPS RRs,
> even when HTTP is used as part of another protocol or without an
> explicit HTTP URL. For example, clients that support HTTPS RRs and
> implement the altered WebSocket [WebSocket] opening handshake from the
> W3C Fetch specification [FETCH] SHOULD use HTTPS RRs for the
> requestURL. -->
> 14) <!-- [rfced] Section 10.3: We had trouble following
> "various
> interpretations of RFCs" in the first sentence, as it appears to
> indicate that the RFCs themselves are being interpreted. Also, the
> second sentence does not parse. Would the "Perhaps" text below be
> helpful? If not, please provide clarifying text.
> Original ("an TargetName" has been fixed): Note that some implementations
> may not allow A or AAAA records on
> names starting with an underscore due to various
> interpretations of
> RFCs. This could be an operational issue when the TargetName contains
> an attrleaf label, as well as using an TargetName of "." when the owner
> name contains an attrleaf label.
> Perhaps:
> Note that some implementations may not allow A or AAAA records on
> names that start with an underscore, due to various interpretations in
> other RFCs. This could be an operational issue when the TargetName
> contains an Attrleaf label, as well as when a TargetName of "." is
> used when the owner name contains an Attrleaf label. --> 15) <!-- [rfced]
> Section 11: We do not see the word
> "stapling" or
> "staple" in RFC 6066. Please confirm that this citation will be clear
> to readers.
> Original:
> Server operators implementing this standard SHOULD also implement TLS
> 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of which confer
> substantial performance and privacy benefits when used in combination
> with SVCB records. -->
> 16) <!-- [rfced] Section 12: "unintended access" reads oddly here.
> If the suggested text is not correct, should the word
> "unintended"
> be removed? Please provide alternative text if you'd like to
> rephrase.
> Original:
> If the attacker can influence the client's payload (e.g. TLS session
> ticket contents), and an internal service has a
> sufficiently lax parser, it's possible that the attacker could gain
> unintended access.
> Suggested:
> If the attacker can influence the client's payload (e.g., TLS session
> ticket contents) and an internal service has a
> sufficiently lax
> parser, it's possible that, as an unintended consequence, the attacker
> could gain access. -->
> 17) <!-- [rfced] FYI, we have changed two instances of
> "Service Binding"
> to "service binding" because it written in lowercase where used
> generally in this document. We will ask IANA to update
> <https://www.iana.org/assignments/dns-parameters/ > accordingly, unless
> you let us know you prefer otherwise. Original:
> * Meaning: General Purpose Service Binding Current: Meaning:
> General-purpose service binding
> Original:
> * Meaning: Service Binding type for use with HTTP Current:
> Meaning: Service binding type for use with HTTP
> -->
> 18) <!-- [rfced] The following ACTION text indicates that the
> "Service Parameter Keys (SvcParamKeys)" registry should appear on the
> "Domain Name System (DNS) Parameters" page. However, the registry
> appears on a page under the heading "DNS Service Bindings
> (SVCB)"
> (see https://www.iana.org/assignments/dns-svcb/ ). Please review and
> let us know if the location of the "DNS Service Bindings
> (SVCB)"
> registry is correct.
> Original:
> ACTION: create this registry, on a new page entitled "DNS Service
> Bindings (SVCB)" under the "Domain Name System (DNS) Parameters"
> category. -->
> 19) <!-- [rfced] Section 14.4: Because the "Underscored and
> Globally Scoped DNS Node Names" IANA registry does not include a "Meaning"
> column, we have updated the table as shown below. Please let us know
> if any other updates are required.
> Original (to avoid the issue of double dashes and XML comments, the
> bottom line of the table is not included):
> Per [Attrleaf], please add the following entry to the DNS Underscore
> Global Scoped Entry Registry:
> +=========+============+=================+=================+
> | RR TYPE | _NODE NAME | Meaning | Reference
> |
> +=========+============+=================+=================+
> | HTTPS | _https | HTTPS SVCB info | (This
> document) |
> Table 2
> Currently:
> Per [Attrleaf], the following entry has been added to the DNS
> "Underscored and Globally Scoped DNS Node Names" registry:
> +=========+============+===========+
> | RR Type | _NODE NAME | Reference |
> +=========+============+===========+
> | HTTPS | _https | RFC 9460 |
> Table 2 -->
> 20) <!-- [rfced] Appendix A: Because Section 3.3 of RFC 1035 says
> "<character-string> is treated as binary information, and can be up to
> 256 characters in length (including the length octet)", we updated
> this sentence to clarify the meaning of "same as". If this is incorrect,
> please provide text that clarifies the meaning
> of "same as".
> Original:
> The algorithm is the same as used by
> <character-string> in RFC 1035, although the output length in this
> document is not limited to 255 octets.
> Currently:
> The algorithm is the same as the
> guideline for <character-string> in [RFC1035], except that in this
> document the output length is not limited to 255 octets.
> -->
> 21) <!-- [rfced] Appendix C.4: We changed "the authoritative" at
> the end of this sentence to "the authoritative DNS server". If this
> is incorrect, please clarify the meaning of "the authoritative".
> Original:
> Recursive resolvers that implement the specification would, upon
> receipt of a ServiceMode query, emit both a ServiceMode and an
> AliasMode query to the authoritative.
> Currently:
> Recursive resolvers that implement the specification would, upon
> receipt of a ServiceMode query, emit both a ServiceMode query and an
> AliasMode query to the authoritative DNS server. --> 22) <!-- [rfced]
> Appendix D.2: Do "target (root label)" and
> "target, root label" mean the same thing? If yes, should they both be
> expressed in the same way (i.e., either parentheses or comma)?
> Also, should "length: 2 bytes" be "length 2", per the format of all
> other "# length" and "; length" entries? Original:
> 00 ; target (root label)
> ...
> \x00 # target, root label
> ...
> \x00\x02 # length: 2 bytes
> ...
> \x00\x05 # length 5
> ...
> \x00\x09 # length 9
> ...
> \x00\x20 # length 32
> ...
> \x00\x10 # length 16 -->
> 23) <!-- [rfced] Figure 8: The "example.com." line is too long and
> yields the following warning:
> Warning: Too long line found (L2319), 4 characters longer than 72
> characters:
> example.com. SVCB 1 example.com.
> ipv6hint="2001:db8:122:344::192.0.2.33"
> We see a similar type of line at the top of Figure 7, although that
> line uses parentheses before and after the line break around
> "ipv6hint". Would it be syntactically correct to format this line
> (i.e., with parentheses and line breaks) per Figure 7? Original:
> example.com. SVCB 1 example.com.
> ipv6hint="2001:db8:122:344::192.0.2.33"
> Possibly:
> example.com. SVCB 1 example.com. (
> ipv6hint="2001:db8:122:344::192.0.2.33"
> ) -->
> 24) <!-- [rfced] Figures 14 and 15: Should "mandatory" be written
> in the same way in both titles (i.e., either lowercase and quoted or
> initial-capitalized and unquoted)?
> Original:
> Figure 14: A mandatory SvcParam is missing ...
> Figure 15: The "mandatory" SvcParamKey must not be included in
> the mandatory list -->
> 25) <!-- [rfced] "Acknowledgments and Related Proposals" reads
> oddly, in that the two ideas seem unrelated. "... proposed solutions ...
> challenge proposed" reads oddly as well.
> May we make a new Section 15 ("Related Proposals") and rephrase some
> text as suggested below?
> Original:
> 15. Acknowledgments and Related Proposals There have been a wide
> range of proposed solutions over the years to the "CNAME at the Zone
> Apex" challenge proposed. These include
> [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others.
> Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas
> Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David
> Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig
> Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis,
> Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many
> others for their feedback and suggestions on this draft. Suggested:
> 15. Related Proposals
> Over the years, there has been a wide range of proposed solutions to
> the zone-apex CNAME challenge. These include [HTTP-DNS- RR],
> [ANAME-DNS-RR], and others.
> ...
> Acknowledgments
> Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas
> Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David
> Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig
> Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis,
> Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many
> others for their feedback and suggestions on this document.
> -->
> 26) <!-- [rfced] Please review the "Inclusive Language" portion of
> the online Style Guide at
> <https://www.rfc-
> editor.org/styleguide/part2/#inclusive_language >, and let us know if any
> changes are needed.
> For example, please consider whether the following should be updated:
> whitespace (whitespace-separated list, internal whitespace)
> -->
> 27) <!-- [rfced] Please let us know if any changes are needed for
> the
> following:
> a) The following terms were used inconsistently in this document.
> We chose to use the latter forms. Please let us know any objections.
> Alt-Svc Field Value / Alt-Svc field value (per [AltSvc]) attrleaf
> label / Attrleaf label (per [Attrleaf])
> IPv6 hint / ipv6hint (per three of the four companion documents)
> (https://www.rfc-editor.org/cluster_info.php?cid=C461 )) key Name / key
> name
> RRType (titles of Sections 14.1 and 14.2) / RR Type (per approx. 40
> instances of "RR type" in text) wire-format / wireformat / wire format
> (noun)
> (per "wire format" in companion document draft-ietf-add- svcb-dns)
> zone file (adj.) / zone-file (adj.)
> b) The following terms appear to be used inconsistently in this
> document. Please let us know which form is preferred. Additional record /
> additional record (We also see
> "Additionals" and "Additional A records" in Section
> 4.2.1.)
> additional section / Additional section / Additional Section mode /
> Mode ("two modes", "same Mode", "connection modes") Multi-CDN ("A
> Multi-CDN customer domain") /
> multi-CDN ("a multi-CDN configuration")
> (We suggest lowercase, based on past usage in RFCs.) Name MUST /
> name MUST (Section 14.3.1)
> c) Should lowercase "alpn" be written in text with or without quotes?
> alpn / "alpn" ('e.g., alpn', 'e.g., URIs or "alpn"') Also, should
> 'non-default alpn' be 'non-default ALPN' or perhaps 'non-default "alpn"'?
> d) May we change the instances of "RRSet" to "RRset"? We see that
> the latter form is used much more often in RFCs from RFC 6000
> onwards.-->
>
> On Sep 8, 2023, [e-mail] wrote:
>
> *****IMPORTANT*****
> Updated 2023/09/08
> RFC Author(s):
> --------------
> Instructions for Completing AUTH48
> Your document has now entered AUTH48. Once it has been reviewed
> and approved by you and all coauthors, it will be
> published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-
> editor.org/faq/ ).
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
> Planning your review --------------------- Please review the
> following aspects of your document:
> * RFC Editor questions
> Please review and resolve any questions raised by the RFC Editor
> that have been included in the XML file as comments marked as
> follows:
> <!-- [rfced] ... -->
> These questions will also be sent in a subsequent email.
> * Changes submitted by coauthors Please ensure that you review any changes
> submitted by your
> coauthors. We assume that if you do not speak up that you agree to changes
> submitted by your coauthors.
> * Content Please review the full content of the document, as this cannot
> change once the RFC is published. Please pay particular attention to:
> - IANA considerations updates (if applicable)
> - contact information
> - references
> * Copyright notices and legends
> Please review the copyright notice and legends as defined in
> RFC 5378 and the Trust Legal Provisions (TLP –
> https://trustee.ietf.org/license-info/ ).
> * Semantic markup
> Please review the markup in the XML file to ensure that elements of
> content are correctly tagged. For example, ensure that
> <sourcecode>
> and <artwork> are set correctly. See details at
> <https://authors.ietf.org/rfcxml-vocabulary >.
> * Formatted output
> Please review the PDF, HTML, and TXT files to ensure that the
> formatted output, as generated from the markup in the XML file, is
> reasonable. Please note that the TXT will have formatting limitations
> compared to the PDF and HTML.
> Submitting changes
> ------------------
> To submit changes, please reply to this email using ‘REPLY ALL’ as
> all the parties CCed on this message need to see your changes. The
> parties
> include:
> * your coauthors
> * [e-mail] (the RPC team)
> * other document participants, depending on the stream
> (e.g.,
> IETF Stream participants are your working group chairs, the
> responsible ADs, and the document shepherd).
> * [e-mail], which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion
> list:
> * More info:
> https://mailarchive.ietf.org/arch/msg/ietf-
> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> * The archive itself:
> https://mailarchive.ietf.org/arch/browse/auth48archive/
> * Note: If only absolutely necessary, you may
> temporarily opt out
> of the archiving of messages (e.g., to discuss a
> sensitive matter).
> If needed, please add a note at the top of the message that you
> have dropped the address. When the discussion is
> concluded,
> [e-mail] will be re-added to the CC list and
> its addition will be noted at the top of the message. You may submit your
> changes in one of two ways:
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format Section # (or indicate
> Global)
> OLD:
> old text
> NEW:
> new text
> You do not need to reply with both an updated XML file and an
> explicit list of changes, as either form is sufficient. We will ask a
> stream manager to review and approve any changes that
> seem beyond editorial in nature, e.g., addition of new text,
> deletion of text, and technical changes. Information about stream
> managers can be found in the FAQ. Editorial changes do not require
> approval from a stream manager.
> Approving for publication
> --------------------------
> To approve your RFC for publication, please reply to this email
> stating that you approve this RFC for publication. Please use
> ‘REPLY ALL’, as all the parties CCed on this message need to see your
> approval.
> Files -----
> The files are available here:
> https://www.rfc-editor.org/authors/rfc9460.xml
> https://www.rfc-editor.org/authors/rfc9460.html
> https://www.rfc-editor.org/authors/rfc9460.pdf
> https://www.rfc-editor.org/authors/rfc9460.txt
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9460-diff.html https://www.
> rfc-editor.org/authors/rfc9460-rfcdiff.html
> (side by side)
> Diff of the XML: https://www.rfc-
> editor.org/authors/rfc9460-xmldiff1.html
> This diff file compares an altered original and the RFC
> (in order to make the changes in moved text viewable): https://www.
> rfc-editor.org/authors/rfc9460-alt-diff.html Tracking progress
> -----------------
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9460
> Please let us know if you have any questions. Thank you for your
> cooperation,
> RFC Editor
> --------------------------------------
> RFC9460 (draft-ietf-dnsop-svcb-https-12)
> Title : Service Binding and Parameter
> Specification via the DNS (DNS SVCB and HTTPS Resource Records (RRs))
> Author(s) : B. Schwartz, M. Bishop, E. Nygren WG Chair(s) : Suzanne Woolf,
> Benno Overeinder, Tim Wicinski
> Area Director(s) : Warren Kumari, Robert Wilton
>
> <rfc9460.xml>
>
> <rfc9460.xml>
>
>