--On Friday, 17 December, 2004 07:32 +0200 Pekka Savola
<pekkas@xxxxxxxxxx> wrote:
> Hi,
>
> On Thu, 16 Dec 2004, John C Klensin wrote:
> [...]
>> I suggest that the RFC Editor's traditional rule about
>> normative references from standards track documents to things
>> of a lower maturity level should apply here as well, even
>> going backwards. If you think there is value in RFC 1517, and
>> it makes normative reference to 1518 and 1519 (which it
>> does-- I just checked), then 1518 and 1519 are live
>> documents. If one reclassifies them to historic, one risks
>> really confusing users/readers and doing a world of harm.
>>
>> If you think it is worth keeping the content of 1517 while
>> removing 1518 and 1519 from the standards track, then I think
>> you need to arrange to replace ("obsolete") 1517 with a new
>> document that stands alone, without those normative
>> references. Such a document could, of course, obsolete all
>> three of 1517-1519, which would eliminate the need for any
>> processing in the "cruft" arrangements.
>
> Correct, though 1517 only has a single References section,
> giving the RFC-editor/IESG some leeway which ones to consider
> normative.
Not exactly. It means one needs to look at the text to
determine whether the statements and requirements of the text
are well-defined and clear without the other documents. In the
case of a document that is written as an applicability statement
on the earlier documents, that is trivially false: the documents
about which the applicability statement is written are, almost
by definition, normative for it.
> If that is what it takes, a 5 page document -- based on
> RFC1517 -- could be easily written which would convey the CIDR
> principles without having to normatively reference the other
> documents.
>
> I think I agree with you that we cannot just recycle 1517 (or
> any other CIDR document) to DS, it'll require some polishing.
But here is where we get into trouble, IMO. The purpose of the
"cruft-cleaning" exercise was described, I think, as permitting
us to identify documents that we could just move to historic or
otherwise lose because doing do didn't depend on making fine
distinctions or generating new documents to pick up the few
remaining useful pieces of old standards-track documents that
have become largely, but not completely, obsolete. We have
always had the possibility of writing new documents that say
"obsolete that", or "update that by removing the requirement for
X", or even "this is the applicability statement by which that
specification should be interpreted", with "always" dating to
long before 2026 (and, if I recall, predating the IETF). The
problem with those approaches to most of these older documents
has been that no one has had the motivation to do the work,
hence, I've assumed, the "cruft" proposal.
If a non-trivial fraction of the putative-cruft documents are
going to require this level of examination by the community, and
then lead to the conclusion that it would be pretty easy to
write a new document to clean up the specific mess, then my own
inference would be that we have demonstrated that there are no
quick fixes and that a rethinking of how we identify and
document what is standard and what is not is really required.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf