support for YANG annotations (attributes)

[abierman]

RFC 7952 defines the 'annotation' extension.
This should be supported with a new namespace in the SID file.
This will allow attributes to be sent with the YANG data.
There are some attributes in use pre-7952 that do not have YANG modules.
A mechanism is needed to support SID file numbering even though
no YANG module exists (special range of manual assignments?)

Hoping for a CBOR tag and an algorithm to specify the order of data node/attribute node.
We have attributes that need to be known before the child nodes are parsed.
It is very convenient that XML has a start tag for this purpose.
The JSON encoding of attributes is not supportable because everything is unordered

[abierman]

I am working on an implementation soon.
Should I follow the design in JSON encoding?
Hoping that Carsten will write a draft.
The CBOR version should allow a string or SID identifier to be used

[cabo]

I wrote

https://cabo.github.io/yang-metadata/draft-bormann-cbor-yang-metadata.html

Please have a look, in particular into the two "questions" inside.

I wouldn't mind submitting a -00 for Wednesday's CBOR WG meeting.

[cabo]

There are some attributes in use pre-7952 that do not have YANG modules.

Would it be possible to write a YANG module for these now?
Is there a list somewhere?

[abierman]

I am trying to understand the draft.

Most attributes do not have an 'annotation' defining them.
There are no SID values assigned to annotations.
It would take the IETF 5 years to assign them.

How do attributes get encoded if no SIDs and only names?

JSON uses "@" for all attributes for a container or list.
It uses @foo for a leaf or leaf-list or anydata.

[cabo]

The actual metadata annotations go into the metadata map.
These have YANG names as keys, and we'd need to provide SIDs for those YANG names.
Are these not defined in a module?

The proposed structure does away with the @ juggling by attaching he metadata to the actual YANG data nodes.
So there is no need for a new name as the existing name covers both the usual YANG data and the metadata annotations.

[abierman]

The JSON version is hard to implement correctly so we don't.
It is too much work to save the extra state data so attributes can be received in any order.
This is not acceptable.

The XML approach is the only way CBOR should work.
All attributes are present in the start-tag.
The same procedure can be used for all nodes:

  1) identify and start node
  2) parse all attributes for node
  3) parse node content
  4) end node

Adding step (2) is not backward compatible with the YANG/CBOR RFC

[core-bot]

Hi Andy

On 16. Apr 2024, at 19:38, Andy Bierman ***@***.***> wrote: The XML approach is the only way CBOR should work. All attributes are present in the start-tag. The same procedure can be used for all nodes: 1) identify and start node 2) parse all attributes for node 3) parse node content 4) end node

This is precisely what my draft-to-be does. Nodes with attributes are encapsulated by CBOR Tag 109, which first has a metadata map with the attributes, and then the regular representation of the data node.

Adding step (2) is not backward compatible with the YANG/CBOR RFC

Not sure I understand this one. Grüße, Carsten

[cabo]

I added a name-based example to the existing SID-based ones.
I submitted the draft now:

https://datatracker.ietf.org/doc/draft-bormann-cbor-yang-metadata/
https://www.ietf.org/archive/id/draft-bormann-cbor-yang-metadata-00.html

[abierman]

I will try to catch up on the new CDDL you are using in the draft.
The special tag approach makes sense. It is better than the "@" hack.

I assume a receiver that just knows the YANG/CBOR RFC will not expect this tag and metadata map.
Is that correct?

[cabo]

On 18. Apr 2024, at 19:30, Andy Bierman ***@***.***> wrote: I will try to catch up on the new CDDL you are using in the draft. The special tag approach makes sense. It is better than the "@" hack.

Right.

I assume a receiver that just knows the YANG/CBOR RFC will not expect this tag and metadata map. Is that correct?

That is correct. To introduce this feature, you’d need YANG-CBOR receivers to replace Tag 109 by its second array element. (This is less work than the standin functionality for timestamps and IP addresses, which I would implement at the same time.) Grüße, Carsten