Re: [core] [art] Obsoletes Re: [Last-Call] Artart last call review of draft-ietf-core-problem-details-05

[Carsten Bormann <[e-mail]>]

On 2022-07-07, at 17:37, tom petch <[e-mail]> wrote:
> 
> "   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
>      implemented and/or can be removed from implementations.  "
> ie we can do without it, forget about it when implementing, operating and such like (unless perhaps we want to research the history).  If the new and old are going to coexist for some time, then that is not 'obsolete’;

That is the definition of the triple “current”/“obsolete”/“deprecated" in RFC 2578.

There is absolutely no bearing on the term “obsolete” that we use to *supersede* (actually, obsolete is a misnomer) **documents**.

Just because a document was superseded (obsoleted), we don’t immediately shut down all systems that implement it.  In that sense the SMI term “deprecated” is closer, but not even that close: The fact that some specifications are no longer repeated in the superseding document bears no quality judgement (unless one is made in the superseding document); the specification is just no longer normative.

> thus SNMPv3 did not obsolete SNMPv2 because the latter was still going to be around.  Likewise, YANG v1.1 does not obsolete YANG 1.0

The latter is an interesting discussion on its own (which I think came to the wrong conclusion: Of course YANG 1.1 obsoleted YANG 1.0, it just didn’t forcibly cut off all YANG 1.0 modules and systems.  Coexisting versions is the normal way to do a transition; nobody in their right mind will start a YANG project with YANG 1.0 now.).  A closer example: HTTP/3 did not obsolete HTTP/2.

Grüße, Carsten