Subject: [core] YANG to CBOR mapping version 1

From: peter van der Stok <[email-masked]>
Date: Tue, 05 Jul 2016 11:50:39 +0200

Hi authors,

Attached my review of the document.
I have not looked at the enum, union encoding as this was done by Andy.

______________________________________________________________________________
YANG to CBOR
Section 1 line 2; remove “only”
Page 5; the table is referenced nowhere
End of section 2.1 “Deltas are represented as positive number” is 
contradicted in section 4.2 “SIDs as keys” second bullet: “Clients and 
servers MUST support negative deltas.
Suggestion: Deltas are represented as numbers preceded by a + or – sign
End page 5: “value need” -> “value needs”
Section 3: “the specification supports three types of keys.”
I would suggest only 2: character strings and numbers.
The use of deltas is either application (CoOL) specific or YANG to CBOR 
mapping specific.
If it is YANG to CBOR specific, I would encourage the use of another 
CBOR type that specifies a delta. As specified here its use is 
ambiguous; and forces each application to specify explicitly what is 
meant.
In the case that the delta is CoOL specific, I recommend to remove it 
completely from this draft, and explain the use of Deltas in the 
appropriate CoOL draft.
In the latter case: What remains are two key types: number and character 
string.
Last alinea of section 3: “entities generating” should that not be” 
agents (processes) generating”…
“The CoAP content-Format Option …. In the first place.”  I don’t 
understand this phrase.
Section 4.2 title:  ‘container” Schema Node. Is “CBOR map key” not a 
better title?
As suggested earlier: Reduce this to string (major type 3) and number 
(major type 0) keys.
I think that a large number of the CBOR encoding examples in section 4.2 
can be left out. They can be generated any time by an interested 
implementer; and now confuse the issues.
Section 4.4; the example is really complex; some explanation what this 
all illustrates would be welcome. Why is the use of choice necessary to 
understand the list encoding? The CBOR encoding can be removed. I 
suggest to first present the names example followed by the number 
example. The hash example is really not needed (see above).
Section 5: I need more explanation to relate the instance examples to 
the type definitions.
For example section 5.1; does the 1280 come from {mtu: 1280} ? Here we 
do need the CBOR encoding to see the relation between the type 
specification and the CBOR encoding.
Section 5.2 example illustrates major type 1? Not immediately clear 
unless you decode the CBOR.
Section 5.3; Start phrase got lost 3 lines lower.
In the example, where do I find in the CBOR encoding that the fraction 
is 2 digits?
Sections 5.4 - 5.8; see comments on section 5.1
Section 5.9 Here more text is needed to connect the complex YANG 
specification to “eth1” value.
Section 5.10; what is a name-space qualified form? In YANG-JSON it is 
defined but may need some repetition here.
Why is the subject SIDs as identityref* split in two parts? And again I 
find the CBOR encoding difficult to relate to the definition example.
Section 5.11
CBOR diagnostic is: {isrouter: [null]} ?
Section 5.13.
I don’t understand how this section relates to YANG to CBOR mapping. If 
the section refers to specifying an instance identifier in the request, 
I think it can be removed. The use of [key=value] as instance identifier 
is well explained in restconf draft. The use of numeric identifier is 
currently described in CoMI draft, and differently in CoOL draft. I 
propose to remove this section as it does not directly relate to CBOR 
encoding.

However, I am missing how to transport a given list instance with its 
key values in the CBOR encoding. Section 4.4 describes the encoding of a 
complete list not a subset of its instances.

_____________________________________________________________________________________________
Hope this helps,
Peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]

---

From: Michel Veillette <[email-masked]>
Date: Fri, 8 Jul 2016 23:00:16 +0000

Hi Peter

See answers inline [MV]

These changes will be submitted later today.

Regards,
Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Tuesday, July 5, 2016 5:51 AM
To: Core <[email-masked]>
Subject: [core] YANG to CBOR mapping version 1

Hi authors,

[MV] “only” removed

[MV] Adding to the text:
[MV] Table 1 below provides a summary of this notation.
[MV]
[MV] Adding after the table:
[MV] Table 1 : CBOR diagnostic notation summary

End of section 2.1 “Deltas are represented as positive number” is contradicted in section 4.2 “SIDs as keys” second bullet: “Clients and servers MUST support negative deltas.
Suggestion: Deltas are represented as numbers preceded by a + or – sign

[MV] Removing "or +123" in the first line of the table
[MV] Second note bellow the table is updated to:
[MV] •	Deltas are represented as numbers preceded by a + or – sign.
[MV] The use of the + sign for positive deltas represents an extension to
[MV] the CBOR diagnostic notation as defined by [RFC7049] section 6.

[MV] Fixed

Section 3: “the specification supports three types of keys.”
I would suggest only 2: character strings and numbers.
The use of deltas is either application (CoOL) specific or YANG to CBOR mapping specific.
If it is YANG to CBOR specific, I would encourage the use of another CBOR type that specifies a delta. As specified here its use is ambiguous; and forces each application to specify explicitly what is meant.
In the case that the delta is CoOL specific, I recommend to remove it completely from this draft, and explain the use of Deltas in the appropriate CoOL draft.
In the latter case: What remains are two key types: number and character string.

[MV] The use of delta to encode integer based keys (SIDs) is an integral part of the YANG to CBOR mapping.
[MV] This optimization is part of the encoding and independent of the application.
[MV] The document is updated to keep only 2 type of keys

