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

[Erik Nygren <[e-mail]>]

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