Service Binding Mapping for DNS Servers
draft-ietf-add-svcb-dns-09

I have reviewed all ballots & the one-year old directorate reviews. All is good for me, I will suggest to the authors to apply Roman's ballot comment.

[Ballot comment]
This is my second ballot for this document.  I'm repeating the same feedback provided for -06.

Thank you to Joseph Salowey for the SECDIR review.  This review noted a few promised changes that were merged into -06.  Please merge those in.  See https://mailarchive.ietf.org/arch/msg/secdir/kpqucIMv2LCibuUqoK42LhJKyKM/

** Section 8.1.2
If an endpoint sends an invalid response to a DNS
  query, the client SHOULD NOT send more queries to that endpoint.

Consider the following additional behavior:

NEW
… the client SHOULD NOT send more queries to that endpoint and MAY log this error.

[Ballot comment]
# GEN AD review of draft-ietf-add-svcb-dns-08

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/T4D0gKTp6m_TFw0C26Ib-7PqttY).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
This is the 2nd ballot after removing all ECH references as this effort appears to be stalled in the TLS WG. The revised I-D went through a 2nd round of WGLC and IETF Last Calls.

The diff is minor: https://author-tools.ietf.org/iddiff?url1=draft-ietf-add-svcb-dns-05&url2=draft-ietf-add-svcb-dns-08&difftype=--html and I suggest to focus only on those changes.

Regards

-éric

PS: of course, a -bis or an update will be written when ECH/ESNI is ready.

This is the 2nd ballot after removing all ECH references as this effort appears to be stalled in the TLS WG. The revised I-D went through a 2nd round of WGLC and IETF Last Calls.

The diff is minor: https://author-tools.ietf.org/iddiff?url1=draft-ietf-add-svcb-dns-05&url2=draft-ietf-add-svcb-dns-08&difftype=--html and I suggest to focus only on those changes.

Regards

-éric

PS: of course, a -bis or an update will be written when ECH/ESNI is ready.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-add-svcb-dns-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Service Parameter Keys (SvcParamKeys) registry on the DNS Service Bindings (SVCB) registry page located at:

https://www.iana.org/assignments/dns-svcb/

the early registration for:

Number: 7
Name: dohpath
Meaning: DNS over HTTPS path template

will be made permanent and its reference changed to [ RFC-to-be ].

Second, in the Underscored and Globally Scoped DNS Node Names registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

the early registration for

RR Type: SVCB
_NODE NAME: _dns

will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-04-09):

From: The IESG
To: IETF-Announce
CC: Andrew.Campling@419.Consulting, add-chairs@ietf.org, add@ietf.org, draft-ietf-add-svcb-dns@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Second Last Call:  (Service Binding Mapping for DNS Servers) to Proposed Standard


The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'Service Binding Mapping for DNS Servers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-04-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The SVCB DNS resource record type expresses a bound collection of
  endpoint metadata, for use when establishing a connection to a named
  service.  DNS itself can be such a service, when the server is
  identified by a domain name.  This document provides the SVCB mapping
  for named DNS servers, allowing them to indicate support for
  encrypted transport protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/

This document is referred to by https://datatracker.ietf.org/doc/draft-ietf-add-ddr/ and the ADD WG has another document https://datatracker.ietf.org/doc/draft-ietf-add-dnr/, which should probably be reviewed at the same time. The SVCB itself is https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/, currently in the RFC Editor queue.

No IPR declarations have been submitted directly on this I-D.

As this is the 2nd IETF Last Call for this document with really minor changes [1], the IETF Last Call will be shorter than usual.

Regards

-éric

[1] https://mailarchive.ietf.org/arch/msg/add/xR8V-Oe-IaQk-rVEwwudvRdS6hk/

Title: Service Binding Mapping for DNS Servers

Current Version: draft-ietf-add-svcb-dns-03


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it will be ready for consideration by the IESG after it is updated to correct some normative referencing issues (see 1.g and 1.h below).


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

The document was written to harmonise several different drafts that all proposed to use the SVCB format to convey information about a DNS server that supports encrypted transport.  This document specifies a minimal SVCB mapping for DNS URIs without addressing any particular use case.  Draft-ietf-add-ddr and draft-ietf-add-dnr have both followed the approach outlined in this document.

The document has had detailed reviews by working group members, with replies to the mailing list by the author indicating how the comments have been addressed.  All issues and pull requests on GitHub are closed. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)

- Duplicate reference: RFC8484, mentioned in 'RFC8484', was also mentioned in 'DOH'.

