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

Hi Michel,

One module per SDO, may be 5?
They can structure the module with submodules to their liking.

My point is about freedom to choose SID values.
For example, SDOs have a history to assign numbers to attribute types, 
device types, etc..
These numbers have a meaning in the group.
Using the same numbers for the SID values when appropriate may be 
welcome indeed.

Peter

Michel Veillette schreef op 2016-11-14 17:27:
> Hi Peter.
> 
> The allocation by range have been introduced to simplify the life of
> SDOs, not to make their life more difficult.
> With your proposal, the SDO must interact with IANA for each module 
> created.
> With the allocation by ranges, the allocated range can be large enough
> to allow the SDO to be autonomous for multiple years of development,
> for dozen of modules.
> 
> Updating the different drafts to identify YANG items using (module ID,
> module item ID) is possible, but not with some impacts on message size
> and complexity.
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der 
> Stok
> Sent: Sunday, November 13, 2016 7:13 PM
> To: Core <core@ietf.org>
> Subject: [core] draft-ietf-core-sid-00, SID allocation
> 
> 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: consultancy@vanderstok.org
> www: www.vanderstok.org
> tel NL: +31(0)492474673     F: +33(0)966015248
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core