[Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Wed, 28 October 2020 21:40 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 B7E043A09C3; Wed, 28 Oct 2020 14:40:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-server-discovery@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov <valery@smyslov.net>, valery@smyslov.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <160392121572.3395.6848068643884505857@ietfa.amsl.com>
Date: Wed, 28 Oct 2020 14:40:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/NZomVnebXAyQXtjz-svYQD87uG4>
Subject: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)
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: Wed, 28 Oct 2020 21:40:16 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-dots-server-discovery-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Overall discussion question (but not at blocking DISCUSS level):
Does it make sense for DOTS clients to proactively discover appropriate DOTS
servers *before* a DDoS attack hits, to avoid the issue of discovery being
blocked by the attack that the client is trying to report?  Should this
document discuss that?

Other comments, all minor:

— Section 1 —

   This approach allows to
   reduce the impact of an attack and leads to more efficient defensive

Nit: “allows to” isn’t proper English, as it lacks a subject: “allows <some
entity> to”.  I think the subject you want here is DOTS, so maybe this works?:

NEW
   With this approach, DOTS can
   reduce the impact of an attack and lead to more efficient defensive
END

— Section 2 —

   The reader should be familiar with the terms defined in [RFC8811],
   [RFC3958], and [I-D.ietf-dots-signal-call-home].

I think this makes RFC 8811 and draft-ietf-dots-signal-call-home normative
references, as they define require terminology.  Certainly 8811 is normative in
any case, as the architecture needs to be understood.

— Section 3 —

   It is tempting to specify one single discovery mechanism for DOTS.
   Nevertheless, the analysis of the various use cases sketched in

Nit: Ignore this if you’re happy with the text as it is, but I would remove the
first sentence and just start this as “Analysis of the various use cases…”.

Please expand “CPE” on first use — especially as it’s confusingly and
contradictorily described as “Customer Premises Equipment” (provided by the
operator) and “Customer Provided Equipment” (not provided by the operator), so
we need to know which you mean.

— Section 4 —

   These may be
   specified either as IP addresses or the DNS name of a DOTS
   server.

The first half of the sentence is plural and the second singular.  Should both
be plural, “…either as IP addresses or DNS names of DOTS servers.” ?  If it’s
intentional that it can be multiple IP addresses but only one DNS name, it
would be better to be more explicit about that.

— Section 5 —

   and server while accommodating for the current best practices

Nit: not “accommodating for”: just “accommodating”.

— Section 5.1.1 —

   o  dots-agent-name: A fully qualified domain name of the peer DOTS
      agent.  This field is formatted as specified in Section 10 of
      [RFC8415].

As all Section 10 of 8415 does is send us to Section 3.1 of 1035, why not just
point to the latter directly, rather than making the reader follow an extra
reference?

And it wouldn’t be bad to append to the “an example” sentence as follows:

NEW
   An example of the dots-agent-name encoding is shown in Figure 4.
   This example conveys the FQDN "dots.example.com.”, and the
   resulting Option-length field is 18.
END