From nobody Thu Dec 1 02:14:51 2016 Return-Path: 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 A4625129C5F; Thu, 1 Dec 2016 02:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=PAJbXdBx; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=uswS0Ct3 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 idViUzVyVwZk; Thu, 1 Dec 2016 02:14:43 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2657127058; Thu, 1 Dec 2016 02:12:46 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1E69A2063D; Thu, 1 Dec 2016 05:12:46 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute7.internal (MEProxy); Thu, 01 Dec 2016 05:12:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=7zPciz9Q7XagDhTe0EVoR0FGpp w=; b=PAJbXdBx4gEyXia+koBuGCFiEXNWz/H79kjMffnsi2r5XVID6DCHwulvjo 8TgAZlHUfgUE6RK73ewSUbDpkLfA4ikiXTKd3G0yzeR7ml11F0/eXaMT5W7VkXjq TOTBne6KShCMcbSuL0i+nnuL2vzEYe04gw2IBQ3w1CMym0dYg= DKIM-Signature: v=1; a=rsa-sha1; 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-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=7z Pciz9Q7XagDhTe0EVoR0FGppw=; b=uswS0Ct3UaX4Vxso4rOzJTjVDrba+E1bFB Mx0YmlJqeO2WfsPavcLuNc8wYZtyZ7dQXNcME8mm4DRhWMRnxjAsA4cfm3FFtttw hbZp9wrEtGQXaihgKgfBNWMT6TAH/5xhNqHl1zZgloRGaP09yC/9GXL94FvY3LXt 4v8irPcLU= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F0C9CAA6B1; Thu, 1 Dec 2016 05:12:45 -0500 (EST) Message-Id: <1480587165.3967771.804826881.2D46728F@webmail.messagingengine.com> From: Alexey Melnikov To: Spencer Dawkins at IETF , Carsten Bormann MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148058716539677711" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e0536e9d Date: Thu, 01 Dec 2016 10:12:45 +0000 References: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> In-Reply-To: Archived-At: Cc: cbor@ietf.org, The IESG Subject: Re: [Cbor] Spencer Dawkins' No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 10:14:45 -0000 This is a multi-part message in MIME format. --_----------=_148058716539677711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thu, Dec 1, 2016, at 06:13 AM, Spencer Dawkins at IETF wrote: > Hi, Carsten, >=20 > On Wed, Nov 30, 2016 at 10:54 PM, Carsten Bormann > wrote: >> Hi Spencer, >> >> On 1 Dec 2016, at 04:48, Spencer Dawkins >> wrote: >> > >> > or other CBOR extension proposals >> >> So far, the text has been careful to limit the scope to work that >> uses existing extension points defined by RFC 7049 (for the two >> documents cited. specifically, by defining CBOR tags). "or other >> CBOR extension proposals=E2=80=9D might be taken to completely open Pand= ora=E2=80=99s >> box here. >>=20 >> But I agree that if something comes up that is of the same quality >> as the two documents, the WG should be allowed to look into it. >=20 > Thanks for the quick response.=20 >=20 > So, would something like=20 >=20 > "Where these CBOR extensions, or other CBOR extension proposals of > similar quality, > are deemed useful and do not require significant new development, > the CBOR WG > will complete these specifications as well."=20 >=20 > be worth saying?=20 I would rather see the first 4 deliverables are completed before writing a blank check to allow any other work. But I welcome other opinions. >=20 > And either answer is OK, I'm just trying to think ahead :-) >=20 > Spencer --_----------=_148058716539677711 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Thu, Dec 1, 2016, at 06:13 AM, Spencer Dawkins at IETF wrote:=
Hi, Carsten,

On Wed, Nov 30, 2016 at 10:54 PM, = Carsten Bormann <cabo@= tzi.org> wrote:
Hi Spencer,

On 1 Dec 2016, at 04:48, Spencer Dawkins <spencerdawkins.ietf@gmail.com&= gt; wrote:
>
> or other CBOR extension proposals

So far, the text has been careful to limit the scope to work that uses = existing extension points defined by RFC 7049 (for the two documents cited.= specifically, by defining CBOR tags).  "or other CBOR extension propo= sals=E2=80=9D might be taken to completely open Pandora=E2=80=99s box here.=

But I agree that if something comes up that is of the same quality as= the two documents, the WG should be allowed to look into it.

Thanks for the quick response. 

So, would something like 

"Where these CBOR exte= nsions, or other CBOR extension proposals of similar quality, <= br>
are deemed useful and do not require significant new development, the CBOR W= G
will complete these specifications as= well." 

be worth saying? 

I would rather see the first 4 deliverables are completed before writi= ng a blank check to allow any other work. But I welcome other opinions.
=


And either answer is OK, I'm just tryin= g to think ahead :-)

Spencer

--_----------=_148058716539677711-- From nobody Thu Dec 1 06:30:09 2016 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD461129557; Thu, 1 Dec 2016 06:30:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 06:30:06 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Stephen Farrell's No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:30:06 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-cbor-00-01: No Objection 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Were this being proposed for approval, I would be balloting a BLOCK so I'd like to understand the issue below before we get there, if at all possible. - What is GRASP? - As I think of it, COSE did not really adopt CBOR, but is an ancillary part of CBOR. For example, it would be impossible for COSE to be COSE and choose something that is not CBOR:-) So there was no "adoption" step ever, for COSE. - COSE did not "successfully" use CDDL IMO. The CDDL text there is specifically stated to be non-normative, and its inclusion was controversial during the WG process. The above seems to me to mean that the level of interest claimed for CBOR/CDDL is not justified by the charter text. And the reason that raises to a possible BLOCK ballot for me is that such enthusiasm, while understandable, doesn't seem to go well with the last part of the charter. "Where these proposals are deemed useful" just seems too likely to happen if I'm to judge by the overly positive "spin" in the current charter language. (Note that "spin" isn't meant pejoratively there, it's quite fine that the proponents of this are proponents of this:-) I think the solution here is to provide more evidence of the claimed level of interest in CBOR/CDDL That could be done in the charter text but may be fine if only done in the email discussion leading up to that. And toning down the language would help too. (Note that fixing errata in CBOR isn't a problem but by itself wouldn't justify a WG.) From nobody Thu Dec 1 07:00:51 2016 Return-Path: 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 F11D01294F0; Thu, 1 Dec 2016 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ibIUW2Pb; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=dVdXfZG0 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 Q7r3SSlhe_Ng; Thu, 1 Dec 2016 07:00:48 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FBA1293F3; Thu, 1 Dec 2016 07:00:48 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A0367208C3; Thu, 1 Dec 2016 10:00:47 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute7.internal (MEProxy); Thu, 01 Dec 2016 10:00:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=DA96sflNYvq7JN724v7Fzx7HjA c=; b=ibIUW2PbR7dfisg3hEPrXCAzvyR+LWl3CU6uSY/H23kXhs35vJbY3P/Id6 EYUgg5f6w6NZt2Pd6wC5hdm9IzIhcw7P5ubl9k3DUYlQ12HsxYVPpqU5W2TANiKx iWh+cGMxOF+IPqi7Jc5VHUwDFn+A72hl9XWMnO86yGL4DvMwY= DKIM-Signature: v=1; a=rsa-sha1; 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-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=DA 96sflNYvq7JN724v7Fzx7HjAc=; b=dVdXfZG0d0GiP3VYu4BRy1NAIa6piREoyR 492xgMeLJfo4b2l8OI6l7EOlwRuyGw/I/BDffdMCppyPMUt0fV3al7ToWei51GUO mOcXEB+nlrkfq3hTDYR6Mdl3rYXUvfz2o3CVCx+b9nn/x65Y+TP7BLGHOHkn8Rob Ed+U9isGw= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 75AF6AA6B2; Thu, 1 Dec 2016 10:00:47 -0500 (EST) Message-Id: <1480604447.4041058.805089889.0E827F08@webmail.messagingengine.com> From: Alexey Melnikov To: Stephen Farrell , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e0536e9d References: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> In-Reply-To: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 15:00:47 +0000 Archived-At: Cc: cbor@ietf.org Subject: Re: [Cbor] Stephen Farrell's No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 15:00:50 -0000 Stephen, On Thu, Dec 1, 2016, at 02:30 PM, Stephen Farrell wrote: > Were this being proposed for approval, I would be balloting > a BLOCK so I'd like to understand the issue below before > we get there, if at all possible. > > - What is GRASP? > > - As I think of it, COSE did not really adopt CBOR, but > is an ancillary part of CBOR. For example, it would be > impossible for COSE to be COSE and choose something > that is not CBOR:-) So there was no "adoption" step > ever, for COSE. > > - COSE did not "successfully" use CDDL IMO. The CDDL > text there is specifically stated to be non-normative, and > its inclusion was controversial during the WG process. This can be reworded. > The above seems to me to mean that the level of > interest claimed for CBOR/CDDL is not justified by the > charter text. > > And the reason that raises to a possible BLOCK > ballot for me is that such enthusiasm, while understandable, > doesn't seem to go well with the last part of the charter. > "Where these proposals are deemed useful" just seems > too likely to happen if I'm to judge by the overly > positive "spin" in the current charter language. (Note > that "spin" isn't meant pejoratively there, it's quite > fine that the proponents of this are proponents of > this:-) > > I think the solution here is to provide more evidence > of the claimed level of interest in CBOR/CDDL That could be > done in the charter text but may be fine if only done in > the email discussion leading up to that. And toning down > the language would help too. (Note that fixing errata > in CBOR isn't a problem but by itself wouldn't justify > a WG.) There are multiple documents in CORE that are using CDDL, so I am sure there is some interest in at least that. I am happy to tone this down. From nobody Thu Dec 1 10:42:06 2016 Return-Path: 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 BFF64129606; Thu, 1 Dec 2016 10:41:55 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9dgVs7beq0vQ; Thu, 1 Dec 2016 10:41:53 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32041289C4; Thu, 1 Dec 2016 10:41:50 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id a10so201453860ywa.3; Thu, 01 Dec 2016 10:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sBt/D3N2mtyD+uQjom8gZ+UYOVPK/TuGf59lzOBS7Xg=; b=S+8oBhPWiOvTDyfZmypJ6b67WyFpPKnSgS58uzfQTf4XybFxyGBjAA3l8TE23DpIq6 z/Z8YYnvR+nJwqmKjtTXg+TddKlJGQuMQPbW9YJypCPat9YdT7gSon2eyUceCksBbH+o RbRldbLhNrRB7bfvbtGNXZDfqWlqOcWfoSjkKP7pAuF+gJAu0DilXUq+Iqt1CcXSkYx6 AdDTqxCTS1cn6uLGmxk7AxfhiWQv/wgdA0cg0/5essJr6sLx6ISTomt2FyWAQzuRs8YD EFZRrWEO3ZdV/c2/HlUzUyim14ILym8m9p07+FFntnrOkXwBNR7sQ6Z8lW/4Bz7sfLZv zi/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sBt/D3N2mtyD+uQjom8gZ+UYOVPK/TuGf59lzOBS7Xg=; b=J8L2+9gvnXDGYJADla6NKhijZKmFhV6V1Z9pQBmSNv5QLeIHWHCzCfaCvNEucaXPAs JMcZoZWdEMo7g7qIaQnqD+OpEOJQgojLQY4ZZtOZeHQzFFuPt+3wPlSVs95krI78uYY9 /7fJNj1d7Wgxhs55h2eI2LJK15r6M77iXlvvmmI7IPuHq9HsVSTqYxdX97Sl1l0noSwZ CNtw6O4LtpEujQA+aFFQtVWhjG6hqAyeTRnPMmA6O248FqIbzOvaIGp6ltCsgwlg78pD a0vxRupbe8duE7VYTcljiFB9kFBsFHMZRXHGQxf+74eYbI44mRpjD01UOChsEKQ4tYgj lSbQ== X-Gm-Message-State: AKaTC01lfSxBQhQcAHdeluOUFF0WPaFomo166HZln87qWAPLhfu+n4QpltgHMIlwJa/Q+sm9oxjIiHEKEjiaMQ== X-Received: by 10.129.125.215 with SMTP id y206mr40641458ywc.234.1480617709955; Thu, 01 Dec 2016 10:41:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.170.79 with HTTP; Thu, 1 Dec 2016 10:41:49 -0800 (PST) In-Reply-To: <1480587165.3967771.804826881.2D46728F@webmail.messagingengine.com> References: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> <1480587165.3967771.804826881.2D46728F@webmail.messagingengine.com> From: Spencer Dawkins at IETF Date: Thu, 1 Dec 2016 12:41:49 -0600 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11492dfaa6764905429d2cab Archived-At: Cc: cbor@ietf.org, Carsten Bormann , The IESG Subject: Re: [Cbor] Spencer Dawkins' No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 18:41:56 -0000 --001a11492dfaa6764905429d2cab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Alexey, On Thu, Dec 1, 2016 at 4:12 AM, Alexey Melnikov wrote: > On Thu, Dec 1, 2016, at 06:13 AM, Spencer Dawkins at IETF wrote: > > Hi, Carsten, > > On Wed, Nov 30, 2016 at 10:54 PM, Carsten Bormann wrote: > > Hi Spencer, > > On 1 Dec 2016, at 04:48, Spencer Dawkins > wrote: > > > > or other CBOR extension proposals > > So far, the text has been careful to limit the scope to work that uses > existing extension points defined by RFC 7049 (for the two documents cite= d. > specifically, by defining CBOR tags). "or other CBOR extension proposals= =E2=80=9D > might be taken to completely open Pandora=E2=80=99s box here. > > But I agree that if something comes up that is of the same quality as the > two documents, the WG should be allowed to look into it. > > > Thanks for the quick response. > > So, would something like > > "Where these CBOR extensions, or other CBOR extension proposals of simila= r > quality, > are deemed useful and do not require significant new development, the > CBOR WG > will complete these specifications as well." > > be worth saying? > > > I would rather see the first 4 deliverables are completed before writing = a > blank check to allow any other work. But I welcome other opinions. > I was wondering if the tight chartering language was intentional, given that the bar for the two extensions seemed pretty high and the amount of work you were authorizing seemed pretty low, and whether there might be other proposed extensions that would also meet that bar and not require much work. If nothing else comes to mind immediately, my question is a NOOP anyway, and if you'd prefer to "pay as you go" on charter updates with a new working group, the current language is exactly right. You're the AD, so I know you'll do the right thing. Spencer > And either answer is OK, I'm just trying to think ahead :-) > > Spencer > > > --001a11492dfaa6764905429d2cab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Alexey,

