DDoS Open Threat Signaling (DOTS) Agent Discovery
draft-ietf-dots-server-discovery-15

[Ballot comment]
Thank you for the work put into this document. It is easy to read.

Please find below a couple of blocking DISCUSS points and some non-blocking COMMENT points and some nits.

In addition to my own points, please consider Zhen Caos' INT directorate review at:
https://datatracker.ietf.org/doc/review-ietf-dots-server-discovery-11-intdir-lc-cao-2020-10-12/

I hope that this helps to improve the document,

Regards,

-éric

== Previous DISCUSS -- solved by Med Boucadair and kept here for archiving purposes ==
-- Section 4 --
Trivial to fix: there is no "DHCP lease" for stateless DHCPv6... You should probably rather refer to the information-request refresh time option (section 21.23 of RFC 8415).

-- Section 5.1.2 --
I fully second Zhen Cao's review: how will the IPv4-mapped IPv6 address(es) be used? They MUST not appear on the wire and there is a DHCPv4 option to convey the DOTS information. Is it when DHCPv6 is available, no DHCPv4, and only IPv4 connectivity to the DOTS server ? If so, then please clarify the text.

== End of previous DISCUSS ==

Is DHCP really the way to go ? Even if it seems that there are use cases, relying on dynamic DHCP for such an important security protocol looks very strange to me (as the security AD has approved DHCP use, it is a mere non-blocking comment).

Should DNSSEC be required for domain name resolution or is relying only on TLS server authentication enough ?

The document gives a lot of IPv6 examples: thank you for this but it also mention multiple address families. Should Happy Eyeball be used when connected to the DOTS server?

-- Section 4 --
While this section title is "Unified DOTS Discovery Procedure", I read 3 different mechanisms so apparently conflicting with the section title. Suggest to remove "unified" from the section title.

Putting DHCP configuration under explicit configuration appears weird to me as DHCP is rather dynamic and on the same level as DNSD.

May I suggest to move the sentence "DOTS clients will prefer information received from the discovery methods in the order listed" before the list? It is an important sentence IMHO.

I wonder wheter the sentence "Expiry of a peer DOTS agent's certificate currently in use." is correct... Should it be "agent peer DOTS certificate" ?

-- Sections 5.1.3 and 5.2.3--
The part of the sentence "as distinguished by the presence of multiple root labels" should be explained more as it is unclear.

-- Section 6 --
Just to say that the use of S-NAPTR surprised me (no need to reply)

== NITS ==

The id-nits tool indicates a non used reference to RFC 8783, so, please clean up the reference list ;-)

-- Section 1 --
s/by multi-homed DOTS clients are out of scope/by multi-homed DOTS clients are out of this document scope/ ?

[Ballot comment]
Shouldn't the security consideration section 8.2 ave some additional warnings about the ease of affecting the dns lookup when .local is used. This as mDNS more easily can be gamed?

[Ballot discuss]
Thank you for the work put into this document. It is easy to read.

Please find below a couple of blocking DISCUSS points and some non-blocking COMMENT points and some nits.

In addition to my own points, please consider Zhen Caos' INT directorate review at:
https://datatracker.ietf.org/doc/review-ietf-dots-server-discovery-11-intdir-lc-cao-2020-10-12/

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4 --
Trivial to fix: there is no "DHCP lease" for stateless DHCPv6... You should probably rather refer to the information-request refresh time option (section 21.23 of RFC 8415).

-- Section 5.1.2 --
I fully second Zhen Cao's review: how will the IPv4-mapped IPv6 address(es) be used? They MUST not appear on the wire and there is a DHCPv4 option to convey the DOTS information. Is it when DHCPv6 is available, no DHCPv4, and only IPv4 connectivity to the DOTS server ? If so, then please clarify the text.

[Ballot comment]
Is DHCP really the way to go ? Even if it seems that there are use cases, relying on dynamic DHCP for such an important security protocol looks very strange to me (as the security AD has approved DHCP use, it is a mere non-blocking comment).

