[core] Comments on draft-ietf-core-yang-cbor-00

Andy Bierman <andy@yumaworks.com> Mon, 16 May 2016 23:13 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 03A9C12DB06 for <core@ietfa.amsl.com>; Mon, 16 May 2016 16:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_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=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 d2a_E1wPvLvD for <core@ietfa.amsl.com>; Mon, 16 May 2016 16:13:21 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 BB8D812DAE4 for <core@ietf.org>; Mon, 16 May 2016 16:13:20 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id x189so26336781ywe.3 for <core@ietf.org>; Mon, 16 May 2016 16:13:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=xwSHqXv4IsvfPsqrDTHoePYYOrGd0flQ1XKj38DCg84=; b=kSkKjpNOjH2O1w6sbQKlp2RgQtCJ8cyQVB0rJ8mi/bMhGa4tUWtWnh4oP6dw768Rgb 0fwU2VEYO64PZom7yLPkK3G/7CW0S70DYDpsCCdn/Q2+zUInadE4JQrU4psqr9OL/R8v ID+FrXEHwTlLT+NIxqWLD9Hu3NF4Z8qYxFVoaQq1BvF9suy5EQ6XAh09Uwg+VXg8qHzY DaYr+501frLWH7Uackje2cilLVV4P0ROwMt+kq63ivc9KU/D7L0br6WVsx3pO5VSqCxY dZnwicV4dokZBscL6tZMFG0b3f6jnESIl/DYazcbjOT7U7YrJHZGOehhrffcJSS40iw7 bJiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=xwSHqXv4IsvfPsqrDTHoePYYOrGd0flQ1XKj38DCg84=; b=VJDXkFVTq3P2jJaINL8l7UoqN5WtZR8eJ4+nsGgtxHtOCKTJUMPlVMnjWKOQN/UuVd ThJlGSVv9sMwHzhBz2TWz7cngV/5UxwF4zmdkpreehbWfq2U1rv//JeXIHOd8nLuwsvu VEetCRBY9bkTnKq7TYBK4mQljutG1L0ya+Utk/xryD4GRvbgLi5Yncw7OcFMtI0P6sRC fFelZzQJ8jTndNTFMXKrUH7GGbUF5O2fLgSYsMgZNMCRijMVoypraDUU9SJqvDr86Jb7 1UFJ8okHuBX22dV/ZytskneUhKbSCRJbgv2l8eX701TcVhavR8mW7e5reoqcVcu3QcEa oUnQ==
X-Gm-Message-State: AOPr4FXqkMuZY2VI6t7qGw98ACTDdc+bLZ/Q8HhuEuZ9PVVcqtA0ojqxcPcJY+JwoYNhFfJFAucjc05PMNJW3A==
MIME-Version: 1.0
X-Received: by 10.37.17.135 with SMTP id 129mr15714799ybr.170.1463440399959; Mon, 16 May 2016 16:13:19 -0700 (PDT)
Received: by 10.37.44.130 with HTTP; Mon, 16 May 2016 16:13:19 -0700 (PDT)
Date: Mon, 16 May 2016 16:13:19 -0700
Message-ID: <CABCOCHRRACvVXx2S_hZm2TxbvP48aO4Q4REkh0LFjmHkMkZ1Vg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Core <core@ietf.org>
Content-Type: multipart/alternative; boundary=001a113e6ef630cb410532fdc53b
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4>
Subject: [core] Comments on draft-ietf-core-yang-cbor-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 23:13:23 -0000

Hi,

Here are my comments on the YANG to CBOR draft


Andy


-------------------------------------------

sec. 3: para 4:

   The end user of this mapping specification
   can mandate the use of a specific key type or a specific subset of
   key types.

C1)  How does the end-user do this?


-----------------------------------------

4.2.  The "container" Schema Node

   Collections such as containers, list instances, notifications, RPC
   inputs, RPC outputs, action inputs and action outputs MUST be encoded
   using a CBOR map data item (major type 5).  A map is comprised of
   pairs of data items, with each data item consisting of a key and a
   value.

