Introduce support for critical annotations

[kwatsen]

Similar to #49, but for annotations (RFC 7952), so that something like Juniper's "inactive" annotation can be introduced without requiring a new version of YANG.

[rgwilton]

I'm not sure what this means or whether it is required.

E.g. rfc7952 defines an example annotation extension in 3.1. A server would advertise support for this module in the normal ways.

Is the intention here to have a way to indicate that a client MUST be able to understand that extension/annotation for correct interaction with the server? If so, this might be a YANG library augmentation rather than a YANG language issue. As such, perhaps this should go on a notional YANG library next issue tracker instead?

[abierman]

This is not needed because the RFC that defines the annotation is also responsible for defining conformance requirements. Maybe YANG Packages issue but not YANG language issue

[kwatsen]

The issue is that, currently, clients can ignore annotations they don't know about. Here, if an annotation is flagged critical, then the client MUST grok/support for the annotation.

Note: it is already the case the server must implement annotations defined in implemented modules.

Noting that #49 has this recent comment: A lot of concern for adding things that have to be understood by clients.

[kwatsen]

Juergen: if client doesn't support an (e.g., inactive) annotation, then the server shouldn't return inactive nodes. Jan: +1 Andy: should be IETF mantra Andy: best to make annotation extension (RFC 7952) a real keyword that cannot be ignored James: Metadata annotations should be ignored Kent: how do clients opt-in: 1) pass a param, i.e., with-defaults or 2) handshake? Kent: concern that round-tripping data will be lossy Jurgen: server should know that the client didn't ask for and so doesn't drop the data the client didn't understand Juergen/Andy: this is a bad idea Juergen:

take this to the list before closing