> On Feb 27, 2019, at 11:48 AM, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Feb 27, 2019 at 04:09:17PM +0000, Kent Watsen wrote: >> >> >>> On Feb 27, 2019, at 6:16 AM, Balázs Lengyel <[email protected]> >>> wrote: >>> >>> feature oldFeature { >>> status obsolete; >>> } >>> leaf myTimer { >>> if-feature oldFeature ; >>> mandatory true; >>> config true; >>> status current; >>> type string; >>> } >>> So should I configure myTimer or not? I assume yes, correct? >> >> This issue is captured here: >> https://github.com/netmod-wg/yang-next/issues/27, which was updated as of >> this morning with this very example. >> >> Of course, the problem is in RFC 7950: >> >> o "obsolete" means that the definition is obsolete and SHOULD NOT be >> implemented and/or can be removed from implementations. >> >> I recommend replacing "SHOULD NOT be implemented" with "is not implemented". > > When an IETF WG decides to obsolete something, I am forced to break > old clients because of this decision? Note sure this makes business > sense (says an academic). > > There is a huge difference between modules where the implementors have > change control over the modules and modules where change control is > far outside the implementors hands and where clients and servers are > implemented by different organizations in an open and largely > uncoordinated way. We always have to keep this in mind when we create > rules. > > The SHOULD NOT allows a server implementor to take a well-informed > decision that there are old clients you care about and that this makes > a business case for supporting obsolete definitions on a server. > > Another aspect here is that we do not make a clear distinction between > server and client. It can very well be that "deprecated" and > "obsolete" mean slightly different things to servers and > clients. (Servers tend to have a natural desire to not break clients > unnecessarily.)
But a server can choose to not implement that revision of the module or, with https://github.com/netmod-wg/yang-next/issues/63 <https://github.com/netmod-wg/yang-next/issues/63> deviate the "status" statement. I want "obsolete" to mean as it does everywhere else: out of use, no longer supported, not expected to work, etc. Perhaps there is a line between having "status obsolete" versus disappearing the node altogether? Maybe within the same "major" version (to use a sem-ver term), "obsolete" leaves it to the server's discretion, whereas the next major version disappears the node? If so, then there should be a way for the server to indicate which discretionary choices it made. I'd suggest that "obsolete" defaults to "not-implemented" and thus only servers that want to continue support for the node need to indicate anything. A deviation would be a good fit for this. Kent // contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
