Re: [netconf] YANG attributes in a datastore

[Andy Bierman <[e-mail]>]

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.

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