Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Version: draft-ietf-dots-server-discovery-11


Overall Summary:

This draft is a standard track proposing the DOTS server discovery procedure. The draft 
proposes 3 different discovery options and sufficiently clarify the procedure required when one or more of the options co-exist. The draft further defines the protocol extensions required to carry the details in DHCPv4, DHCPv6 options and for DNS service discovery.

Overall this is a well written document. Some ambiguity observed that needs attention are listed below:

--> Section 5 states the below:
"
   The list of the IP addresses returned by DHCP servers is typically
   used to feed the DOTS server selection procedure or to provide DOTS
   agents with primary and backup IP addresses of their peer DOTS
   agents."
   
While the DHCP options replies with the bunch of IP/Ipv6 address of the peer DOTS agents. Is there any mechanism specified (or required) to select the primary/backup?. Or is it a local matter?.

==> The below text suggest to discard multicast and loopback address. While it is obvious for global scoped address, how would the node behave if it receives other reserved range address (such as Discard)?. Can it accept link-local address?.

The DHCP client MUST silently discard multicast and host loopback
   addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS.

==> It will be good if you can name the tables.


Few observations below:

s/Districuted/Distributed

Thanks,
Nagendra