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

Hi Alex, and Michel

see below

Michel Veillette schreef op 2016-08-24 20:31:
> 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."
<pvds>
YANG to CBOR mapping may also be used by RESTCONF/http and I like to 
maintain the textual representation.
</pvds>
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: Alexander Pelov [mailto:a@ackl.io]
> Sent: Wednesday, August 24, 2016 3:57 AM
> To: consultancy@vanderstok.org
> Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>;
> core@ietf.org WG <core@ietf.org>
> 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 <stokcons@xs4all.nl> 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.
<pvds>
I agree to keep things simple.
Specifying that there are two representations: numeric and textual, 
keeps the yang to cbor draft simple.
IMO the yang to cbor draft is useful beyond CoMI/CoOL applications.
Providing one content format for CoMI/CoOL, using yang-to-cbor, that 
specifies i.a. delta encoding keeps things simple and inter-operable for 
CoMI/CoOL.
May be two content formats to cover the merge-patch case if needed.

Other (future) applications can use the CBOR content format and the YANG 
to CBOR encoding independent of what we invent for CoMI/CoOL.
</pvds>
> 
> 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
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core