Should DNSSEC be required for domain name resolution or is relying only on TLS server authentication enough ?

The document gives a lot of IPv6 examples: thank you for this but it also mention multiple address families. Should Happy Eyeball be used when connected to the DOTS server?

-- Section 4 --
While this section title is "Unified DOTS Discovery Procedure", I read 3 different mechanisms so apparently conflicting with the section title. Suggest to remove "unified" from the section title.

Putting DHCP configuration under explicit configuration appears weird to me as DHCP is rather dynamic and on the same level as DNSD.

May I suggest to move the sentence "DOTS clients will prefer information received from the discovery methods in the order listed" before the list? It is an important sentence IMHO.

I wonder wheter the sentence "Expiry of a peer DOTS agent's certificate currently in use." is correct... Should it be "agent peer DOTS certificate" ?

-- Sections 5.1.3 and 5.2.3--
The part of the sentence "as distinguished by the presence of multiple root labels" should be explained more as it is unclear.

-- Section 6 --
Just to say that the use of S-NAPTR surprised me (no need to reply)

== NITS ==

The id-nits tool indicates a non used reference to RFC 8783, so, please clean up the reference list ;-)

-- Section 1 --
s/by multi-homed DOTS clients are out of scope/by multi-homed DOTS clients are out of this document scope/ ?

[Ballot comment]
Figure 2.  Editorial.  Expand DMS somewhere in the surrounding text.

Section 3.  Editorial. Per “Dynamic means to discover DOTS servers in a deterministic manner are interesting from an operational standpoint”, this reads like a problem statement.  Should it be restated as “dynamic discovery needs to be deterministic”?

Section 4.  Editorial.  Recommend not using the colloquialism “whack-a-mole”.

Section 4.  Per “DOTS clients will prefer information received from the discovery methods in the order listed”, does that mean the order list of 1, 2, 3 in the text above?  If so, perhaps make that clearer.

Section 4.  Editorial.  s/The discovery method is reiterated/The discovery method is repeated/

Section 5. I don’t have a better IETF reference, but RFC6125 is 9 years old so if something newer could be found that would be great.

Section 8.3.  In the absence of DNSSEC, DoT or DoH could also provide a degree of path integrity protection.

[Ballot comment]
Sec 5

“... this document allows for configuring names to DOTS clients ...“

I think this means that the client receives server names, not that the clients have names themselves. But I’m not sure.

[Ballot comment]
Sec 5

“... this document allows for configuring names to DOTS clients ...“

I think this means that the client receives server names, not that the clients have names themselves. But I’m not sure.

[Ballot comment]
Overall discussion question (but not at blocking DISCUSS level):
Does it make sense for DOTS clients to proactively discover appropriate DOTS servers *before* a DDoS attack hits, to avoid the issue of discovery being blocked by the attack that the client is trying to report?  Should this document discuss that?

Other comments, all minor:

— Section 1 —

  This approach allows to
  reduce the impact of an attack and leads to more efficient defensive

Nit: “allows to” isn’t proper English, as it lacks a subject: “allows  to”.  I think the subject you want here is DOTS, so maybe this works?:

NEW
  With this approach, DOTS can
  reduce the impact of an attack and lead to more efficient defensive
END

— Section 2 —

  The reader should be familiar with the terms defined in [RFC8811],
  [RFC3958], and [I-D.ietf-dots-signal-call-home].

I think this makes RFC 8811 and draft-ietf-dots-signal-call-home normative references, as they define require terminology.  Certainly 8811 is normative in any case, as the architecture needs to be understood.

— Section 3 —

  It is tempting to specify one single discovery mechanism for DOTS.
  Nevertheless, the analysis of the various use cases sketched in

Nit: Ignore this if you’re happy with the text as it is, but I would remove the first sentence and just start this as “Analysis of the various use cases…”.

