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

Alissa Cooper <alissa@cooperw.in> Thu, 02 May 2019 15:20 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 EA1B8120397; Thu, 2 May 2019 08:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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=jyPuYu3H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wsUO3b+D
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 e-CnrizmVVSQ; Thu, 2 May 2019 08:20:27 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC23120377; Thu, 2 May 2019 08:20:27 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8B5E025C4C; Thu, 2 May 2019 11:20:26 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 02 May 2019 11:20:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=nGoTaVAEwOgLAyujr18YpE2 JoVZa8WjBkoJCxUeotaw=; b=jyPuYu3HLI8n5tDuYaLpEHRQ1NYmXfdOGf7bRlo fZCcqhpT2Fpj6RZ9h6pEBWLK1z5XC2/kxw3r/bdzZpEZNmHC3lsPoh+nXKiIMfyg REqhszVnK3iujgB2fom9HY7xEkjQcH4Y+cJ/toSNNzIc9ckLKSR38O29pCUXGrfv ryFMmZkIqc95SwkiSv+5BdSTqMcPDrTb0VMLwTDmVZeIETixieAmJaB66Y/A3hS9 GqQbBjWpbJzWfRGbi79PiegOfiBqdnbm+oqfHSwSa6Y3n3nBWo0SIlfUIVQnvdH4 d+AJv5t3N7jWPLvGzI3ggQnj8YsMafr9VmjAasRrBuk5C7g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=nGoTaV AEwOgLAyujr18YpE2JoVZa8WjBkoJCxUeotaw=; b=wsUO3b+DCzh5FUGY6GcsFJ hnhVubYjQfDQSzOvZUO1ye0Ic29vmQIPKWqbko/xNDLYMEdzJcM68/NhjgRpAKs0 QaRqDZI0lmy3H9CJoCDxOFCQTlljpIe8Tf78Pub1fuHHRIlhxNn1w9LLRFkXVY5f M947I+dUxp1PylEH7lX+MZFM646A7yVYt7tJUjZO07e6tY345IaLfIgcygz3K6lf hvowlelNAx5kVyJJvUtyCTmN/o7tNJgVMFUWNml6XVqSndzMAK9mZ7z4TyN7c5Ue jiPMQzkZryl3dtbbM8MuVN8cG2lJi5wiBhtmrmMyNsIU+5tD5fpt0WwSWZBLBT/w ==
X-ME-Sender: <xms:uQrLXC_uY90gv3TNjZFARSIV6G9JKa_NiO-Jy0HFdBXx-lHBtjhHKw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieelgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffktgggufffjgfvfhfosegrtdhmre hhtdejnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegtohho phgvrhifrdhinheqnecukfhppedujeefrdefkedruddujedrleegnecurfgrrhgrmhepmh grihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgvrhfu ihiivgeptd
X-ME-Proxy: <xmx:uQrLXJoBwnU5wpZF_oMAJl5WMvU0pk79zuN-ehcZdwkTMBeryQ8aTQ> <xmx:uQrLXNFc8iiOKaEcOKNAFbIbkL7_BuX78lznJ5tqGDKnFjIr7JIGFg> <xmx:uQrLXBmD9yH-0YHJaTQEby5zvFV7NxQKltIKh1at0-7P0g8_28iqCw> <xmx:ugrLXIe4yOfQNPpQnc_nTgBwHHbAq387WXwLNtw4d2a5opFjAgLU8A>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.94]) by mail.messagingengine.com (Postfix) with ESMTPA id DF50FE464C; Thu, 2 May 2019 11:20:24 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <95C6D084-9E41-496A-8FD1-4AA5BAA7426E@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C56B98FE-5DC0-4F3D-9264-138337F3FE71"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 2 May 2019 11:20:24 -0400
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA68A8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Cc: IESG <iesg@ietf.org>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
To: mohamed.boucadair@orange.com
References: <155676213548.2612.17892772935784304109.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68A8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/_02nGqOLBM7MLjAHn_FR6VYuE8c>
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, 02 May 2019 15:20:30 -0000

Hi Med,

> On May 2, 2019, at 3:18 AM, mohamed.boucadair@orange.com wrote:
> 
> Hi Alissa, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Alissa Cooper via Datatracker [mailto:noreply@ietf.org <mailto:noreply@ietf.org>]
>> Envoyé : jeudi 2 mai 2019 03:56
>> À : The IESG
>> Cc : draft-ietf-dots-signal-channel@ietf.org <mailto:draft-ietf-dots-signal-channel@ietf.org>; Liang Xia; dots-
>> chairs@ietf.org <mailto:chairs@ietf.org>; frank.xialiang@huawei.com <mailto:frank.xialiang@huawei.com>; dots@ietf.org <mailto:dots@ietf.org>
>> Objet : Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with
>> DISCUSS and COMMENT)
>> 
>> 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.
> 
> [Med] It seems that you missed "By default, “. 

Even with “by default” this still is problematic. MUST indicates an absolute requirement.

> 
> 
> 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,
> 
> [Med] I updated that reference to I-D.ietf-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/
> 
> [Med] I implemented the second change. 
> 
>> 
>> = 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?
> 
> [Med] It refers to the information conveyed in cdid. 

I think it would be helpful to clarify that.

> 
>> 
>> (2) The constructions "MUST ... (absent explicit policy/configuration
>> otherwise)" are problematic. I'm assuming these are meant to be SHOULDs.
>> 
> 
> [Med] I checked this wording with Ben.  

Ok, perhaps he can comment then.

> 
>> = Section 13.1 =
>> 
>> I don't understand why RFC 7951 is a normative reference but
>> draft-ietf-core-yang-cbor is an informative reference.
> 
> [Med] We used to have both as informative references, but unless I'm mistaken 7951 was moved to normative so that at least one method is supported.

This is being discussed in another thread, but if that is the case the normative requirement text needs to change too.

Thanks,
Alissa

> 
>> 
>> 
>> ----------------------------------------------------------------------
>> 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?
>> 
> 
> [Med] because all resources/state of a DOTS client are bound to this identifier.