Re: Proposed IESG Statement on the Conclusion of Experiments

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

 



+1


/d

--
Dave Crocker
bbiw.net

via mobile



-----Original Message-----
From: Scott O Bradner <sob@xxxxxxxxx>
To: adrian@xxxxxxxxxxxx
Cc: wgchairs@xxxxxxxx, ietf@xxxxxxxx
Sent: Thu, 19 Apr 2012 1:48 PM
Subject: Re: Proposed IESG Statement on the Conclusion of Experiments

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]