Re: [core] YANG list to CBOR mapping

[peter van der Stok <[e-mail]>]

Carsten Bormann schreef op 2015-11-23 17:50:
> Michel Veillette wrote:
>> Hi Peter
>> 
>> Have you defined an MergePatch() function similar to RFC 7396 section 
>> 2 for your proposed extension?
> 
> AFAIK, the function defined by RFC 7396 should "just work".
<pvds>
"just" is the word, for example CBOR allows more identifier types.
I would really like to encourage Carsten to write a CBOR-merge draft.
It looks useful in more and more applications.
</pvds>
> 
>> Do we intent to support two PATCH approaches, RFC 7396 style and 
>> draft-ietf-netconf-yang-patch style?
> 
> Good question.  yang-patch seems a bit more complicated than is needed
> for many constrained applications.  It also is not idempotent.
<pvds>
Their use is also very different.
The one is part of the transport format, the other is embedded in it.
</pvds>
> 
>> IF so, why list need to be supported by the RFC 7396 style since this 
>> approach provide a partial coverage (list without keys and user 
>> ordered list is not fully supported) ? Should we address list only in 
>> the draft-ietf-netconf-yang-patch style?
<pvds>
IMO user-ordered is orthogonal to keyed modifications.
Why punish keyed lists because non-keyed lists do not provide the 
required handles?
</pvds>
> 
> I would expect many constrained applications to make use of maps, which
> typically are represented in YANG as lists with keys*).  So I would
> prefer to be able to address these with a simple, merge-patch style
> update mechanism.
</pvds> so do I</pvds>
> 
> Grüße, Carsten
> 
> *) leaf-lists are a special case where updating isn't quite addressed
> yet by CoMI as far as I know.
<pvds> They represent the same characteristics as a JSON array.
In json-merge you change all array members or none.
Otherwise take refuge to the verbose RFC 6902 approach.
</pvds>