Skip to main content

Last Call Review of draft-ietf-dots-server-discovery-11
review-ietf-dots-server-discovery-11-opsdir-lc-nainar-2020-10-12-00

Request Review of draft-ietf-dots-server-discovery
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2020-10-12
Requested 2020-09-28
Authors Mohamed Boucadair , Tirumaleswar Reddy.K
I-D last updated 2020-10-12
Completed reviews Intdir Last Call review of -11 by Zhen Cao (diff)
Genart Last Call review of -12 by Peter E. Yee (diff)
Tsvart Last Call review of -11 by Kyle Rose (diff)
Opsdir Last Call review of -11 by Nagendra Kumar Nainar (diff)
Assignment Reviewer Nagendra Kumar Nainar
State Completed
Request Last Call review on draft-ietf-dots-server-discovery by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/773bdRWz1m9E9962_s0riPxYv7Y
Reviewed revision 11 (document currently at 15)
Result Has nits
Completed 2020-10-12
review-ietf-dots-server-discovery-11-opsdir-lc-nainar-2020-10-12-00
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