[Dots] Warren Kumari's No Objection on draft-ietf-dots-architecture-16: (with COMMENT)
Warren Kumari via Datatracker <noreply@ietf.org> Wed, 05 February 2020 17:31 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 302921200BA; Wed, 5 Feb 2020 09:31:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw <rdd@cert.org>, Valery Smyslov <valery@smyslov.net>, dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <158092386119.12787.6879612110839501695.idtracker@ietfa.amsl.com>
Date: Wed, 05 Feb 2020 09:31:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Tz1kCz_gJYTbEIsakKF1s6uL9No>
Subject: [Dots] Warren Kumari's No Objection on draft-ietf-dots-architecture-16: (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, 05 Feb 2020 17:31:01 -0000
Warren Kumari has entered the following ballot position for draft-ietf-dots-architecture-16: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Firstly, thank you for a well written, and easy to understand document -- I personally always find architecture type documents helpful... I do have a few non-blocking comments: 1: "For example, if the DOTS client domain leverages the DDoS mitigation service of its Internet Transit Provider (ITP), the ITP knows the prefixes assigned to the DOTS client domain. However, if the DDoS Mitigation is offered by a third party DDoS mitigation service provider, it does not know the resources owned by the DOTS client domain." This is vastly oversimplifying the real-world, to the point that it is harmful / propagates dangerous misconceptions. ISPs may or may not know the prefixes assigned to their customers - they really *should* know the prefixes that the client is choosing to announce to them, but the client may have other prefixes which they only announce through other transits (yes, in this case this ISP would only be providing mitigations for prefixes announced to it, but this isn't clear). In addition, if the DDoS mitigation is provides by a 3rd party, it could know what resources are owned by the client -- in fact, it kind of has to if it is going to agree to mitigate for those prefixes. Note that I *almost* made this a DISCUSS point - I really really think that this bit should be either carefully revised, or, better yet, just struck... 2: "Signal loss is not caused by links congested with attack traffic alone, and as such mitigation requests triggered by signal channel degradation in either direction may incur unnecessary costs, in network performance and operational expense alike." The "operational expense" is vary vague - enabling DDoS mitigations is almost definitely going to cause a user visible impact, especially in the case where the mitigator announces a BGP route to attract traffic. Is this covered by 'operational expense'? This section also leaves out the fact that there is likely a financial impact. 3: "The signal and data channels are loosely coupled, and may not terminate on the same DOTS server." - s/may not/might not/. Every-time I'm sitting on a plane and the safety briefing says that oxygen mask will fall from the ceiling and that "the bag may not inflate" I have visions of IETFers (and similar pedants!) sitting there and squeezing the bag to ensure that it doesn't... "the bag *might* not inflate" is what is intended, and is also what you want :-P
- [Dots] Warren Kumari's No Objection on draft-ietf… Warren Kumari via Datatracker
- Re: [Dots] Warren Kumari's No Objection on draft-… Konda, Tirumaleswar Reddy