Re: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 09 May 2019 21:09 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F60120156; Thu, 9 May 2019 14:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=JHJ2DrJW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=16nU3WUf
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-kGR57mvy6f; Thu, 9 May 2019 14:09:20 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD51120026; Thu, 9 May 2019 14:08:51 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 98C7022572; Thu, 9 May 2019 17:08:50 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 09 May 2019 17:08:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=h 60zLrCyiRwdqWjRY8r4Ox2uxr0dIOPJW2siMOiSIUM=; b=JHJ2DrJWbYNRTXJq6 OeLmhYwjBdvksocGt65LfT/NoZ11QMhPZgoEB8nJXoVbwYkU1LqTceA3UlDQWfak d+EQjX71+hIYgUl1rSrsmCYsOzsvQbn1vbD2sFw2ge1ZDo5lzBwR0bqFHMhrdYuB H/gbHrmCWsJuJhFeA8zzyGnDwtFPUx5uEeggGONc6ZsLqUN2Xi4YjHh6FcynBpps NgBPEmpy3yowAflWwRk157Ry7qWShUP7Vb90uwv57uUQjW7eqoy+xHCYZfRc/qF5 GPLYjZIpEi901SOXX4nr27r9FNpS62m3FF01hIeC5Rn2BkbG7rYPK4T0pNPJhx9d bfI/w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=h60zLrCyiRwdqWjRY8r4Ox2uxr0dIOPJW2siMOiSI UM=; b=16nU3WUfO9IRcFamHvdM6wVdksk5RkOU2AOOuPgcIYqiV+uf76GAedjkk AX0BuV6qz4fLrU51gG3KJtcP37MFPAseqZ9pHfwCXGq28qJ8wi/LZHjUknCIQTQh +wPVOdMd4136iIQnmAnXPnZvpT+AEp7hHWU9uZjDkVe3GDkD7NAl+6E/IX/lbIO0 QNRclbia6HEuOILq36anYqiXlqOfBej+CY8PnO5QaIEslkRU/n/srBxxSlPxHpGP SQPkbBuGkSrADjgoF8WpISaTTDXKjTk7H+/Wf7lYPThMWga83KBcshqEPherFRL2 IL1mU0duzQ1vikYuVCDLNIe7C/9WA==
X-ME-Sender: <xms:4ZbUXB-FxqT2aXA4SXuiikTkR6GB8j_XXjFHsd0-r2X58yV6zn4_RA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeeigdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogetfedtuddqtdduucdludehmdenucfjughrpegtgg fuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhsrgcuvehoohhp vghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrihhnpehivghtfh drohhrghenucfkphepudejfedrfeekrdduudejrdekjeenucfrrghrrghmpehmrghilhhf rhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpe dt
X-ME-Proxy: <xmx:4ZbUXJ992b_f4a37-i2c58xnAlSxwpHrr8TpJUlizdrG0ldDrLzYSg> <xmx:4ZbUXKBDtogUGZ7DeOLUn6sYXJt8uVz1zIh-PgzOaVxS6XsRmmxusQ> <xmx:4ZbUXJyU2xxncaz-4-6bXo7_XQbS3_Hfu9lFcyolOwglMA0BSBYcpw> <xmx:4pbUXCNfAUh534WR6rpOGpHoz9Fty05-CHjLy6V3DTP6kUH__Yaetw>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 27AE510379; Thu, 9 May 2019 17:08:49 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <155676213548.2612.17892772935784304109.idtracker@ietfa.amsl.com>
Date: Thu, 9 May 2019 17:08:47 -0400
Cc: IESG <iesg@ietf.org>, draft-ietf-dots-signal-channel@ietf.org, Liang Xia <frank.xialiang@huawei.com>, dots@ietf.org, dots-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D15F9BD-A743-4EA4-86D8-35FA22FE5438@cooperw.in>
References: <155676213548.2612.17892772935784304109.idtracker@ietfa.amsl.com>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/j_aXUZYQvpS3yUjhv6y1q-uNmdA>
Subject: Re: [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
Precedence: list
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, 09 May 2019 21:09:23 -0000

Thanks, the changes look good. However I still don’t understand why RFC 7951 is listed as a normative reference.

Alissa


> On May 1, 2019, at 9:55 PM, Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
> 
> 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?
> 
>