On Thu, Dec 1, 2016 at 4:12 AM, Alexey Melnikov <aamelniko= v@fastmail.fm> wrote:
On Thu, Dec 1, 2016, at 06:13 AM, Spencer Dawkin= s at IETF wrote:
Hi, Carsten,

On Wed, Nov 30, 2016 at 10:54 PM, Carsten Bormann <cabo@tzi.org&g= t; wrote:
Hi Spencer,

On 1 Dec 2016, at 04:48, Spencer Dawkins <spencerdawkins.ietf@g= mail.com> wrote:
>
> or other CBOR extension prop= osals

So far, the text has been careful to limit the scope = to work that uses existing extension points defined by RFC 7049 (for the tw= o documents cited. specifically, by defining CBOR tags).=C2=A0 "or oth= er CBOR extension proposals=E2=80=9D might be taken to completely open Pand= ora=E2=80=99s box here.

But I agree that if something comes up that is of the same quality as= the two documents, the WG should be allowed to look into it.

Thanks for the quick response.=C2=A0

So, would something like=C2=A0

= "Where these CBOR extensions, or other CBOR extension proposals of sim= ilar quality,=C2=A0
are=C2=A0deemed useful and do not require significant new developmen= t, the CBOR WG
= will=C2=A0complete these specifications as well."=C2=A0

be worth saying?=C2=A0

I would rather see the first 4 deliverables are completed befor= e writing a blank check to allow any other work. But I welcome other opinio= ns.

I was wondering if the tigh= t chartering language was intentional, given that the bar for the two exten= sions seemed pretty high and the amount of work you were authorizing seemed= pretty low, and whether there might be other proposed extensions that woul= d also meet that bar and not require much work.=C2=A0

<= div>If nothing else comes to mind immediately, my question is a NOOP anyway= , and if you'd prefer to "pay as you go" on charter updates w= ith a new working group, the current language is exactly right.=C2=A0
=

You're the AD, so I know you'll do the right th= ing.

Spencer=C2=A0
And either answer is OK, I'm just trying to think ahead :-)

Spencer


