Re: Proposed IESG Statement on the Conclusion of Experiments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.  :-)





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]