[core] draft-ietf-core-sid-00, SID allocation

[peter van der Stok <[e-mail]>]

Dear YANG-SID authors,

I want to propose a change to the allocation of SIDs.
Currently, the SIDs are divided in ranges and prospective users can 
register a range with IANA.
When the range is already assigned, they need to select a new not 
allocated range.
I think that this will discourage many future SDOs who may want to use 
YANG + COMI. Many of these SDOs like to figure out the best number 
structure for their uses, and will be very disappointed when they cannot 
acquire the range. Actually, I believe, they will abandon the use of 
YANG + COMI.

My proposal is to assign numbers to modules, and let IANA handle the 
module number registration as proposed for the SIDs. The assignment of 
SIDs to YANG identifiers, as proposed in the draft remains, the same. 
The difference is the complete freedom to choose the SIDs in any given 
module. The advantage is that all modules can pick their values from the 
small number range.

The change is in the discovery and the structure of the resource path. 
In COMI I want to define another resource type called YANG module with 
name core.c.module. The discovery will return the path: 
/prefix/module-number-in-binary64. For example, with an empty prefix and 
for module 32, discovery will return /g. To retrieve a specific YANG 
instance with numeric identifier sid in module 32, the statement GET 
coap/example.com/g/sid will do. With two characters, modules with 
numbers < 4096 are covered; probably 3 characters will cover all 
modules.  Given that the SIDs are small, the total URI size will not 
increase due to this modification.

When the full datastore is accessed, the path /c is currently used. We 
can reserve c, meaning module number 28 is already assigned. Another 
method is returning a long path name, such as /whole_store. The size of 
the related URI is not important in this case. However, the proposed 
module allocation necessitates a small modification to the CBOR 
representation of the contents of the full datastore. This is attained 
by representing the full datastore as a CBOR map containing (key, value) 
pairs, where key is the module number and value is the content of the 
module as specified in yang-cbor document.

For the PATCH and the FETCH methods, this representation will also work, 
given the content-formats that are currently looked at.

I hope you like my proposal. The advantage is a simpler IANA 
administration, SID allocation freedom within a module, and shorter 
SIDs. The disadvantage is a slight complexity increase in the CBOR 
representation of the full datastore.

Hope this helps,

Peter


-- 
Peter van der Stok
vanderstok consultancy
mailto: [e-mail]
www: www.vanderstok.org
tel NL: [phone]     F: [phone]