I support the thoughts expressed by Eliot Lear, Scott Bradner,
Lars Eggert and several others that research often does not
have a crisp conclusion and that not all Experimental RFCs
describe a scientific experiment. For example, Transaction TCP
(T/TCP) research was active in at least two different eras.
The last time, there was a conclusion that the security risks
of the then-available T/TCP specification outweighed the
advantages of that particular T/TCP specification.
There are a few situations where it might well be sensible
to publish an Informational RFC that deprecates, but does NOT
de-allocate, the code-point for an IETF standards-track protocol
or for an IETF-track Experimental protocol. An ICMP message
unique to IPv7 might well be such a code point, and some of
Fernando Gont's recent proposals also might well be,
but extreme caution needs to be used in this area.
As a counter-example that supports the phrase "extreme caution",
I'll mention a real-world current problem in this exact area.
A while back, the IESG moved RFC-1108 to Historic, over the
objections of a few of us who are familiar with it. However,
RFC-1108 continues to be implemented in new platforms, continues
to be deployed, and to my understanding has much more deployment
today than it did when the IESG deprecated that specification
(i.e. deployment continues to grow, in multiple countries,
on multiple continents, including by non-US organisations/governments,
even though its total deployment size remains small due that
specification's niche applicability). A better approach to RFC-1108,
one that I suggested to the IESG at the time, would have been
to move that RFC from standards-track status to Informational
status due to its very limited applicability.
Separately, the draft proposed IESG Statement is not sufficiently
clearly scoped. At a bare minimum, the scope for that statement
needs to be clearly and crisply limited to IETF-track RFCs.
For example, RFCs published on either the IRTF track, Individual
Submission track, or legacy-track (e.g. older publication date and
never present in any version of "IAB Official Standards") ought to
clearly and obviously be outside the purview of the IETF/IESG
and also outside the scope of the IESG Statement. For a tiny few
legacy-track documents, it might be appropriate for the IESG
to publish an Informational RFC or a BCP recommending against
implementation and/or deployment of a particular RFC, but it
would NOT be appropriate for the IETF/IESG to re-classify the
status of any RFC that is not OBVIOUSLY on the IETF track.
I agree that the IESG might well want to put together IETF
guidelines for IETF-sponsored experiments and publish those
after suitable community review. It might well be legitimate
for most or all IETF-sponsored experiments to reach a conclusion.
However, generally speaking, I would expect the bulk of the
experimental work to be either in IRTF-sponsored research --
or in non-I* research -- either one of which routinely results
in (IRTF track or Individual Submission track) Experimental
status RFCs.
I also share the surprise of several other folks that the IESG
appears to be trying to volunteer itself for more work.
Lastly, the time window allowed for comments on this proposal
is clearly too short. This should have been at least a 4 week
Last Call item, because it really does have broader implications.
Yours,
Ran Atkinson
PS: Unlike some other folks, I imagine this question was begged
mostly by some recent proposals by F. Gont. The IESG would
help itself by being a bit more transparent in outlining its
motivations for this proposal at this moment in time. :-)