Subject: [core] New CoOL drafts available

From: Michel Veillette <[email-masked]>
Date: Mon, 14 Mar 2016 14:48:11 +0000

The following drafts related to the CoOL protocol have been released last week.

https://datatracker.ietf.org/doc/draft-turner-core-cool-problem-statement/
https://datatracker.ietf.org/doc/draft-somaraju-core-sid/ 
https://datatracker.ietf.org/doc/draft-veillette-core-yang-cbor-mapping/ 
https://datatracker.ietf.org/doc/draft-veillette-core-cool/

A pyang plugin is also available to generate or update the identifiers used to CoOL (SID).
https://github.com/lemikev/pyang/blob/master/pyang/plugins/sid.py

Comments on these drafts are welcome.

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-531-3109

---

From: David Reid <[email-masked]>
Date: Thu, 17 Mar 2016 12:08:29 -0400

I read draft-somaraju-core-sid and I have a few questions.

How are yang revisions handled? I see a mention of adding new SIDs for
revisions, but I don't know how the new SIDs are assigned.

The process for assigning SIDs is "recommended". Does this mean I can
assigned the SIDs any way I want and not follow the recommended approach?
And does that mean that my SID assignments and someone elses will be different?

In the .sid file, what is the value of the assigned date field and 
the type field.

Is there a way that the .sid file could be a yang module so that standard
yang tools could read it. For example, could deviations be used to add sid
assignments with the deviate add statement. That way I would not have to
have special tools to read the .sid file, any yang compiler would work.

When assigning sids, "the list of items is ordered by type and label".
What is the purpose of this ordering? 

-David Reid

---

From: Michel Veillette <[email-masked]>
Date: Thu, 17 Mar 2016 17:11:27 +0000

Hi David.

See [MV] bellow.

Regards,
Michel Veillette

-----Original Message-----
From: David Reid [mailto:[email-masked]] 
Sent: March-17-16 12:08 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] New CoOL drafts available

How are yang revisions handled? I see a mention of adding new SIDs for revisions, but I don't know how the new SIDs are assigned.

[MV] For revision, the algorithm defined at the bottom of section 3 can be also be used assuming that the process 
[MV] is resumed using the highest SID already allocated and YANG items already assigned are not modified.
 [MV] I agree that the draft should add this clarification.
[MV]
[MV] The following example is based on http://www.netconfcentral.org/modulereport/toaster :
[MV]
[MV] python  pyang --list-sid --generate-sid-file 2000 0:100 [email-masked]
[MV]
[MV] SID        Assigned to
[MV] ---------  --------------------------------------------------
[MV] 20000      identity toaster:frozen-bagel
[MV] 20001      identity toaster:frozen-waffle
[MV] 20002      identity toaster:hash-brown
[MV] 20003      identity toaster:toast-type
[MV] 20004      identity toaster:wheat-bread
[MV] 20005      identity toaster:white-bread
[MV] 20006      identity toaster:wonder-bread
[MV] 20007      node /toaster-info
[MV] 20008      node /toaster-info/toaster-manufacturer
[MV] 20009      node /toaster-info/toaster-model-number
[MV] 20010      node /toaster-info/toaster-status
[MV] 20011      notification /toast-done
[MV] 20012      notification /toast-done/toast-status
[MV] 20013      rpc /cancel-toast
[MV] 20014      rpc /make-toast
[MV] 20015      rpc /make-toast/input/toaster-doneness
[MV] 20016      rpc /make-toast/input/toaster-toast-type
[MV]
[MV]
[MV] File [email-masked] created
[MV] Number of SIDs available : 100
[MV] Number of SIDs assigned : 17
[MV]
[MV] python pyang --list-sid --update-sid-file [email-masked]  [email-masked]
[MV]
[MV] SID        Assigned to
[MV] ---------  --------------------------------------------------
[MV] 20000      identity toaster:frozen-bagel
[MV] 20001      identity toaster:frozen-waffle
[MV] 20002      identity toaster:hash-brown
[MV] 20003      identity toaster:toast-type
[MV] 20004      identity toaster:wheat-bread
[MV] 20005      identity toaster:white-bread
[MV] 20006      identity toaster:wonder-bread
[MV] 20017      identity toaster:croisant (New)
[MV] 20007      node /toaster-info
[MV] 20008      node /toaster-info/toaster-manufacturer (Remove)
[MV] 20009      node /toaster-info/toaster-model-number
[MV] 20010      node /toaster-info/toaster-status
[MV] 20018      node /toaster-info/power-source/electric/voltage (New)
[MV] 20011      notification /toast-done
[MV] 20012      notification /toast-done/toast-status
[MV] 20013      rpc /cancel-toast
[MV] 20014      rpc /make-toast
[MV] 20015      rpc /make-toast/input/toaster-doneness
[MV] 20016      rpc /make-toast/input/toaster-toast-type
[MV]
[MV] WARNING, obsolete definitions should be defined as 'deprecated' or 'obsolete'.
[MV]
[MV] File [email-masked] updated
[MV] Number of SIDs available : 100
[MV] Number of SIDs assigned : 19