Both have been highlighted to the author so should be addressed shortly.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

DOH (RFC 8484) – standards Track (also referenced as RFC 8484)
DOT (RFC7858) – standards Track (updated by RFC8310)
RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 3629 – Standards Track
RFC 6570 – Standards Track
RFC 7540 – Standards Track (updated by RFC 8740, obsoleted by RFC 9113)
RFC 8174 – BCP 14
RFC 8484 – Standards Track

SVCB (Internet-Draft) - Standards Track

NB The DNSOP SVCB doc is already in the RFC editor queue.

Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Eight of the nine normative references are to RFCs, with the remaining one referencing an Internet-Draft.  The text in the draft providing the link to the Internet-Draft currently references an older version which has been superseded.


If such normative references exist, what is the strategy for their completion? 

I’ve asked the author to remove the “DOH” reference and replace it with RFC8484 to avoid clashing references to the same document, and to replace the “DOT” reference with RFC7858 for consistency of referencing.  I’ve asked the author to replace the reference to RFC7580 with an appropriate reference to RFC 9113.

The link to the Internet-Draft will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 9 of the document contains the IANA considerations, identifying the need for additions to the SVCB Service Parameters and DNS Underscore Global Scoped Entry Registries.  Specifically, IANA is requested to add the following entries:

- SVCB Service Parameters Registry
Number – 7; Name – dohpath; Meaning - DNS over HTTPS path template

- DNS Underscore Global Scoped Entry Registry
RR Type – SVCB; _Node Name - _dns; Meaning – DNS SVCB Info


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

[Ballot comment]
# GEN AD review of draft-ietf-add-svcb-dns-06

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/T4D0gKTp6m_TFw0C26Ib-7PqttY).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thank you for the work on this document.

Many thanks to Martin Dürst for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/2tLphDE7pymmSMBtcQ2VSBpONn8/.
Authors: please consider Martin's comments (also reported below) which would improve readability - in particular, expanding on uses and context would help a non-expert reader.

Thanks,
Francesca

--

Reviewer: Martin Dürst
Review result: On the Right Track

I'm the assigned reviewer for the App Area for the draft
"Service Binding Mapping for DNS Servers" (draft-ietf-add-svcb-dns).
I have mainly reviewed -05, but also checked the diff to -06.
This is an app area review, and so my concerns are mostly from an application
perspective.

Summary:
As far as I was able to tell (not an expert on DNS, and didn't check [SVCB],
which is required reading for implementers), the document is technically okay.
But I'm not sure readers will understand where to use this information.

Major:
The main issue with the document is that there is no explanation on
who/where/when this information is to be queried and used. Is this the job of
an application (e.g. a web browser or an email user agent)? Is this the job of
a resolver in an OS? Is it the job of DNS libraries, e.g. in programming
languages such as Ruby and Python? Who/what decides which of the alternatives
is used if there are multiple? How should (or shouldn't) DNS queries for SVCB
records be combined with queries for other records?

While I understand that there may be many different contexts, a pointer to a
document describing various potential scenarios or so could help a lot.

The addition of a bullet list to section 6, Limitations, is an improvement, but
it would be way better if there were more such information, and if that
information were worded in a positive way, and if that information were given
upfront, or if there were at least a pointer up front to such information.
Another idea would be a separate document explaining the possibilities and
giving recommendations or proposals.

Also, while the above considerations are mainly on the using side, some
additional considerations for the publishing side are also desirable.

Minor:
Section 4.2:
"This key is automatically mandatory for this binding. This means that a client
that does not respect the "port" key MUST ignore any SVCB record that contains
this key. (See Section 7 of [SVCB] for the definition of "automatically
mandatory".)" Summary: "Mandatory means MUST ignore" -> This just doesn't make
sense. Please improve the wording so that it becomes clear what you want to say
on first reading.

Section 4.3:
"Future SvcParamKeys might also be applicable.": It's totally unclear HOW they
might (or might not) be applicable.

Section 5.1
""dohpath" is a single-valued SvcParamKey whose value (both in presentation and
wire format) MUST be a URI Template in relative form ([RFC6570], Section 1.1)
encoded in UTF-8 [RFC3629].": It would be good to add that this essentially
makes the URI Template an IRI [RFC3987] Template.

Nits:

Section 3.1: "places the port number in an additional *a* prefix" ->
"places the port number in an additional prefix"

Section 4.1: "All keys specified for use with the HTTPS record":
Please add a reference here.

Section 4.2: "The client is being used with a DNS server that it trusts not
attempt this attack." -> "The client is being used with a DNS server that it
trusts not _to_ attempt this attack."

Reference [Attrleaf] is an RFC, but is the only RFC that uses a name rather
than an RFC number as the reference label. Please streamline.

Regards,  Martin.

[Ballot comment]
I support Lars's DISCUSS.  While I'm at it, a few points on your IANA Considerations:

* It's common to group each registry's actions into their own separate subsections.

* The first registry you're updating is called "Service Parameter Keys", and the "Change Controller" field is missing.

* The second registry you're updating is called "Underscored and Globally Scoped DNS Node Names".

Some exposition around that SHOULD and NOT RECOMMENDED at the end of Section 6 might be helpful.  When might an implementer legitimately decide to do something different?

[Ballot comment]
# SEC AD comments for draft-ietf-add-svcb-dns-06
CC @paulwouters


## Comments

###

    SVCB record names (i.e., QNAMEs) for DNS services

This should probably say "for nameserver services", as it is not meant for any and
all DNS services (eg a DNS service presenting a JSON API to submit DNS record updates,
or the DNS visualization service on dnsviz.net)

This applies to further use of "DNS services" throughout the document.

###

  Clients SHOULD NOT query for any "HTTPS" RRs when using "dohpath".
  Instead, the SvcParams and address records associated with this SVCB
  record SHOULD be used for the HTTPS connection

Why are these SHOULD NOT and SHOULD not MUST NOTs and MUST ?

###

In section 7 examples, why "fooexp" and not "fooexp.example." ?

[Ballot discuss]
# GEN AD review of draft-ietf-add-svcb-dns-06

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/T4D0gKTp6m_TFw0C26Ib-7PqttY).

