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

[Andy Bierman <[e-mail]>]

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?