C2) Add a comment that "key" refers to the child node identifier
and value refers the the value of the child node. It does not
refer to the YANG term "key".


----------------------------------------
sec 4.2:

   *SIDs as keys*

   Keys implemented using SIDs MUST be encoded using a CBOR unsigned
   integer (major type 0)

  2nd bullet:
    Delta values may result in a negative number, clients and servers
      MUST support negative deltas.

C3) Doesn't 2nd bullet require CBOR type 1?

Summary: KEY ENCODING (3 variants):
   SID:     Major type 0 or 1
   string:  Major type 3
   hash:    Major type 2

--------------------------------------------

5.3.  The "decimal64" Type

   Leafs of type decimal64 MUST be encoded using either CBOR unsigned
   integer (major type 0) or CBOR signed integer (major type 1),
   depending on the actual value.  The position of the decimal point is
   defined by the fraction-digits YANG statement and is not available in
   the CBOR encoding.

C4) How are decimal64 values that start with zero encoded?

   leaf foo {
     type decimal64 {
       fraction-digits 3;
     }
     default 0.005;
   }

C5) You probably mean to convert the deciaml64 to a signed
or unsigned integer:

   1.005 == 1005

Then it is up to the decoder to know the YANG schema so it
can adjust based on the fraction-digits value.

---------------------------------------------------

5.6.  The "enumeration" Type

   Leafs of type enumeration MUST be encoded using a CBOR unsigned
   integer data item (major type 0).

C6) Need to say that the implicit or explicit value-stmt value
is used, not the enumeration name like in XML or JSON

C7) Enumeration value is allowed to be negative, so major type 1 also
allowed


------------------------------------------------------

5.7.  The "bits" Type

   Leafs of type bits MUST be encoded using a CBOR byte string data item
   (major type 2).

C8) Need to say that the implicit or explicit position-stmt value
is used, not the bit name like in XML or JSON


------------------------------------------------------

5.8.  The "binary" Type

   Leafs of type binary MUST be encoded using a CBOR byte string data
   item (major type 2).

C9) What string format is used? base64? raw UTF-8?

------------------------------------------------------

5.12.  The "union" Type

   Leafs of type union MUST be encoded using the rules associated with
   one of the types listed.

C10) This does not really work because so many YANG types use
the same CBOR major encoding

   type union {
      type int32;
      type enumeration {
        enum A { value -5; }
        enum B { value 3; }
      }
      type bits {
        bit X { position 1; }
        bit Y { position 3; }
      }
      type decimal64 {
        fraction-digits 2;
      }
   }

How do I know if '3' is for int32, enum B or bit Y?
How do I know 103 is really decimal64 "1.03" and not
an int32 "103"?

C11)  Need to specify that types are evaluated in YANG
statement order (e.g., check int32, then enumeration, then bits)


--------------------------------------------------------

sec. 5.13, para 5

   When SIDs identify a YANG list, the presence of the key(s) for this
   list is optional.  When the key(s) are present, the targeted instance
   within this list is selected.  When the key(s) are absent, the entire
   YANG list is selected.

C12) A YANG instance-identifier MUST identify exactly 1 instance.
It cannot specify all instances of a YANG list.

C13) If instance-identifier used in a union, no way to tell that
SID, name, or hash encoding is really an instance-identifier
and not a string or a number.

C14) How are the keys specified?  The CoMI draft specifies a URI encoding
but nothing in CBOR. Seems like they would have to be a separate string
(keys=A,14,fred).  Examples (e.g. for SID) using an array are not clear.

-----------------------------------------------------------

Attributes:

C15) XML and YANG/JSON allow meta-data to be sent with
the YANG data.  (e.g. NETCONF "operation" or "default" attributes)
How would meta-data be encoded in CBOR?

-----------------------------------------------------------

YANG List Keys:

C16) XML and YANG/JSON require YANG list keys to be encoded first
even if they are not defined first in the list.  This allows server
code to dispatch or do entry lookup without requiring buffering.
Should CBOR encoding of YANG lists require the same?