Re: [core] Comments on draft-ietf-core-yang-cbor-06

Michel Veillette <Michel.Veillette@trilliant.com> Mon, 09 July 2018 15:18 UTC

Return-Path: <Michel.Veillette@trilliant.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE0E130E23; Mon, 9 Jul 2018 08:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.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 HfqJJ_j_53DQ; Mon, 9 Jul 2018 08:18:10 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EF612F295; Mon, 9 Jul 2018 08:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q2AtKxiF+NuIqqNh8CJLXODTYo+YV7S833HqSRfk8Jc=; b=WrcY07v8lyUkgdhlw5yoAKtb3NQF4+FGcmgW/jTSqb69OA9VigH/HdZbfwOsbfQiYw1hsnutgJ4leTnl2gOgKqQEnbXSiJkRmYX0RzgKWgEvMDTo0qsz1DqYqJ4sUsJkMhArVMJbCCihHgIphuXTeZMPl35PmAVNN77hnHrlpEo=
Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2715.namprd06.prod.outlook.com (10.168.199.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Mon, 9 Jul 2018 15:18:09 +0000
Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300%5]) with mapi id 15.20.0930.022; Mon, 9 Jul 2018 15:18:09 +0000
From: Michel Veillette <Michel.Veillette@trilliant.com>
To: Robert Wilton <rwilton@cisco.com>, "draft-ietf-core-yang-cbor@ietf.org" <draft-ietf-core-yang-cbor@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Comments on draft-ietf-core-yang-cbor-06
Thread-Index: AQHUF5WX0PmR6lU92EO3Kbe/Vd91WaSG/U6Q
Date: Mon, 09 Jul 2018 15:18:08 +0000
Message-ID: <DM5PR06MB2777C2ABB330D1054D2E1D8D9A440@DM5PR06MB2777.namprd06.prod.outlook.com>
References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com>
In-Reply-To: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com;
x-originating-ip: [207.96.192.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR06MB2715; 7:5HConIXh8pHll/AkUjn4hal6bAEshAyGxT7GgyIChBQrMpvWfwKBC4XAIilHU19tVVsWnYgJQSjybUnv8Wu1VX1IiBBUa84A4aXHuBehC9si7hI35qim6BRjc39fq0J2/QlxuuY+bGyJETPi5nRy/1rZC8yAXqkkhbQSJyn5iTDtLl9BwCtfp6hv+2gfuwcmemr+OBCBm6snKJAKIO8HdKBf52zLRNioOYEwihEC5o5qfYxDDz6zt+YNoUvh2gNr
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 5fafa327-df2e-446c-0b1d-08d5e5af2da2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2715;
x-ms-traffictypediagnostic: DM5PR06MB2715:
x-microsoft-antispam-prvs: <DM5PR06MB271530B61DC68D4E4E49CB929A440@DM5PR06MB2715.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(95692535739014)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB2715; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2715;
x-forefront-prvs: 07283408BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39850400004)(396003)(376002)(346002)(51444003)(199004)(189003)(99286004)(81156014)(476003)(110136005)(66066001)(6506007)(486006)(81166006)(14444005)(256004)(86362001)(3846002)(53546011)(6116002)(790700001)(8676002)(446003)(97736004)(8936002)(102836004)(26005)(2501003)(5250100002)(316002)(186003)(105586002)(11346002)(2201001)(7736002)(74316002)(25786009)(7696005)(478600001)(55016002)(72206003)(6306002)(5660300001)(9686003)(2906002)(68736007)(54896002)(14454004)(6436002)(106356001)(2900100001)(6246003)(76176011)(53936002)(229853002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2715; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: d5Pb4rWnL+c+HWwX4v0IE8Thzru1Wup8aTfwkU97lwvXLf6yNK17xUdYuNU8gdoxyY02b9tWnpnS+4XRvPYKq281UgemCqNXr35oXy+hJvoVdR6vd/SuIGZJ3JPx9cItoj7qzZjwxukavF9emmtIStmwJCODJ+cShfFzTblQlSYrn332drFzdUF/rZzmd/WstwO08yy99PJDwVnheEQ67jIcbtLjqQXT/CxlG7yJP2l4gfjWquA92Liy40kkSWCk+cwYhWgUGioYq1yfMoXoZRhYn7eLRHUOfodm1ZfAmrDyNTovvmRVDcBQmUKgyleb1N4cHcet7oKumpN1vQdGyAJ+xb9VIMMbEUXURotoAPM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR06MB2777C2ABB330D1054D2E1D8D9A440DM5PR06MB2777namp_"
MIME-Version: 1.0
X-OriginatorOrg: Trilliant.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5fafa327-df2e-446c-0b1d-08d5e5af2da2
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 15:18:08.9175 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2715
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tYi-iPAkqkzK9Wvn_xYNWRNQWpY>
Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 15:18:15 -0000

Hi Robert

Andy also asked for a clarification about the encoding of the root data node identifier (absolute vs. delta).
Section 4.4.1. have a sentence addressing this topic.
   It is important to note that the protocol or method
   using this mapping may carry a parent SID or may have the knowledge
   of this parent SID based on its context.  In these cases, delta
   encoding can be performed based on this parent SID which minimizes
   the size of the encoded data.

A similar sentence need to be added to section 4.2.1.
We also need to clarify that the protocol or method using this encoding must mandate which approach is implemented, the data serialized don’t carry this information.

Regards,
Michel

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Monday, July 9, 2018 11:00 AM
To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org
Subject: Comments on draft-ietf-core-yang-cbor-06


Hi,

I've read this draft, and think that it is well written.

There is one area of the draft that is somewhat unclear to me when using SID encodings:  Is the root node(s) of a request or a response always an absolute SID value, or could it still be a delta?

In particular:

Sec 2.1 indicates that the translation to/from SID deltas is stateless, which implies to me that the root node(s) of a request/response would always be an absolute SID value.

Sec 4.2.1 gives an example using a absolute SID for the top node.  It then has this text: "

   On the other hand, if the serializer is aware of the parent SID, 1716

   in the case 'system-state' container, root data nodes are encoded

   using deltas.
"

I think that it is quite plausible that the serializer may know the SIDs for all nodes in the data tree, which the text implies it could then use a relative SID for the top node.  Particularly, if the top level node was explicit from the request.

Hence, I think that this draft could probably benefit in being more explicit on exactly when a top level node uses an absolute SID, and in what scenarios it may end up using a a relative SID.  If this distinction is down to the protocol being used, then perhaps that could be stated?

One other nit:

Section 4.4.1 says "delta encoding can be performed", but I think that this should probably be "delta encoding MUST be performed".
Thanks,
Rob