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

[Mike Bishop <[e-mail]>]

This entry was originally used by this document; when that was extracted out, this document “Reserved” it for the future use of ECH to ensure the codepoint doesn’t get allocated elsewhere. I don’t see why we really care where the reservation points, so long as it’s reserved.  It would be formally allocated when some ECH document is published to make use of it.

Frankly, I think we’d also be fine to drop the reservation – there’s already an adopted document that requests the assignment of this codepoint, so as a practical matter I don’t think it will get stomped on.

From: Warren Kumari <[e-mail]>
Sent: Saturday, October 21, 2023 3:49 PM
To: Lynne Bartholomew <[e-mail]>
Cc: [e-mail]; Erik Nygren <[e-mail]>; [e-mail]; Rob Wilton <[e-mail]>; Tim Wicinski <[e-mail]>; [e-mail]; Mike Bishop <[e-mail]>; [e-mail]; dnsop-chairs <[e-mail]>; Ben Schwartz <[e-mail]>; [e-mail]
Subject: Re: *[AD] Re: [IANA #1284364] [IANA] Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https-12> for your review





On Fri, Oct 20, 2023 at 11:59 PM, Lynne Bartholomew <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Amanda, Erik, and *AD (Warren or Rob).
Amanda, thank you for making the updates! All looks good (but we're asking the AD about the updated "ech" entry).
Erik, thank you for your suggestion.
* Warren or Rob, please see Erik's suggestion re. a reference for the "ech" entry, and let us know if that suggested update in this document and on <https://www.iana.org/assignments/dns-svcb> would be acceptable. Please see <https://www.rfc-editor.org/authors/rfc9460.html#table-1> and IANA's note below.


Erm, I think I got lost somewhere in the (many) levels of quoting…

Doesn't that mean that the reference would be to a (currently in progress) draft? Is this OK? What if the draft significantly changes?

W



Thanks again!
RFC Editor/lb
On Oct 19, 2023, at 5:09 PM, Erik Nygren <[e-mail]<mailto:[e-mail]>> wrote:
Another option for the reference for "ech" would be to "draft-ietf-tls-svcb-ech-00" which is where that portion of the format specification has moved to and where the TLS WG is working on it.
Thanks, Erik
On Thu, Oct 19, 2023 at 8:01 PM Amanda Baber via RT <[e-mail]<mailto:[e-mail]>> wrote: Hi,
We've completed these changes, but need to make a note about the second one:
On Wed Oct 18 19:43:35 2023, [e-mail]<mailto:[e-mail]> wrote:
Dear IANA,
We are preparing this document for publication.
Please make the following updates to the "Resource Record (RR) TYPEs" registry on
<https://www.iana.org/assignments/dns-parameters/>:
OLD:
General Purpose Service Binding
Service Binding type for use with HTTP
NEW:
General-purpose service binding
SVCB-compatible type for use with HTTP
This is complete:
https://www.iana.org/assignments/dns-parameters
= = = = =
Please make the following update to the "Service Parameter Keys
(SvcParamKeys)" registry on
<https://www.iana.org/assignments/dns-svcb/>:
OLD (column name):
Format Reference
NEW:
Reference
The Service Parameter Keys (SvcParamKeys) registry originally had the "Format Reference" field populated by the document and a "Reference" field added by IANA. Aside from the entry for "ech", which was filled in with "N/A", the former contained either a more detailed version of IANA's reference or the same reference.
We've removed IANA's "Reference" field and changed the name of the "Format Reference" field to "Reference," but we've also replaced "N/A" with "[RFC-ietf-dnsop-svcb-https-12]" for "ech", so as to avoid leaving that entry unreferenced:
https://www.iana.org/assignments/dns-svcb
thanks,
Amanda
Thank you!
RFC Editor/lb
On Oct 18, 2023, at 12:31 PM, Lynne Bartholomew
<[e-mail]<mailto:[e-mail]>> wrote:
Hi, Ben. Great; thanks!
RFC Editor/lb
On Oct 18, 2023, at 12:26 PM, Ben Schwartz <[e-mail]<mailto:[e-mail]>> wrote:
Correct.
On Oct 18, 2023, at 11:26 AM, Lynne Bartholomew
<[e-mail]<mailto:[e-mail]>> wrote:
Hi, Ben.
Just to confirm -- 'replace the "Reference" column that IANA added' means 'change IANA's "Format Reference" column heading to
"Reference"; correct?
Thank you!
RFC Editor/lb
On Oct 18, 2023, at 11:17 AM, Ben Schwartz <[e-mail]<mailto:[e-mail]>> wrote:
That's correct. This will replace the "Reference" column that IANA added for compliance with their usual processes.
--Ben SchwartzFrom: Lynne Bartholomew <[e-mail]<mailto:[e-mail]>> Sent: Wednesday, October 18, 2023 1:34 PM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>
Cc: Erik Nygren <[e-mail]<mailto:[e-mail]>>; Ben Schwartz
<[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; rfc- [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; dnsop- [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <dnsop- [e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https- 12> for your review
!-------------------------------------------------------------------
|
This Message Is From an External Sender
|-------------------------------------------------------------------
!
Hi, Mike. So noted:
https://www.rfc-editor.org/auth48/rfc9460
Before we ask IANA to make updates per changes made to this document, we first want to confirm that, per AUTH48 XML updates that you sent us on 26 September, we also need to ask for the following change on <https://www.iana.org/assignments/dns-svcb/ >:
OLD (column name):
Format Reference
NEW:
Reference
Please let us know about the above. We will wait to hear from you before proceeding.
Thank you!
RFC Editor/lb
On Oct 17, 2023, at 12:52 PM, Mike Bishop <[e-mail]<mailto:[e-mail]>> wrote:
Approved -- thanks to everyone for their work on this.
-----Original Message-----
From: Lynne Bartholomew <[e-mail]<mailto:[e-mail]>> Sent: Monday, October 16, 2023 11:30 AM
To: Erik Nygren <[e-mail]<mailto:[e-mail]>>
Cc: Ben Schwartz <[e-mail]<mailto:[e-mail]>>; Mike Bishop
<[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; rfc-editor@rfc- editor.org<http://editor.org/>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb-https- 12> for your review
Hi, Erik. Thank you for confirming your approval!
RFC Editor/lb
On Oct 15, 2023, at 6:45 AM, Erik Nygren <[e-mail]<mailto:[e-mail]>> wrote:
I just looked at the latest and it looks good to me.
Thanks! Erik
On Fri, Oct 13, 2023 at 5:53 PM Lynne Bartholomew
<[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> Sent: Thursday, October 5, 2023 12:32 PM
To: Erik Nygren <[e-mail]<mailto:[e-mail]>>; Ben Schwartz
<[e-mail]<mailto:[e-mail]>>
Cc: Mike Bishop <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; rfc- [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; dnsop-
[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; auth48archive@rfc- editor.org<http://editor.org/>
Subject: Re: AUTH48: RFC-to-be 9460 <draft-ietf-dnsop-svcb- https-12> for your review
Hi, Erik and Ben.
Erik, thank you for the suggestion. Ben, is Erik's suggestion acceptable, and may we update accordingly?
Thank you!
RFC Editor/lb
On Oct 5, 2023, at 6:12 AM, Erik Nygren
<[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> Sent: Tuesday, October 3, 2023 12:29 PM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <rfc- [e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <dnsop- [e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>; auth48archive@rfc- editor.org<http://editor.org/> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> Sent: Thursday, September 28, 2023 11:48 AM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; rfc-editor@rfc- editor.org<http://editor.org/>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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<http://example.com/> line in Figure 8 extends beyond the 72-character limit.
24. Figure 8: The "example.com<http://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<http://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<http://_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<http://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<http://_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]<mailto:[e-mail]>> Sent: Friday, September 22, 2023 2:39 PM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[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]<mailto:[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<http://_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<http://_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<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<http://example.com/>"' because we found 'the operator of
"https://example.com<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<http://_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<http://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<http://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<http://example.com/>. SVCB 1 example.com<http://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<http://example.com/>. SVCB 1 example.com<http://example.com/>.
ipv6hint="2001:db8:122:344::192.0.2.33"
Possibly:
example.com<http://example.com/>. SVCB 1 example.com<http://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<http://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]<mailto:[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/<http://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]<mailto:[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]<mailto:[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]<mailto:[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<http://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>