Subject: [Dots] Opsdir last call review of draft-ietf-dots-server-discovery-11

From: Nagendra Nainar via Datatracker <[email-masked]>
Date: Mon, 12 Oct 2020 16:47:39 -0700

Reviewer: Nagendra Nainar
Review result: Has Nits

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

---

From: <[email-masked]>
Date: Tue, 13 Oct 2020 06:02:47 +0000

Hi Nagendra, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : last-call [mailto:[email-masked]] De la part de
> Nagendra Nainar via Datatracker
> Envoyé : mardi 13 octobre 2020 01:48
> À : [email-masked]
> Cc : [email-masked]; draft-ietf-dots-server-
> [email-masked]; [email-masked]
> Objet : [Last-Call] Opsdir last call review of draft-ietf-dots-
> server-discovery-11
> 
> 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.
> 
> 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:
> 
> 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?.

[Med] This is beyond discovery and is handled by the DOTS agent itself. See for example, https://tools.ietf.org/html/rfc8782#section-4.3. 

> 
> ==> 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?.

[Med] link-local addresses are acceptable. Think about an internal DOTS client in a LAN and a DOTS gateway in the CPE.  

Entities operating a DOTS server are supposed to be familiar with RFC6666 (discard). No specific behaviour is required at the client side. Packets sent to such address are likely to be blocked (if the client and the server are located in the distinct domains) or be subject to any policy at the DOTS server domain. 

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

[Med] OK.

> s/Districuted/Distributed

[Med] Thanks.

> 
> Thanks,
> Nagendra
> 
> 
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.