Please expand “CPE” on first use — especially as it’s confusingly and contradictorily described as “Customer Premises Equipment” (provided by the operator) and “Customer Provided Equipment” (not provided by the operator), so we need to know which you mean.

— Section 4 —

  These may be
  specified either as IP addresses or the DNS name of a DOTS
  server.

The first half of the sentence is plural and the second singular.  Should both be plural, “…either as IP addresses or DNS names of DOTS servers.” ?  If it’s intentional that it can be multiple IP addresses but only one DNS name, it would be better to be more explicit about that.

— Section 5 —

  and server while accommodating for the current best practices

Nit: not “accommodating for”: just “accommodating”.

— Section 5.1.1 —

  o  dots-agent-name: A fully qualified domain name of the peer DOTS
      agent.  This field is formatted as specified in Section 10 of
      [RFC8415].

As all Section 10 of 8415 does is send us to Section 3.1 of 1035, why not just point to the latter directly, rather than making the reader follow an extra reference?

And it wouldn’t be bad to append to the “an example” sentence as follows:

NEW
  An example of the dots-agent-name encoding is shown in Figure 4.
  This example conveys the FQDN "dots.example.com.”, and the
  resulting Option-length field is 18.
END

[Ballot comment]
Pulling in some follow-up from the directorate review comments...

Section 3

  o  Resolving a DOTS server domain name offered by an upstream transit
      provider provisioned to a DOTS client into IP address(es) requires
      the use of the appropriate DNS resolvers; otherwise, resolving
      those names will fail.  The use of protocols such as DHCP does
      allow associating provisioned DOTS server domain names with a list
      of DNS servers to be used for name resolution.  Furthermore, DHCP
      allows directly provisioning IP addresses therefore avoiding the
      need for extra lookup delays.

I wonder if using "providing" rather than "provisioning" for at least the
last instance would be more clear.

  o  A resolution mechanism based on straightforward Naming Authority
      Pointer (S-NAPTR) resource records in the Domain Name System (DNS)
      (Section 6).

"Straightforward" needs to be capitalized here.

Section 4

  will support a local configuration.  More samples are discussed in
  Section 3:

nit: s/:/./

Section 5

  The list of the IP addresses returned by DHCP servers is typically
  used to feed the DOTS server selection procedure including when DOTS
  agents are provided with primary and backup IP addresses of their
  peer DOTS agents.  An example of DOTS server selection procedure is
  specified in Section 4.3 of [RFC8782].

The referenced section in 8782 is about the "happy eyeballs", i.e.,
picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem intended
to cover the case where you have to pick betwen different actual nodes.

I'm also not sure how the "primary and backup" is intended to work,
here.  Is the "provided with" referring to "by DHCP" or some out-of-band
configuration?

Section 8.1

  configured name.  If the DOTS agent is instructed to trust subdomains
  of the names in that list as well, a DOTS agent will also accept a
  DHCP-discovered name if the left-most label of the discovered name is
  matching a name in the pre-configured list.

If the agent is configured to trust subdomains of the configured list,
then in the case where that configuration is relevant for the attack,
the left-most label will be the (part of the) subdomain name, which is
explicitly not matching the pre-configured list -- the remaining bits
are what match.

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

The IANA Functions Operator has completed its review of draft-ietf-dots-server-discovery-11. 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 seven actions which we must complete.

First, IANA notes that, in Section 9.1 of the current document, the authors request the allocation of a new service name in the Port Number and Service Name Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

The service name dots-data will be added to the registry.

Second, also in the Port Number and Service Name Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

the existing registration for port number 4646 and service name dots-signal will be changed to reflect the following template:

Service Name: dots-signal
Port Number: 4646
Transport Protocol(s): TCP/UDP
Description: DOTS Signal Channel Protocol.
The service name is used to construct
SRV service names "_dots-signal._udp" and
"_dots-signal._tcp" for discovering DOTS
servers used to establish DOTS signal
channel.
Assignee: IESG
Contact: IETF Chair
Reference: [RFC8782][ RFC-to-be ]

