Re: Proposed IESG Statement on the Conclusion of Experiments

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

 



I agree with everything Scott wrote. I don't see a good reason for removing code points from a registry, unless very exceptional cases (range is almost full need more space), which could be processed as one-off, not as a regular process.

Marc.

Le 2012-04-19 à 16:48, Scott O Bradner a écrit :

> encouraging a report is fine
> 
> retracting the code points seems to add more confusion than it is worth unless the
> code space is very tight
> 
> and I see no reason to obsolete the experimental rfc or move it to historic status unless the report is
> that some bad thing happens when you try it out - updating the old rfc is fine
> 
> and I agree with Elliot about the nature of research - it is very common to not
> reach a conclusion that something is bad (as in bad for the net) - and that is the
> only case where I think that an experiment should be flagged as a don't go there situation
> 
> Scott
> 
> 
> On Apr 19, 2012, at 4:31 PM, Adrian Farrel wrote:
> 
>> All,
>> 
>> The IESG has been discussing how to tidy up after Experimental RFCs.
>> 
>> We have developed the following draft IESG statement. This does not 
>> represent a change in process, and continues to value Experimental RFCs
>> as an important part of the IETF process. It does, however, seek to 
>> encourage documentation of the conclusion of experiments.
>> 
>> We are aware that there may be other discussion points around 
>> Experimental RFCs, and we would like to discuss these, but we also
>> believe that there is merit in making small, incremental improvements.
>> 
>> The IESG would welcome your thoughts on this draft before they approve
>> the final text on April 26th.
>> 
>> Thanks,
>> Adrian
>> 
>> =============
>> 
>> IESG Statement on Conclusion of IETF Experiments
>> 
>> 
>> Experiments are an established and valuable part of the IETF process.
>> A number of core Internet protocols were first published as Experimental
>> RFCs while the community gathered experience and carefully investigated
>> the consequences of deploying new mechanisms within the Internet.
>> 
>> In the case where an experiment leads on to the development of a      
>> Standards Track RFC documenting a protocol, the new RFC obsoletes the 
>> old Experimental RFC and there is a clear conclusion to the experiment.
>> 
>> However, many experiments do not lead to the development of Standards
>> Track RFCs. Instead, the work may be abandoned through lack of interest
>> or because important lessons have been learned.
>> 
>> It is currently hard to distinguish between an experiment that is still
>> being investigated, and an old experiment that has ceased to be of
>> interest to the community. In both cases an Experimental RFC exists in
>> the repository and newcomers might easily be misled into thinking that
>> it would be helpful to conduct more research into an abandoned
>> experiment.
>> 
>> In view of this, the original proponents of experiments (that is, 
>> authors of Experimental RFCs, and Working Groups that requested the
>> publication of Experimental RFCs) are strongly encouraged to document
>> the termination of experiments that do not result in subsequent
>> Standards Track work by publishing an Informational RFC that:
>> 
>> - very briefly describes the results of the experiment
>> 
>> - obsoletes the Experimental RFC
>> 
>> - if appropriate, deprecate any IANA code points allocated for the 
>> experiment
>> 
>> - may request that the Experimental RFC is moved to Historic status.
>> 
>> If there is no energy in the community for the producing such an
>> Informational RFC, if the authors have moved on to other things, or if
>> the Working Group has been closed down, Area Directors should author or
>> seek volunteers to author such an Informational RFC.
>> 




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