[core] comments on draft-ietf-core-yang-cbor-07.txt

Andy Bierman <andy@yumaworks.com> Sun, 16 September 2018 18:56 UTC

Return-Path: <andy@yumaworks.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 53D8F130DCE for <core@ietfa.amsl.com>; Sun, 16 Sep 2018 11:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 GFXG4odGZJuL for <core@ietfa.amsl.com>; Sun, 16 Sep 2018 11:56:15 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 D65A8130DC4 for <core@ietf.org>; Sun, 16 Sep 2018 11:56:14 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id f8-v6so11323891ljk.1 for <core@ietf.org>; Sun, 16 Sep 2018 11:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=5JBAOSbWz5g47HqvJT1uOM/iuaAUhXJh3vPkDBGwlFo=; b=X6Ye4KnusG7jdg2NKvC+MGcI7aOY2lTkZVJ0g9HUb9Ts11JiT+Ee9f5LKnV2wE+yID awy61GYljYKomiSHB2F4cZpBfVqrQTxpeqI7xu9fewOw0KJCD+5vSx39XP/c5+d0AeHr bRegdytPguR/9RezNIyr5U+/r91z8laF6NyBrxb9PJwnGwmC+CgwboaxRvqddbkt1Om+ pI/58uBacrTlk0nPv6GOthaPLPlrtNW88tA9P/38rEV4YxxokVEeuG4DatWZPXbVor/D BEr7576x69TYWyBgOv/A8h8z3fczpl2RlBxpTXepyxwinaw0oVU6TF6frHiG37Hh9GAR emBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5JBAOSbWz5g47HqvJT1uOM/iuaAUhXJh3vPkDBGwlFo=; b=OifT46UR00Qn2UsmV441UJ196yRUDkqA3eN5Mztv6tkiy0VA0c+5KRIg3XJEdsNgvA 6k4OmIHZlH/PAmL9v+3Smh+KGqO6iscgUnz8nzQu0VuJ+OceaXWI0G8wGhbefSI59Ldy scgAFsL9eONO45YYsMRgqaQrvKJuchaIVeweu4quo9ojCGGzmCEAQfQvwDhvVUw4XA2V onLuw8/rNnV52kWQIHVt3KmymC/B0IcE9wW+wAXvXxmZuceYl7OYUkqYS+oMleW7d384 sSSw0HTK3+ywr5G8VTmcAtGRChew/fjiy1ePwtCpWK9h9AFVECtBj03RYZTiCey0xtH7 suGw==
X-Gm-Message-State: APzg51AsnbWt8qkIZmMj907QTdgzOv62lGy8RG9JSAOfBEFznqxnrVz/ bSfVXkt8ZB7iUq/n+yBfsiMZ1NPyRmNs67YfC2W5nSDf0sY=
X-Google-Smtp-Source: ANB0VdaKK2lsMy6MPsZ4em1oSeWiqiBc2YPzsbtZsBQFF+rjvLarc3noB9h8wGWWW4wrad14gScqvwXJt8Y/wkRoIi8=
X-Received: by 2002:a2e:5687:: with SMTP id k7-v6mr12458132lje.105.1537124172510; Sun, 16 Sep 2018 11:56:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:6a19:0:0:0:0:0 with HTTP; Sun, 16 Sep 2018 11:56:11 -0700 (PDT)
From: Andy Bierman <andy@yumaworks.com>
Date: Sun, 16 Sep 2018 11:56:11 -0700
Message-ID: <CABCOCHRLmi1VYnFefWOu_5G1zsQ2AjSTeKj8y6qxQJW-rwUi5A@mail.gmail.com>
To: Core <core@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004747810576019cad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/m8FMCl2J3Irc1_CLITQXrE3u-L4>
Subject: [core] comments on draft-ietf-core-yang-cbor-07.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 16 Sep 2018 18:56:17 -0000

Hi,

I have a few comments on the YANG to CBOR draft.
In general it is very close to being complete.


1) RFC 7951 references

   The following terms are defined in [RFC7951]:

   o  member name

   o  name of an identity


Actually, RFC 7951 does not define these terms. It says RFC 5234 defines
the member-name
syntax,. IMO, this term should really be linked an 'identifier' as defined
in RFC 7950.
Each datadef-stmt has its own specific definition, e.g. container:
https://tools.ietf.org/html/rfc7950#section-7.5

The mapping should be defined directly from YANG to CBOR, as the draft name
suggests.

2) sec 4.5 anydata

The text should mention that SID encoding is not possible since child nodes
of an anydata do not exist in the schema.

The example seems to be wrong. It does not have the member-names
port-name and port-fault in the notation.

3) sec. 4.6 anyxml

The actual usage of anyxml is really as a container, same as anydata,
so the example is confusing. This should be encoded the same as anydata
if possible.

Not sure why the 2nd sentence is there:

sec 4.6, para 1:

   An anyxml schema node is used to serialize an arbitrary CBOR content,
   i.e., its value can be any CBOR binary object. anyxml value MAY
   contain CBOR data items tagged with one of the tag listed in
   Section 8.1, these tags shall be supported.

If this is a binary object then how can it have nested data nodes with data
types?
I suggest that anyxml can be treated as anydata if it does not contain any
mixed-mode content or processing instructions.

NEW:

   An anyxml schema node is used to serialize an arbitrary CBOR content,
   i.e., its value can be any CBOR binary object. If the anyxml instance
   data contains only YANG data nodes, then it MAY be encoded the same
   as an anydata object.



Andy