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

Nagendra Nainar via Datatracker <noreply@ietf.org> Mon, 12 October 2020 23:47 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 372CE3A0DD4; Mon, 12 Oct 2020 16:47:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Nagendra Nainar via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-dots-server-discovery.all@ietf.org, last-call@ietf.org, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160254645915.19164.9668371473019350974@ietfa.amsl.com>
Reply-To: Nagendra Nainar <naikumar@cisco.com>
Date: Mon, 12 Oct 2020 16:47:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/lxvKgls-ykNk-tm9nYxEGCCK2jA>
Subject: [Dots] Opsdir last call review of draft-ietf-dots-server-discovery-11
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2020 23:47:46 -0000

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