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

[Erik Nygren <[e-mail]>]

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];
> [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, 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] <
> [e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[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.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]; [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.
> > >
> > > 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];
> > >> [e-mail]
> > >> 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>
> >
>
>