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

On Mon, Nov 14, 2016 at 8:27 AM, Michel Veillette <
Michel.Veillette@trilliantinc.com> wrote:

> 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.
>
>
The interpretation of the number is completely independent of the
allocation of the number.  One could allocate a block of module IDs
just as easily as a block of object IDs.

The disconnect here is the number of available IDs vs. the number of
IDs needed.  You seem to think this is a precious resource.  I do not.

Andy

> 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
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>