Re: [core] yang cbor encoding without SID

Dear all,

Section "4.2.2. Member names as keys" of draft-ietf-core-yang-cbor-04 describes how you achieve what you want in your demand.

I think there is no point in continuing the discussion of should we include something that is already there. You can start using it as it is today.

Also, we will be doing an interop event by the end of August. Please, make sure to participate to this event, as without running code, a specification serves no useful purpose.

Alexander

> Le 24 juil. 2017 à 08:42, peter van der Stok <stokcons@xs4all.nl> a écrit :
> 
> For case 3, CoMI with string identifiers, I recommend to send hashes and fall back to strings when a clash occurs.
> Strings are only used for clashing names, all others are sent as hashes.
> For an installation with 1000 names and 30 bit hash, the clash probability is less than 5*10^-4.
> With little extra code, string identifiers are only necessary when 3 or more names clash to the same hash value.
> The probability of such a clash with 30 bit hash and 1000 names is less than 5*10^-8.
> For comparison, the probability that a given flight will crash is 10^-7.
> 
> Peter
> 
> Andy Bierman schreef op 2017-07-23 20:39:
>> On Sat, Jul 22, 2017 at 7:02 AM, Juergen Schoenwaelder
>> <j.schoenwaelder@jacobs-university.de> wrote:
>>> On Sat, Jul 22, 2017 at 03:37:33PM +0200, Carsten Bormann wrote:
>>>>> Anyway, I do not want to prevent people from getting experience
>>> with
>>>>> this as long as there is a way to use YANG-CBOR without SID.
>>> Make SID
>>>>> an additional optimization. If you want to require SID for CoMI,
>>> fine.
>>>>> Then in the worst case CoMI goes with the fate of SIDs.
>>>> Sounds good to me.
>>>> So we would have the following levels of optimization:
>>>> 1 RESTCONF with JSON-YANG
>>>> 2 RESTCONF with CBOR-YANG
>>> Option #2 makes sense to investigate, i.e., to find out how much
>>> efficiency gain there is. Someone would need to implement both and
>>> provide hard numbers. I would expect a certain gain on the
>>> encoding/decoding side but then one needs to lock at the whole
>>> picture. But I think this is a reasonable experiment to
>>> make. Volunteers?
>> Isn't CBOR-YANG covered by changes to the current document?
>> IMO, the following protocol-independent media types should be defined:
>> (2)
>>  application/yang-data+cbor : exact same identifier and instance
>> value mappings as XML and JSON versions of yang-data.
>> (4)
>>  application/yang-data+cbor.sid : identifier and instance value
>> mappings according to SID registry
>> Efficiency in system design is not limited to the protocol.
>> Designers of YANG modules for constrained devices can use numeric
>> types over string types
>> and increase the efficiency of the CBOR encoding.
>> The main use-case for CBOR for RESTCONF right now is pushing lots of
>> operational state telemetry data
>> off of routers. I can imagine routers using
>> application/yang-data+cbor.sid a little at a time, for spot solutions.
>> Some might want to see the technology mature before putting it in
>> production networks.
>>>> 3 COMI with string identifiers
>>>> 4 COMI with SIDs
>>> Up to COMI people to decide, perhaps #4 is sufficient if COMI's
>>> scope
>>> is restricted to very constrained devices or boxes using highly
>>> limited links and we do not need #3. All depends on what is the real
>>> target for COMI.
>>>> (There might also be NETCONF with CBOR-YANG, which doesn’t quite
>>> fit
>>>> into the above hierarchy.)
>>> NETCONF has no way to negotiate different content encodings, NETCONF
>>> is pretty much hard wired to use XML since the whole protocol is
>>> encoded in XML.
>>> /js
>> Andy
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>>> Germany
>>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
>>> [1]>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org <mailto:core@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> [2]
>> Links:
>> ------
>> [1] http://www.jacobs-university.de/ <http://www.jacobs-university.de/>
>> [2] https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>
>> _______________________________________________
>> core mailing list
>> core@ietf.org <mailto:core@ietf.org>
>> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>
> 
> _______________________________________________
> core mailing list
> core@ietf.org <mailto:core@ietf.org>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>