IETF Logo Mail Archive

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

Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 02 May 2019 08:19 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 913901202FE; Thu, 2 May 2019 01:19:45 -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, FREEMAIL_FROM=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=fastmail.fm header.b=T9PrIbJm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jMZ9c4gl
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 Of_90kgnYqWc; Thu, 2 May 2019 01:19:44 -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 4EDDE1200B8; Thu, 2 May 2019 01:19:44 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5085123CA0; Thu, 2 May 2019 04:19:43 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 02 May 2019 04:19:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=S N941G+bLNYl/tAQk+//kYK2M+46FfQglPMOTEXkWr8=; b=T9PrIbJm51F8sT/iR gLNHFTSuKaFRJXY/lk25IKjbk877CAqHsJGldqH7EEKzmdd95NHYRuc2LYlhoDT6 Xw/RTMhM8ZQDs25vlWzxicwNhiCTJZHSP9m2epPnyVdcMJY4oSfSIDn+wfiVYWdv t6Yb9ioxy3a5HNzKbOsVohmCqtT2e9CNw9D6ChZ6o2eFC+N99E9s2u6WofgnFyMj dkE6T9lR1YcNQmK1lGDsd+1ZEAT5hWqkZTsGwmCu98S9Vkeil96TSfsPqb/PApLA 65vmuw3R1kVYt15JaY5/LXxc80NvNKJoMOPqN4dAG/GIe/hf1rtHGAtzDEAkorZ+ svAxQ==
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=SN941G+bLNYl/tAQk+//kYK2M+46FfQglPMOTEXkW r8=; b=jMZ9c4gl2Rzix12rujrMniVN6V2eDZP1WeAzXgp6wF90yrL1RveHmTLNI LVUKnW6PV0tXGYC2DKqh/8tLaBtb7ORaOWWF/siile/TuOZLCgFQpVvUa0EzbVmp +d83pBPoISLyl1rXwjKdlevF0bzQIvIYChSCPt6VqxGwS/THPu1ACZ91vk8H4du+ jicmk6eL+CMUuVDIFw/ZnsB45AoJw/as0FAvjZykBCOigxNUmhm/WiFTc+cVifO2 6zXpx6dsjWbtcBRF6zp0AKMSRn1HMEKX88IEbBFzpvyAXZm9yGEl3JcVRkgtnZyd SZOmrv+8Li723pAFxtrOy5CewgGvw==
X-ME-Sender: <xms:HqjKXH_w7OJzB29T7PCuddkfo2RrPLRQDDqR16hdzYywl0t2Kd1_NA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieelgddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhffojgffgffkfhfvsehtqhhmtdhhtddvnecuhfhrohhmpeetlhgvgigv hicuofgvlhhnihhkohhvuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqe enucfkphepjeejrdeljedrudeghedrheehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr rghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpe dt
X-ME-Proxy: <xmx:HqjKXKDDxirS56xQRSYtg6p11X8SQFRUIRoKHML9QNi3eAjRyA2ArQ> <xmx:HqjKXBtiG_jOvoQb3Typ2cTUOn1AYvS6rk9ElqOpI9MUPt1ytarUow> <xmx:HqjKXCGAaBAed47D3oU1y5HDZpd8kYZA6Z_vysxIxPvtBX56oiSbmw> <xmx:H6jKXMfjhY2Y0vn-6k-QR3xkDcVukDnF-hil9c1aTZOZfRDeCvs2-w>
Received: from [192.168.0.12] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 5FD48103D0; Thu, 2 May 2019 04:19:42 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPad Mail (16D57)
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA68A8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 02 May 2019 09:19:41 +0100
Cc: Alissa Cooper <alissa@cooperw.in>, The 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@ietf.org" <dots@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <474C0602-E496-4577-B772-9BF9B6DCA28A@fastmail.fm>
References: <155676213548.2612.17892772935784304109.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68A8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Dr_7JuY3CawR9itp838nGOFmvs0>
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 08:19:46 -0000

Hi,

On 2 May 2019, at 08:18, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:

>> = 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.

As other IESG reviewers pointed out (better than my own description), having 2 non identical ways to encode the same information is going to cause interoperability problems. It also forces implementations to support both encodings and it makes draft-ietf-core-yang-cbor Normative.

I would encourage the WG to pick one mechanism. If it ends up being draft-ietf-core-yang-cbor, I am happy to progress it quick. (CORE WG is one of the WGs I am responsible for)

Best Regards,
Alexey

v2.23.0 | Report a Bug | By Email