[Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
Alissa Cooper via Datatracker <noreply@ietf.org> Thu, 02 May 2019 01:55 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 7A0B81202A7; Wed, 1 May 2019 18:55:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-signal-channel@ietf.org, Liang Xia <frank.xialiang@huawei.com>, dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <155676213548.2612.17892772935784304109.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 18:55:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/C4NaE4niEX66VAKWfrkYuSIlvOI>
Subject: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and 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: Thu, 02 May 2019 01:55:36 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-dots-signal-channel-31: Discuss 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-signal-channel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 3 = "By default, a DOTS signal channel MUST run over port number TBD as defined in Section 9.1, for both UDP and TCP, unless the DOTS server has a mutual agreement with its DOTS clients to use a different port number. DOTS clients MAY alternatively support means to dynamically discover the ports used by their DOTS servers (e.g., [I-D.boucadair-dots-server-discovery])." MUST implies an absolute requirement, so "MUST ... unless" is a problematic construction. Furthermore, it doesn't make sense together with "MAY alternatively," which indicates that port number discovery is an alternative to the fixed to-be-assigned port. I didn't have time to get very far into draft-boucadair-dots-server-discovery, but it appears that it does not mandate support for any single discovery mechanism for clients and servers to support. If so, that "alternatively" seems like more of a problem, since it allows for there to be no interoperable mechanism for clients to discover server ports. I think maybe what was intended here was: s/MUST/SHOULD/ s/MAY alternatively/MAY additionally/ = Section 4.4.1 = (1) "In deployments where server-domain DOTS gateways are enabled, identity information about the origin source client domain SHOULD be propagated to the DOTS server. That information is meant to assist the DOTS server to enforce some policies such as grouping DOTS clients that belong to the same DOTS domain, limiting the number of DOTS requests, and identifying the mitigation scope. These policies can be enforced per-client, per-client domain, or both. Also, the identity information may be used for auditing and debugging purposes." Does "identity information" just refer to cdid, or something else? (2) The constructions "MUST ... (absent explicit policy/configuration otherwise)" are problematic. I'm assuming these are meant to be SHOULDs. = Section 13.1 = I don't understand why RFC 7951 is a normative reference but draft-ietf-core-yang-cbor is an informative reference. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 4.4.1 = "The 'cuid' is intended to be stable when communicating with a given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD NOT change over time. " Why is this the recommended behavior?
- [Dots] Alissa Cooper's Discuss on draft-ietf-dots… Alissa Cooper via Datatracker
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Barry Leiba
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [Dots] Alissa Cooper's Discuss on draft-ietf-… mohamed.boucadair