Dave,
--On Wednesday, 29 March, 2017 07:34 -0500 Dave Crocker
<dhc@xxxxxxxxxxxx> wrote:
> On 3/29/2017 7:19 AM, Yoav Nir wrote:
>> I question how useful it is. The obsoletes/obsoletedBy
>> relationship is semantically overloaded. Consider the header
>> of RFC 4306:
>
> Yoav,
>
> Thanks for the thoughtful (and quick) response. Yes, the
> total model and application of its details are more
> complicated. But I found myself relying on a very simple
> distinction:
>
> If someone wants to do research and explore old stuff, they
> can still do that. The can still merrily wander the link
> sequences.
>
> However "Obsoleted By" means "don't use the old stuff".
Sadly, while it should, it doesn't. The community has allowed
several situations to occur in which a document is obsoleted,
some of its sections are not replaced with newer material, and
those sections continue to be referenced, occasionally
normatively, from other documents. An even more common case
occurs when
* RFC X is published
* RFY Y is published sometime later, normatively
referencing RFC X
* RFC Z is published, obsoleting RFC X.
It is now unclear whether, until RFC Y is replaced, whatever it
specifies should be used in conjunction with the relevant parts
of RFC X or with the implementer's guess as to what the
specification of RFC Ybis, referencing RFC Z and modified
consistently, would be. Sometime that is easy and obvious,
sometimes, especially when Z changes protocol behavior or data
structures from X rather than just being a clarification, it is
not.
To make things a bit more complicated, replacement of a document
is not always one-one. We consolidate documents in
updates/replacements, sometimes we split them, and more complex
relationships, while not common, have happened. In some of the
forking cases, we have part of RFC A replaced by RFC C and
another part replaced by RFC D and, because the historical
metadata doesn't make it convenient, list only C as doing the
obsoleting so a simple link based on the metadata would be
misleading.
One can sensibly argue that we shouldn't let those kinds of
entanglements happen. But it is what we do. In the extreme
case, the normative reference from Y to to X should imply that
the request to publish Z should go into normative reference hold
in the RFC Editor queue until Ybis is ready for publication.
But we don't do that. More realistically, I think the real
question is "what do I need to use to properly implement this
specification today?". Explorations of that question are what
lead us to summary roadmap documents or associated Applicability
Statements. They are also what led to to the "ISD" proposal and
similar ideas, where the _standard_ (even, that WG concluded, at
the Proposed level) would be a summary document independent of
RFC numbers with appropriate links and, as necessary,
explanation.
In the past, I've argued that, if a document is published with
"Obsoletes XYZ", it needs to contain a section that sorts all of
those issues out. I've gotten zero traction.
I fear that, unless there were a case by case analysis of each
document with an "obsoletes" tag, there are enough non-obvious
cases around to create significant risk that you idea would
cause more harm than the added convenience it would provide.
On the other hand, if the incoming IESG were convinced that this
is enough of a problem, it wouldn't be hard to dig the ISD and
other NEWTRK proposals up and update and re-post them.
best,
john