## Discuss

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[Ballot comment]
## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thank you to Joseph Salowey for the SECDIR review.  This review noted a few promised changes that were merged into -06.  Please merge those in.  See https://mailarchive.ietf.org/arch/msg/secdir/kpqucIMv2LCibuUqoK42LhJKyKM/

** Section 8.1.2
If an endpoint sends an invalid response to a DNS
  query, the client SHOULD NOT send more queries to that endpoint.

Consider the following additional behavior:

NEW
… the client SHOULD NOT send more queries to that endpoint and MAY log this error.

[Ballot comment]
# Internet AD comments for {draft-ietf-add-svcb-dns-06}
CC @ekline

## Nits

### S3.1

* "in an additional a prefix" -> "in an additional prefix", perhaps,
  or maybe "in an additional attrleaf prefix"

### S4.2

* "that it trusts not attempt" -> "that it trusts not to attempt", perhaps

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-add-svcb-dns-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Service Parameter Keys (SvcParamKeys) registry on the DNS Service Bindings (SVCB) registry page located at:

https://www.iana.org/assignments/dns-svcb/

a new registration is to be made as follows:

Number: [ TBD-at-Registration ]
Name: dohpath
Meaning: DNS over HTTPS path template
Reference: [ RFC-to-be ]
Change Controller: IETF

IANA notes that the authors have requested the value 7 for the number of this registration.

As this requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. We are currently requesting that an expert be designated for this registry.

Second, in the Underscored and Globally Scoped DNS Node Names registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

a new registration is to be made as follows:

RR Type: SVCB
NODE NAME: _dns
Reference: [ RFC-to-be ]

As this also requests registration in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-07-08):

From: The IESG
To: IETF-Announce
CC: Andrew.Campling@419.Consulting, add-chairs@ietf.org, add@ietf.org, draft-ietf-add-svcb-dns@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service Binding Mapping for DNS Servers) to Proposed Standard


The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'Service Binding Mapping for DNS Servers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-07-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The SVCB DNS resource record type expresses a bound collection of
  endpoint metadata, for use when establishing a connection to a named
  service.  DNS itself can be such a service, when the server is
  identified by a domain name.  This document provides the SVCB mapping
  for named DNS servers, allowing them to indicate support for
  encrypted transport protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/

This document is referred to by https://datatracker.ietf.org/doc/draft-ietf-add-ddr/ and the ADD WG has another document https://datatracker.ietf.org/doc/draft-ietf-add-dnr/, which should probably be reviewed at the same time. The SVCB itself is https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/, currently in the RFC Editor queue.

No IPR declarations have been submitted directly on this I-D.

Title: Service Binding Mapping for DNS Servers

Current Version: draft-ietf-add-svcb-dns-03


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it will be ready for consideration by the IESG after it is updated to correct some normative referencing issues (see 1.g and 1.h below).


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

