--On Friday, January 07, 2011 21:26 -0800 Dave CROCKER
<dhc2@xxxxxxxxxxxx> wrote:
>
>
> On 1/6/2011 12:40 PM, Bob Braden wrote:
>> Historic might imply that they were once in service, but have
>> later been replaced/deprecated.
>
>
> We assign labels to indicate the status of the specification,
> not the status of a service that might use it.
>
> We say 'experimental' to mean that we thinks it's ok to play
> around with the spec and maybe that we are hoping to get
> further information about it. But it also means that we very
> much caution about use. It's our "caveat emptor" label.
>
> We say 'historic' when we frankly think the spec should now
> not be used, for whatever reason and no matter its prior
> status.
>
> These both are affirmative labels. I too do not think we
> should use them for "housekeeping" and the mere fact that a
> specification is not used does not mean that it shouldn't be
> used.
Dave (and Bob),
I'm clearly on record as believing that it is time we do
something about the category labels we have, either to improve
clarity and distinctions or to supplement or replace the
categories with narrative. I've also got doubts as to whether
this sort of reclassification effort is worth the energy it
takes (an opinion I think I expressed privately to Mykyta very
early in the process). To some extent, if someone cannot figure
out that they should at least ask a lot of questions about a
protocol that was identified 20+ years ago as Experimental and
that has not been followed up on since, maybe they deserve
whatever happens to them.
But, in a context in which we have stretched "best current
practice" to including both IETF procedures and ideas about how
things should be operated and other statements that have not
been tested in practice a all, we disagree a bit about the
meaning of terms. I think "experimental" isn't just a warning
label, it is also an implicit invitation to experiment. Here,
if the experiments were performed (and some were) and the
results written up, recommendations with those results might
well have said "don't use this in this form". That would have
met most criteria for reclassification to Historic.
It has long been my personal view that, while the automatic
timeout provisions of RFC 2026 have never been successfully
applied to standards-track protocols, a somewhat similar rule
should apply to Experimental work: either some progress --a
report on the experiment, an update to the protocol spec
(possibly including a move to Standards Track but not
necessarily), or something equivalent occurs in some reasonable
period of time, the spec automatically moves to Historic
(because it is the only nearly-appropriate category we have) as
no longer of interest.
Interestingly, NETBLT seems to be a special case of just that
situation: it was implemented, small problems with it were
discovered in a different environment, changes were made, and a
revised spec was published outside the IETF under another name
(there was also an I-D within the IETF pointing to that spec,
but it was allowed to expire without any action). If Mykyta (or
someone else) is willing to do the work, and an appropriate AD
is willing to sponsor it or assign review to a WG, then I see
considerable advantage in publishing that newer spec or a
pointer to it, preferably with an analysis of limitations, as
either an Informational or Historic record for the community and
using that document to obsolete the original experimental spec.
Documenting ideas that didn't quite work, or that work only in
specialized environments with a good description of those
environments, is the only way we can make progress rather than
repeating ideas that are known to be failures or limited in
scope.
As far as the others are concerned, the procedures don't work
the way I've described above. While I wouldn't personally want
to invest significant effort in reclassification (and didn't put
significant effort into the successful "de-crufting" effort of
several years ago), I also don't see any harm in it if Mykyta
(or someone else) wants to invest the energy and can find
appropriate AD sponsorship. I only wish that we had not made
reclassification to Historic, even of experimental specs to
which no one has paid attention for years, into a painful
process that requires nearly as much work as getting a
standards-track specification approved. There is actually
nothing in RFC 2026 or related documents that requires that much
effort.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf