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

From: Michel Veillette <[email-masked]>
Date: Wed, 24 Aug 2016 18:31:55 +0000

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:[email-masked]] 
Sent: Wednesday, August 24, 2016 3:57 AM
To: [email-masked]
Cc: Michel Veillette <[email-masked]>; [email-masked] WG <[email-masked]>
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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Thu, 25 Aug 2016 11:54:32 +0200

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."
> 
> 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>
>> 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
> 
> 
>