Re: [core] js review of draft-ietf-core-yang-cbor-12

Juergen Schoenwaelder <> Tue, 07 April 2020 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF7813A098D; Tue, 7 Apr 2020 12:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yBhxkC5DJJ3U; Tue, 7 Apr 2020 12:48:03 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe1f::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7D3A3A096E; Tue, 7 Apr 2020 12:48:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=ORFcECd+mEv6fJu3dBbZiPXvv2vvPTYiovgKOewt/fVmtn/M4RZOVklAjHLg+77toeYukcQq/7L4weDNUT3t21wwe2vhW1xA5OW6u2ry1NWFQpmiiU67BnOs/jZjelItV/9WVnHr02hGMbbhC9fHF/zWaWdI4JPI4Or+Cc8wagDjCrIy4dN22HlJGQ2UaxCHi7NIecSVV7myaUeV0blZ97e9q7oN+g7l2gC9rPYnGEgqV/6RL2608UqdQpFfSrcv4fd6dHVXS9ADlq8Tzn78IMaAor1+VTNpdiZ1kS8AqZJElsLCA/Nt3CdkC0lpQCjxzrtqW+NXfMRmEW+BivvH6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tAIMTTc8MpftKPyNhnlzw6zNRbCAgtmJCi9R5wuc+Vo=; b=ID6pDRu/kusCyIvwmuNMawP0Y7i71OOXS6B5Rg5H440eedNcRqzdDXBL6JmrR3yY1ZxnU+nx68ofgTpp55y9RJ2QXD2kkbx2RXOHbe573Oe6ott4uirf+J9Es9AIq40sqEmBBNoTHHwIm0OoYITf9pgJ+Yp16bzcs9XZBPFnNmxtGlrp9qKO919aqiepDKuEW3NAl7xxemdbXJtICQilBmR3R8181Y5hIZj278x5dwlMYqDoX135MVn03YBSgAhwiCUJanb2mLFqUhZ8urFsPNqDrppSuS0IeGmjYlUbgKD40N8HjMD5CAG9FyEEmZ9ULi0LE0RSRbDzQHo8T0VBXA==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tAIMTTc8MpftKPyNhnlzw6zNRbCAgtmJCi9R5wuc+Vo=; b=NlMCcxlIMPkv5V01rY1D82KlGKUcXve7mwoYJE1h3IVTJVrY/dgVZoCL3fgVJtneYBPUCn5hHtBK8A5KXh44rEWBhNzSPcnT55HbAiww2R4jq3wsrDIlc5NOJPNYwN7/K3nzYDrIo2CyRvvaosheHlXPDS4W0zIuj56dWjJBVDc=
Authentication-Results: spf=none (sender IP is );
Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ( by AM0P190MB0770.EURP190.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 19:48:00 +0000
Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440%8]) with mapi id 15.20.2878.021; Tue, 7 Apr 2020 19:47:59 +0000
Date: Tue, 07 Apr 2020 21:47:58 +0200
From: Juergen Schoenwaelder <>
To: Ivaylo Petrov <>
Cc: core <>,
Message-ID: <>
Reply-To: Juergen Schoenwaelder <>
Mail-Followup-To: Ivaylo Petrov <>, core <>,
References: <> <>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-ClientProxiedBy: FR2P281CA0027.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::14) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (2001:638:709:5::7) by FR2P281CA0027.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Tue, 7 Apr 2020 19:47:59 +0000
X-Originating-IP: [2001:638:709:5::7]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9ba87a87-4f01-4105-9326-08d7db2c936c
X-MS-TrafficTypeDiagnostic: AM0P190MB0770:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM0P190MB07709A0DEBBEFFC2C69423D2DEC30@AM0P190MB0770.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 036614DD9C
X-Forefront-Antispam-Report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(39850400004)(136003)(376002)(396003)(366004)(346002)(6486002)(52116002)(66946007)(6496006)(66476007)(786003)(81156014)(66556008)(8676002)(2906002)(3450700001)(316002)(8936002)(3716004)(1076003)(81166006)(86362001)(186003)(478600001)(4326008)(6916009)(16526019)(5660300002); DIR:OUT; SFP:1101;
Received-SPF: None ( does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: AnGCq2bgIVEMmvQmIUS3S90IDadL8izRVcq+cJg+vM7jSQw129NV8eF14sSperWrztJ0GM5ODyvrtJpYAyo9+jpHskixusO9sYq5XZg5D2qsru1HxKpsxXRJRHxzTUgEsXSZP5RzyXAoOmkVsbalMMNS80ZfNnbgf1ipVAfaQYRuqw/KYAJERqaum4F2NLoKV1loMl9bZGzgE2fF1UMWRZ8q5PPHsHdyAjMerFyKIyyyJWH+Rg9Jstkt5IjjFuqwW4NtMZxz611nr1/IkGGgFvVBweoJTATPG3lsy0SYQFg3m/JDXoVqAi047SvjaGSlI/hN3V/Phl6uMxGGwWDRBg/atLl1kJ88G53b5qiD5MQ8Gzqi7NMOwXlYr0F8jGlW0ypErca3H71+IiDIsLqzEbUZV5Qnaumwo6nWH5w59mxjQQADcE1k1812WnwImMzMjpfUCmIrjRkn1JIETvkLsrtGffRYlRYuHWRbs/RfqMMEPbdyhMhc6qZA7eLPRcPeyQmiOGpoxdCb8HQUTMQS5w==
X-MS-Exchange-AntiSpam-MessageData: gm+kFDoNSwzlUPB5n8Pq3n1VWw28Nle0qw/W5AyBFXVOImb/LSwpKwYXvq8CtSWbLotvCJCuowKUI4/AjuIaj8EoXalnvZJQBphEnCIhBs4xQZvg6YIy0/DFVWFVOUvIuzEF7pU4tOMUaKEnRGpFe5P+29Zs8o1r4gSuz4DzqB8=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ba87a87-4f01-4105-9326-08d7db2c936c
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 19:47:59.6177 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: EmGtbNluDXub7tZM393mQovH6HHox9i9KkmdBfySFnCBvyuRLH2HSXpCcbbyn3KIfrUcfP4DzYZPz0HDzpK37ZvFw0Yq0ahoNu747Hzyj58=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0770
Archived-At: <>
Subject: Re: [core] js review of draft-ietf-core-yang-cbor-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Apr 2020 19:48:06 -0000

Dear Ivaylo,

thanks for your item-by-item response. I will cut things down to the
few items I felt I still want to comment on (everything else I
consider resolved).

On Tue, Apr 07, 2020 at 03:35:37PM +0200, Ivaylo Petrov wrote:
> > - Is there a reason why SID terminology is not imported from the SID
> >   specification? Is the reason to avoid a dependency? But then, can
> >   this dependency really be avoided? I reviewed the SID document first
> >   because I thought knowing what SIDs are is essential to understand
> >   this document...
> >
> [IP]: This decision has been made before my personal involvement with this
> document. I will let the other authors correct me if I am mistaken, but my
> understanding is that while it is a good candidate, we did not necessarily
> want to mandate the use of the SID draft in order to use the yang-cbor
> draft. If the implementers want to have another way of deriving meaning for
> the SIDs, that is fine. I will have to verify if the interoperability in
> this case was a concern and how it was supposed to be handled.

For me, the question is whether this ID defines SIDs and the other ID
details how they are managed or this ID imports the definition of SIDs
from the other document, which also details how they are managed.
Right now, it seem something in between, i.e., it is not clear what
the dependencies between these specifications is.
> > - To summarize the last few comments, I propose to import 'item' and
> >   'SID' from the SID document, to not define 'child' and 'parent'
> >   (following RFC 7950), and so the only term to defined here is
> >   'delta'. But see above concerning the relationship to the SID
> >   document; it is not clear to me what the goals and intentions are in
> >   terms of intended document dependencies.
> >
> [IP]: I believe that my previous points provide the relevant answers, but do
> not hesitate to let us know if you have more concerns about any of your
> remarks.

Your solution kind of works for me. Note that here is one usage of
'collection' left in section 4.4.
> - I do not understand this statement:
> >
> >    Application payloads carrying a value serialized using the rules
> >    defined by this specification (e.g.  CoAP Content-Format) SHOULD
> >    include the identifier (e.g.  SID, namespace qualified name,
> >    instance-identifier) of this value.
> >
> >   What is "the identifier of this value"? I am not getting what
> >   is being conveyed here.
> [IP]: I rewrote this as
> When schema node are serialized using the rules defined by this
> specification as part of an application payload, the payload SHOULD include
> information that would allow a stateless way to identify each node, such as
> the SID number associated with each node, SID delta from another SID in the
> application payload, the namespace qualified name or the
> instance-identifier.
> Please let us know if that is more clear.

This is better, but I am still not sure what exactly this SHOULD is
about. The SIDs in the payload are assumed to be unique and so are
names and paths. So what is the requirement for an 'application
payload' that uses this serialization format?

(nit: first noun should be plural)
> - SIDs other than [I-D.ietf-core-sid]?
> >
> >      [...] If SIDs are to be used, the present specification is
> >      used in conjunction with a specification defining this management.
> >      One example for such a specification is [I-D.ietf-core-sid].
> >
> >   This seems to indicate that there can be other kinds of SIDs or SIDs
> >   managed differently. Why is this? The SID I-D claims the entire
> >   number space, so how would a different 'specification defining the
> >   management of SIDs' ever work? Why not be specific that the usage of
> >   SIDs depends on [I-D.ietf-core-sid]? See my earlier comments about
> >   the unclear dependency relationship between this specification and
> >   the SID specification.
> >
> [IP]: My understanding is that indeed there is the presumption that other
> implementations that map YANG item identifiers to unsigned numbers could
> exist in the future. If this is the case, I am not aware how one could
> interoperate (I would guess based on the content format), but I will let my
> coauthors comment on that.

Such a different mapping would most likely have to use separate SID
allocations, i.e., a part of the number space may be managed
differently but the resulting number is still a SID. (Of course, the
whole idea sounds pretty scary in terms of interoperability.)


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>