Re: [netconf] YANG attributes in a datastore

[Andy Bierman <[e-mail]>]

On Wed, Dec 11, 2019 at 12:35 PM Andy Bierman <[e-mail]> wrote:

>
>
> On Tue, Dec 10, 2019 at 11:59 PM Ladislav Lhotka <[e-mail]> wrote:
>
>> On Tue, 2019-12-10 at 17:06 +0000, Kent Watsen wrote:
>> > > OK, but there is no way to prevent "annotation zipcode", etc.
>> > > The use of foo="value" to set and foo="" to delete seems fine, but
>> not sure
>> > > any new
>> > > standards are needed for that.
>> >
>> >
>> > Metadata is not data.  Whilst syntacally possible, and some may attempt
>> to
>> > [mis-]use
>> > it as such, we must hold the line that any IETF-defined
>> metadata/annotations
>> > do not
>> > encode data.
>>
>> While I agree with this, the original question remains: how to edit such
>> metadata in an interoperable way. Deleting the annotation with foo="" may
>> not
>> always work, and indicating deletion with a special magic value is also
>> brittle
>> because such a value is not specified in the annotation's definition.
>>
>>
> I think empty string is the least worst solution for deletion.
> It does not work for type 'empty' os an administrative string that
> allows empty-string in the value-set.
>
>
> RFC 7952 is under-specified wrt. data type encoding
>
> 1) it is not even clear that the type-stmt is a mandatory sub-statement of
> the annotation-stmt.
> There is no example showing this usage.
>
>
I found the last-modified example so disregard comment (1)



> 2) The data type encodings are not correct for the empty type
>
>       The attribute value SHALL be encoded in the same way as the value
>       of a YANG leaf instance having the same type; see Section 9 of
>       [RFC7950] <https://tools.ietf.org/html/rfc7950#section-9>.
>
>
> This does not work for 'empty' type which is encoded as an empty element
> in XML and a null array in JSON.
> This encoding cannot be used in an XML or JSON attribute.
>
> I assume the solution is constrained to only use valid XML, so inventing
> some hack to identity the deletion operation
> will not work (unless it is valid XML)
>
>
>
> Lada
>>
>>
> Andy
>
>
>> >
>> > Kent // contributor
>> >
>> >
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>>