Third, also in the Port Number and Service Name Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

IANA will assign a port number for dots-call-home. An expert review will be requested for the port request. The IANA state for the document will be set to "IANA NOT OK" until the port review is completed and approved.

Fourth, in the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

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

two new Option Codes are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_V6_DOTS_RI
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_V6_DOTS_ADDRESS
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (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."

Fifth, in the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

two new DHCP Options are to be registered as follows:

Tag: [ TBD-at-Registration ]
Name: OPTION_V4_DOTS_RI
Data Length: N
Meaning: The name of the peer DOTS agent
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Name: OPTION_V4_DOTS_ADDRESS
Data Length: N (the minimal length is 4)
Meaning: N/4 IPv4 addresses of peer DOTS agent(s)
Reference: [ RFC-to-be ]

Sixth, in the S-NAPTR Application Service Tags registry on the Straightforward-NAPTR (S-NAPTR) Parameters registry page located at:

https://www.iana.org/assignments/s-naptr-parameters/

the following two registrations will be made:

Tag: DOTS
Reference: [ RFC-to-be ]

Tag: DOTS-CALL-HOME
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (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."

Seventh, in the S-NAPTR Application Protocol Tags also on the Straightforward-NAPTR (S-NAPTR) Parameters registry page located at:

https://www.iana.org/assignments/s-naptr-parameters/

the following three registrations will be made:

Tag: signal.udp
Reference: [ RFC-to-be ]

Tag: signal.tcp
Reference: [ RFC-to-be ]

Tag: data.tcp
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-12):

From: The IESG
To: IETF-Announce
CC: Valery Smyslov , draft-ietf-dots-server-discovery@ietf.org, dots-chairs@ietf.org, kaduk@mit.edu, valery@smyslov.net, dots@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery) to Proposed Standard


The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Distributed-Denial-of-Service Open
Threat Signaling (DOTS) Agent
  Discovery'
  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 2020-10-12. 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


  This document specifies mechanisms to configure Districuted Denial of
  Service Open Threat Signaling (DOTS) clients with their DOTS servers.
  The discovery procedure also covers the DOTS Signal Channel Call
  Home.  Knowing the appropriate DOTS server for a given location can
  be useful to engage mitigation actions even in cases where the DOTS
  client cannot localize the attack, but only knows that some resources
  are under attack and that help is needed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/



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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

  Proposed Standard as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:

  This document specifies mechanisms to configure Distributed-Denial-of-Service
  Open Threat Signaling (DOTS) clients with their DOTS servers. 
  The discovery procedure also covers the DOTS Signal Channel Call Home.

Working Group Summary:

  The -00 version of the document was published as individual I-D in June 2017.
  The call for adoption was issued in November 2018 and ended up in March 2019.
  The WG support for adoption of this draft was steady with quite a lot of
  suggestions how to improve the document. The draft was fairly well (for this WG)
  discussed and has been reviewed by active WG members.

Document Quality:

  Document authors are also co-authors of core DOTS documents (signal channel, data channel etc.)
  I believe that they have good understanding of DOTS architecture.
  There is at least one implementations of this specification.

