[core] Name support in draft-ietf-core-yang-cbor?

[Michel Veillette <[e-mail]>]

Hi Alexander

About "There are two types of identifiers supported by draft-ietf-core-yang-cbor - textual (for full compatibility with RESTConf/NETCONF names) and delta-encoded integers (a.k.a. SIDs). The former could be used when network constraints are not so stringent, while the latter is the preferred way of using this encoding in constrained networks."

Don't we have an action item from the last IETF to remove name?
The minutes are not clear about this topic.
https://www.ietf.org/proceedings/96/minutes/minutes-96-core 
The last sentence is from Andy " We do not need multiple ways to do the same thing, especially on constrained devices. Nobody provides short module names, so they can be very large."

Regards,
Michel

-----Original Message-----
From: Alexander Pelov [mailto:[e-mail]] 
Sent: Wednesday, August 24, 2016 3:57 AM
To: [e-mail]
Cc: Michel Veillette <[e-mail]>; [e-mail] WG <[e-mail]>
Subject: Re: [core] 🔔 Working Group Adoption call for draft-somaraju-core-sid

Dear Peter,

> Le 24 août 2016 à 08:39, peter van der Stok <[e-mail]> a écrit :
> 
> Some comments based on the arguments below:
> 
>> This draft is a prerequisite for the following works:
>> - CBOR encoding of YANG data model
>> (https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/)
> I have argued already for some time that the text about SIDs does not belong in the yang to cbor draft.
> It reduces its independence from the CoMI work.
> Given that CBOR is not to be changed, Putting the SID text in a content format draft seems more appropriate.

There are two types of identifiers supported by draft-ietf-core-yang-cbor - textual (for full compatibility with RESTConf/NETCONF names) and delta-encoded integers (a.k.a. SIDs). The former could be used when network constraints are not so stringent, while the latter is the preferred way of using this encoding in constrained networks.

We should keep it simple. Having several content formats to express the same thing - especially when this is not necessary - is adding complexity for no reason. 

The SID draft allows for having ranges of SIDs be managed by independent registries and have different rules of assignment. No need to use different Content Formats necessary to solve overlapping of the integer values. Moreover, as of the time of this writing, we have 3 different Content-Formats for the CoOL/CoMI draft. Adding an alternative Content-Format for the interpretation of the integers would multiply this by 2, e.g. 6 content formats, where half are doing the same thing.

If you have a server with mixed modules (e.g. ones using SID and ones using a different interpretation of the IDs), the Content-Format will force you to chose ONE or ANOTHER. There is no possibility in one request to read or write values from different modules. This effectively removes all interoperability between the two, making one of the two redundant. 

Best,
Alexander



>> The alternate assignment algorithm of IDs based on murmur3 and 
>> improved description texts  proposed by Andy in
>> (https://datatracker.ietf.org/doc/draft-bierman-core-yid/) don't 
>> fundamentally change the registration process defined by the SID draft.
> 
> I should like to wait till this agreement is visible on this mailing list.
> 
> Peter
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core