Should it be possible to deviate "status"?

[rgwilton]

Should it be possible for an implementation to modify the status of a datanode? E.g. to mark it as 'deprecated' in that implementation.

Or possibly to change status 'obsolete' to 'deprecated' to indicate that the node is still implemented.

[mbj4668]

No.

What is needed though is a way for a server to indicate which 'deprecated' and 'obsolete' nodes it has implemented. This can e.g. be solved by requiring all deprecated nodes to be implemented (if not, use deviate not-implemented), and requiring that no obsolete nodes are implemented. Or some other solution.

[rgwilton]

The reason why it might be useful to allow an implementation to deviate add "status deprecated", is to notify clients that some functionality in a 3rd party module that is currently implemented, but will not be implemented in future releases (i.e. and that the server will use a deviate delete in a future release).

Stating that all servers should implement deprecated nodes is potentially OK (except that it is clearly a non-backwards compatible change that needs to be managed).

However, I don't necessarily agree with forcing that obsolete nodes are removed, unless it is shown that obsolete nodes will break backwards compatibility.

One issue with obsolete nodes is: What does it mean if an obsolete node is marked as mandatory and is actually implemented by the server. Should the mandatory statement be removed at the point that it is marked as obsolete? Or is it just ignored?

[mbj4668]

The reason why it might be useful to allow an implementation to deviate add "status deprecated", is to notify clients that some functionality in a 3rd party module that is currently implemented, but will not be implemented in future releases (i.e. and that the server will use a deviate delete in a future release).

I'm not sure that this is the correct solution to the problem. "status" is meta-data, and it's not clear that deviate should be used to change meta-data like this.

Stating that all servers should implement deprecated nodes is potentially OK (except that it is clearly a non-backwards compatible change that needs to be managed).

However, I don't necessarily agree with forcing that obsolete nodes are removed, unless it is shown that obsolete nodes will break backwards compatibility.

I think we should capture this problem (advertise how deprecated / obsolete nodes are implemented) in a separate issue.

One issue with obsolete nodes is: What does it mean if an obsolete node is marked as mandatory and is actually implemented by the server. Should the mandatory statement be removed at the point that it is marked as obsolete? Or is it just ignored?

There is no interaction between these statements. If the server implements a node that is mandatory, the node needs to be present. The status statement is meta-data that indicates if a node needs to be implemented or not. (the advertisement problem needs to be solved)

[rgwilton]

Raised #65 and #66 for changing default behavior of whether deprecated and obsolete nodes are implemented.

Lets just keep this issue to track, in the case where the server doesn't control the YANG module definition:

• should a server be able to indicate that it currently implements a data node, but won't in a future revision (e.g. somewhat equivalent to adding "deviate add 'status deprecated'").
• if this should be supported, then should deviating the "status" statement be the way to achieve this.

[mbj4668]

Raised #65 and #66 for changing default behavior of whether deprecated and obsolete nodes are implemented.

Lets just keep this issue to track, in the case where the server doesn't control the YANG module definition:

* should a server be able to indicate that it currently implements a data node, but won't in a future revision (e.g. somewhat equivalent to adding "deviate add 'status deprecated'").

Might be useful, but this shouldn't imo change the status of the module definition. You're looking for the status of the module implementation in this server.

* if this should be supported, then should deviating the "status" statement be the way to achieve this.

I don't think so.

[BalazsLengyel]

We are forced to implement functionality based on draft ietf models. I would like to mark these explicitly as preliminary/experimental as there is a strong possibility of later NBC changes.
For this I would need to

• use the status preliminary (Preliminary Status Preliminary Status #59)
• add 'status' as a sub statement to 'module' add 'status' as a sub statement to 'module' #28
• be able to deviate the status statement (even on the module level)