The process for assigning SIDs is "recommended". Does this mean I can assigned the SIDs any way I want and not follow the recommended approach?

[MV] The only requirement for a SID is to be globally unique.
[MV] Any process which comply with this requirement should be fine.

[MV] Yes, this is why .sid files should be registered.
[MV] Even if the same algorithm is used, the result can be different depending when in the development cycle SIDs have been assigned.
[MV] The only way to produce the same list of SIDs is to use the same algorithm, on the same revisions, in the same order.

In the .sid file, what is the value of the assigned date field and the type field.

[MV] I agree that the assigned date don't add much value and should be optional (mandatory false).
[MV] For the type, this allows to group data nodes, RPCs and notifications together which make the .sid file more readable and optimise the delta encoding.

Is there a way that the .sid file could be a yang module so that standard yang tools could read it. For example, could deviations be used to add sid assignments with the deviate add statement. That way I would not have to have special tools to read the .sid file, any yang compiler would work.

[MV] .yang files are the input of the  SID assignment process, the .sid are the output.
[MV] Since the inputs are not modified, this process can be repeated as needed.
[MV] This is useful during the initial development when .yang files are changing and a completely new SID assignment is preferred.
[MV] Re-writing the .yang file will also add lot of complexities to the tool.
[MV] Finally, adding this information to the yang files won't change the fact that the actual YANG tools don't understand SIDs and don't do anything useful with them.

[MV] This ordering is important to minimise the size of the delta encoding.

-David Reid

---

From: David Reid <[email-masked]>
Date: Thu, 17 Mar 2016 17:35:54 -0400

> [MV] This ordering is important to minimise the size of the delta encoding.

I'm not familar with CBOR encoding. Perhaps the answer is obvious to those
who are. How does sorting alphabetically before assigning the SID minimize 
the encoding?

-David Reid

---

From: Michel Veillette <[email-masked]>
Date: Thu, 17 Mar 2016 22:43:39 +0000

Hi David

The optimization I'm referring is not associated to the CBOR encoding but with delta as defined by
https://tools.ietf.org/html/draft-veillette-core-yang-cbor-mapping-00#section-4.2.

In the following example, SID 1709 and 1710 are encoded as 1 and 2 respectively.

CBOR diagnostic notation:

   {
     1708 : {                              # clock
       2 : "2015-10-02T14:47:24Z-05:00",   # current-datetime, SID 1710
       1 : "2015-09-15T09:12:58Z-05:00"    # boot-datetime, SID 1709
     }
   }

To keep these delta small, all children of a container or list need to be assigned to consecutive SIDs.
With the use of grouping in yang files, children can be defined far apart.
By sorting the final schema tree, these children are group together.

/system-state/clock
/system-state/clock/boot-datetime
/system-state/clock/current-datetime

For more .sid files example, see:
https://github.com/core-wg/yang-cbor/tree/master/registry

Regards,
Michel Veillette

-----Original Message-----
From: David Reid [mailto:[email-masked]] 
Sent: March-17-16 5:36 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] New CoOL drafts available

> [MV] This ordering is important to minimise the size of the delta encoding.

I'm not familar with CBOR encoding. Perhaps the answer is obvious to those who are. How does sorting alphabetically before assigning the SID minimize the encoding?

-David Reid