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

Benjamin Kaduk <kaduk@mit.edu> Mon, 06 May 2019 17:11 UTC

Return-Path: <kaduk@mit.edu>
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 6CA4D120110; Mon, 6 May 2019 10:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ArSDNIMud3N7; Mon, 6 May 2019 10:11:46 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AFA120071; Mon, 6 May 2019 10:11:46 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x46HBWLQ025685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 13:11:34 -0400
Date: Mon, 6 May 2019 12:11:32 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: mohamed.boucadair@orange.com
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "dots@ietf.org" <dots@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Message-ID: <20190506171132.GJ19509@kduck.mit.edu>
References: <155676213548.2612.17892772935784304109.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68A8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <474C0602-E496-4577-B772-9BF9B6DCA28A@fastmail.fm> <787AE7BB302AE849A7480A190F8B93302EA68B47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA68B47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/KsghAa2eXYxJvOfWZ6_Ug739pYI>
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: Mon, 06 May 2019 17:11:49 -0000

On Thu, May 02, 2019 at 08:30:51AM +0000, mohamed.boucadair@orange.com wrote:
> Re-,
> 
> Actually, there is no interoperability problem. 

The reference to both draft-ietf-core-yang-cbor and RFCs 7951+7049 presents
an attractive nuisance of an interoperability problem; to say that "both
approaches produce a valid encoding" without qualifier that an extra
consultation to tables 4 and 6 is grossly misleading.

> The implementers do only need to look at tables 4 and 6:

If that's what they have to do, you need to point them there, instead of
just the "normal" ways to go from YANG to CBOR.

-Ben

>    All parameters in the payload of the DOTS signal channel MUST be
>    mapped to CBOR types as shown in Table 4.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Alexey Melnikov [mailto:aamelnikov@fastmail.fm]
> > Envoyé : jeudi 2 mai 2019 10:20
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : Alissa Cooper; The IESG; draft-ietf-dots-signal-channel@ietf.org; Liang
> > Xia; dots@ietf.org; dots-chairs@ietf.org
> > Objet : Re: Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31:
> > (with DISCUSS and COMMENT)
> > 
> > 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
>