--001a11492dfaa6764905429d2cab-- From nobody Fri Dec 2 00:07:28 2016 Return-Path: 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 2A3DC1294E0; Fri, 2 Dec 2016 00:07:21 -0800 (PST) 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] 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 jHiFxLEsrvKh; Fri, 2 Dec 2016 00:07:18 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 8E4A3129512; Fri, 2 Dec 2016 00:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uB2878hS013753; Fri, 2 Dec 2016 09:07:08 +0100 (CET) Received: from [172.20.10.2] (ip-109-45-1-173.web.vodafone.de [109.45.1.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tVRZh106Yz8LvC; Fri, 2 Dec 2016 09:07:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> Date: Fri, 2 Dec 2016 09:07:06 +0100 X-Mao-Original-Outgoing-Id: 502358826.515752-078911775628afbdbcdf9fba3a521772 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3251) Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] Stephen Farrell's No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:07:21 -0000 Hi Stephen, Alexey has already said that the charter can be reworded. But I=E2=80=99ll try to answer your comment as best as I can, in three = parts. # CBOR adoption > - What is GRASP?=20 The Generic Autonomic Signaling Protocol (draft-ietf-anima-grasp), = nearing WGLC in the ANIMA WG. > - As I think of it, COSE did not really adopt CBOR, but > is an ancillary part of CBOR. For example, it would be > impossible for COSE to be COSE and choose something > that is not CBOR:-) So there was no "adoption" step > ever, for COSE. Well, creating a new WG to exploit the capabilities of a base standard = by creating another standard on top of it is a form of =E2=80=9Cadoption=E2= =80=9D of the base standard in my dictionary. =20 But I=E2=80=99m not a native English speaker. # CDDL =E2=80=9Csuccess" > - COSE did not "successfully" use CDDL IMO. COSE very successfully used CDDL as a tool to communicate about the COSE = data structures during development. In large parts, the (normative) = English language spec text we still need right now was then developed = from the CDDL. > The CDDL > text there is specifically stated to be non-normative, Of course: to avoid a downref to an I-D. > and=20 > its inclusion was controversial during the WG process. That=E2=80=99s not what happened. There was a discussion how to make use of CDDL in COSE while CDDL itself = is still a draft. Solved as said above. There was an individual in the WG who does not see any benefit to using = CDDL. (That individual does not even see a benefit to using ABNF, either. = Different people work in different ways, so I don=E2=80=99t blame him = for this view at all, but a lot of people do derive benefits from both = ABNF and CDDL.) We then had a discussion whether we should keep the CDDL specs in the = main text (as opposed to moving it to an appendix). This discussion = even had a chairs=E2=80=99 call for consensus. That call resoundingly = validated keeping the CDDL in the main text, with a single person in the = rough. =E2=80=9CControversial=E2=80=9D is not the word I would use for that = level of consensus, but then again I=E2=80=99m not a native English = speaker. # Specs for additional CBOR Tags > "Where these proposals are deemed useful" just seems > too likely to happen if I'm to judge by the overly=20 > positive "spin" in the current charter language. (Note > that "spin" isn't meant pejoratively there, it's quite > fine that the proponents of this are proponents of=20 > this:-) The fact that CDDL is actually useful (and is increasingly being used in = other SDOs as well, unfortunately at this time shrouded by their = confidential modes of operation) does not mean that these CBOR Tag specs = are useful. I do have some doubts even about some of the parts of the = CBOR Tag specs I=E2=80=99m a co-author on, and I=E2=80=99m sure the WG = will be good to determine what parts to keep. So yes, the charter language should be clear that this is not an open = invitation for doing more of these additional CBOR Tag specifications. = Alexey=E2=80=99s approach (wait for completion [or WG decision not to do = them!] for the first two specs we have on the table now) sounds right to = me. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 2 06:27:27 2016 Return-Path: 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 5C790129602; Fri, 2 Dec 2016 06:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=moXhifXJ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=kixsgZfx 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 opbvRwPjFj9K; Fri, 2 Dec 2016 06:27:23 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FF51296DD; Fri, 2 Dec 2016 06:27:23 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9455F20941; Fri, 2 Dec 2016 09:27:22 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 02 Dec 2016 09:27:22 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=Q2Z8pkf/x5zZlwqe4zYgfn20Ph 4=; b=moXhifXJHe0bysgp3XxsnBdTpdrDyc9/ISpkZkcU4C+3N3ecRI4vVy+hVO eDMYkQwz//oehXnibZheMcXBXRsnA1S31/mee9TbbVf4nqMinHOBad4dXI8ciCrx +xjOn4OBHG+qsGx7xoQBpeSVO3LxZMYWfJLVoTICQlCc97q+4= DKIM-Signature: v=1; a=rsa-sha1; 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-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Q2 Z8pkf/x5zZlwqe4zYgfn20Ph4=; b=kixsgZfxsZxdH1y/gUO3SE05gNxcqJ16ol dTKwwN8wKfBHGiVjgpjhU4WEqC7xJZaHUB/IjhhJrAXvg+P+Ez56/l6omfWrSRa5 0NKmSKScXAC4Valg0Rs/db22uL8olf65P3Ou0TM1JwWe8JInXoN3APe6mkWQWo29 nI/3rranU= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 745AF6ABD0; Fri, 2 Dec 2016 09:27:22 -0500 (EST) Message-Id: <1480688842.128394.806273713.664257C7@webmail.messagingengine.com> From: Alexey Melnikov To: Stephen Farrell MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e0536e9d In-Reply-To: Date: Fri, 02 Dec 2016 14:27:22 +0000 References: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> Archived-At: Cc: cbor@ietf.org, The IESG Subject: Re: [Cbor] Stephen Farrell's No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:27:25 -0000 I am looking at this is a rather impressive list of drafts referencing CDDL. From nobody Fri Dec 2 06:37:34 2016 Return-Path: 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 71DF41294CD; Fri, 2 Dec 2016 06:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 l50qfgTKNDq2; Fri, 2 Dec 2016 06:37:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439E41294A6; Fri, 2 Dec 2016 06:37:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60085BE5D; Fri, 2 Dec 2016 14:37:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-DUraYlrnhr; Fri, 2 Dec 2016 14:37:20 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 63000BE39; Fri, 2 Dec 2016 14:37:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480689439; bh=7T09h+ublRuD6gsY8/jJVPkCGXBTG3y7jRUu0n24zqk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=a/8V7jrCJI4A9BUM3lNiVVT3ww3XJfhgEAht87B4Vx2D4V+NPGBwTn4FiEItU/e51 03iSeTriJBY6mALE6dTrajmmIqbzfnnK8uhquzqgETs1phNd53lW/JpgL9Mx8/Uyds mwOeyIT7GW6EUiYhcFEGUgYKtxu6vDadNuf7WWzE= To: Alexey Melnikov References: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> <1480688842.128394.806273713.664257C7@webmail.messagingengine.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <468f7a93-b381-ed4c-f828-8eeff084689b@cs.tcd.ie> Date: Fri, 2 Dec 2016 14:37:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1480688842.128394.806273713.664257C7@webmail.messagingengine.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040305030604030200090707" Archived-At: Cc: cbor@ietf.org, The IESG Subject: Re: [Cbor] Stephen Farrell's No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:37:27 -0000 This is a cryptographically signed message in MIME format. --------------ms040305030604030200090707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/12/16 14:27, Alexey Melnikov wrote: > I am looking at > > this is a rather impressive list of drafts referencing CDDL. >=20 Yep. Agreed. Just a matter of tweaking the text then which is easier. TBH though, I still do have some concerns about the relative lack of author diversity in that set of drafts. But it is diverse enough I guess. Just. Note that that's nothing personal, I remember other times the IETF went down wrong but seemingly reasonable paths that looked similar from that respect. (BEEP anyone?;-) Thanks, S. --------------ms040305030604030200090707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDIx NDM3MTlaMC8GCSqGSIb3DQEJBDEiBCBV50aFGgc14Z8fRLb2hoc81DmAsNIDwVKcuzImTJQi 5zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBOuTHMvfENQ6vjw3zhfvEM3RbFgKzH7wGGGVbV2eV5AoE2S2A/5hrY 04HgbQDnvjW6T7w6igIPMD0GVJ8eEltNwmlgV+Oqnw6zYwfiboKCNj3A6bUtkPY0LZ03oJ5T 0IuwRbrTw/SuONQJZyp0MKqc6ZhKh0+Z9p5JQ+nlfdm4BewOlgxdyQDIuvjhfGCPzNJTL19o zyrvFIHRReJMHUbsekWLqKqqNCJtp9YCPGIXxRM4qLIQsPTQ4K4Y4kV2nMKsNnwvkcn/UOXB b0JlHyBKctxajt0YHIB9ap8hUN2Bg3jwzOFmnKaeNGQskPtot2NJLV6Av9x+KoGWXzx6opfv AAAAAAAA --------------ms040305030604030200090707-- From nobody Fri Dec 2 09:53:24 2016 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E882E1270B4; Fri, 2 Dec 2016 09:53:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148070119891.29664.17551137527551630383.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 09:53:18 -0800 Archived-At: Cc: cbor@ietf.org Subject: [Cbor] WG Review: Concise Binary Object Representation Maintenance and Extensions (cbor) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:53:19 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-12-12. Concise Binary Object Representation Maintenance and Extensions (cbor) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Ben Campbell Alissa Cooper Alexey Melnikov Mailing list: Address: cbor@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Charter: https://datatracker.ietf.org/doc/charter-ietf-cbor/ Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL, based on draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an Informational or Standards Track RFC. In parallel to the work on CDDL, the WG will examine the CBOR extension for tagging of Typed Arrays (based on draft-jroatch-cbor-tags) and the CBOR extension for tagging of Object Identifiers and UUIDs (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well. The WG will recharter before working on any further CBOR extensions. Milestones: TBD From nobody Fri Dec 2 11:19:29 2016 Return-Path: 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 14202128B38; Fri, 2 Dec 2016 11:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rp6ytwxCUpbP; Fri, 2 Dec 2016 11:19:26 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CF11296DB; Fri, 2 Dec 2016 11:19:26 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id e9so8656274pgc.1; Fri, 02 Dec 2016 11:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Lwdd19dVyMRaCcauAoaaqWhg4OiwRfUtUEibK5KJi6U=; b=tSUfOfKtXNrAtxEJZQX8UcU3UPZn0IPsq62SQ9NKtTEq4i5HRWnOzQL1LfdhUQhnks 0c3Seoqybofcx/j3c7z1JJunOLKFW6rTV7l/MffVTfHgt2mOD7q+memy2xae3SjNyoh9 9M1G2L5iuTAfdW7fFnkfw6vcB78ZpbEdumQbYHBGEE+04n/sKnjWMzDnuD60YkOffXU5 h6exQzAsGz/AoGN8Uw3otnKd3IzctMdvykgtt+hKGEm9HF/f763bq7tQfbLSKrliLO8m YoUq5khCJmivqfHlehD8ccVBgD3PszbeaMdoPjS2/dwqbSRjRxCdJp6tA4m665YW4vD5 wGLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Lwdd19dVyMRaCcauAoaaqWhg4OiwRfUtUEibK5KJi6U=; b=X/T2PB/+bQK2U+96zpfQyVLztMoRyp0FCkkqgJx9bf5YO9euk80IkAZxaxdipAsTUl FSV+muHBEx0thCUeXzU2VNo7xzbj80FysFzF5p6QO0JjR08tsm7rVy7e16rKxTwXna7T wC3TUFwuwV+ehNzQAiNU4hZwdJLLpmlrAtYf1Jwnd9NnwlvbCXnq52XU6emqdJ7KzxkT FP7/QxSRLF3eKzUQfmKU3qu6ZetZ2qiP6l/K3xOX0cI0ykaQ/5O0HnFo0z4a7zELaJuY jMPPp33Jy0Zt44/uf2i0NDf40Wjv981PD8vw7s5APK1Mhp+1MG/rLRnEOEyg67h4es/t Roag== X-Gm-Message-State: AKaTC03nmMs6MvcrSk0Q6T6RzvCJ3H4G37TuxlhhmKdBLoP6v/NxU99beIHAq+xtwhHt5A== X-Received: by 10.84.149.139 with SMTP id m11mr99091314pla.38.1480706366012; Fri, 02 Dec 2016 11:19:26 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.241]) by smtp.gmail.com with ESMTPSA id p79sm9542937pfj.51.2016.12.02.11.19.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 11:19:25 -0800 (PST) To: Stephen Farrell , Alexey Melnikov References: <148060260670.10471.9213688702078185454.idtracker@ietfa.amsl.com> <1480688842.128394.806273713.664257C7@webmail.messagingengine.com> <468f7a93-b381-ed4c-f828-8eeff084689b@cs.tcd.ie> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 3 Dec 2016 08:19:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <468f7a93-b381-ed4c-f828-8eeff084689b@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: cbor@ietf.org, The IESG Subject: Re: [Cbor] Stephen Farrell's No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 19:19:28 -0000 Hi Stephen, On 03/12/2016 03:37, Stephen Farrell wrote:> > > On 02/12/16 14:27, Alexey Melnikov wrote: >> I am looking at >> >> this is a rather impressive list of drafts referencing CDDL. >> > > Yep. Agreed. Just a matter of tweaking the text then > which is easier. > > TBH though, I still do have some concerns about the > relative lack of author diversity in that set of > drafts. But it is diverse enough I guess. Just. > > Note that that's nothing personal, I remember other > times the IETF went down wrong but seemingly reasonable > paths that looked similar from that respect. (BEEP > anyone?;-) I'm not sure that's comparable. BEEP* failed, but CBOR is quite a success, and CDDL is a useful tool for CBOR-using protocol design. We *could* have written the various Anima drafts without CDDL, but it would have needed a lot of extra words to reach the same level of precision. We *could* wordsmith the drafts to get rid of the normative references, but it would be artificial. In my GRASP prototype, I didn't attempt to develop a CDDL-driven parser or message generator, but I assume that would be possible too. *(Wasn't BEEP a noble attempt to do better than SOAP?) Regards, Brian From nobody Tue Dec 13 23:44:14 2016 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0BA129C8D; Tue, 13 Dec 2016 23:44:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148170144413.10757.8639503972391184179.idtracker@ietfa.amsl.com> Date: Tue, 13 Dec 2016 23:44:04 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Spencer Dawkins' Yes on charter-ietf-cbor-00-03: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 07:44:10 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-cbor-00-03: Yes 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I saw the answer to Stephen's "what is GRASP" question in the Internet Review ballot, but I'm still not sure why it's necessary to say "ANIMA GRASP" in this charter. For the parallel case in CORE, the WG name is provided, but no detail beyond that. If I knew what GRASP was without having to look back at Stephen's ballot thread, I wouldn't mention this, of course ... but I wonder how many other readers will have to look it up, too! From nobody Thu Dec 15 07:03:55 2016 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99836129CA3; Thu, 15 Dec 2016 07:03:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148181423460.27522.15050868161354943333.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2016 07:03:54 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Benoit Claise's No Record on charter-ietf-cbor-00-03: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:03:54 -0000 Benoit Claise has entered the following ballot position for charter-ietf-cbor-00-03: No Record 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ No record for now] - I have some questions regarding "The CBOR data definition language" In the world of data modeling-driven management, we have: YANG as a data modeling language, with ABNF specifications YANG modules, written with YANG different encoding, such as XML, JSON, or CBOR and finally protocols such as NETCONF or RESTCONF Now, in this WG, you want to define a new data modeling language, "The CBOR data definition language", right? So the structure of what could be accessed on a managed device, but without the semantic definition (which is in YANG modules) of data models? Am I right? How does it work from a management point of view? Disclaimer: I haven't read draft-greevenbosch-appsawg-cbor-cdd. I probably should. - OLD: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model NEW: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model Note: - In OPS, we make a clear distinction between the (YANG) data model, and the encoding (XML, JSON, etc.) - RFC 7159 mentions "data interchange format" in his abstract - I see in RFC 7049: The format defined here follows some specific design goals that are not well met by current formats. The underlying data model is an extended version of the JSON data model [RFC4627]. This is a mistake. Great we will have a new charter to accomplish this work - And don't forget the milestones. Regards, Benoit From nobody Thu Dec 15 09:09:29 2016 Return-Path: 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 45E32129D45; Thu, 15 Dec 2016 09:09:28 -0800 (PST) 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] 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 De-8SyNQhTKw; Thu, 15 Dec 2016 09:09:26 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 39B4F1299AD; Thu, 15 Dec 2016 09:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uBFH9Djv012009; Thu, 15 Dec 2016 18:09:13 +0100 (CET) Received: from [192.168.217.113] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tfg091hsvz8L6f; Thu, 15 Dec 2016 18:09:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <148181423460.27522.15050868161354943333.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2016 18:09:12 +0100 X-Mao-Original-Outgoing-Id: 503514552.712721-835abd8a218a690beb789540659249e0 Content-Transfer-Encoding: quoted-printable Message-Id: <4C009289-7A69-44BE-A050-ABCB9D23EE1F@tzi.org> References: <148181423460.27522.15050868161354943333.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.3251) Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] Benoit Claise's No Record on charter-ietf-cbor-00-03: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:09:28 -0000 Hi Benoit, great questions. Let me try to put in my position on these. > Now, in this WG, you want to define a new data modeling language, "The > CBOR data definition language", right? Yes. > So the structure of what could be accessed on a managed device, No. While CDDL could be used to describe the structure of data at rest = (a data store), that is not the objective. CDDL is used to define the structure of data in flight, e.g. a protocol = message going from a node to a different node. (Using a term popular in semantic interoperability work in the health = care domain, CDDL is about "structural interoperability=E2=80=9D =E2=80=94= it can tell you that there is supposed to be a data item = =E2=80=9Ccheese-firmness=E2=80=9D in the message and out of what set of = values it needs to come, but it cannot tell you what the specific values = mean in the real world or what cheese firmness is in the first place on = a semantic level.) In that sense CDDL is very similar to the use of ABNF for text-based = messages, and CDDL indeed was modeled on ABNF as far as that is = reasonable for this application. > Concise Binary Object Representation (CBOR, RFC 7049) extends the > JavaScript Object Notation (JSON, RFC 7159) data model to include = binary > data > and an extensibility model >=20 > NEW: > Concise Binary Object Representation (CBOR, RFC 7049) extends the > JavaScript Object Notation (JSON, RFC 7159) data interchange format to > include binary data > and an extensibility model Ah, that is an interesting terminology problem. Data interchange formats have (if they are half-way reasonable) a = generic data model, into which all specific data models that are being = interchanged using that format need to fit. One of the major = innovations of JSON was to make this generic data model simple and = reasonably close to what application developers want to interchange. JSON=E2=80=99s generic data model has never been formally defined (and = the finer details are an interesting area of contention!), but most = application writers familiar with JSON would be able to define that = generic data model to about 99 % precision. CBOR goes ahead and extends JSON's generic data model (with binary data = and with extensibility). As with JSON, CBOR is not a data modeling language though, so whenever = people needed to describe the specific data model used by the messages = interchanged from their application, they had to resort to ad-hoc = methods. CDDL is filling in the structural level of that need. CBOR does not extend JSON=E2=80=99s interchange format =E2=80=94 it has = its own (binary) one, which is completely different from JSON=E2=80=99s = text-based format. > - I see in RFC 7049: > The format defined here follows some specific design goals that are > not well met by current formats. The underlying data model is an > extended version of the JSON data model [RFC4627].=20 > This is a mistake. Well, we neglected to make the distinction between the generic data = model and the application specific data models here., but I don=E2=80=99t = agree with your proposed change. > Great we will have a new charter to accomplish this > work >=20 > - And don't forget the milestones. Good point. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 19 04:48:55 2016 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EF41299F1; Mon, 19 Dec 2016 04:48:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 04:48:53 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:48:53 -0000 Benoit Claise has entered the following ballot position for charter-ietf-cbor-00-04: Block 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Sorry for this late BLOCK. I had a very quick call with Alexey before the last IESG telechat: I want to understand if I missed anything. I filed a quick "NO RECORD" COMMENT. Then, we discussed some more during the telechat itself. And now, I finally had the time to think some more about this. My BLOCK is about this charter paragraph: Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL, based on draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an Informational or Standards Track RFC. In OPS, we need automation. And automation will come from data models as, from data models, we're able to generate APIs. In the world of data modeling-driven management, we have: YANG as a data modeling language, with ABNF specifications YANG data modules, written with the YANG data modeling language different encodings, such as XML, JSON, or CBOR (draft-ietf-core-yang-cbor-03) protocols such as NETCONF or RESTCONF for configuration/monitoring/capabilities discovery note: working on pub/sub protocol (aka telemetry) for events See the first picture at http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/ Btw, I should add cbor. Now, in this proposed WG, you want to define a new data modeling language, "The CBOR data definition language" When I ask the question: So the structure of what could be accessed on a managed device?, you answer: No. While CDDL could be used to describe the structure of data at rest (a data store), that is not the objective. CDDL is used to define the structure of data in flight, e.g. a protocol message going from a node to a different node. (Using a term popular in semantic interoperability work in the health care domain, CDDL is about "structural interoperability” — it can tell you that there is supposed to be a data item “cheese-firmness” in the message and out of what set of values it needs to come, but it cannot tell you what the specific values mean in the real world or what cheese firmness is in the first place on a semantic level.) But what about the semantic definition (which is in YANG modules) of this information? This is key for management. I guess that the next item you'll want after this milestone is exactly data models and semantic, right? There are many schemas for IoT and I'm not trying to impose YANG in the IoT world but I want to understand why we need duplication. Note that there was an IAB-organized workshop on IoT data modeling in the past (https://www.iab.org/activities/workshops/iotsi/) However, it seems to me that your effort is exactly the reverse of data modeling driven management? You have an encoding, and then you want a new schema language Next, you'll need a mechanism to discover what is available on the managed devices, a mechanism to know the device capabilities, a mechanism for pub/sub, ... And you will redo the full OPS stack, for IoT (hence duplication). And, obviously, in the end, we will need a mapping between the two data modeling languages: YANG and CDDL. What is specific here? I wanted to write: what's specific to IoT here, but I don't even see IoT in the charter. There is just a kind of IoT reference in RFC7049 abstract. Why do we need this duplication within the IETF? Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work? Those are completely inline with data modeling-driven management and this charter seems to contradict this effort? What do I miss? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OLD: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model NEW: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model Note: - In OPS, we make a clear distinction between the (YANG) data model, and the encoding (XML, JSON, etc.) - RFC 7159 mentions "data interchange format" in his abstract - I see in RFC 7049: The format defined here follows some specific design goals that are not well met by current formats. The underlying data model is an extended version of the JSON data model [RFC4627]. This is a mistake. Great we will have a new charter to accomplish this work - And don't forget the milestones. Regards, Benoit From nobody Mon Dec 19 04:52:31 2016 Return-Path: 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 9BA8C1299FB; Mon, 19 Dec 2016 04:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 2fcD1z3zdYlF; Mon, 19 Dec 2016 04:52:25 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4041299FA; Mon, 19 Dec 2016 04:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2419; q=dns/txt; s=iport; t=1482151945; x=1483361545; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=58l/6Axg9RPAzwq3aN+u9M8uk1L/GHuxpbFhQzxzxuw=; b=O4VZFAOdsx+G1S6Ygt1IwvjqnUvdufo7lj+YZXg4BRd1SJP3HaA3pZsy xfj+gcmOe0pT/6UB0nCrHdE7LiJgORIqFglwPOr+OtsWjFsJ3B6INzkGS eQqYNlJJK0MVKySjeKyeES3msS/0tHGsk/kaIoTT68HYJcezkj+9ITcJP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAwAS11dY/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAZBBqGSEGYYiAoI6EAECAQEBAQEBAWIohGkCBBIRDwEFQRA?= =?us-ascii?q?JEAwCHwcCAlcGDQgBAR6ISYolj1UBjXaCKIsLAQEBAQEBAQMBAQEBAQEBIYELh?= =?us-ascii?q?SuBfYZuEQGDIIJdAQSacJE0ih6GL4o0h3Q2IGMfFQ6EPIFGPYZigi4BAQE?= X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208";a="649026158" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 12:52:22 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBJCqMue011850; Mon, 19 Dec 2016 12:52:22 GMT To: Carsten Bormann References: <148181423460.27522.15050868161354943333.idtracker@ietfa.amsl.com> <4C009289-7A69-44BE-A050-ABCB9D23EE1F@tzi.org> From: Benoit Claise Message-ID: <7fe65126-bff7-b619-9b41-f55963623acd@cisco.com> Date: Mon, 19 Dec 2016 13:52:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <4C009289-7A69-44BE-A050-ABCB9D23EE1F@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: [Cbor] cbor terminology (was: Re: Benoit Claise's No Record on charter-ietf-cbor-00-03: (with COMMENT)) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:52:26 -0000 Hi Carsten, Let me reduce this email thread to the terminology issue, as I just file a BLOCK regarding my main point. >> Concise Binary Object Representation (CBOR, RFC 7049) extends the >> JavaScript Object Notation (JSON, RFC 7159) data model to include binary >> data >> and an extensibility model >> >> NEW: >> Concise Binary Object Representation (CBOR, RFC 7049) extends the >> JavaScript Object Notation (JSON, RFC 7159) data interchange format to >> include binary data >> and an extensibility model > Ah, that is an interesting terminology problem. > > Data interchange formats have (if they are half-way reasonable) a generic data model, into which all specific data models that are being interchanged using that format need to fit. But there is no semantic. So what you call a data interchange format here is a basically an encoding, not a data model. Regards, B. > One of the major innovations of JSON was to make this generic data model simple and reasonably close to what application developers want to interchange. > JSON’s generic data model has never been formally defined (and the finer details are an interesting area of contention!), but most application writers familiar with JSON would be able to define that generic data model to about 99 % precision. > CBOR goes ahead and extends JSON's generic data model (with binary data and with extensibility). > As with JSON, CBOR is not a data modeling language though, so whenever people needed to describe the specific data model used by the messages interchanged from their application, they had to resort to ad-hoc methods. CDDL is filling in the structural level of that need. > > CBOR does not extend JSON’s interchange format — it has its own (binary) one, which is completely different from JSON’s text-based format. > >> - I see in RFC 7049: >> The format defined here follows some specific design goals that are >> not well met by current formats. The underlying data model is an >> extended version of the JSON data model [RFC4627]. >> This is a mistake. > Well, we neglected to make the distinction between the generic data model and the application specific data models here., but I don’t agree with your proposed change. > >> Great we will have a new charter to accomplish this >> work >> >> - And don't forget the milestones. > Good point. > > Grüße, Carsten > > . > From nobody Mon Dec 19 07:18:55 2016 Return-Path: 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 1B0B1129B53; Mon, 19 Dec 2016 07:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Nb7zTJX1; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ukL9Wnlx 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 svBMXmKYPBoj; Mon, 19 Dec 2016 07:18:52 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D254129B54; Mon, 19 Dec 2016 07:18:52 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BBA2C207BF; Mon, 19 Dec 2016 10:18:51 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 19 Dec 2016 10:18:51 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=3MvEAr8tLpYcJvK/xxldVTR2Lr A=; b=Nb7zTJX1zF9+pzLwbFLVSQ7JgDcF8eaWZa8TPADCWcpP4gTRMkPb/xTdAz 3pVFlF4PooAI6w27CC2cGUU0OwbkJiOCk73CSCtRDZrT+6RRUtUms/oLJAuSKLBh 3sgAVxANjoEm0Kz4Af4/6mJRo61q2/vLApWVtIzVg4DiLaiKk= DKIM-Signature: v=1; a=rsa-sha1; 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-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=3M vEAr8tLpYcJvK/xxldVTR2LrA=; b=ukL9Wnlxv+gmRknpOLiXHp+fziZYQGi5CY airCdKpY9R8zghtRhjs8OXfmFfdtUPa4m99DibGlapDgLym3R5HVW3u/FlfbB0hY 7VntN6V7IHBY+/qYMIySVmqn8LLLC8kr+VxqaZJRVPeTKNyIgGqm1/XH5JtBWs7C whi+e0GPk= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 95E856ABEC; Mon, 19 Dec 2016 10:18:51 -0500 (EST) Message-Id: <1482160731.2337839.823677849.3D7AA932@webmail.messagingengine.com> From: Alexey Melnikov To: Benoit Claise , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-85983a1c Date: Mon, 19 Dec 2016 15:18:51 +0000 In-Reply-To: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: Re: [Cbor] Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:18:54 -0000 Hi Benoit, On Mon, Dec 19, 2016, at 12:48 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-cbor-00-04: Block >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-cbor/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > Sorry for this late BLOCK. > I had a very quick call with Alexey before the last IESG telechat: I want > to understand if I missed anything. > I filed a quick "NO RECORD" COMMENT. > Then, we discussed some more during the telechat itself. > And now, I finally had the time to think some more about this. >=20 > My BLOCK is about this charter paragraph: >=20 > Similar to the way ABNF (RFC 5234/7405) can be used to describe the > set of valid messages in a text representation, it would be useful if > protocol specifications could use a description format for the data in > CBOR-encoded messages. The CBOR data definition language (CDDL, based on > draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a > description technique that has already been used in CORE, ANIMA, CDNI, > and efforts outside the IETF. The CBOR WG will complete the development > of this specification by creating an Informational or Standards Track > RFC. >=20 >=20 > In OPS, we need automation. And automation will come from data models as, > from data models, we're able to generate APIs. > In the world of data modeling-driven management, we have: > YANG as a data modeling language, with ABNF specifications > YANG data modules, written with the YANG data modeling language > different encodings, such as XML, JSON, or CBOR > (draft-ietf-core-yang-cbor-03) > protocols such as NETCONF or RESTCONF for > configuration/monitoring/capabilities discovery > note: working on pub/sub protocol (aka telemetry) for events >=20 > See the first picture at > http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driv= en-management/ > Btw, I should add cbor. >=20 > Now, in this proposed WG, you want to define a new data modeling > language, "The CBOR data definition language" > When I ask the question: So the structure of what could be accessed on a > managed device?, you answer: >=20 > No. While CDDL could be used to describe the structure of data at > rest (a data store), that is not the objective. CDDL is used to define > the structure of data in flight, e.g. a protocol message going from a > node to a different node. (Using a term popular in semantic > interoperability work in the health care domain, CDDL is about > "structural interoperability=E2=80=9D =E2=80=94 it can tell you that ther= e is supposed to > be a data item =E2=80=9Ccheese-firmness=E2=80=9D in the message and out o= f what set of > values it needs to come, but it cannot tell you what the specific values > mean in the real world or what cheese firmness is in the first place on a > semantic level.)=20 >=20 >=20 > But what about the semantic definition (which is in YANG modules) of this > information? This is key for management. > I guess that the next item you'll want after this milestone is exactly > data models and semantic, right? >=20 > There are many schemas for IoT and I'm not trying to impose YANG in the > IoT world but I want to understand why we need duplication. > Note that there was an IAB-organized workshop on IoT data modeling in the > past (https://www.iab.org/activities/workshops/iotsi/) > However, it seems to me that your effort is exactly the reverse of data > modeling driven management? You have an encoding, and then you want a new > schema language Yes, the same way there are several schema languages for XML (for example). > Next, you'll need a mechanism to discover what is available on the > managed devices, a mechanism to know the device capabilities, a mechanism > for pub/sub, ... > And you will redo the full OPS stack, for IoT (hence duplication). And, > obviously, in the end, we will need a mapping between the two data > modeling languages: YANG and CDDL. I am not convinced that the mapping would be needed in all cases. See below. > What is specific here? I wanted to write: what's specific to IoT here, > but I don't even see IoT in the charter. There is just a kind of IoT > reference in RFC7049 abstract. > Why do we need this duplication within the IETF? I don't think saying that CBOR is only for IoT is helpful. There is some talk about using it for PKIX-like things. I can also see it being used directly in protocols. There is no YANG there, because there are no devices to manage, just a data structure. I don't think YANG is going to be helpful there. I am Ok with having some text in CDDL saying that if you want to do modeling-driven device management, CDDL is not the right tool. But as I said above I see other uses for CBOR/CDDL, which should be allowed. > Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work? > Those are completely inline with data modeling-driven management and this > charter seems to contradict this effort? > What do I miss? From nobody Mon Dec 19 11:39:01 2016 Return-Path: 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 B01DB1295EE; Mon, 19 Dec 2016 11:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Gz8RtwEah5e8; Mon, 19 Dec 2016 11:38:55 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D47A1295C4; Mon, 19 Dec 2016 11:38:55 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id p66so19354525pga.2; Mon, 19 Dec 2016 11:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kTurRUmiGnCIGj1jaTDZDwYVmUXLxbyJmAVBSPlW6Qo=; b=Y8rkyYU1nruq4PJjlXAHaxl8h4zsW6QS1YpFMdbY9iayqKQqVqtYpXQlki2XGYacnR ey6l8BsZ+hD34rbFYzyzDb3Aedxm4dc3sU7fGe7Zzs0q+FMG0HfbygbNFoPb+2uNliQD jO7NTK/jKeKFaLXrBfig91i8qvM0DzpPCVrWvWG1EOcRNqTwt4DH4CaFeiEEtk8ZLLes kAMmgopwNRXvftX6DYzekIvaWqs1k9OgMJl+PAbPixPNifRZN/rce6hK5VljtspuyKAl hHy+JPbrn7kdb86VyRQ0MZLsxlUSH/D1BATOi5n6ChTSksbcByzPmvU4fK0tL/XOwusN dFEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=kTurRUmiGnCIGj1jaTDZDwYVmUXLxbyJmAVBSPlW6Qo=; b=YahHB9tW5Uf3APOp9EKxU2cu4SHFW/Hl2iF04xQ7Q7fXR78Ul0qUwSgZR8nBIGLb+V qGziOT0vyoQjiOlGPiPmquN0lUDUiyJQnV1IXzgW1iBJMN1EetIEn3W92BctnHwVeUJV VHTi/Mv733H3pi6qyuIUABdoIwPSdDeSBO831+sAcpJZYbS76T0aaRNhnjOMsc39jQTC UOGGr5OCwLaP/wsezXLaPAucdkIMLM3zrotfZGlAtFKEs66DflfvI1qGsBWqh+aEtJan Y4fNM6Es/DQmJLA0DV1a4nP4CcPrDRDw2VcK1o3brYYdI70c3kkpqhIqsa7kOc0MndI6 8qJQ== X-Gm-Message-State: AKaTC01/DPbUyLsmaTRUkMHHYkNAqOtH+3eRJWzkbuxZ2dKkrIx+xra5uiLzpUcXXNIXlQ== X-Received: by 10.98.200.203 with SMTP id i72mr16528226pfk.181.1482176334745; Mon, 19 Dec 2016 11:38:54 -0800 (PST) Received: from [192.168.178.27] ([118.148.126.26]) by smtp.gmail.com with ESMTPSA id u78sm33313742pfa.53.2016.12.19.11.38.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 11:38:53 -0800 (PST) To: Benoit Claise , The IESG References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 20 Dec 2016 08:38:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: Re: [Cbor] Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:38:57 -0000 H Benoit, On 20/12/2016 01:48, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-cbor-00-04: Block ... > There are many schemas for IoT and I'm not trying to impose YANG in the > IoT world but I want to understand why we need duplication. What duplication? I am a CDDL user and in fact it is a normative reference for the GRASP protocol spec. It is the best way to objectively specify CBOR message formats without either very complicated and error-prone English or embedding pages of ABNF. In fact it is roughly speaking an ABNF vocabulary. It's a method of syntax definition, which like ABNF doesn't express semantics. It's orthogonal to YANG in purpose and capability. As an example: In fragmentary CDDL, every GRASP message follows the pattern: grasp-message = (message .within message-structure) / noop-message message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option] MESSAGE_TYPE = 1..255 session-id = 0..4294967295 ;up to 32 bits grasp-option = any If I was deprived of CDDL, I would never consider YANG as an alternative. I'd simply have to write an appendix for the GRASP spec that defines all the parts of CDDL that I need. BTW this has nothing in particular to do with IoT. It's a very general tool, but for a completely different purpose than YANG. Regards Brian From nobody Mon Dec 19 12:24:15 2016 Return-Path: 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 6D3BE129625 for ; Mon, 19 Dec 2016 12:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=cursive.net 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 vnRDGLrDJ6Ki for ; Mon, 19 Dec 2016 12:24:12 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D7D129405 for ; Mon, 19 Dec 2016 12:24:12 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 124so27635pgj.2 for ; Mon, 19 Dec 2016 12:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FSZElUKcBMG7PsUcrd2WhQnoHkJXle8S5FfXi9MhnfU=; b=o/vlG/s/8JTBQ4nK3j82g/ynfEr0gMLct6EzzQdBNgUAj8tqJKZ2HebwAAXhBWV2wx bcPM9+zpY8DUVJMevNwcf8i51YR2T1FTbaJFE7T71wOncA0/4Ca6ZuapJQp1jrum3yQS +l8tX6HdYm8hDMYZiFDC0zMVjToIr5eUPTcmc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FSZElUKcBMG7PsUcrd2WhQnoHkJXle8S5FfXi9MhnfU=; b=Favo6SXFJvItXiRh4ICoL/GYXNVjGRKS6ajbKW61gLIhnaWmKXL9rPRdezEFqszP/Q Js5m46F10lEgp/wWpL2vmmgal5zzpNM/PE738SJJxGYOv+BNvNuLz9jvbL2g+qMx4un3 YQFVKRG30UG/PUBMQEzGlR573tlO5TgQLxpRWd1PwLop7kqwY/8uGo8v3FNKwVGUP6r4 U6SFQgXjA35HWjZZXQaXNiaanfCddgvTmhYULT8mUpOkO6CZd64BhrQoD0k663wkT617 2L6PF89d1aGt8Vjk0HGO3LfzsSf7UShU00Gk/TMDI5OjBtMn4x82xfF3wpYNvepA7k60 pMCg== X-Gm-Message-State: AIkVDXIpqNd/FpfOXO4MwyEpdGcTpXPVtYl5LsCVawZaGhW0ZZyWhS0Q+dJIpmquD+/C2A== X-Received: by 10.84.218.204 with SMTP id g12mr20044035plm.78.1482179052388; Mon, 19 Dec 2016 12:24:12 -0800 (PST) Received: from [10.6.20.194] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id s3sm1317538pfg.14.2016.12.19.12.24.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 12:24:11 -0800 (PST) From: Joe Hildebrand X-Google-Original-From: Joe Hildebrand Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) In-Reply-To: Date: Mon, 19 Dec 2016 13:24:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24354528-00C4-47C8-A099-B50FB6EDA08B@cursive.net> References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Benoit Claise , cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 20:24:13 -0000 > On Dec 19, 2016, at 12:38 PM, Brian E Carpenter = wrote: >=20 > If I was deprived of CDDL, I would never consider YANG as an = alternative. > I'd simply have to write an appendix for the GRASP spec that defines = all > the parts of CDDL that I need. +1. Not everything is YANG. CDDL is for some of those things. --=20 Joe Hildebrand From nobody Tue Dec 20 08:17:01 2016 Return-Path: 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 14119129AFA for ; Tue, 20 Dec 2016 08:17:00 -0800 (PST) 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] 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 d7uufvwaSiaF for ; Tue, 20 Dec 2016 08:16:58 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283D3129B07 for ; Tue, 20 Dec 2016 08:16:50 -0800 (PST) Received: from [2001:b98:204:102:fff1::11] (port=61185 helo=Jims-iMac.local) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cJN5r-0007Z3-5n for cbor@ietf.org; Tue, 20 Dec 2016 16:16:48 +0000 To: cbor@ietf.org From: Jim Hague Organization: Sinodun Internet Technologies Ltd. Message-ID: Date: Tue, 20 Dec 2016 16:16:44 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: [Cbor] cddl validation - tracking errors X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 16:17:00 -0000 Hi, I'm working on a draft (https://tools.ietf.org/html/draft-dickinson-dnsop-dns-capture-format-00) which describes a CBOR based file format for recording DNS traffic. The draft includes a CDDL definition. I'm also working on an implementation. I'm using the 'cddl' tool to validate that the files I'm outputting match the CDDL in the draft. First, a minor thing. It would make including an output-matches-CDDL test in the regular test suite easier if 'cddl' exited 1 if validation fails. Currently it only seems to exit 1 if the CDDL is invalid. Second, and rather bigger. Does anyone have any tips for how to track down where a validation actually fails? The file format in question isn't simple, and error messages therefore become: CDDL validation failure (nil for [ <500+ lines> , 2=>44878, 3=>2329, 4=>2, 5=>64, 6=>75, 7=>1602, 11=>67, 8=>499, 9=>{}, 10=>{2=>3, 3=>24}}], 4=>[]}]]): [32769, [:prim, 3], "[32769, [:prim, 3], \"occur not reached in array [\\\"C-DNS\\\", <500+ lines> 1=>67, 8=>499, 9=>{}, 10=>{2=>3, 3=>24}}], 4=>[]}]] for [:array, [:member, 1, 1, [:text, \"file-type-id\"], [:prim, 3]], [:member, 1, 1, [:text, \"file-preamble\"], <60 lines> [:prim, 0]], [:member, 1, 1, [:int, 2], [:prim, 0]], [:member, 1, 1, [:int, 3], [:prim, 0]]]]]]]]]]]"] which basically seems to be telling me there's a problem somewhere in or below the array that contains the entire format. Thanks. -- Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Tue Dec 20 14:42:10 2016 Return-Path: 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 9471612962E for ; Tue, 20 Dec 2016 14:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 sQBMp2N3DoZD for ; Tue, 20 Dec 2016 14:42:04 -0800 (PST) Received: from cos-us-iron01k.cos.keysight.com (cos-us-iron01k.cos.keysight.com [192.25.5.35]) (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 ADFAC129422 for ; Tue, 20 Dec 2016 14:42:04 -0800 (PST) X-IPAS-Result: =?us-ascii?q?A2B5AgBTs1lYfRUYjJxcGwEBAQMBAQEJAQEBgnNEAQEBAQF?= =?us-ascii?q?5gQ2OPKhmhBmGIgKCLBEBAgEBAQEBAQETAQEWLzCEbAMtXgEqViYBBBuIY5hmk?= =?us-ascii?q?iiLEAELJosPhEJKgmWCMAWacKIBkik1hVEfgV2IbAGBDAEBAQ?= X-IronPort-AV: E=Sophos; i="5.33,380,1477980000"; d="scan'208,217"; a="43572519" Received: from wcosexch02k.cos.is.keysight.com (HELO 2k10hubs.keysight.com) ([156.140.24.21]) by cos-us-iron01k.cos.keysight.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2016 15:42:01 -0700 Received: from wcosexch01k.cos.is.keysight.com ([169.254.3.33]) by wcosexch02k.cos.is.keysight.com ([156.140.24.21]) with mapi id 14.03.0279.002; Tue, 20 Dec 2016 15:41:59 -0700 From: To: Thread-Topic: Representation of High Precision Timestamps with CBOR Thread-Index: AdJbEfWCkOxsADK/Tq2XABvS3H6vdg== Date: Tue, 20 Dec 2016 22:41:59 +0000 Message-ID: <04EFF12F483FA149B07653989B86861F305E897F@wcosexch01k.cos.is.keysight.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.140.13.70] x-tm-as-product-ver: SMEX-12.0.0.1220-8.000.1202-22774.003 x-tm-as-result: No--19.054800-8.000000-31 x-tm-as-matchedid: 139704-113220-708196-111604-700362-705718-700345-701827-7 00264-702497-700450-700732-701306-709859-111605-700074-303242-121155-706066 -707997-703712-702836-703657-705313-704349-705901-701594-702358-706117-1215 04-702131-188124-707209-700498-704240-709298-701506-704425-709251-703355-70 2097-863299-700759-709584-708915-705102-121111-710972-188093-148004-148050- 42000 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_04EFF12F483FA149B07653989B86861F305E897Fwcosexch01kcosi_" MIME-Version: 1.0 Archived-At: Subject: [Cbor] Representation of High Precision Timestamps with CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 22:42:07 -0000 --_000_04EFF12F483FA149B07653989B86861F305E897Fwcosexch01kcosi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have implementations of IEEE1588 Precision Time Protocol which utilize 9= 6 bit timestamps to provide sub-nanosecond resolution. In the case of IEEE= 1588, they define a binary timestamp structure as 48 bits of seconds, 32 bi= ts of nanoseconds, and 16 bits of sub-nanoseconds. These timestamps are re= lative to the conventional Jan 1, 1970 date. This cannot be represented by= a 64 bit floating point number as it only has 48 bits of mantissa. We use= these timestamps to mark measurement data and schedule hardware related ac= tions among cooperating nodes in a network. CBOR defines tag 1 to represent numerical representation of date and time a= nd mentions specifically integer and floating point types. Is it permissib= le to utilize a decimal fraction that uses a Tag 2 bignum in conjunction wi= th tag 1? I imagine using this to encode a 64 or 96 bit integer with a 10*= *-9 or 10**-14 scale factor. The encoding might be as follows: C1 -- Tag 1 Date/Time C4 -- Tag 4 Decimal Fraction 82 -- Array of length 2 2d -- -14 exponent C2 -- Tag 2 Bignum 2C -- Byte string of length 12 (96 bits) 0102030405060708090a0b0c0d0e -- Bytes content The text for Date and Time says the tagged item can be major types 0, 1 or = 7 but does not say 'MUST'. Is use of Tag 4 allowed with Tag 1 Date/Time? Is there a better way of rep= resenting this? Alternatively, I suppose proposing a new IEEE1588 timestam= p tag would be an option to reduce the tag overhead. Feedback appreciated, Glenn --_000_04EFF12F483FA149B07653989B86861F305E897Fwcosexch01kcosi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have implementations of IEEE1588 Precision Time P= rotocol which utilize 96 bit timestamps to provide sub-nanosecond resolutio= n.  In the case of IEEE1588, they define a binary timestamp structure = as 48 bits of seconds, 32 bits of nanoseconds, and 16 bits of sub-nanoseconds.  These timestamps are relative to the= conventional Jan 1, 1970 date.  This cannot be represented by a 64 bi= t floating point number as it only has 48 bits of mantissa.  We use th= ese timestamps to mark measurement data and schedule hardware related actions among cooperating nodes in a network.<= /p>

 