The document was written to harmonise several different drafts that all proposed to use the SVCB format to convey information about a DNS server that supports encrypted transport.  This document specifies a minimal SVCB mapping for DNS URIs without addressing any particular use case.  Draft-ietf-add-ddr and draft-ietf-add-dnr have both followed the approach outlined in this document.

The document has had detailed reviews by working group members, with replies to the mailing list by the author indicating how the comments have been addressed.  All issues and pull requests on GitHub are closed. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)

- Duplicate reference: RFC8484, mentioned in 'RFC8484', was also mentioned in 'DOH'.

Both have been highlighted to the author so should be addressed shortly.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

DOH (RFC 8484) – standards Track (also referenced as RFC 8484)
DOT (RFC7858) – standards Track (updated by RFC8310)
RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 3629 – Standards Track
RFC 6570 – Standards Track
RFC 7540 – Standards Track (updated by RFC 8740, obsoleted by RFC 9113)
RFC 8174 – BCP 14
RFC 8484 – Standards Track

SVCB (Internet-Draft) - Standards Track

NB The DNSOP SVCB doc is already in the RFC editor queue.

Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Eight of the nine normative references are to RFCs, with the remaining one referencing an Internet-Draft.  The text in the draft providing the link to the Internet-Draft currently references an older version which has been superseded.


If such normative references exist, what is the strategy for their completion? 

I’ve asked the author to remove the “DOH” reference and replace it with RFC8484 to avoid clashing references to the same document, and to replace the “DOT” reference with RFC7858 for consistency of referencing.  I’ve asked the author to replace the reference to RFC7580 with an appropriate reference to RFC 9113.

The link to the Internet-Draft will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 9 of the document contains the IANA considerations, identifying the need for additions to the SVCB Service Parameters and DNS Underscore Global Scoped Entry Registries.  Specifically, IANA is requested to add the following entries:

- SVCB Service Parameters Registry
Number – 7; Name – dohpath; Meaning - DNS over HTTPS path template

- DNS Underscore Global Scoped Entry Registry
RR Type – SVCB; _Node Name - _dns; Meaning – DNS SVCB Info


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: Service Binding Mapping for DNS Servers

Current Version: draft-ietf-add-svcb-dns-03


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it will be ready for consideration by the IESG after it is updated to correct some normative referencing issues (see 1.g and 1.h below).


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

The document was written to harmonise several different drafts that all proposed to use the SVCB format to convey information about a DNS server that supports encrypted transport.  This document specifies a minimal SVCB mapping for DNS URIs without addressing any particular use case.  Draft-ietf-add-ddr and draft-ietf-add-dnr have both followed the approach outlined in this document.

The document has had detailed reviews by working group members, with replies to the mailing list by the author indicating how the comments have been addressed.  All issues and pull requests on GitHub are closed. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)

- Duplicate reference: RFC8484, mentioned in 'RFC8484', was also mentioned in 'DOH'.

Both have been highlighted to the author so should be addressed shortly.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

DOH (RFC 8484) – standards Track (also referenced as RFC 8484)
DOT (RFC7858) – standards Track (updated by RFC8310)
RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 3629 – Standards Track
RFC 6570 – Standards Track
RFC 7540 – Standards Track (updated by RFC 8740, obsoleted by RFC 9113)
RFC 8174 – BCP 14
RFC 8484 – Standards Track

SVCB (Internet-Draft) - Standards Track

NB The DNSOP SVCB doc is already in the RFC editor queue.

Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Eight of the nine normative references are to RFCs, with the remaining one referencing an Internet-Draft.  The text in the draft providing the link to the Internet-Draft currently references an older version which has been superseded.


If such normative references exist, what is the strategy for their completion? 

I’ve asked the author to remove the “DOH” reference and replace it with RFC8484 to avoid clashing references to the same document, and to replace the “DOT” reference with RFC7858 for consistency of referencing.  I’ve asked the author to replace the reference to RFC7580 with an appropriate reference to RFC 9113.

The link to the Internet-Draft will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 9 of the document contains the IANA considerations, identifying the need for additions to the SVCB Service Parameters and DNS Underscore Global Scoped Entry Registries.  Specifically, IANA is requested to add the following entries:

- SVCB Service Parameters Registry
Number – 7; Name – dohpath; Meaning - DNS over HTTPS path template

- DNS Underscore Global Scoped Entry Registry
RR Type – SVCB; _Node Name - _dns; Meaning – DNS SVCB Info


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: Service Binding Mapping for DNS Servers