[MV] Updating to "application entities" (for now)
[MV] I can't use "agent" because this encoding is implemented by both the manager (client) and the agent (server).
[MV] I also want to stay generic since this mapping is not necessary restricted network management

“The CoAP content-Format Option …. In the first place.”  I don’t understand this phrase.

[MV] Sentence removed
[MV] I also don’t understand the intent of this sentence within the context of this draft.

Section 4.2 title:  ‘container” Schema Node. Is “CBOR map key” not a better title?

[MV] Titles of this draft are aligned with https://www.ietf.org/id/draft-ietf-netmod-yang-json-10.txt 
[MV] I'm renaming all titles of section 4 to "Data Node" to keep this alignment.

As suggested earlier: Reduce this to string (major type 3) and number (major type 0) keys.

[MV] Done

I think that a large number of the CBOR encoding examples in section 4.2 can be left out.
They can be generated any time by an interested implementer; and now confuse the issues.

[MV] I received many questions about the final encoding and the number of bytes required.
[MV] If I remove these examples, I'm concern that I will receive even more of these questions.
[MV] I agree that these examples are useless for peoples with a good knowledge of CBOR
[MV] but seem very welcome from newcomers. 

Section 4.4; the example is really complex; some explanation what this all illustrates would be welcome.
Why is the use of choice necessary to understand the list encoding?

[MV] I'm trying to use real life examples, the server list is the simplest example of list I found in a RFC.
[MV] If I use an subset of the list, I can probably use the "interface" list from RFC 7223.
[MV] A suggestion will be welcome.

I suggest to first present the names example followed by the number example.

[MV] SIDs should be the prevalent naming used by this mapping.
[MV] For this reason, I prefer to show SIDs first.

Section 5: I need more explanation to relate the instance examples to the type definitions.
For example section 5.1; does the 1280 come from {mtu: 1280} ?
Here we do need the CBOR encoding to see the relation between the type specification and the CBOR encoding.

[MV] Adding is section 5.1:
[MV] The following example shows the encoding of leaf 'mtu' set to 1280 bytes.
[MV] Adding is section 5.2:
[MV] The following example shows the encoding of leaf ' timezone-utc-offset' set to -300 minutes.
[MV] Adding is section 5.3:
[MV] The following example shows the encoding of leaf 'my-decimal' set to 2.57 minutes.
[MV] Adding is section 5.4:
[MV] The following example shows the encoding of leaf 'name' set to "eth0".
[MV] Adding is section 5.5:
[MV] The following example shows the encoding of leaf 'enabled' set to 'true'.
[MV] Adding is section 5.6:
[MV] The following example shows the encoding of leaf 'oper-status' set to 'testing'.
[MV] Adding is section 5.7:
[MV] The following example shows the encoding of leaf 'mybits' with the 'disable-nagle' and '10-Mb-only' set.
[MV] Adding is section 5.8:
[MV] The following example shows the encoding of leaf 'aes128-key' set to the value 0x1f1ce6a3f42660d888d92a4d8030476e.
[MV] Adding is section 5.9:
[MV] The following example shows the encoding of leaf 'interface-state-ref' set to the value "eth1".
[MV] Adding is section 5.10:
[MV] The following following example shows the encoding of leaf 'type' set to the value 'ethernetCsmacd'.
[MV] Adding is section 5.11:
[MV] The following example shows the encoding of leaf 'is-router' when present.
[MV] Adding is section 5.12:
[MV] The following example shows the encoding of leaf 'ip-address' when set to "2001:db8:a0b:12f0::1".
[MV] Adding is section 5.13:
More added, see http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.html for final result
See https://github.com/core-wg/yang-cbor/commit/28f5dae04c20c13667b5749541f036d3dbdb4b43#diff-083fd5e71ffd63b12d8cd2854c3ad1bf for a diff

Section 5.2 example illustrates major type 1? Not immediately clear unless you decode the CBOR.

[MV] Should I add more text than the note already added. (This example shows the encoding of leaf ' timezone-utc-offset' set to -300 minutes.)
[MV] If so, do you have a sentence to propose?

[MV] Fixed

In the example, where do I find in the CBOR encoding that the fraction is 2 digits?

[MV] The number of digits is not encoded. This information is considered an unnecessary metadata
[MV] similar to "units", text of an enumeration, name of a flag within bits. This was the consensus
[MV] of the group which is aligned with the statement in section 3 (In order to minimize the size of
[MV] the encoded data, the proposed mapping avoid any unnecessary meta-information beyond
[MV] those natively supported by CBOR.)
[MV] It might be worth it to raise this topic within a larger audience. 

Sections 5.4 - 5.8; see comments on section 5.1 Section 5.9 Here more text is needed to connect the complex YANG specification to “eth1” value.

[MV] Done

Section 5.10; what is a name-space qualified form? In YANG-JSON it is defined but may need some repetition here.

[MV] Adding 'namespace-qualified' in the list of terms listed in section 2.
[MV] Adding "Names and namespaces are defined in [I-D.ietf-netmod-yang-json] section 4.".

Why is the subject SIDs as identityref* split in two parts?

[MV] The intent is to keep the name and SID example together.
[MV] Replacing the title in the example section to "Encoding example using name", "Encoding example using SID",

And again I find the CBOR encoding difficult to relate to the definition example.

Section 5.11

[MV] Yes, an empty datatype have no value
[MV] When present, it is set to 'null'.
[MV] draft-ietf-netmod-yang-json-10 implements the same approach.

Section 5.13.
I don’t understand how this section relates to YANG to CBOR mapping. If the section refers to specifying an instance identifier in the request, I think it can be removed. The use of [key=value] as instance identifier is well explained in restconf draft. The use of numeric identifier is currently described in CoMI draft, and differently in CoOL draft. I propose to remove this section as it does not directly relate to CBOR encoding.

[MV] An instance-identifier is a YANG datatype which need to be supported.
[MV] See example leaf 'error-path' in http://www.netconfcentral.org/modulereport/ietf-restconf
[MV] We simply reuse this YANG datatype in the CoAP methods to minimize overhaul complexity.

However, I am missing how to transport a given list instance with its key values in the CBOR encoding. Section 4.4 describes the encoding of a complete list not a subset of its instances.

[MV] A list instance is a collection which is described in section 4.2.
_____________________________________________________________________________________________
Hope this helps,
Peter

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Tue, 12 Jul 2016 11:58:14 +0200

Hi Michel,

I separated my answer into three parts to simplify the discussion.

> Section 5.3;

The following example shows the encoding of leaf 'my-decimal' set to
    2.57.

    Definition example from [RFC7317]:

    leaf my-decimal {
      type decimal64 {
        fraction-digits 2;
        range "1 .. 3.14 | 10 | 20..max";
      }
    }

    CBOR diagnostic notation: 257

<pvds>
Should it not be pointed out more strongly that the yang to cbor 
conversion fails in this case?
I don't see how a change from 2.57 or 257 represents loosing unnecessary 
meta information.
Unless I completely miss the point of the example.
</pvds>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 12 Jul 2016 12:04:06 +0200

Dear Peter,

In this case you can infer the decimal point position from the YANG definition, e.g. the statement "fraction-digits 2;"

Which indicates that 257 represents the number 2.57. 2 represents 0.02, 50 represents 0.50, 1000 represents 10.00

I think that you are right that we should provide more examples to be clear on this point.

Best,
Alexander

> Le 12 juil. 2016 à 11:58, peter van der Stok <[email-masked]> a écrit :
> 
> Hi Michel,
> 
> Should it not be pointed out more strongly that the yang to cbor conversion fails in this case?
> I don't see how a change from 2.57 or 257 represents loosing unnecessary meta information.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 12 Jul 2016 12:07:42 +0200

Hi Michel,

> key values in the CBOR encoding. Section 4.4 describes the encoding of
> a complete list not a subset of its instances.
> 

With the current text I don't see how you distinguish instances with the 
same key from instances with different keys.

Example:

list server {
      key name;

      leaf name {
        type string;
      }
      leaf iburst {
        type boolean;
        default false;
    }

How to distinguish that in the list below that two instances are 
identical (should not occur)
    [
      {
        1755 : "NRC TIC server",          # name (SID 1755)
        1754 : false,                     # iburst (SID 1754)
      },
      {
        1755 : "NRC TIC server",          # name (SID 1755)
        1754 : true,                     # iburst (SID 1754)
      }
    ]

And the following two instances are different  (valid array)

    [
      {
        1755 : "NRC TAC server",          # name (SID 1755)
        1754 : true,                      # iburst (SID 1754)
      },
      {
        1755 : "NRC TIC server",          # name (SID 1755)
        1754 : true,                     # iburst (SID 1754)
      }
    ]

---

From: peter van der Stok <[email-masked]>
Date: Tue, 12 Jul 2016 12:18:26 +0200

Hi Michel,

Here we have a point where my vision on this document differs from 
yours.

> [MV] The use of delta to encode integer based keys (SIDs) is an
> integral part of the YANG to CBOR mapping.

I am preparing a third document that describes a local numbering scheme 
for YANG identifiers based on discovery.
The numbers will be quite small and I like to encode them as unsigned 
integers.
However, with the present YANG to CBOR document some numbers must be 
encoded as Deltas, and that is not what I want.

Therefore I recommend that all hash conversion to CBOR goes to the 
yang-hash document
and the SID conversion to CBOR goes to an appropriate CoOL document.
and the coming numbering conversion to CBOR also treats it in an 
appropriate document

This document can then specify that identifiers can be strings and 
numbers, where for example numbers are encoded as unsigned integers.

Greetings,

Peter

---

From: peter van der Stok <[email-masked]>
Date: Tue, 12 Jul 2016 12:23:29 +0200

I forgot to add the following in an earlier e_mail,
Bit stupid to annoy all wg members with this trivial remark

> [MV] but seem very welcome from newcomers.

What about putting them in an appendix?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Jul 2016 12:59:32 +0200

Hi Alexander,

This is right. However, I thought that in the discussion of unions we had arrived at encoding decimals as CBOR decimal fraction tags. But maybe I'm misremembering.  

Grüße, Carsten

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 13:33:20 +0000

Hi Peter

Multiple aspects of YANG assume that the entities which serialize and de-serialize are schema aware.
This knowledge is used for example to apply default values where needed (see rfc6020bis section 7.6.1)
This knowledge is also used to perform all kings of validations
(range, pattern, length, min-elements, max-elements, must, when, if-feature)

The proposed mapping, as stated by https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-3
use this awareness to minimize the information transferred.

In the example

    leaf temperature {
      type decimal64 {
        fraction-digits 2;
        units "°C";
      }
    }

This information is used to serialize 2.57 °C into a CBOR unsigned integer 257 (3bytes).
The same information is used to de-serialize to the CBOR unsigned integer 257 back to 2.57 °C

This encoding is less friendly to schema unaware debugging tools (e.g. wireshark).
If the group believe we need to be more friendly to such tools, we can adopt the CBOR tag 4 (Decimal fraction) as defined in RFC7049 section 2.4.3.
However, this encoding will require 6 bytes in the case of "2.57" which is more than the textual form.
This significant overhead is the main reason why peoples have agreed to adopt the current encoding.

Can you propose some texts to clarify this topic?

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2016 5:58 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

> [MV] The number of digits is not encoded. This information is 
> considered an unnecessary metadata [MV] similar to "units", text of an 
> enumeration, name of a flag within bits. This was the consensus [MV] 
> of the group which is aligned with the statement in section 3 (In 
> order to minimize the size of [MV] the encoded data, the proposed 
> mapping avoid any unnecessary meta-information beyond [MV] those 
> natively supported by CBOR.) [MV] It might be worth it to raise this 
> topic within a larger audience.
> 

    leaf my-decimal {
      type decimal64 {
        fraction-digits 2;

<pvds>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 12 Jul 2016 15:50:05 +0200

Hi Carsten,

Yes, you are right. I thought that we could keep this representation outside of unions. But of course, we need to balance the complexity of doing this. 

There could be a confusion if the server and the client have different versions of the same module (rare, but must be taken care of). Which is of course, the thing we’ve always tried to avoid.. So yeah, for the moment we could keep the CBOR decimal tag. 

Best,
Alexander

> Le 12 juil. 2016 à 12:59, Carsten Bormann <[email-masked]> a écrit :
> 
> Hi Alexander,
> 
> On 12 Jul 2016 12:04, Alexander Pelov wrote: 
> 
>> Dear Peter,
>> 
>>>> considered an unnecessary metadata

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 14:14:20 +0000

Hi Carsten

The current solution is based on the following line in the file "20160525 – minutes.docx".
"DECIMAL – use CBOR’s DECIMAL Tag (we lose one byte, but there are only 5 values of this type)

Since tag 4 (Decimal fraction) require at least 3 bytes of overhead, I assumed the introduction of a new tag used sorely in the context of the union datatype.
(Similar approach as the other 4 tags used in unions)

The use of tag 4 (decimal fraction) for decimal64 values inside or outside the context of an union is another viable solution I will support.

Any strong opinion?

Michel

From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, July 12, 2016 7:00 AM
To: Alexander Pelov <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Alexander,

Grüße, Carsten

Dear Peter,

Best,
Alexander

Le 12 juil. 2016 à 11:58, peter van der Stok <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Michel,

Section 5.3;
In the example, where do I find in the CBOR encoding that the fraction
is 2 digits?
[MV] The number of digits is not encoded. This information is
considered an unnecessary metadata
[MV] similar to "units", text of an enumeration, name of a flag within
bits. This was the consensus
[MV] of the group which is aligned with the statement in section 3 (In
order to minimize the size of
[MV] the encoded data, the proposed mapping avoid any unnecessary
meta-information beyond
[MV] those natively supported by CBOR.)
[MV] It might be worth it to raise this topic within a larger audience.

leaf my-decimal {
type decimal64 {
fraction-digits 2;

<pvds>

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Paul Duffy <[email-masked]>
Date: Tue, 12 Jul 2016 10:46:59 -0400

IMO the examples are useful.

Move them to an appendix if you must, but I would leave them in the draft.

Cheers

On 7/12/2016 6:23 AM, peter van der Stok wrote:
> .

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 14:57:03 +0000

Hi Alexander

I want to be sure of your answer.
The CBOR tag 4 (Decimal fraction) require 3 bytes of overhead, see example for RFC 8049 section 2.4.3 bellow.
This is the tag you are proposing?
This tag will be used all the time (within the context of a union and without)?

C4             # Tag 4
  82           # Array of length 2
    21         # -2
    19 0101    # unsigned(257)

Regards,
Michel

From: core [mailto:[email-masked]] On Behalf Of Alexander Pelov
Sent: Tuesday, July 12, 2016 9:50 AM
To: Carsten Bormann <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Carsten,

Best,
Alexander

Le 12 juil. 2016 à 12:59, Carsten Bormann <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander,

Grüße, Carsten

Best,
Alexander

Hi Michel,

Section 5.3;

leaf my-decimal {
type decimal64 {
fraction-digits 2;

<pvds>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 15:07:12 +0000

Hi Peter

The validations performed by the entity which de-serialize the CBOR payload is based on the YANG schema.
This validation is based on all king of YANG statements such as:
key, unique, range, pattern, length, min-elements, max-elements, must, when, if-feature

The identification of which data nodes are keys is considered unnecessary meta-data since available in the schema.
Even more heavy weight representations such as xml and json don't include this meta-data in the encode payload.

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2016 6:08 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

> [MV] A list instance is a collection which is described in section 4.2.

With the current text I don't see how you distinguish instances with the same key from instances with different keys.

Example:

list server {
      key name;

      leaf name {
        type string;
      }
      leaf iburst {
        type boolean;
        default false;
    }

How to distinguish that in the list below that two instances are identical (should not occur)
    [
      {
        1755 : "NRC TIC server",          # name (SID 1755)
        1754 : false,                     # iburst (SID 1754)
      },
      {
        1755 : "NRC TIC server",          # name (SID 1755)
        1754 : true,                     # iburst (SID 1754)
      }
    ]

    [
      {

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 15:28:44 +0000

Hi Peter

Transferring the concept of parent deltas from "draft-ietf-core-yang-cbor" to "draft-veillette-core-cool" is technically possible.
This change require some level of effort so I will prefer to get a consensus from a larger group before moving ahead.
Carsten, Alexander, Abhi, Randy, Ana, ... do you have a strong opinion about the approach proposed by Peter?

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2016 6:18 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR , identification of objects

Hi Michel,

Here we have a point where my vision on this document differs from yours.

> [MV] The document is updated to keep only 2 type of keys

I am preparing a third document that describes a local numbering scheme for YANG identifiers based on discovery.
The numbers will be quite small and I like to encode them as unsigned integers.
However, with the present YANG to CBOR document some numbers must be encoded as Deltas, and that is not what I want.

Therefore I recommend that all hash conversion to CBOR goes to the yang-hash document and the SID conversion to CBOR goes to an appropriate CoOL document.
and the coming numbering conversion to CBOR also treats it in an appropriate document

This document can then specify that identifiers can be strings and numbers, where for example numbers are encoded as unsigned integers.

Greetings,

Peter

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 12 Jul 2016 18:00:06 +0200

Hi Michel, Peter,

I would be indeed very interested in seing this new local numbering scheme. 

I would suggest that we keep the delta encoding as it is right now and decide how to proceed when we have the new numbering scheme. 

Does that sound reasonable? 

Best,
Alexander

PS.
As a preview, can this new numbering scheme be implemented by using the experimental/private SID range?

> Le 12 juil. 2016 à 17:28, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Peter
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Jul 2016 18:00:55 +0200

Michel Veillette wrote:
> do you have a strong opinion about the approach proposed by Peter?

Actually I'm intrigued as to what that approach will be; until we know
that, I'd be a bit weary about moving things around.

So far, I have been quite happy with the parent delta approach, but I'm
not sure we have really succeeded in explaining it succinctly and
unambiguously.
For instance, what happens if a data structure is buried further into
another one that itself doesn't have a SID?

I'm not a big fan of specification-by-algorithm, but here it probably
*would* help to phrase this as an algorithm (preferably functional).
Cf. RFC 7396: The pseudo-code on page 4 really helps understanding the
obtuse language around it.

Given that the CBOR data model maps right into data structures that can
be addressed by pseudo code, specifying the "decoder" (as is usual for
compression algorithms) should be lean and precise.

Grüße, Carsten

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 16:07:00 +0000

Hi Peter

Are you proposing to move all examples in an appendix or just the larger ones.
Most examples are single liners.

Should I move only the following ones:
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.1
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.2
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.4.1
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.4.2

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2016 6:23 AM
To: Michel Veillette <[email-masked]>; [email-masked]
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR mapping version 1

I forgot to add the following in an earlier e_mail, Bit stupid to annoy all wg members with this trivial remark

> [MV] I agree that these examples are useless for peoples with a good 
> knowledge of CBOR [MV] but seem very welcome from newcomers.
> 

Peter

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 12 Jul 2016 18:09:53 +0200

Hi Michel,

If there is a way to unambiguously differentiate between union and non-union, then we should use the most efficient representation. However, I get the impression that you can modify locally a module, which could change the type of a leaf from decimal to union.. which could then lead to confusion. 

One of the main issues we’re having is the possible mismatch between the module versions on a server and a client. How about this - 
1) we define a (lightweight) mechanism for ensuring the matching of the module versions
2) if matching, then use most efficient representation (e.g. encode 2.57 as 257)
3) if not matching, then use tags for all representations

How does this sound? 

Alexander

> Le 12 juil. 2016 à 16:57, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Alexander
>  
> From: core [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Alexander Pelov
> To: Carsten Bormann <[email-masked] <mailto:[email-masked]>>
> Cc: Core <[email-masked] <mailto:[email-masked]>>
> Le 12 juil. 2016 à 12:59, Carsten Bormann <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Alexander,
> 
> Le 12 juil. 2016 à 11:58, peter van der Stok <[email-masked] <mailto:[email-masked]>> a écrit : 
> 
> Hi Michel, 
> 
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>
> 
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 12 Jul 2016 18:13:37 +0200

Hi Michel,

the proposal is to keep one larger JSON examples, accompanied by its 
CBOR conversion, and all other larger examples to the appendix.
The one liners are perfect as they are.
It is only a minor suggestion to improve the reading.

Peter

Michel Veillette schreef op 2016-07-12 18:07:
> I forgot to add the following in an earlier e_mail, Bit stupid to
> annoy all wg members with this trivial remark
> 
>>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 12 Jul 2016 16:29:19 +0000

Hi Carsten

About " is buried further into another one that itself doesn't have a SID".

No sure what do you means by "doesn't have a SID".
Do you means that the associated SID is encoded as a delta?

Each data node is associated to a SID.
SIDs of data node children are encoded using a delta from the parent SID (independently if this parent SID in also encoded as a delta).
The example https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-4.2.1 should be enhanced to show thiscase.
The description can also be enhanced, I'll check what I can do for the algorithm.

(Carsten) Do you have an example of a similar type of algorithm (serialization) to share?

Regards,
Michel

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2016 12:01 PM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Alexander Pelov <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] YANG to CBOR , identification of objects

> do you have a strong opinion about the approach proposed by Peter?

Actually I'm intrigued as to what that approach will be; until we know that, I'd be a bit weary about moving things around.

So far, I have been quite happy with the parent delta approach, but I'm not sure we have really succeeded in explaining it succinctly and unambiguously.
For instance, what happens if a data structure is buried further into another one that itself doesn't have a SID?

I'm not a big fan of specification-by-algorithm, but here it probably
*would* help to phrase this as an algorithm (preferably functional).
Cf. RFC 7396: The pseudo-code on page 4 really helps understanding the obtuse language around it.

Given that the CBOR data model maps right into data structures that can be addressed by pseudo code, specifying the "decoder" (as is usual for compression algorithms) should be lean and precise.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Wed, 13 Jul 2016 08:31:30 +0200

> that, I'd be a bit weary about moving things around.
Thanks for your interest.
However, the success of my proposal should not be of influence on the 
use of delta notation.

For the moment every YANG integer identifier MUST be encoded with delta 
notation. That is too restrictive in my opinion.
Secondly, using the delta notation can be interesting outside the YANG 
context.

Peter

---

From: peter van der Stok <[email-masked]>
Date: Wed, 13 Jul 2016 08:34:19 +0200

Hi Michel,

When a specification changes it set of of keys, I don't think the SIDs 
will change.
It is for sure that the hashes are not affected by the attribution of a 
key.

Therefore, what happens when client and server use different keys in 
otherwise identical list specification?

Peter

Michel Veillette schreef op 2016-07-12 17:07:
> The identification of which data nodes are keys is considered
> unnecessary meta-data since available in the schema.
> Even more heavy weight representations such as xml and json don't
> include this meta-data in the encode payload.
> 
> Regards,
> Michel
> 
> With the current text I don't see how you distinguish instances with
> the same key from instances with different keys.
> 
> Example:
> 
> list server {
>       key name;
> 
>       leaf name {
>         type string;
>       }
>       leaf iburst {
>         type boolean;
>         default false;
>     }
>

---

From: Michel Veillette <[email-masked]>
Date: Wed, 13 Jul 2016 14:36:09 +0000

Hi Peter

The scenario you described is part of the generic discovery problem.
To perform its tasks, clients typically need to known the list of modules, features, deviations implemented by a server and associated versions.
This problem is addressed in http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-latest.html which is the constrained version of https://datatracker.ietf.org/doc/rfc7895/ 

module: ietf-cool-library
   +--ro modules-state
      +--ro module-set-id    union
      +--ro module* [sid revision]
         +--ro sid                 sid
         +--ro revision            revision
         +--ro feature*            sid
         +--ro deviation* [sid revision]
         |  +--ro sid         sid
         |  +--ro revision    revision
         +--ro conformance-type    enumeration
         +--ro submodules
            +--ro submodule* [sid revision]
               +--ro sid         sid
               +--ro revision    revision
notifications:
   +---n yang-library-change
      +--ro module-set-id    -> /modules-state/module-set-id

Regards
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2016 2:34 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

When a specification changes it set of of keys, I don't think the SIDs will change.
It is for sure that the hashes are not affected by the attribution of a key.

Therefore, what happens when client and server use different keys in otherwise identical list specification?

Peter

Michel Veillette schreef op 2016-07-12 17:07:
>> key values in the CBOR encoding. Section 4.4 describes the encoding 
>> of a complete list not a subset of its instances.
>> 
>> _____________________________________________________________________
>> _
>> _______________________
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 13 Jul 2016 18:54:33 +0200

Hi Michel,

That looks pretty complex to me; while the keys can be elegantly 
expressed in the CBOR contents.

Peter

Michel Veillette schreef op 2016-07-13 16:36:
> To perform its tasks, clients typically need to known the list of
> modules, features, deviations implemented by a server and associated
> versions.
> This problem is addressed in
> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-latest.html
> which is the constrained version of
> https://datatracker.ietf.org/doc/rfc7895/
>

---

From: Michel Veillette <[email-masked]>
Date: Wed, 13 Jul 2016 17:06:04 +0000

Hi Peter

I'm not convinced that Including in the encoding which data nodes are the keys completely solve the issue.
If the client transmit a payload with one key and the server required two keys, the payload will be rejected.
If the client transmit a payload with two keys (marked as such) and the server require one key, the payload will be rejected.
To work, both sides need to known the number of keys used by the other side and only 'ietf-cool-library' can resolve that.

Also, not making which data nodes are keys might help during the migration.

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2016 12:55 PM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

That looks pretty complex to me; while the keys can be elegantly expressed in the CBOR contents.

Peter

Michel Veillette schreef op 2016-07-13 16:36:
>>> However, I am missing how to transport a given list instance with 
>>> its key values in the CBOR encoding. Section 4.4 describes the 
>>> encoding of a complete list not a subset of its instances.
>>>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Jul 2016 09:56:54 +0200

Hi Michel,

IMO, an error is an error and should be treated as such. Trying to 
salvage unhealthy situations leads to worse problems.

My approach would be that servers and clients are simple and don't need 
to parse the yang modules during operation; and keep extensive state 
information about each other.

The discussion seems to confirm my growing conviction that the CoMI and 
CoOL approaches are fundamentally different.

Peter

Michel Veillette schreef op 2016-07-13 19:06:
> If the client transmit a payload with two keys (marked as such) and
> the server require one key, the payload will be rejected.
> To work, both sides need to known the number of keys used by the other
> side and only 'ietf-cool-library' can resolve that.
>

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 14 Jul 2016 10:39:44 +0200

Dear Peter,

I agree with you - if a server expects TWO keys, but receives ONE this is an error. What I don’t understand is how marking the CBOR content changes anything to this. (if the client insists that a leaf is a key and the server disagrees - then you have error. if the server requires a key and the client does not provide it - stil an error). 

From implementation point of view, the server will never recompile the YANG module. YANG is used compile-time (when you generate your program on your laptop) and as a contract between the client and the server. The same goes for constrained clients. 

In most cases, the server and the client will actually not need to have the YANG module scheme at all - only a couple of SIDs, associated meta-data (in binary - such as the type) and the associated functions (which you need anyways). As SIDs never change, you don’t need anything else on the device. It could be even simpler - without the meta-data - but then the associated functions need to do the validation (e.g. Arduino implementations).

Alexander

> Le 14 juil. 2016 à 09:56, peter van der Stok <[email-masked]> a écrit :
> 
> Hi Michel,
> 
> IMO, an error is an error and should be treated as such. Trying to salvage unhealthy situations leads to worse problems.
> 
> My approach would be that servers and clients are simple and don't need to parse the yang modules during operation; and keep extensive state information about each other.
> 
> The discussion seems to confirm my growing conviction that the CoMI and CoOL approaches are fundamentally different.
> 
> Peter
>

---

From: Michel Veillette <[email-masked]>
Date: Thu, 14 Jul 2016 11:37:28 +0000

Hi Peter

Validation mechanisms are defined by YANG  ('key', 'unique', 'range', 'pattern', 'length', 'min-elements', 'max-elements', 
'must', 'when', 'if-feature'), not by CoOL or CoMI. 
Any protocol based on YANG need to be able to support those mechanisms.
Adding meta data in the encoding to identity which data nodes are keys don't eliminate de need for clients and servers to have some knowledge of the schema.

The general rule established for "draft-ietf-core-yang-cbor" is simple.
" In order to minimize the size of the encoded data, the proposed
   mapping avoid any unnecessary meta-information beyond those natively
   supported by CBOR."
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-3

In this case, you propose to add more meta data than "draft-ietf-netmod-yang-json"
which don't share the same limitations on the payload size.
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4

Regards,
Michel

-----Original Message-----

Sent: Thursday, July 14, 2016 3:57 AM

Hi Michel,

Peter

Michel Veillette schreef op 2016-07-13 19:06:
>> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-
>> l
>> atest.html
>>>> ___________________________________________________________________
>>>> _
>>>> _
>>>> _
>>>> _______________________
>>>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Jul 2016 17:39:49 +0200

Hi Michel,

> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4

I don't think extra meta-data is needed (depending on your definition of 
meta-data)

Greetings,

Peter

> My approach would be that servers and clients are simple and don't
> need to parse the yang modules during operation; and keep extensive
> state information about each other.
> 
> The discussion seems to confirm my growing conviction that the CoMI
> and CoOL approaches are fundamentally different.
> 
> Peter
>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Jul 2016 17:46:27 +0200

Alexander Pelov schreef op 2016-07-14 10:39:
> Dear Peter,
> 
> I agree with you - if a server expects TWO keys, but receives ONE this
> is an error. What I don’t understand is how marking the CBOR content
> changes anything to this. (if the client insists that a leaf is a key
> and the server disagrees - then you have error. if the server requires
> a key and the client does not provide it - stil an error).
> 
> From implementation point of view, the server will never recompile the
> YANG module. YANG is used compile-time (when you generate your program
> on your laptop) and as a contract between the client and the server.
> The same goes for constrained clients.
> 
> In most cases, the server and the client will actually not need to
> have the YANG module scheme at all - only a couple of SIDs, associated
> meta-data (in binary - such as the type) and the associated functions
> (which you need anyways). As SIDs never change, you don’t need
> anything else on the device. It could be even simpler - without the
> meta-data - but then the associated functions need to do the
> validation (e.g. Arduino implementations).
> 
> Alexander

Hi Alexander,

absolutely agree with you in the above.
The need to identify keys and to distinguish different instances is 
needed when you want to "replace" (same key values) or "add" (different 
key values) individual instances to a list.

I try to argue that you want that express this in the payload because 
you cannot count on server and client to have the same view on the key 
set.

Peter

---

From: Michel Veillette <[email-masked]>
Date: Fri, 15 Jul 2016 18:27:25 +0000

Hi Peter

"Meta data" is defined as "data that provides information about other data"
The identification of  which data nodes are listed in the 'key' YANG statement is information about the data transferred, not the data itself.

So yes, extra meta-date is required if we want to identify the list of key(s) in the encoded payload.

Updating the list of keys is not something typical and if done, I assume  that the interactions between clients and servers change significantly. I still believe that the discovery process is the most appropriate and generic way to address these types of problems.

Regards,

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Thursday, July 14, 2016 11:40 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

Greetings,

Peter

>> To work, both sides need to known the number of keys used by the 
>> other side and only 'ietf-cool-library' can resolve that.
>> 
>>>> With the current text I don't see how you distinguish instances 
>>>> with the same key from instances with different keys.
>>>> 
>>>> Example:
>>>> 
>>>> list server {
>>>>       key name;
>>>> 
>>>>       leaf name {
>>>>         type string;
>>>>       }
>>>>       leaf iburst {
>>>>         type boolean;
>>>>         default false;
>>>>     }
>>>>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 15 Jul 2016 20:04:04 +0000

Hi Alexander

To simplify the implementation, I'll prefer to keep the same representation for decimal64 within or without a union (2.57 or 257)
We simply need to select one.
I'm find with either ones but LPWAN implementers might prefer the CBOR unsigned integer representation.

Regards,
Michel

From: Alexander Pelov [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 12:10 PM
To: Michel Veillette <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Michel,

How does this sound?

Alexander

Le 12 juil. 2016 à 16:57, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander

C4             # Tag 4
  82           # Array of length 2
    21         # -2
    19 0101    # unsigned(257)

Regards,
Michel

From: core [mailto:[email-masked]] On Behalf Of Alexander Pelov
Sent: Tuesday, July 12, 2016 9:50 AM
To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Cc: Core <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Carsten,

Best,
Alexander

Hi Alexander,

Grüße, Carsten

Best,
Alexander

Hi Michel,

Section 5.3;

leaf my-decimal {
type decimal64 {
fraction-digits 2;

<pvds>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jul 2016 13:15:30 -0700

On Fri, Jul 15, 2016 at 1:04 PM, Michel Veillette <
[email-masked]> wrote:

> Hi Alexander
>
>
>
> To simplify the implementation, I'll prefer to keep the same
> representation for decimal64 within or without a union (2.57 or 257)
>

So how is this union supported with the 2nd option?
2.57 seems the obvious choice if robustness is a concern.

   leaf foo {
      type union {
         type decimal64 {
             fraction-digits 2;
          }
          type decimal64 {
             fraction-digits 4;
          }
      }
   }

Regards,
> Michel

Andy

>
>
> *From:* Alexander Pelov [mailto:[email-masked]]
> *Sent:* Tuesday, July 12, 2016 12:10 PM
> *To:* Michel Veillette <[email-masked]>
> *Cc:* Carsten Bormann <[email-masked]>; Core <[email-masked]>
> *Subject:* Re: [core] YANG to CBOR mapping version 1
>
>
>
> Hi Michel,
>
>
>
> If there is a way to unambiguously differentiate between union and
> non-union, then we should use the most efficient representation. However, I
> get the impression that you can modify locally a module, which could change
> the type of a leaf from decimal to union.. which could then lead to
> confusion.
>
>
>
> One of the main issues we’re having is the possible mismatch between the
> module versions on a server and a client. How about this -
>
> Le 12 juil. 2016 à 16:57, Michel Veillette <
> [email-masked]> a écrit :
>
>
>
> Hi Alexander
>
>
>
> The CBOR tag 4 (Decimal fraction) require 3 bytes of overhead, see
> example for RFC 8049 section 2.4.3 bellow.
>
> *From:* core [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alexander Pelov
> *Sent:* Tuesday, July 12, 2016 9:50 AM
> *To:* Carsten Bormann <[email-masked]>
> *Cc:* Core <[email-masked]>
> *Subject:* Re: [core] YANG to CBOR mapping version 1
>
>
>
> Hi Carsten,
>
>
>
> Yes, you are right. I thought that we could keep this representation
> outside of unions. But of course, we need to balance the complexity of
> doing this.
>
>
>
> There could be a confusion if the server and the client have different
> versions of the same module (rare, but must be taken care of). Which is of
> course, the thing we’ve always tried to avoid.. So yeah, for the moment we
> could keep the CBOR decimal tag.
>
>
>
> Best,
>
> Alexander
>
>
>
> This is right. However, I thought that in the discussion of unions we had
> arrived at encoding decimals as CBOR decimal fraction tags. But maybe I'm
> misremembering.
>
> Grüße, Carsten
>
>
> In this case you can infer the decimal point position from the YANG
> definition, e.g. the statement "fraction-digits 2;"
>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 15 Jul 2016 20:33:15 +0000

Hi Andy

The current solution consist of tagging decimal64 only when used in the context of a union.
Same for bits, enumeration, identityref and instance-identifier.
(https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-5.12)
With this solution, the 2 or 3 bytes overhead is present only in the context of a union.

If the group prefer to serialize decimal64 using decimal fractions
(https://tools.ietf.org/html/rfc7049#section-2.4.3)
The 3 bytes overhead will always be present.

I like the second approach but users of more constrained networks might prefer the current solution.

Regards,
Michel

From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, July 15, 2016 4:16 PM
To: Michel Veillette <[email-masked]>
Cc: Alexander Pelov <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] YANG to CBOR mapping version 1

On Fri, Jul 15, 2016 at 1:04 PM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alexander

   leaf foo {
      type union {
         type decimal64 {
             fraction-digits 2;
          }
          type decimal64 {
             fraction-digits 4;
          }
      }
   }

Regards,
Michel

Andy

From: Alexander Pelov [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 12, 2016 12:10 PM
To: Michel Veillette <[email-masked]<mailto:[email-masked]>>
Cc: Carsten Bormann <[email-masked]<mailto:[email-masked]>>; Core <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] YANG to CBOR mapping version 1

Hi Michel,

How does this sound?

Alexander

Hi Alexander

C4             # Tag 4
  82           # Array of length 2
    21         # -2
    19 0101    # unsigned(257)

Regards,
Michel

Hi Carsten,

Best,
Alexander

Hi Alexander,

Grüße, Carsten

Best,
Alexander

Hi Michel,

Section 5.3;

leaf my-decimal {
type decimal64 {
fraction-digits 2;

<pvds>

---

From: peter van der Stok <[email-masked]>
Date: Sun, 17 Jul 2016 22:26:36 +0200

Then no extra meta data is needed.

Peter

Michel Veillette schreef op 2016-07-15 20:27:
> The identification of  which data nodes are listed in the 'key' YANG
> statement is information about the data transferred, not the data
> itself.
> 
> Updating the list of keys is not something typical and if done, I
> assume  that the interactions between clients and servers change
> significantly. I still believe that the discovery process is the most
> appropriate and generic way to address these types of problems.
> 
> Regards,
> 
>