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

<mohamed.boucadair@orange.com> Tue, 07 May 2019 06:30 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 2FE5612006B; Mon, 6 May 2019 23:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qcH7RArDZYVj; Mon, 6 May 2019 23:30:48 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99897120020; Mon, 6 May 2019 23:30:47 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 44yqVY712Kz5wQq; Tue, 7 May 2019 08:30:45 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 44yqVY4CGszCqjh; Tue, 7 May 2019 08:30:45 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 7 May 2019 08:30:45 +0200
From: <mohamed.boucadair@orange.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
Thread-Index: AQHVBC7K8lepRrQofUSBfHTPZVdDZqZfMjjA
Date: Tue, 7 May 2019 06:30:44 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA78DF7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <20190506171132.GJ19509@kduck.mit.edu>
In-Reply-To: <20190506171132.GJ19509@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ecbK_7Sk75u-N_ek8XBJYSN0qkw>
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: Tue, 07 May 2019 06:30:49 -0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoyé : lundi 6 mai 2019 19:12
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Alexey Melnikov; draft-ietf-dots-signal-channel@ietf.org; Alissa Cooper;
> dots@ietf.org; Liang Xia; The IESG; dots-chairs@ietf.org
> Objet : Re: Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> 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.

[Med] I made this change: 

OLD: 
   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signalling (Section 5).  Representing these data
   as CBOR data can either follow the rules in [I-D.ietf-core-yang-cbor]
   or those in [RFC7951] combined with JSON/CBOR conversion rules in
   [RFC7049]; both approaches produce a valid encoding.  All parameters
   in the payload of the DOTS signal channel are mapped to CBOR types as
   specified in Section 6.

NEW:
   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signaling (Section 5).  All parameters in the
   payload of the DOTS signal channel are mapped to CBOR types as
   specified in Table 4 (Section 6).

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