CBOR defines tag 1 to represent numerical representa= tion of date and time and mentions specifically integer and floating point = types.  Is it permissible to utilize a decimal fraction that uses a Ta= g 2 bignum in conjunction with tag 1?  I imagine using this to encode a 64 or 96 bit integer with a 10**-9 or 10*= *-14 scale factor.

 

The encoding might be as follows:

=  

= C1           -- Tag 1 Dat= e/Time

=   C4         -- Tag 4 Decimal = Fraction

=     82       -- Array of lengt= h 2

=       2d     -- -14 exponent

=       C2     -- Tag 2 Bignum

=          2C  -- Byte string of= length 12 (96 bits)

=             01020304= 05060708090a0b0c0d0e  -- Bytes content

 

The text for Date and Time says the tagged item can = be major types 0, 1 or 7 but does not say ‘MUST’.

 

Is use of Tag 4 allowed with Tag 1 Date/Time?  = Is there a better way of representing this?  Alternatively, I suppose = proposing a new IEEE1588 timestamp tag would be an option to reduce the tag= overhead.

 

Feedback appreciated,

 

Glenn

--_000_04EFF12F483FA149B07653989B86861F305E897Fwcosexch01kcosi_-- From nobody Tue Dec 20 17:23:45 2016 Return-Path: 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 E81F7129B6A for ; Tue, 20 Dec 2016 17:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pZc882p-Z_F3 for ; Tue, 20 Dec 2016 17:23:42 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82372129B6C for ; Tue, 20 Dec 2016 17:23:42 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id g1so39610374pgn.0 for ; Tue, 20 Dec 2016 17:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=12pMbv/kEbB8URLzhThfgBWE9WCPQOgKKdgKi4cYSyc=; b=i1d33BncB/xjd24mDq5Nzixdu/36EogO2YoXTHzyj6/fSIce6E4gacFCX93NjtVhr6 nTzsBJhSZ4OZzeDMpN6qDTIABvgvHo/HhgoeTRl5wukBnSBoIjsXN22wnvrhS26OqlC5 nSCO+px3V4hM8MosQRcgQ9CJEOX15sOOxJRTrnTXZX7ySE8WSBhmSM9FuxtwwU9ODZUJ b1kkRO5y5i39lZogA43YGKI27oz192FZan+OzQkWNk9fDR8mL2hT9h9gTiCpWj5tI+S2 Fqjxyi0nwTqtHvP6bpwzCQjQzvSrVWAD0ksrRCR9HmOFsllskGwOaUmbUCiEdLTyPDTp ekNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=12pMbv/kEbB8URLzhThfgBWE9WCPQOgKKdgKi4cYSyc=; b=N0qWdMZzb+eQBw4vMnEtolQ6VqpmDmXmXmRBhG1/4CsChL7TcbaSsowDOK4f3+ZDmZ UDD4wyjBGp2i0wHl7lNPzHA1pULqwwWeTk8HZiR+GXwVOcA0VDnwIi6/5xu4QvhSosdp DCl9BnEYI0khezZztFNKCHnsziDo6IdrUsjEKli1L4nsc8jw55h1RCj208zPzkjvgxZf I2ZGCGN2u9ZQOBEgunvG+PlMYfHubPqkVR/If6zy8cstshDOFn45UzZdnMJIMcA4agvz q1F8G5OPgw0Jzskap6eLAWK6wr9UcpO6XcRoyGTeX07OBT6j7XMqoCcoRu9FN0c0KHoj lVyg== X-Gm-Message-State: AIkVDXKwY0EAOTf8Az8fRsk8zapvLmY3QdGp4XGGtOIWBapgiP4zeRHQEwn8aPcAo0wMTw== X-Received: by 10.99.209.5 with SMTP id k5mr3429258pgg.145.1482283422131; Tue, 20 Dec 2016 17:23:42 -0800 (PST) Received: from [192.168.178.27] ([118.148.115.63]) by smtp.gmail.com with ESMTPSA id a68sm42106173pgc.31.2016.12.20.17.23.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Dec 2016 17:23:41 -0800 (PST) To: glenn_engel@keysight.com References: <04EFF12F483FA149B07653989B86861F305E897F@wcosexch01k.cos.is.keysight.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <25f2e76f-d2b3-85a6-7f0d-17d8fab30a82@gmail.com> Date: Wed, 21 Dec 2016 14:23:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <04EFF12F483FA149B07653989B86861F305E897F@wcosexch01k.cos.is.keysight.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: cbor@ietf.org Subject: Re: [Cbor] Representation of High Precision Timestamps with CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 01:23:44 -0000 I'm wondering whether you need the tags at all, if you know from context that you are expecting this format. Then [-14,0x0102030405060708090a0b0c0d0e] would be 822dc24e0102030405060708090a0b0c0d0e according to my handy Python->CBOR converter. Incidentally, your example C1C4822dC22C0102030405060708090a0b0c0d0e blows up Python's cbor.loads() with a type error. Regards Brian Carpenter On 21/12/2016 11:41, glenn_engel@keysight.com wrote: > We have implementations of IEEE1588 Precision Time Protocol which utilize 96 bit timestamps to provide sub-nanosecond resolution. In the case of IEEE1588, they define a binary timestamp structure as 48 bits of seconds, 32 bits of nanoseconds, and 16 bits of sub-nanoseconds. These timestamps are relative to the conventional Jan 1, 1970 date. This cannot be represented by a 64 bit floating point number as it only has 48 bits of mantissa. We use these timestamps to mark measurement data and schedule hardware related actions among cooperating nodes in a network. > > CBOR defines tag 1 to represent numerical representation of date and time and mentions specifically integer and floating point types. Is it permissible to utilize a decimal fraction that uses a Tag 2 bignum in conjunction with tag 1? I imagine using this to encode a 64 or 96 bit integer with a 10**-9 or 10**-14 scale factor. > > The encoding might be as follows: > > C1 -- Tag 1 Date/Time > C4 -- Tag 4 Decimal Fraction > 82 -- Array of length 2 > 2d -- -14 exponent > C2 -- Tag 2 Bignum > 2C -- Byte string of length 12 (96 bits) > 0102030405060708090a0b0c0d0e -- Bytes content > > The text for Date and Time says the tagged item can be major types 0, 1 or 7 but does not say 'MUST'. > > Is use of Tag 4 allowed with Tag 1 Date/Time? Is there a better way of representing this? Alternatively, I suppose proposing a new IEEE1588 timestamp tag would be an option to reduce the tag overhead. > > Feedback appreciated, > > Glenn > > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > From nobody Tue Dec 20 22:16:06 2016 Return-Path: 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 9EC6712711D for ; Tue, 20 Dec 2016 22:16:05 -0800 (PST) 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] 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 uoHTQl1Ab8yy for ; Tue, 20 Dec 2016 22:16:03 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 8D7741294C3 for ; Tue, 20 Dec 2016 22:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uBL6G0Ke001712; Wed, 21 Dec 2016 07:16:00 +0100 (CET) Received: from [192.168.217.102] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tk4Cg6WnPz8KWr; Wed, 21 Dec 2016 07:15:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <04EFF12F483FA149B07653989B86861F305E897F@wcosexch01k.cos.is.keysight.com> Date: Wed, 21 Dec 2016 07:15:59 +0100 X-Mao-Original-Outgoing-Id: 503993759.197629-cbc9f5dab6fb1c4640ce23619bb29eba Content-Transfer-Encoding: quoted-printable Message-Id: <1AB0D9F4-1ABF-463D-8AE8-1394A3EE98AC@tzi.org> References: <04EFF12F483FA149B07653989B86861F305E897F@wcosexch01k.cos.is.keysight.com> To: glenn_engel@keysight.com X-Mailer: Apple Mail (2.3259) Archived-At: Cc: cbor@ietf.org Subject: Re: [Cbor] Representation of High Precision Timestamps with CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 06:16:05 -0000 On 20 Dec 2016, at 23:41, = wrote: >=20 > The text for Date and Time says the tagged item can be major types 0, = 1 or 7 but does not say =E2=80=98MUST=E2=80=99. Hi Glenn, I think we made a mistake by not allowing number formats other than int = or float with Tag 1. Clearly both decimal and big float (binary exponent) make a lot of sense = here. Can we fix that mistake? As Brian notes, some implementers are relying on the =E2=80=9Ccan be=E2=80= =9D being the normative, complete set of possibilities. So allowing new = number types in Tag 1 would be a change affecting implementations. We = could still decide that making this change is justified. This is not the only place where we got the type embedded in a tag = wrong. Tag 36 only allows UTF-8 structured MIME messages; but those can = be byte strings as well. This was worked around by registering Tag 257 = for the byte string case. Is it better to have a new tag when we need to extend the types allowed = inside a tag? Old implementations can=E2=80=99t make a lot of use of = that new tag either, but at least they won=E2=80=99t =E2=80=9Cblow up=E2=80= =9D with data they don=E2=80=99t expect in an existing tag. (I don=E2=80=99t think that having a two-byte tag representation for a = hypothetical =E2=80=9Ctime with decimal=E2=80=9D tag would be a problem = given its natural size. That tag also could [or could not] imply the = Decimal tag, gaining back one byte.) Brian is of course right that a tag is not strictly needed at all. When = defining CBOR-YANG, we first went that way (not using the tag) with = representing RFC 6020=E2=80=99s Decimal type. But then we went back to = using the tag because we may need it to disambiguate unions. In summary, I=E2=80=99m not sure there is a single best way forward here = (at least I haven=E2=80=99t made up my mind yet). That is exactly why I = look forward to having a CBOR working group soon =E2=80=94 we can make = decisions like this as a working group decision, taking input from a = variety of perspectives. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 21 03:39:07 2016 Return-Path: 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 6CC8D129D55 for ; Wed, 21 Dec 2016 03:39:06 -0800 (PST) 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] 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 sX_wSMC843Le for ; Wed, 21 Dec 2016 03:39:04 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 B9304129D59 for ; Wed, 21 Dec 2016 03:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uBLBcxOf014381; Wed, 21 Dec 2016 12:38:59 +0100 (CET) Received: from eduroam-pool12-664.wlan.uni-bremen.de (eduroam-pool12-664.wlan.uni-bremen.de [134.102.154.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tkCNM2PS6z8Kfs; Wed, 21 Dec 2016 12:38:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Wed, 21 Dec 2016 12:38:58 +0100 X-Mao-Original-Outgoing-Id: 504013138.715193-e7b81cd3b2e3a850135f2d7111f6f86d Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jim Hague X-Mailer: Apple Mail (2.3259) Archived-At: Cc: cbor@ietf.org Subject: Re: [Cbor] cddl validation - tracking errors X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 11:39:06 -0000 On 20 Dec 2016, at 17:16, Jim Hague wrote: >=20 > Hi, >=20 > I'm working on a draft = (https://tools.ietf.org/html/draft-dickinson-dnsop-dns-capture-format-00) = which describes a CBOR based file format for recording DNS traffic. The = draft includes a CDDL definition. I'm also working on an implementation. >=20 > I'm using the 'cddl' tool to validate that the files I'm outputting = match the CDDL in the draft. Great to hear! > First, a minor thing. It would make including an output-matches-CDDL = test in the regular test suite easier if 'cddl' exited 1 if validation = fails. Currently it only seems to exit 1 if the CDDL is invalid. Good point. Fixed in 0.8.4. (Jim had earlier alerted me to this before, but it never made in on the = list=E2=80=A6). > Second, and rather bigger. Does anyone have any tips for how to track = down where a validation actually fails? As you have noticed, error messages are not something that the current = tool does very well. > The file format in question isn't simple, and error messages therefore = become: >=20 > CDDL validation failure (nil for [ > <500+ lines> > , 2=3D>44878, 3=3D>2329, 4=3D>2, 5=3D>64, 6=3D>75, 7=3D>1602, 11=3D>67, = 8=3D>499, 9=3D>{}, 10=3D>{2=3D>3, 3=3D>24}}], 4=3D>[]}]]): > [32769, > [:prim, 3], > "[32769, [:prim, 3], \"occur not reached in array [\\\"C-DNS\\\", > <500+ lines> > 1=3D>67, 8=3D>499, 9=3D>{}, 10=3D>{2=3D>3, 3=3D>24}}], 4=3D>[]}]] for = [:array, [:member, 1, 1, [:text, \"file-type-id\"], [:prim, 3]], = [:member, 1, 1, [:text, \"file-preamble\"], > <60 lines> > [:prim, 0]], [:member, 1, 1, [:int, 2], [:prim, 0]], [:member, 1, 1, = [:int, 3], [:prim, 0]]]]]]]]]]]"] >=20 > which basically seems to be telling me there's a problem somewhere in = or below the array that contains the entire format. Actually it also tells you that an occurrence indicator wasn=E2=80=99t = reached. There also was an attempt to match up 32769 with a text string ([:prim, = 3] =E2=80=94 primitive with major type 3). Getting better error output is definitely an objective for further = development of the tool. Since there is some backtracking going on, it is not always obvious what = exactly triggered the validation failure. The current tool is a bit = like Kernighan=E2=80=99s car. It may be useful to extend CDDL by a few = mechanisms that would cut back on the backtracking to make this easier. If you have a particularly hard nut to crack, please do send it (CDDL = file, CBOR instance) to me so I can develop a little set of examples = from which I can improve the error handling. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 21 16:20:47 2016 Return-Path: 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 307E8129445; Wed, 21 Dec 2016 16:20:43 -0800 (PST) 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] 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 cf4GnWAdMaw2; Wed, 21 Dec 2016 16:20:41 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 2FE6A129437; Wed, 21 Dec 2016 16:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uBM0KVHb007214; Thu, 22 Dec 2016 01:20:31 +0100 (CET) Received: from [192.168.217.102] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tkXH33Dfrz8Ktg; Thu, 22 Dec 2016 01:20:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <7fe65126-bff7-b619-9b41-f55963623acd@cisco.com> Date: Thu, 22 Dec 2016 01:20:31 +0100 X-Mao-Original-Outgoing-Id: 504058830.981668-e176ef6894ebb97fc797dcf0e16da212 Content-Transfer-Encoding: quoted-printable Message-Id: <9DCB0B24-9D78-46AD-BFAA-84686ACFC33D@tzi.org> References: <148181423460.27522.15050868161354943333.idtracker@ietfa.amsl.com> <4C009289-7A69-44BE-A050-ABCB9D23EE1F@tzi.org> <7fe65126-bff7-b619-9b41-f55963623acd@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3259) Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] cbor terminology (was: Re: Benoit Claise's No Record on charter-ietf-cbor-00-03: (with COMMENT)) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 00:20:43 -0000 On 19 Dec 2016, at 13:52, Benoit Claise wrote: >=20 >> Data interchange formats have (if they are half-way reasonable) a = generic data model, into which all specific data models that are being = interchanged using that format need to fit. > But there is no semantic. So what you call a data interchange format = here is a basically an encoding, not a data model. Hi Benoit, there cannot be an encoding unless there is something to encode. That something is best described by a data model. =20 (Interchange formats are often not separating data models and encoding = very well. =20 That has been a major cause for lots of pain.) Whether the data model focuses at the level of structural = interoperability or it is semantically rooted is not making the former = less of a data model. I=E2=80=99m not aware of any successful use of semantically rooted = formal description techniques (FDT) for protocol data models in the = IETF, so I=E2=80=99m not even sure what you are aiming at. Today, = semantics are typically described in English. Structural = interoperability is described in ABNF, or in a special purpose FDT = (e.g., RFC 4997 formal notation =E2=80=94 which is rather advanced as it = combines elements of a data model with specialized encoding semantics = for stateful compression =E2=80=94, or TLS "presentation language"). (To use the terminology in another context: A YANG model describes a = specific data model for data at rest, from which a protocol for = manipulating that data is then automatically derived. This is great, = but not all protocols are about manipulating data at rest [that would = then also happen to fit into the YANG generic data model]. BTW, YANG = models are not semantically rooted either, except for the = =E2=80=9Csemantics=E2=80=9D of being able to automatically derive a = protocol from the model.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 21 17:45:07 2016 Return-Path: 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 324611295E5 for ; Wed, 21 Dec 2016 17:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 TvL_FlwnCvJF for ; Wed, 21 Dec 2016 17:45:05 -0800 (PST) Received: from cos-us-iron01k.cos.keysight.com (cos-us-iron01k.cos.keysight.com [192.25.5.35]) (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 09F321295D6 for ; Wed, 21 Dec 2016 17:45:04 -0800 (PST) X-IPAS-Result: =?us-ascii?q?A2ASCABZL1tYfRUYjJxeGgEBAQECAQEBAQgBAQEBgyoLAQE?= =?us-ascii?q?BAQGCCgGOO5VekwSEGYYiAhqCCBABAgEBAQEBAQETAQEWLzCEaAEBAQECASMRS?= =?us-ascii?q?gsCAQgaAgYgAgICMBUQAQEEARqIXAioXIIoin8BAQEBBgEBAQEBAQEhgQuKBIR?= =?us-ascii?q?CgwItgjAFmneiCpIzNodWiD8BgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,386,1477980000"; d="scan'208";a="43660770" Received: from wcosexch02k.cos.is.keysight.com (HELO 2k10hubs.keysight.com) ([156.140.24.21]) by cos-us-iron01k.cos.keysight.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2016 18:45:02 -0700 Received: from wcosexch01k.cos.is.keysight.com ([169.254.3.33]) by wcosexch02k.cos.is.keysight.com ([156.140.24.21]) with mapi id 14.03.0279.002; Wed, 21 Dec 2016 18:45:00 -0700 From: To: , Thread-Topic: [Cbor] Representation of High Precision Timestamps with CBOR Thread-Index: AdJbEfWCkOxsADK/Tq2XABvS3H6vdgAUZTyAACIgXdA= Date: Thu, 22 Dec 2016 01:45:00 +0000 Message-ID: <04EFF12F483FA149B07653989B86861F305E8BAD@wcosexch01k.cos.is.keysight.com> References: <04EFF12F483FA149B07653989B86861F305E897F@wcosexch01k.cos.is.keysight.com> <25f2e76f-d2b3-85a6-7f0d-17d8fab30a82@gmail.com> In-Reply-To: <25f2e76f-d2b3-85a6-7f0d-17d8fab30a82@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.140.13.71] x-tm-as-product-ver: SMEX-12.0.0.1220-8.000.1202-22776.004 x-tm-as-result: No--10.322200-8.000000-31 x-tm-as-matchedid: 150567-701625-704425-700685-139010-706891-700469-700630-7 01252-702791-710739-705526-700498-700063-702616-712032-703788-113872-702358 -703657-701594-186035-705313-701513-701461-700726-704034-703154-707950-1480 04-148133-42000-42003 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] Representation of High Precision Timestamps with CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 01:45:06 -0000 DQo+IEknbSB3b25kZXJpbmcgd2hldGhlciB5b3UgbmVlZCB0aGUgdGFncyBhdCBhbGwsIGlmIHlv dSBrbm93IGZyb20gY29udGV4dCB0aGF0IHlvdSBhcmUgZXhwZWN0aW5nIHRoaXMgZm9ybWF0Lg0K DQpTaW5jZSB3ZSBzdG9yZSB0aGlzIGFzIGEgbWV0YSBkYXRhIG1hcCB3ZSBjb3VsZCBjZXJ0YWlu bHkgaW5mZXIgZnJvbSBjb250ZXh0IHRoYXQgYSBEZWNpbWFsIEZyYWN0aW9uIG9yIGJpZyBmbG9h dCByZXByZXNlbnRzIHRpbWUgYnV0IG9uIHRoZSBvdGhlciBoYW5kIGl0J3MgcHJlZmVyYWJsZSB0 byBjb252ZXJ0IENCT1IgcmF3IHN0cmVhbXMgaW50byBhIG5hdGl2ZSB0eXBlIChlLmcuIERhdGUp IHdoZW4gYnVpbGRpbmcgYSBtYXAgb2YgbWV0YSBkYXRhIGZvciBleGFtcGxlLg0KDQpJIHRoaW5r IGEgYmlnZ2VyIGNvbmNlcm4gaXMgdGhhdCBieSBwcmVjbHVkaW5nIHVzZSBvZiBiaWcgZmxvYXQg b3IgZGVjaW1hbCBmcmFjdGlvbiB3ZSBjYW5ub3QgZXZlbiBleHByZXNzIGEgdGltZXN0YW1wIGlu IG1pY3Jvc2Vjb25kIHJlc29sdXRpb24gdXNpbmcgZmxvYXQ2NC4gICBXaGlsZSBtaWxsaXNlY29u ZHMgaXMgc3VmZmljaWVudCBmb3IgbW9zdCBhcHBsaWNhdGlvbnMsIGEgZ3Jvd2luZyBudW1iZXIg bmVlZCBhbGwgYXZhaWxhYmxlIHJlc29sdXRpb24uICBUb29scyBsaWtlIHdpcmVzaGFyayBjYXB0 dXJlIGluIHVTZWMgcmVzb2x1dGlvbiAoYWxiZWl0IHJlbGF0aXZlIHRvIHRoZSBzdGFydCkuICBB IGNvbXBhbmlvbiBuZWVkIHdoZW4gdXNpbmcgdGltZSBpcyB0aGUgY29uY2VwdCBvZiBkdXJhdGlv biB3aGljaCBJIGhhdmVuJ3Qgc2VlbiBhIHRhZyBmb3IuDQoNCkFzIGZvciBtYWtpbmcgYSBuZXcg dGFnIG9yIG9wZW5pbmcgdXAgdGhlIGV4aXN0aW5nIHRhZyB0byBhIHdpZGVyIGludGVycHJldGF0 aW9uIGl0IGRvZXNuJ3QgbWF0dGVyIG11Y2ggdG8gbWUuICBOb3QgaGF2aW5nIGEgd29ya2luZyBp bXBsZW1lbnRhdGlvbiAoeWV0KSBJJ2QgcHJlZmVyIHVzaW5nIHRoZSBleGlzdGluZyB0YWcgYnV0 IEkgc2VlIHRoZSBiZW5lZml0IG9mIG5vdCBicmVha2luZyBhbnl0aGluZyBpbiB0aGUgd2lsZCBl aXRoZXIuDQoNCi0tDQpHbGVubg0KDQoNCg== From nobody Fri Dec 23 06:55:10 2016 Return-Path: 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 76EC31295A5; Fri, 23 Dec 2016 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 K4uDUEo9Ru9k; Fri, 23 Dec 2016 06:55:04 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E8A12947F; Fri, 23 Dec 2016 06:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1567; q=dns/txt; s=iport; t=1482504904; x=1483714504; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=W5hKU7GPSyl4TaF2+s7PBoSi1Lsz6dEnNOioHH+OTPc=; b=ioGX+yNpE3YQeuC5wa6kw56jgDWSv/+HhdIEZPO4nwWVGSPJWYBvycyd 0nAeYy849Jl7nrAodM57GihuLrNzgSF7t4S4Y0BKdSwFyGBELmh/bznYd xZUjjqFV3de5cP/0u8+8941/kJVChaoewW+6PTarNmwTTUHDPsgjSOrSx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0GQC1OV1Y/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYErBByOf5VfkwiEGIYiAoI3EQECAQEBAQEBAWIohGk?= =?us-ascii?q?BBSMVQRALGAICJgICVwYBDAgBAYhrrAyCJ4p9AQEBAQEBAQEBAQEBAQEBAQEBI?= =?us-ascii?q?IELhT2CAoJgh06CXQEElQaFdJE8iiWGL4pGg2aEEDUhAYEHFg2ESoFGPYk8AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.33,393,1477958400"; d="scan'208";a="650994698" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2016 14:53:01 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBNEr0vh023379; Fri, 23 Dec 2016 14:53:01 GMT To: Brian E Carpenter , The IESG References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Fri, 23 Dec 2016 15:53:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: Re: [Cbor] Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 14:55:05 -0000 Thanks Brian, This is useful. Regards, Benoit > H Benoit, > On 20/12/2016 01:48, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> charter-ietf-cbor-00-04: Block > ... >> There are many schemas for IoT and I'm not trying to impose YANG in the >> IoT world but I want to understand why we need duplication. > What duplication? I am a CDDL user and in fact it is a normative reference > for the GRASP protocol spec. It is the best way to objectively specify > CBOR message formats without either very complicated and error-prone English > or embedding pages of ABNF. In fact it is roughly speaking an ABNF vocabulary. > It's a method of syntax definition, which like ABNF doesn't express semantics. > It's orthogonal to YANG in purpose and capability. As an example: > > In fragmentary CDDL, every GRASP message follows the pattern: > > grasp-message = (message .within message-structure) / noop-message > > message-structure = [MESSAGE_TYPE, session-id, ?initiator, > *grasp-option] > > MESSAGE_TYPE = 1..255 > session-id = 0..4294967295 ;up to 32 bits > grasp-option = any > > If I was deprived of CDDL, I would never consider YANG as an alternative. > I'd simply have to write an appendix for the GRASP spec that defines all > the parts of CDDL that I need. > > BTW this has nothing in particular to do with IoT. It's a very general tool, > but for a completely different purpose than YANG. > > Regards > Brian > > . > From nobody Fri Dec 23 07:01:17 2016 Return-Path: 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 8455C1293E9; Fri, 23 Dec 2016 07:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 GT24gsxPEYMr; Fri, 23 Dec 2016 07:01:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3521200A0; Fri, 23 Dec 2016 07:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13887; q=dns/txt; s=iport; t=1482505273; x=1483714873; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6s7BJypazI3zGJMsqSWgMcc89BSRZEim8wD28d0EE9g=; b=YQ/k5CHjaFziY5cniMjYiBbFnV5L1t9x01H6PraJzWwsyk9mTDS2YQOy /ukIQuG8NlSUtcVMOygic1rx3/c+p+0m7/gZbkh5/cHb989KUGR/O/bmJ KogqlxXMIP9iry5j7Pnswa1LdlX6se50E4+BPyHnGimh8uWNkJev9f+l1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZCgCeOl1Y/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXwvIDuNUnKVX49xgxeCD4IJLIV2AoI0FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDASNWBQsJAg4KKgICVwYBDAgBAYhjCA6OOJ1Mgicuik8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdhkiCAoJghBwRAYMggl0FiGaSFIZTimmBdYUJgye?= =?us-ascii?q?GL4pGg2aEEB83AWgfFg2EFhyBXj2HDoIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,393,1477958400"; d="scan'208,217";a="648154805" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2016 15:01:10 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBNF1AnZ025245; Fri, 23 Dec 2016 15:01:10 GMT To: Alexey Melnikov , The IESG References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <1482160731.2337839.823677849.3D7AA932@webmail.messagingengine.com> From: Benoit Claise Message-ID: Date: Fri, 23 Dec 2016 16:01:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1482160731.2337839.823677849.3D7AA932@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------99DB7832D628234B083620E9" Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: Re: [Cbor] Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 15:01:15 -0000 This is a multi-part message in MIME format. --------------99DB7832D628234B083620E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks to all who educated me, in the different email threads. Moving back to a COMMENT at this point in time. As Alexey mentioned, some more wording about this in the charter would help (if nobody else, at least me): I am Ok with having some text in CDDL saying that if you want to do modeling-driven device management, CDDL is not the right tool. But as I said above I see other uses for CBOR/CDDL, which should be allowed. In the end, I missed the key message that CDDL is more helpful for horizontal protocol to support device-to-device communication, as opposed to a management protocol. I've been probably too biased by my OPS background :-) Regards, Benoit > Hi Benoit, > > On Mon, Dec 19, 2016, at 12:48 PM, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> charter-ietf-cbor-00-04: Block >> >> 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.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-cbor/ >> >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> Sorry for this late BLOCK. >> I had a very quick call with Alexey before the last IESG telechat: I want >> to understand if I missed anything. >> I filed a quick "NO RECORD" COMMENT. >> Then, we discussed some more during the telechat itself. >> And now, I finally had the time to think some more about this. >> >> My BLOCK is about this charter paragraph: >> >> Similar to the way ABNF (RFC 5234/7405) can be used to describe the >> set of valid messages in a text representation, it would be useful if >> protocol specifications could use a description format for the data in >> CBOR-encoded messages. The CBOR data definition language (CDDL, based on >> draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a >> description technique that has already been used in CORE, ANIMA, CDNI, >> and efforts outside the IETF. The CBOR WG will complete the development >> of this specification by creating an Informational or Standards Track >> RFC. >> >> >> In OPS, we need automation. And automation will come from data models as, >> from data models, we're able to generate APIs. >> In the world of data modeling-driven management, we have: >> YANG as a data modeling language, with ABNF specifications >> YANG data modules, written with the YANG data modeling language >> different encodings, such as XML, JSON, or CBOR >> (draft-ietf-core-yang-cbor-03) >> protocols such as NETCONF or RESTCONF for >> configuration/monitoring/capabilities discovery >> note: working on pub/sub protocol (aka telemetry) for events >> >> See the first picture at >> http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/ >> Btw, I should add cbor. >> >> Now, in this proposed WG, you want to define a new data modeling >> language, "The CBOR data definition language" >> When I ask the question: So the structure of what could be accessed on a >> managed device?, you answer: >> >> No. While CDDL could be used to describe the structure of data at >> rest (a data store), that is not the objective. CDDL is used to define >> the structure of data in flight, e.g. a protocol message going from a >> node to a different node. (Using a term popular in semantic >> interoperability work in the health care domain, CDDL is about >> "structural interoperability” — it can tell you that there is supposed to >> be a data item “cheese-firmness” in the message and out of what set of >> values it needs to come, but it cannot tell you what the specific values >> mean in the real world or what cheese firmness is in the first place on a >> semantic level.) >> >> >> But what about the semantic definition (which is in YANG modules) of this >> information? This is key for management. >> I guess that the next item you'll want after this milestone is exactly >> data models and semantic, right? >> >> There are many schemas for IoT and I'm not trying to impose YANG in the >> IoT world but I want to understand why we need duplication. >> Note that there was an IAB-organized workshop on IoT data modeling in the >> past (https://www.iab.org/activities/workshops/iotsi/) >> However, it seems to me that your effort is exactly the reverse of data >> modeling driven management? You have an encoding, and then you want a new >> schema language > Yes, the same way there are several schema languages for XML (for > example). > >> Next, you'll need a mechanism to discover what is available on the >> managed devices, a mechanism to know the device capabilities, a mechanism >> for pub/sub, ... >> And you will redo the full OPS stack, for IoT (hence duplication). And, >> obviously, in the end, we will need a mapping between the two data >> modeling languages: YANG and CDDL. > I am not convinced that the mapping would be needed in all cases. See > below. > >> What is specific here? I wanted to write: what's specific to IoT here, >> but I don't even see IoT in the charter. There is just a kind of IoT >> reference in RFC7049 abstract. >> Why do we need this duplication within the IETF? > I don't think saying that CBOR is only for IoT is helpful. There is some > talk about using it for PKIX-like things. I can also see it being used > directly in protocols. There is no YANG there, because there are no > devices to manage, just a data structure. I don't think YANG is going to > be helpful there. > > I am Ok with having some text in CDDL saying that if you want to do > modeling-driven device management, CDDL is not the right tool. But as I > said above I see other uses for CBOR/CDDL, which should be allowed. > >> Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work? >> Those are completely inline with data modeling-driven management and this >> charter seems to contradict this effort? >> What do I miss? > . > --------------99DB7832D628234B083620E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks to all who educated me, in the different email threads.

Moving back to a COMMENT at this point in time.
As Alexey mentioned, some more wording about this in the charter would help (if nobody else, at least me):
I am Ok with having some text in CDDL saying that if you want to do
modeling-driven device management, CDDL is not the right tool. But as I
said above I see other uses for CBOR/CDDL, which should be allowed.
In the end, I missed the key message that CDDL is more helpful for horizontal protocol to support device-to-device communication, as opposed to a management protocol. I've been probably too biased by my OPS background :-)

Regards, Benoit 

Hi Benoit,

On Mon, Dec 19, 2016, at 12:48 PM, Benoit Claise wrote:

Benoit Claise has entered the following ballot position for
charter-ietf-cbor-00-04: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-cbor/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Sorry for this late BLOCK.
I had a very quick call with Alexey before the last IESG telechat: I want
to understand if I missed anything.
I filed a quick "NO RECORD" COMMENT.
Then, we discussed some more during the telechat itself.
And now, I finally had the time to think some more about this.

My BLOCK is about this charter paragraph:

    Similar to the way ABNF (RFC 5234/7405) can be used to describe the
set of valid messages in a text representation, it would be useful if
protocol specifications could use a description format for the data in
CBOR-encoded messages. The CBOR data definition language (CDDL, based on
draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a
description technique that has already been used in CORE, ANIMA, CDNI,
and efforts outside the IETF. The CBOR WG will complete the development
of this specification by creating an Informational or Standards Track
RFC.


In OPS, we need automation. And automation will come from data models as,
from data models, we're able to generate APIs.
In the world of data modeling-driven management, we have:
    YANG as a data modeling language, with ABNF specifications
    YANG data modules, written with the YANG data modeling language
    different encodings, such as XML, JSON, or CBOR
(draft-ietf-core-yang-cbor-03)
    protocols such as NETCONF or RESTCONF for
configuration/monitoring/capabilities discovery
    note: working on pub/sub protocol (aka telemetry) for events

See the first picture at
http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/
Btw, I should add cbor.

Now, in this proposed WG, you want to define a new data modeling
language, "The CBOR data definition language"
When I ask the question: So the structure of what could be accessed on a
managed device?, you answer:

    No. While CDDL could be used to describe the structure of data at
rest (a data store), that is not the objective. CDDL is used to define
the structure of data in flight, e.g. a protocol message going from a
node to a different node. (Using a term popular in semantic
interoperability work in the health care domain, CDDL is about
"structural interoperability” — it can tell you that there is supposed to
be a data item “cheese-firmness” in the message and out of what set of
values it needs to come, but it cannot tell you what the specific values
mean in the real world or what cheese firmness is in the first place on a
semantic level.) 


But what about the semantic definition (which is in YANG modules) of this
information? This is key for management.
I guess that the next item you'll want after this milestone is exactly
data models and semantic, right?

There are many schemas for IoT and I'm not trying to impose YANG in the
IoT world but I want to understand why we need duplication.
Note that there was an IAB-organized workshop on IoT data modeling in the
past (https://www.iab.org/activities/workshops/iotsi/)
However, it seems to me that your effort is exactly the reverse of data
modeling driven management? You have an encoding, and then you want a new
schema language

Yes, the same way there are several schema languages for XML (for
example).


Next, you'll need a mechanism to discover what is available on the
managed devices, a mechanism to know the device capabilities, a mechanism
for pub/sub, ...
And you will redo the full OPS stack, for IoT (hence duplication). And,
obviously, in the end, we will need a mapping between the two data
modeling languages: YANG and CDDL.

I am not convinced that the mapping would be needed in all cases. See
below.


What is specific here?  I wanted to write: what's specific to IoT here,
but I don't even see IoT in the charter. There is just a kind of IoT
reference in RFC7049 abstract.
Why do we need this duplication within the IETF?

I don't think saying that CBOR is only for IoT is helpful. There is some
talk about using it for PKIX-like things. I can also see it being used
directly in protocols. There is no YANG there, because there are no
devices to manage, just a data structure. I don't think YANG is going to
be helpful there.

I am Ok with having some text in CDDL saying that if you want to do
modeling-driven device management, CDDL is not the right tool. But as I
said above I see other uses for CBOR/CDDL, which should be allowed.


Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work?
Those are completely inline with data modeling-driven management and this
charter seems to contradict this effort?
What do I miss?

.

--------------99DB7832D628234B083620E9-- From nobody Fri Dec 23 07:02:37 2016 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD80F1295A5; Fri, 23 Dec 2016 07:02:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148250535274.16802.7859646663699558560.idtracker@ietfa.amsl.com> Date: Fri, 23 Dec 2016 07:02:32 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Benoit Claise's No Objection on charter-ietf-cbor-00-04: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 15:02:33 -0000 Benoit Claise has entered the following ballot position for charter-ietf-cbor-00-04: No Objection 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to all who educated me, in the different email threads. - Moving back to a COMMENT at this point in time. As Alexey mentioned, some more wording about this in the charter would help (if nobody else, at least me): I am Ok with having some text in CDDL saying that if you want to do modeling-driven device management, CDDL is not the right tool. But as I said above I see other uses for CBOR/CDDL, which should be allowed. In the end, I missed the key message that CDDL is more helpful for horizontal protocol to support device-to-device communication, as opposed to a management protocol. I've been probably too biased by my OPS background :-) OLD: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model NEW: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model Note: - In OPS, we make a clear distinction between the (YANG) data model, and the encoding (XML, JSON, etc.) - RFC 7159 mentions "data interchange format" in his abstract - I see in RFC 7049: The format defined here follows some specific design goals that are not well met by current formats. The underlying data model is an extended version of the JSON data model [RFC4627]. This is a mistake. Great we will have a new charter to accomplish this work - And don't forget the milestones. Regards, Benoit