Re: [Cbor] [Ext] Éric Vyncke's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Mon, 28 September 2020 13:49 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296C3A0F19 for <cbor@ietfa.amsl.com>; Mon, 28 Sep 2020 06:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dkmaw4yG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=s1xS/z9B
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 LeTN49LUT0MQ for <cbor@ietfa.amsl.com>; Mon, 28 Sep 2020 06:49:32 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CCC3A0F09 for <cbor@ietf.org>; Mon, 28 Sep 2020 06:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8060; q=dns/txt; s=iport; t=1601300972; x=1602510572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oQu0WtEHBNY2On8f1lUfpiXyc9SsXnc1SEZ2kZY6cHI=; b=dkmaw4yGbkmyLmywnql8nf/RQ5tR5niJco27EIMKBJTJNw6EeXxRJK8Q +cCYlaI0RMr0FxfQDRW5FgT7iNwjFfbc87TIv8E/vccHV/OXnEp+1h0oI zCFPbGSR5HLoY6mbVkyBGvE+CkF3ei+l0IybboxWoEoFMpgNGdgTYDtDp I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AvuSZIRUK6BS0pLmoKE8Wb1U9/WrV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHufNPguzQ9af6Vj9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7TqXS063gVAB?= =?us-ascii?q?qsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByCgAx6XFf/4QNJK1ggQmBT4FSUQd?= =?us-ascii?q?wWS8shD2DRgONVSaYdoJTA1ULAQEBDQEBJQgCBAEBhEsCF4IaAiU3Bg4CAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRthVwMhXIBAQEBAgESEREMAQEpDgELBAIBCBEDAQIDAiY?= =?us-ascii?q?CAgIwFQUDCAIEAQ0FIoMEAYJLAw4gAQ6pfwKBOYhhdoEygwEBAQWBNwIBDUG?= =?us-ascii?q?CehiCEAmBDiqCcoNpgiaELRuBQT+BEScMEIFPfj6CXAICAQGBW4MXM4ItkBc?= =?us-ascii?q?IgxqSfpAFgQkKgmeIe5FcAx+DDYEoiFaFO4kChUuET446immVIwIEAgQFAg4?= =?us-ascii?q?BAQWBaiSBV3AVZQGCPglHFwINjigDFxSDOoJugiaFQnQCNQIGAQkBAQMJAXu?= =?us-ascii?q?OQQEB?=
X-IronPort-AV: E=Sophos;i="5.77,313,1596499200"; d="scan'208";a="563000594"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Sep 2020 13:49:31 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 08SDnUZZ008733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2020 13:49:31 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 28 Sep 2020 08:49:30 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 28 Sep 2020 09:49:28 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 28 Sep 2020 08:49:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lKULt5Jh+XE34RkhYpqD4RnljfEofqt9TqCGkirMrlPWLCwPWbwh9hVrzeUTPAJjfPBaU0xNC3pn/WhcpGkLt8GiGnPsZA4SMdBgOAPaMACXP63bca9Yws0+j/OQDOCDmDbZusgw3/7HuwEhTzKVDmS+zhGTgJ92TE26PRYF3WfLaV437eN40sFZ31Qsk7uHiawPKpPXbGiUme7Wb+N/eIihfo/D8PN6u7G9D/WUI9stQ7n8y7sVxApSfx9PJUS1RM19AY4s/NsNTumU5qSk1EE4ktdjZH34XW44lhRgPcwOAxeRn0Ob5H2OkAPfmq/yTFG2wpSfuxtj38U8K7usIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oQu0WtEHBNY2On8f1lUfpiXyc9SsXnc1SEZ2kZY6cHI=; b=RencV6yxu/j8T9ymqe/TMPyiLeAimEwJ/ZiG37CbnNisGALQ8jPw3UxZ2MatC0tC7wkyUHl1YUQXji5YlmE5W3Zq3B4wCjYVR5oM44+jj4WA8BU6C/2HpF/kimgt0QPNsN6XjnJKOV2HvKRc/PizMxkrz3ne0hR7Wa43ACnquJX641YCb7yQgZJuayQVtQCz0DapV9cuwJuX45zCZpy0Lr4tNahH439b0FK+cqpNEIC9xjaplt2rdaBJ9uJM4ONH4nZNuDYUT1qN4/0sIf0/LNqJKVuDd4zotzMktAdhlm9yQdkakWHLPH2qGx7MGSXitMO6dWlE3hEiRcT710l1hw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oQu0WtEHBNY2On8f1lUfpiXyc9SsXnc1SEZ2kZY6cHI=; b=s1xS/z9B9+C242/GNEgurhmdLSyqchGJmKaU6w51qvZkdYTy2/ldL0YcOITspktg0koNV//ZwjNPVErZvwccgCl4ivIhiVI3t0vOLT3b+hTFVjdC2tZrepOnnha2h/SWQxQ49k9N7XHl+KlFmB1SaMtguvMIKfyomGxQDtx1aJE=
Received: from BN6PR11MB1844.namprd11.prod.outlook.com (2603:10b6:404:103::20) by BN6PR1101MB2179.namprd11.prod.outlook.com (2603:10b6:405:52::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.25; Mon, 28 Sep 2020 13:49:27 +0000
Received: from BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::d525:a81a:74e0:12e7]) by BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::d525:a81a:74e0:12e7%12]) with mapi id 15.20.3412.029; Mon, 28 Sep 2020 13:49:27 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Paul Hoffman <paul.hoffman@icann.org>, "eve.m.schooler@intel.com" <eve.m.schooler@intel.com>
CC: "cbor@ietf.org" <cbor@ietf.org>
Thread-Topic: =?utf-8?B?W0V4dF0gw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-cbor-7049bis-14:_(with_COMMENT)?=
Thread-Index: AQHWhrYnIU5oiGSWzkqWuSBzlwTbV6l3KCKAgAcoVAA=
Date: Mon, 28 Sep 2020 13:49:27 +0000
Message-ID: <94325768-848A-43EA-9013-87748B991882@cisco.com>
References: <159966199241.32601.2625919984583918486@ietfa.amsl.com> <97DFCD48-DB0D-46F6-9329-A6D525E9AD39@icann.org>
In-Reply-To: <97DFCD48-DB0D-46F6-9329-A6D525E9AD39@icann.org>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: icann.org; dkim=none (message not signed) header.d=none;icann.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:dd2e:9aca:59:8fb1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4dde37b8-1589-4cd7-a12f-08d863b55152
x-ms-traffictypediagnostic: BN6PR1101MB2179:
x-microsoft-antispam-prvs: <BN6PR1101MB2179624EDAD20B73D1123B4EA9350@BN6PR1101MB2179.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L913Q6bgxMgonQO84nUU83xtYCi3fOejSemzj6LA7Z63sIO/m/WJ4/g2DSYDWsHXsHcm5AAseBALyfH6tjplMzyLkXZlPxitHIHtMeH83XRnOMpBnNE5d57UpQQQl4aZq3GlWhhn2X2hHc9OSYWHHSUWYC53WJbx+gtcbPWHKhbrfZTfMZ+cznblilfW+wvIN9Fw8UYHIikdB50vUUJ230t3p9wxLUN+1pBZG8+sWJknBMuHCv5OwzKJGjFOVMv23Msen+F/jfapotMJBa7v39YyvNFTO06Nt6k9ueh093UdmIdGv9Kcytb4IhP1KonRNsqOEhoZKAaBi1Bpb1O/1diEtUTV6A239mjUYiGwfyLodjHWNtjluqz1h02YneMK28cag6T/5r2mQP41aMRpJW1jO+Py5GC7G5DPvfcn+ktVRFBzK5geGI5SjZdattH5nSIaH84r40J02Y71V64igw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1844.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(376002)(366004)(39860400002)(2906002)(4326008)(8936002)(6512007)(36756003)(33656002)(6486002)(110136005)(966005)(83380400001)(316002)(66556008)(66476007)(5660300002)(86362001)(64756008)(66446008)(91956017)(76116006)(66946007)(478600001)(186003)(71200400001)(224303003)(6506007)(53546011)(2616005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: dN+xKAGb29NWjGWFTbaEjtO2fUFpdpDAg2clWbmegLTixfJ2FqPW+xbsSHx3Kx33phxhfMU9QOC4MR7av6PqiqAPQ7He3fyqBfCLKgNn+Odkvv5usKTLrfGlqsXcjOJcT5KrcSkwMGT26td8j/DE+dERyOcfFVxm1zz3DLB0TGYWCYvSjs7xQQr1Ow8/iExB2w+jk1PI8zWUzXa9R6vsY1Y0kCkPr2RbZ2KqFmkFiyLbNFEbM/pTYmzicvM7/7vtVIaNI8SAMypv7gzKua7zs/SFFtZYtMYR+r+2xa8gq0x3GXKPLgM86tyZAp9DRkh7p1D66SWzhUTxar7C2/oiafwp5kojC3y16gejH5vLeVss0SKIVrj47mSqtPGscc9NJEmVPtz1hmdKCbkqK0RZGX2w/joGN3IQVtwZ0j+Th3KB+R1VQU2ZA/eqRgnbHBBl/nuvmnJbob5oSs8/NRCg0WPd4Myc5gjVGK5jia8u+JNfO72XiYd8XA8gYqqKID/hl5g6jmbBwG5Qj1bZpY+AqzLTfG030lSAsqq6v9Ygj/bKiNpkxTHZlFvrnK9hlYoJ7zQxMIAF/wZlx3fg7DJqjvaEvrwQpUOLnK1f3lI3VVe4eiFDj9DKTr1mAQ9o0sACDOfhk7kpSYUH23k733nLOj8Fap3BeoGyVY31YfeXsO9VNqZ5/CCUYbVj654gWZpeGGtRyDxwla9ZoouhtWwy4A==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A20F19503BA084438176CF22A6418D68@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB1844.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4dde37b8-1589-4cd7-a12f-08d863b55152
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2020 13:49:27.5636 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qTPnrW6N0xbYAycuWGJuv6+AYFPk4xlkpZ0tgkl81PkeNL8yza2ZbdeAM76/aqp36MsRpfiktaWVXGCeTHPesQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2179
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/cQEjx0U31yjAGEUaiamfFVhDJwE>
Subject: Re: [Cbor] =?utf-8?q?=5BExt=5D_=C3=89ric_Vyncke=27s_No_Objection_on_?= =?utf-8?q?draft-ietf-cbor-7049bis-14=3A_=28with_COMMENT=29?=
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2020 13:49:34 -0000

Paul

It looks like I did not reply to your own reply :-o

Thank you for your reply and the answers, they sound logical.

Regards

-éric

-----Original Message-----
From: iesg <iesg-bounces@ietf.org> on behalf of Paul Hoffman <paul.hoffman@icann.org>
Date: Wednesday, 23 September 2020 at 21:31
To: Eric Vyncke <evyncke@cisco.com>om>, "eve.m.schooler@intel.com" <eve.m.schooler@intel.com>
Cc: "cbor@ietf.org" <cbor@ietf.org>rg>, The IESG <iesg@ietf.org>
Subject: Re: [Ext] Éric Vyncke's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)

    Thanks for your comments and those of the IoT directorate review. Our notes are below.

    --Paul Hoffman


    > The document is very thorough. In places, it provides a lot of detail upfront
    > that seems like it could be deferred until later sections and closer to the
    > topics at hand. For consistency and accuracy, the document would benefit from
    > review by the authors of the usage of may and must, capitalized or not, and
    > alternate terms (e.g., "does not", "can", "cannot", "might", etc.) that may
    > require replacement by those recommended by [RFC2119][RFC8174]. Explicit use of
    > "recommended" advice and usages could be beneficial.

    The WG tried to do this wherever possible. It is very difficult to do this in the
    specification of a data format because most the recommendations are for application
    developers, not encoder and decoder developers. The WG jiggled some of the
    requirements language, and this is the best result we could come up with.

    > Given the length and
    > coverage of the spec, and given that this was a first read of the spec by this
    > reviewer, below are suggestions for additional forward/backward pointers to
    > sections where topics are mentioned (as I found myself flipping forward or
    > backward in the doc, in search of the first mention or deeper discussion), for
    > places where subsections and table names could use reconciling, for consistent
    > use of double quotes that highlight special terms, and a few places where
    > clarifications could help readability. The examples throughout are great,
    > though there are some places where examples are missing.It is also helpful
    > when a section includes an explanation of the primary purpose for a feature
    > (for example, tags are explained well on page 20, last paragraph); these kinds
    > of explanations are not always present.

    This is useful input. Many of us have been reading this for seven years...
    We have taken many of your suggestions about forward references and first
    definitions to heart and will put them in the document before sending it
    to the RFC Editor.

    > The linkage to IoT is given in the
    > document as advice for constrained node processing, though it would be
    > interesting -  now that the IoT Edge includes constrained as well as less
    > constrained nodes - to evaluate if there is also relevance for lower latency
    > IoT scenarios.

    Great!

    [[ Lots of editorial notes elided here, but many edits were added to the
    document based on them: thanks! We could not add the extensive cross-references that
    were requested, but were able to add some of them to increase clarity. ]]


    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    >
    > Thank you for the work put into this document. While it is rather long, it is
    > exhaustive and usually quite clear (with exceptions see below).
    >
    > Thanks to Eve Schooler for her very detailed IoT directorate review at
    > https://datatracker.ietf.org/doc/review-ietf-cbor-7049bis-14-iotdir-telechat-schooler-2020-09-08/
    > I strongly suggest to the authors to follow Eve's recommendation to clarify and
    > make the text easier to read.

    Definitely! See above.

    > Please find below a couple of non-blocking COMMENT points.
    >
    > I hope that this helps to improve the document,
    >
    > Regards,
    >
    > -éric
    >
    > == COMMENTS ==
    >
    > -- Section 3.4  --
    > Is there a reason why "specifically, tag number 25 and tag number 29" have no
    > reference to a RFC ? The reader would benefit from some short description. This
    > oddity was also mentioned by Eve in her review, so, I strongly suggest to
    > address the issue.

    As you can see at <https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#tags>,
    these are not RFCs, they are to a personal website.  Instead of creating a link in an
    RFC that could go stale, we added another reference to the IANA registry.

    > -- Section 3.4.5.2 --
    > As noted by other AD, I am puzzled by the added value of checking whether a
    > string is PCRE or ECMA262.

    Already fixed; see earlier responses to Ben.

    >
    > -- Section 3.4.6 --
    > I like this idea of 'magic number' but, as I am not a Unicode expert, I wonder
    > whether "In particular, 0xd9d9f7 is not a valid start of a Unicode text in any
    > Unicode encoding if it is followed by a valid CBOR data item." will always
    > stand true.

    One can never predict the future, but the stability of the Unicode standard in
    respect to these code points seems pretty good.


    > -- Section 4.2.1 --
    > Humm this section says "MUST be as short as possible" while the introduction
    > says "optimize for CPU not for bytes". Same applies for sorted keys... How can
    > we reconciliate ? Suggestion: add some text about this apparent goals conflict.

    The goal of Section 4.2.1 is pretty clearly "deterministic encoding". This section
    has nothing to do with the optimization of the format itself.