[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
- Re: [Dots] Barry Leiba's No Objection on draft-ie… Benjamin Kaduk
- [Dots] Barry Leiba's No Objection on draft-ietf-d… Barry Leiba via Datatracker
- Re: [Dots] Barry Leiba's No Objection on draft-ie… mohamed.boucadair
- Re: [Dots] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [Dots] Barry Leiba's No Objection on draft-ie… mohamed.boucadair
- Re: [Dots] Barry Leiba's No Objection on draft-ie… Barry Leiba