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

Hi Nagendra, 

Thank you for the review. 

Please see inline.

Cheers,
Med

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

[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. 

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

[Med] OK.

> 
> Few observations below:
> 
> s/Districuted/Distributed

[Med] Thanks.

> 
> Thanks,
> Nagendra
> 
> 
> 
> --
> last-call mailing list
> last-call@ietf.org
> 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.