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

["Scott O. Bradner" <[e-mail]>]

I agree (as one might expect) with John’s description of the issue and am maybe less optimistic 
that he indicates he is that the IESG will actually address the issues

Scott

> On Jul 6, 2022, at 4:43 PM, John C Klensin <[e-mail]> wrote:
> 
> 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).
> 
>