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

On Sun, Nov 13, 2016 at 5:45 PM, Alexander Pelov <a@ackl.io> wrote:

> Dear Peter, Andy,
>
> Excellent points, thanks for bringing this up!
>
> A major difference between SIDs and MIBs is that we cannot allocate
> prefixes in SIDs (as is the case with MIB-OID). The system works perfectly
> well - it is just NOT feasible for IANA to allocate ranges to individual
> modules on a global scale. It’s also not feasible for developers/companies
> to ask IANA for individual allocations per module (and anything else boils
> down to what we’re currently doing).
>

You want to manually manage ranges.  Why?

Why not allocate module-ids with a fixed range of objects within a module?

e.g.,32 bits for modules,  20 bits for objects --> module ID 1 has objects
0x100000 to 0x1fffff.

What evidence do you have that we need more than 4 billion modules,
each with up to 1 million objects?

There is no operational experience with SIDs but there is plenty with
managed objects
in general.

Andy

>
> The SID draft functions under a Two-tier registration system. IANA ->
> SDOs/Registrars -> Modules. IANA allocates chunks of IDs to other
> SDOs/registrars. A module is then registered by these third parties and the
> particular SIDs get assigned to the individual modules.
>
> Note, that IANA can also register SIDs for individual modules, e.g. for
> all YANG modules published by the IETF. I would suppose the same policy
> could apply to other SDOs.
>
> Hope that this clarifies the question.
>
> Best,
> Alexander
>
>
>
> Le 14 nov. 2016 à 10:17, Andy Bierman <andy@yumaworks.com> a écrit :
>
> Hi,
>
>
> One question to ask:  How many modules do we expect to have?
> How many objects do we expect to have?  In 30 years of writing MIB modules
> we have never even come close to a million objects. (Maybe 100,000?)
>
> A million modules, each with a million objects, would still be less than
> 40 bits.
> So why to we need complex range assignments and non-contiguous numbering
> within a module?  Presumably to preserve numbers and not waste them.
> But since the SID encoding is based on deltas, and the full SID is only
> used
> once per transaction, this does not seem to be a real concern.
>
>
> Andy
>
>
> On Sun, Nov 13, 2016 at 4:12 PM, peter van der Stok <stokcons@xs4all.nl>
> wrote:
>
>> 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
>
>
>