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

[Erik Nygren <[e-mail]>]

I just looked at the latest and it looks good to me.

Thanks!  Erik

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

> Hi, Erik, Ben, and Mike.
>
> Ben and Mike, we have made further updates to this document per your notes
> below.
>
> The latest files are posted here (please refresh your browser):
>
>    https://www.rfc-editor.org/authors/rfc9460.txt
>    https://www.rfc-editor.org/authors/rfc9460.pdf
>    https://www.rfc-editor.org/authors/rfc9460.html
>    https://www.rfc-editor.org/authors/rfc9460.xml
>    https://www.rfc-editor.org/authors/rfc9460-diff.html
>    https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9460-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9460-lastdiff.html
>    https://www.rfc-editor.org/authors/rfc9460-lastrfcdiff.html
>
>    https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html
>    https://www.rfc-editor.org/authors/rfc9460-alt-diff.html
>
> Erik and Ben, we have noted your approvals on the AUTH48 status page.
> Please note, however, that if you object to any subsequent updates to this
> document you will let us know:
>
>    https://www.rfc-editor.org/auth48/rfc9460
>
> Thank you!
>
> RFC Editor/lb
>
> > On Oct 12, 2023, at 2:05 PM, Mike Bishop <[e-mail]> wrote:
> >
> > I’ve finished my final read-through.  These are minor issues, and
> everything else looks fine.
> >
> >  I caught a few uses of the first-person through the document.  I
> suggest:
> >
> > • Section 1.3: “Our terminology…” => “Terminology in this document…”
> >
> > • Section 2.3:  “We term this behavior "Port Prefix Naming" and use it
> in the examples throughout this document.” => “This document terms this
> behavior "Port Prefix Naming" and uses it in the examples throughout.”
> >
> > • Appendix A: “Here, we summarize…” => “The following summarizes…”
> >
> > • Appendix C: “…by providing an extensible solution that solves multiple
> problems we will overcome this inertia…” => “…an extensible solution that
> solves multiple problems will overcome this inertia…”
> >
> >  There is a nested parenthetical in 2.3.  I suggest the following:
> >
> > Current:
> > (Parentheses are used to ignore a line break in DNS zone-file
> presentation format ([RFC1035], Section 5.1).)
> >
> >  Proposed:
> > (Parentheses are used to ignore a line break in DNS zone-file
> presentation format, per Section 5.1 of [RFC1035].)
>
>
> > On Oct 11, 2023, at 10:51 AM, Ben Schwartz <[e-mail]> wrote:
> >
> > The caption of Figure 10 is 'An alpn Value with ...'.  I believe "alpn"
> should be quoted for consistency, resulting in 'An "alpn" Value with ...".
> >
> > Apart from that suggestion, I approve this version for publication.
> >
> > --Ben Schwartz
>
> > On Oct 11, 2023, at 10:34 AM, Erik Nygren <[e-mail]> wrote:
> >
> > Approved from my perspective!  (Assuming no objections from Mike or Ben.)
> >
> > Best, Erik
> >
> >
> > On Wed, Oct 11, 2023 at 12:11 PM Lynne Bartholomew <
> [e-mail]> wrote:
> > Hi, Erik.
> >
> > We have updated this document per your note below.
> >
> > The latest files are posted here (please refresh your browser):
> >
> >    https://www.rfc-editor.org/authors/rfc9460.txt
> >    https://www.rfc-editor.org/authors/rfc9460.pdf
> >    https://www.rfc-editor.org/authors/rfc9460.html
> >    https://www.rfc-editor.org/authors/rfc9460.xml
> >    https://www.rfc-editor.org/authors/rfc9460-diff.html
> >    https://www.rfc-editor.org/authors/rfc9460-rfcdiff.html
> >    https://www.rfc-editor.org/authors/rfc9460-auth48diff.html
> >    https://www.rfc-editor.org/authors/rfc9460-lastdiff.html
> >    https://www.rfc-editor.org/authors/rfc9460-lastrfcdiff.html
> >
> >    https://www.rfc-editor.org/authors/rfc9460-xmldiff1.html
> >    https://www.rfc-editor.org/authors/rfc9460-xmldiff2.html
> >    https://www.rfc-editor.org/authors/rfc9460-alt-diff.html
> >
> > We will wait to hear from your coauthors regarding any subsequent
> changes before noting anyone's approval.
> >
> > Thank you!
> >
> > RFC Editor/lb
> >
> > > On Oct 10, 2023, at 2:13 PM, Erik Nygren <[e-mail]> wrote:
> > >
> > > I took a final reading pass through and the only thing that jumped out
> would be to change this:
> > >
> > > - "," and "\" characters instead of implementing the
> <tt>value-list</tt> escaping
> > > + "," and "\" characters in ALPN IDs instead of implementing the
> <tt>value-list</tt> escaping
> > >
> > > The current text is ambiguous as to whether those characters are
> prohibited in ALPN IDs or prohibited in value-list.
> > > It is clear that the intent is for them to only be prohibited in ALPN
> IDs so that value-list can contain commas,
> > > but inserting the "in ALPN IDs" would reduce risk of misreading.
> > > Everything else looks good.
> > >
> > > I believe Mike and Ben are making similar read-throughs.
> > >
> > > Thanks, Erik
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Oct 6, 2023 at 4:30 PM Mike Bishop <[e-mail]>
> wrote:
> > > Ben proposed this text on GitHub:
> > >
> > > In this document, this algorithm is referred to as "character-string
> decoding", because
> > > <xref target="RFC1035" sectionFormat="of" section="5.1"/> uses this
> > > algorithm to produce a <tt>&lt;character-string&gt;</tt>.
> > >
> > > (And a corresponding "the allowed input" => "some allowed inputs".)
> > >
> > > The attached XML incorporates this proposal, if that works for
> everyone.
> > >
> > > -----Original Message-----
> > > From: Lynne Bartholomew <[e-mail]>
> > > Sent: Thursday, October 5, 2023 12:32 PM
> > > To: Erik Nygren <[e-mail]>; Ben Schwartz <[e-mail]>
> > > Cc: Mike Bishop <[e-mail]>; [e-mail];
> [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>
> > > >
> > >
> >
>
>