On Wed, Oct 12, 2022 at 11:00 AM Sterne, Jason (Nokia - CA/Ottawa) < [email protected]> wrote:
> Hi all, > > IMO an obsolete node is not in the schema: > - any mandatory statement should be ignored (i.e. it is fine for a > datastore to *not* have data for mandatory obsolete nodes) > - trying to write data to that element should be an error (no such node) > > I generally agree with Jan about the deprecated item, although 7950 allows > a deprecated node to not be supported: > > o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. > > IMO this definition has always been incorrect. Balazs has brought up this issue many times. We implement what is useful: deprecated: same as active except may change to obsolete someday. This is what most opensource implements. Using a deprecated item is a warning, not an error. obsolete: must be removed and not implemented. Usage results in an error. Jason > > Andy > > -----Original Message----- > > From: netmod <[email protected]> On Behalf Of Jan Lindblad > > Sent: Tuesday, October 4, 2022 7:32 AM > > To: Michal Vasko <[email protected]> > > Cc: netmod <[email protected]> > > Subject: Re: [netmod] Deprecated/obsolete nodes and validation > > > > Michal, > > > > > we have come across a situation that does not seem to be mentioned in > the > > specs. What exactly should happen if deprecated/obsolete data are > invalid? > > Specifically: > > > > > > Should the whole data be considered invalid? > > > > > > Are there differences between deprecated and obsolete data? > > > > > > If there are mandatory obsolete data missing, is that considered an > error? > > This is the actual problem we are not sure what to do about. > > > > While 7950 and 8407 may not be totally crisp on the subject, the IMHO > "usual > > definition" is that deprecated APIs are still fully functional. The > deprecation is a > > warning to developers not to use it in new designs, and to maintainers of > > existing solutions that depend on it to migrate to a newer API within a > grace > > period (at least a year suggested in 8407). Obsolete APIs, OTOH, may not > be > > (fully) functional. > > > > Every server that declares an API should of course adhere to that API in > order > > to be taken seriously. Breaking that API might even be construed as a > legal > > breach of contract in certain situations. I think that definitely > applies to > > deprecated data as much as current. I would say that obsolete data would > still > > have to stick to the schema, but if some optional obsolete data is > missing, I > > think that is generally acceptable. Obsolete APIs do not need to be > usable, they > > just need to not break other things. But if that obsolete data is marked > > mandatory, the server must provide some valid value in order not to > break the > > schema. > > > > Careful readers will find a lot of personal opinions and few references > to RFCs in > > the above. In my mind, if we don't respect the schema, what is the > schema for? > > If schemas can't be trusted, how do we build the next level of > automation? > > > > Best Regards, > > /jan > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