Personnel:

  Valery Smyslov (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

  No. The document was a subject of several reviews in WG. In addition, early version of the draft was reviewed by Bernie Volz from DHC WG:
  https://github.com/boucadair/draft-ietf-dots-discovery/issues/1

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

  The document is concerned with using DHCP and DNS. I don't see any issues with using them,
  but I think that additional reviews from DHCP and DNS experts would be helpful.

(6) Describe any specific concerns or issues that the Document Shepherd has 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. 

  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  All authors and contributors confirmed that they are not aware of any IPR related to this draft.
  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/H8mMCJRRoJLgL3cu1lXoWyKnTR8
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/yBVC0Ehv0A4wDVQRiIHQzWRv1aU
  ** Prashanth Patil -- https://mailarchive.ietf.org/arch/msg/dots/8zBAGkTbOQ4eH2s1V_Xg4Iamo4k

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

  No IPR disclosure has been filed that reference this document.

(9) 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? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 

  No ID nits were found by idnits tool except for referencing old versions of some active I-Ds, that can easily be fixed during publication.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

  None are applicable.

(13) Have all references within this document been identified as either normative or informative? 

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

  IANA actions are clearly described and are consistent with the body of the document.
  1) A new service name "dots-data" is added to the "Service Name and Transport Protocol Port Number" registry (without port allocation).
  2) Two records in the "Service Name and Transport Protocol Port Number" registry are updated: "dots-signal" and "dots-call-home". These records don't
    exist yet, they will be allocated when draft-ietf-dots-signal-channel and draft-ietf-dots-signal-call-home are processed by IANA (these drafts contain
    the corresponding requests). Note, that a situation may happen when this draft is processed by IANA before draft-ietf-dots-signal-channel, so the IANA
    should be instructed to handle this correctly - either allocate "dots-call-home" service name instead of updating the record or postpone processing
    this document until draft-ietf-dots-signal-channel is processed. There is no such problem with draft-ietf-dots-signal-channel since it's already in the RFC Editor queue.
  2) Two new DHCPv6 Option Codes are allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6): Option Codes" registry.
  3) Two new DHCPv4 Option Codes are allocated in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters: BOOTP Vendor Extensions and DHCP Options" registry.
  4) Two new Application Service Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Service Tags" registry.
  5) Three new Application Protocol Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Protocol Tags" registry.
  Registration policies for all these allocations are met (provided that the draft is published as a Standards Track RFC).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

  No new registries are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The document contsins no YANG module.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

  Proposed Standard as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:

  This document specifies mechanisms to configure Distributed-Denial-of-Service
  Open Threat Signaling (DOTS) clients with their DOTS servers. 
  The discovery procedure also covers the DOTS Signal Channel Call Home.

Working Group Summary:

  The -00 version of the document was published as individual I-D in June 2017.
  The call for adoption was issued in November 2018 and ended up in March 2019.
  The WG support for adoption of this draft was steady with quite a lot of
  suggestions how to improve the document. The draft was fairly well (for this WG)
  discussed and has been reviewed by active WG members.

Document Quality:

  Document authors are also co-authors of core DOTS documents (signal channel, data channel etc.)
  I believe that they have good understanding of DOTS architecture.
  To my best knowledge there are no implementations of this specification yet.