Current Version: draft-ietf-add-svcb-dns-03


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it will be ready for consideration by the IESG after it is updated to correct some normative referencing issues (see 1.g and 1.h below).


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

The document was written to harmonise several different drafts that all proposed to use the SVCB format to convey information about a DNS server that supports encrypted transport.  This document specifies a minimal SVCB mapping for DNS URIs without addressing any particular use case.  Draft-ietf-add-ddr and draft-ietf-add-dnr have both followed the approach outlined in this document.

The document has had detailed reviews by working group members, with replies to the mailing list by the author indicating how the comments have been addressed.  All issues and pull requests on GitHub are closed. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)

- Duplicate reference: RFC8484, mentioned in 'RFC8484', was also mentioned in 'DOH'.

Both have been highlighted to the author so should be addressed shortly.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

DOH (RFC 8484) – standards Track (also referenced as RFC 8484)
DOT (RFC7858) – standards Track (updated by RFC8310)
RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 3629 – Standards Track
RFC 6570 – Standards Track
RFC 7540 – Standards Track (updated by RFC 8740, obsoleted by RFC 9113)
RFC 8174 – BCP 14
RFC 8484 – Standards Track

SVCB (Internet-Draft) - Standards Track



Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Eight of the nine normative references are to RFCs, with the remaining one referencing an Internet-Draft.  The text in the draft providing the link to the Internet-Draft currently references an older version which has been superseded.


If such normative references exist, what is the strategy for their completion? 

I’ve asked the author to remove the “DOH” reference and replace it with RFC8484 to avoid clashing references to the same document, and to replace the “DOT” reference with RFC7858 for consistency of referencing.  I’ve asked the author to replace the reference to RFC7580 with an appropriate reference to RFC 9113.

The link to the Internet-Draft will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 9 of the document contains the IANA considerations, identifying the need for additions to the SVCB Service Parameters and DNS Underscore Global Scoped Entry Registries.  Specifically, IANA is requested to add the following entries:

- SVCB Service Parameters Registry
Number – 7; Name – dohpath; Meaning - DNS over HTTPS path template

- DNS Underscore Global Scoped Entry Registry
RR Type – SVCB; _Node Name - _dns; Meaning – DNS SVCB Info


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: Service Binding Mapping for DNS Servers

Current Version: draft-ietf-add-svcb-dns-03


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it will be ready for consideration by the IESG after it is updated to correct some normative referencing issues (see 1.g and 1.h below).


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

The document was written to harmonise several different drafts that all proposed to use the SVCB format to convey information about a DNS server that supports encrypted transport.  This document specifies a minimal SVCB mapping for DNS URIs without addressing any particular use case.  Draft-ietf-add-ddr and draft-ietf-add-dnr have both followed the approach outlined in this document.

The document has had detailed reviews by working group members, with replies to the mailing list by the author indicating how the comments have been addressed.  All issues and pull requests on GitHub are closed. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)

- Duplicate reference: RFC8484, mentioned in 'RFC8484', was also mentioned in 'DOH'.

Both have been highlighted to the author so should be addressed shortly.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references are as follows:

DOH (RFC 8484) – standards Track (also referenced as RFC 8484)
DOT (RFC7858) – standards Track (updated by RFC8310)
RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 3629 – Standards Track
RFC 6570 – Standards Track
RFC 7540 – Standards Track (updated by RFC 8740, obsoleted by RFC 9113)
RFC 8174 – BCP 14
RFC 8484 – Standards Track

SVCB (Internet-Draft) - Standards Track



Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Eight of the nine normative references are to RFCs, with the remaining one referencing an Internet-Draft.  The text in the draft providing the link to the Internet-Draft currently references an older version which has been superseded.


If such normative references exist, what is the strategy for their completion? 

I’ve asked the author to remove the “DOH” reference and replace it with RFC8484 to avoid clashing references to the same document, and to replace the “DOT” reference with RFC7858 for consistency of referencing.  I’ve asked the author to replace the reference to RFC7580 with an appropriate reference to RFC 9113.

The link to the Internet-Draft will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 9 of the document contains the IANA considerations, identifying the need for additions to the SVCB Service Parameters and DNS Underscore Global Scoped Entry Registries.  Specifically, IANA is requested to add the following entries:

- SVCB Service Parameters Registry
Number – 7; Name – dohpath; Meaning - DNS over HTTPS path template

- DNS Underscore Global Scoped Entry Registry
RR Type – SVCB; _Node Name - _dns; Meaning – DNS SVCB Info


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.