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

[John C Klensin <[e-mail]>]

Adding the IESG to the distribution because this is, in several
respects, their problem (and not an ART-specific one, much less
CORE or YANG specific) and IANA because this affects them and
their responsibility to try to maintain working and coherent
registries, and Scott Bradner for reasons that will be obvious.

--On Wednesday, July 6, 2022 11:16 +0000 tom petch
<[e-mail]> wrote:

> <tp>
> In answer to Martin's question with a trimmed list
>...
>> If somebody has a pointer to an official IETF definition of
>> "obsoletes" that differs from this general understanding, I'd
>> appreciate it.
>...
> No I do not but see it come up regularly in WG and with ADs.
> 
> There might be an IESG statement but is not.
> 
> There might be something in the RFC Editor Style Guide but is
> not.
> 
> What there is is a definition in SMIv2 (RFC2578 s.6.1) which
> has been inherited by YANG (RFC7950 s.7.21.2) so that is where
> I point people.

That definition is not only specific to one protocol (and the
one that inherited it) but cannot be applied generally because
it distinguishes between "obsolete" (which is part of the
vocabulary for classifying RFCs) and "deprecated", which is not.
Its use of "deprecated" comes close to what RFC 2026 calls "Not
Recommended" (or possibly "Limited Use") but those are not
categories in the RFC system either (and, of course, the only
ways 2026 uses "obsolete" is a part of the definition of
"Historic" and with regard to what it does to 1602).

This is quite a nice tangle.  It has arguably gotten worse over
the years.

> More generally, I think that the problem arises when authors
> include material with different life cycles in the one
> document.  I see that now with YANG where the one document
> contains: - the initial version of an IANA-maintained module,
> never to be updated, never to be obsoleted - a protocol module
> which will evolve over time with the protocol and with
> experience.

Yes, although it is not clear to me that is the best example.
It certainly is not the only one. 
 
> When it is time to update the protocol module, the
> IANA-maintained module must not be reissued so the original
> document must be torn apart and now part of the original
> document is obsolete, part is not; there is no good way to
> handle this.  What the benefits are to the author of putting
> disparate material in one I-D I know now, but I see the cost
> to the IETF.  This is not peculiar to YANG but could apply to
> other situations involving IANA.

Yes.  See above and below.

> I realise that the discussion about this I-D being divided or
> not is resolved but did think during it that keeping the
> document as one might be storing up such problems in the
> future.

Not just in the future: we have had these problems in the past
and, unless this is sorted out, will continue to do so.  To make
things worse, the relationship between "Historic" and
"Obsoleted" was, IMO, clear at one point but has also become
unclear.  The problems of what Historic or Obsoleted do to a
document that still contains active references (to or from IANA
registries and sometimes other things) that are still useful
(and have not been replaced) have been identified on and off for
years.   There are also problems when the original spec is still
in active use on the Internet but have been declared Obsolete,
Historic, Deprecated, or general bad news.   Of course, the
latter two categories don't exist either, but the documents Tom
cites are not the only place one or the other have appeared in
RFCs without clear "Not Recommended" A/S language.    There have
been multiple proposals to fix all or part of the problem and
reports of multiple conversations within the IESG.   At least up
to the present, the IESG has not been receptive to proposals to
actually clean things up (including rejection of the NEWTRK work
which, for standards track and BCP documents, would have
provided a way to do so).

What can be done?   Absent IESG action (presumably with a
proposal that gets community consensus and with careful
attention to what it updates or obsoletes), under current rules,
we can either live with the situation and the ambiguity it
creates or we (the community) can insist, via appeals if needed,
that no document obsolete another unless it replaces or removes
the need for every bit of the predecessor and updates any
document that refers to the predecessor.   That would probably
kill off the relatively recent idea that one can change the only
some of the provisions of a old spec but obsolete that spec
without repeating the provisions that are not changed and the
somewhat older one of updating by handwaving (i.e., indicating
RFCs that are updated by description of a category rather than
enumerating them.  IANA could also start objecting to adoption
of documents that leave registries in an uncertain state.

Or we (the community including the IESG) could decide this has
gone on long enough and start precisely defining terms and/or
creating and defining new mechanisms.  Sadly, almost 16 years
after the NEWTRK WG was shut down, there has been zero progress
on those fronts unless one counts RFC 6410 as a great success
[1].  Comments posted to the NEWTRK list on 2010-07-15 in
response to the draft that evolved into 6410 might provide
additional perspective on the issue [2].

I have not lost hope that the IETF will address this problem
before I drop out, but it is hard to stay optimistic.

best,
    john



[1] 6410, published in October 2011, specifying two maturity
levels instead of one, was expected to significantly increase
the number of documents moving to Internet Standard.   If one
looks at the two-year periods before and after it, there were,
by my rough count, 8 documents published at Internet Standard
between January 2009 and December 2010 and 2 published at that
level between January 2012 and December 2013.  One could measure
things differently, but that change does not look like a roaring
success.

[2] The NEWTRK archive at
https://mailarchive.ietf.org/arch/browse/newtrk/ appears to be
too old to show an Archived-At header field, but the two
postings on that date are fairly obvious (and the third and
second most recent ones in the archive).