Personnel:

  Valery Smyslov (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

  No. The document was a subject of several reviews in WG. In addition, early version of the draft was reviewed by Bernie Volz from DHC WG:
  https://github.com/boucadair/draft-ietf-dots-discovery/issues/1

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

  The document is concerned with using DHCP and DNS. I don't see any issues with using them,
  but I think that additional reviews from DHCP and DNS experts would be helpful.

(6) Describe any specific concerns or issues that the Document Shepherd has 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. 

  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  All authors and contributors confirmed that they are not aware of any IPR related to this draft.
  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/H8mMCJRRoJLgL3cu1lXoWyKnTR8
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/yBVC0Ehv0A4wDVQRiIHQzWRv1aU
  ** Prashanth Patil -- https://mailarchive.ietf.org/arch/msg/dots/8zBAGkTbOQ4eH2s1V_Xg4Iamo4k

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

  No IPR disclosure has been filed that reference this document.

(9) 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? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 

  No ID nits were found by idnits tool except for referencing old versions of some active I-Ds, that can easily be fixed during publication.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

  None are applicable.

(13) Have all references within this document been identified as either normative or informative? 

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

  IANA actions are clearly described and are consistent with the body of the document.
  1) A new service name "dots-data" is added to the "Service Name and Transport Protocol Port Number" registry (without port allocation).
  2) Two records in the "Service Name and Transport Protocol Port Number" registry are updated: "dots-signal" and "dots-call-home". These records don't
    exist yet, they will be allocated when draft-ietf-dots-signal-channel and draft-ietf-dots-signal-call-home are processed by IANA (these drafts contain
    the corresponding requests). Note, that a situation may happen when this draft is processed by IANA before draft-ietf-dots-signal-channel, so the IANA
    should be instructed to handle this correctly - either allocate "dots-call-home" service name instead of updating the record or postpone processing
    this document until draft-ietf-dots-signal-channel is processed. There is no such problem with draft-ietf-dots-signal-channel since it's already in the RFC Editor queue.
  2) Two new DHCPv6 Option Codes are allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6): Option Codes" registry.
  3) Two new DHCPv4 Option Codes are allocated in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters: BOOTP Vendor Extensions and DHCP Options" registry.
  4) Two new Application Service Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Service Tags" registry.
  5) Three new Application Protocol Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Protocol Tags" registry.
  Registration policies for all these allocations are met (provided that the draft is published as a Standards Track RFC).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

  No new registries are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The document contsins no YANG module.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

  Proposed Standard as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:

  This document specifies mechanisms to configure Distributed-Denial-of-Service
  Open Threat Signaling (DOTS) clients with their DOTS servers. 
  The discovery procedure also covers the DOTS Signal Channel Call Home.

Working Group Summary:

  The -00 version of the document was published as individual I-D in June 2017.
  The call for adoption was issued in November 2018 and ended up in March 2019.
  The WG support for adoption of this draft was steady with quite a lot of
  suggestions how to improve the document. The draft was fairly well (for this WG)
  discussed and has been reviewed by active WG members.

Document Quality:

  Document authors are also co-authors of core DOTS documents (signal channel, data channel etc.)
  I believe that they have good understanding of DOTS architecture.
  To my best knowledge there are no implementations of this specification yet.

Personnel:

  Valery Smyslov (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

  No. The document was a subject of several reviews in WG. In addition, early version of the draft was reviewed by Bernie Volz from DHC WG:
  https://github.com/boucadair/draft-ietf-dots-discovery/issues/1

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

  The document is concerned with using DHCP and DNS. I don't see any issues with using them,
  but I think that additional reviews from DHCP and DNS experts would be helpful.

(6) Describe any specific concerns or issues that the Document Shepherd has 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. 

  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  All authors and contributors confirmed that they are not aware of any IPR related to this draft.
  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/H8mMCJRRoJLgL3cu1lXoWyKnTR8
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/yBVC0Ehv0A4wDVQRiIHQzWRv1aU
  ** Prashanth Patil -- https://mailarchive.ietf.org/arch/msg/dots/8zBAGkTbOQ4eH2s1V_Xg4Iamo4k

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

  No IPR disclosure has been filed that reference this document.

(9) 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? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 

  No ID nits were found by idnits tool except for referencing old versions of some active I-Ds, that can easily be fixed during publication.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

  None are applicable.

(13) Have all references within this document been identified as either normative or informative? 

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

  IANA actions are clearly described and are consistent with the body of the document.
  1) A new service name "dots-data" is added to the "Service Name and Transport Protocol Port Number" registry (without port allocation).
  2. Two records in the "Service Name and Transport Protocol Port Number" registry are updated: "dots-signal" and "dots-call-home". These records don't
    exist yet, they will be allocated when draft-ietf-dots-signal-channel and draft-ietf-dots-signal-call-home are processed by IANA (these drafts contain
    the corresponding requests). Note, that a situation may happen when this draft is processed by IANA before draft-ietf-dots-signal-channel, so the IANA
    should be instructed to handle this correctly - either allocate "dots-call-home" service name instead of updating the record or postpone processing
    this document until draft-ietf-dots-signal-channel is processed. There is no such problem with draft-ietf-dots-signal-channel since it's already in the RFC Editor queue.
  2) Two new DHCPv6 Option Codes are allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6): Option Codes" registry.
  3) Two new DHCPv4 Option Codes are allocated in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters: BOOTP Vendor Extensions and DHCP Options" registry.
  4) Two new Application Service Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Service Tags" registry.
  5) Three new Application Protocol Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Protocol Tags" registry.
  Registration policies for all these allocations are met (provided that the draft is published as a Standards Track RFC).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

  No new registries are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The document contsins no YANG module.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

  Proposed Standard as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:

  This document specifies mechanisms to configure Distributed-Denial-of-Service
  Open Threat Signaling (DOTS) clients with their DOTS servers. 
  The discovery procedure also covers the DOTS Signal Channel Call Home.

Working Group Summary:

  The -00 version of the document was published as individual I-D in June 2017.
  The call for adoption was issued in November 2018 and ended up in March 2019.
  The WG support for adoption of this draft was steady with quite a lot of
  suggestions how to improve the document. The draft was fairly well (for this WG)
  discussed and has been reviewed by active WG members.

Document Quality:

  Document authors are also co-authors of core DOTS documents (signal channel, data channel etc.)
  I believe that they have good understanding of DOTS architecture.
  To my best knowledge there are no implementations of this specification yet.

Personnel:

  Valery Smyslov (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

  No. The document was a subject of several reviews in WG. In addition, early version of the draft was reviewed by Bernie Volz from DHC WG:
  https://github.com/boucadair/draft-ietf-dots-discovery/issues/1

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

  The document is concerned with using DHCP and DNS. I don't see any issues with using them,
  but I think that additional reviews from DHCP and DNS experts would be helpful.

(6) Describe any specific concerns or issues that the Document Shepherd has 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. 

  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  All authors and contributors confirmed that they are not aware of any IPR related to this draft.
  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/H8mMCJRRoJLgL3cu1lXoWyKnTR8
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/yBVC0Ehv0A4wDVQRiIHQzWRv1aU
  ** Prashanth Patil -- https://mailarchive.ietf.org/arch/msg/dots/8zBAGkTbOQ4eH2s1V_Xg4Iamo4k

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

  No IPR disclosure has been filed that reference this document.

(9) 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? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 

  No ID nits were found by idnits tool except for referencing old versions of some active I-Ds, that can easily be fixed during publication.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

  None are applicable.

(13) Have all references within this document been identified as either normative or informative? 

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

  IANA actions are clearly described and are consistent with the body of the document.
  1) A new service name "dots-data" is added to the "Service Name and Transport Protocol Port Number" registry (without port allocation).
  2. Two records in the "Service Name and Transport Protocol Port Number" registry are updated: "dots-signal" and "dots-call-home". These records don't
    exist yet, they will be allocated when draft-ietf-dots-signal-channel and draft-ietf-dots-signal-call-home are processed by IANA (these drafts contain
    the corresponding requests). Note, that a situation may happen when this draft is processed by IANA before draft-ietf-dots-signal-channel, so the IANA
    should be instructed to handle this correctly - either allocate "dots-call-home" service name instead of updating the record or postpone processing
    this document until draft-ietf-dots-signal-channel is processed. There is no such problem with draft-ietf-dots-signal-channel since it's already in the RFC Editor queue.
  2) Two new DHCPv6 Option Codes are allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6): Option Codes" registry.
  3) Two new DHCPv4 Option Codes are allocated in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters: BOOTP Vendor Extensions and DHCP Options" registry.
  4) Two new Application Service Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Service Tags" registry.
  5) Three new Application Protocol Tags are allocated in the "Straightforward-NAPTR (S-NAPTR) Parameters: S-NAPTR Application Protocol Tags" registry.
  Registration policies for all these allocations are met (provided that the draft is published as a Standards Track RFC).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

  No new registries are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The document contsins no YANG module.