Hi Brian, On 01/15/2013 10:55 AM, Brian E Carpenter wrote: > On balance I think this experiment is safe to carry out, and therefore > probably should be carried out. There are a few comments below. > > However, I would urge the IESG to update the page at > http://www.ietf.org/iesg/process-experiment.html, including current > status of the experiments mentioned, and the history of concluded > experiments, which I'm pretty sure was there a few years ago. > At least, the history of the RFC 4693 experiment isn't there. Fair point. I've noted that that ought happen in the working copy, [1] just so's we remember to look at it again later during/after this LC. > > 1. It seems clear that the explicit mention of GPLv3 should be removed. > It's contentious for a number of reasons. The phrase "e.g., under a Free > Software or Open Source license" seems necessary and sufficient. Ok, I reluctantly fold on that since I got other off-list comments to the same effect. My working copy now says: There is no requirement here as to the licensing of the implementation whether open- or closed-source. At one end of a spectrum the source code of the implementation could be available under a Free Software or Open Source License. Publishing the code source under such a license permits the public at large to read, compile and run it and removes all ambiguity about the existence of the implementation. At the other end of the spectrum, a public statement by an employee of a known vendor, or the publication of an interoperability report from multiple implementers, can give sufficient confidence. In all cases the WG chairs and AD do need to be able to say why they consider the implementation is appropriate for fast-track processing. > 2. There's a slight inconsistency between the mention of interoperablity > in a few places and the proposal to use *one* implementation as a > criterion. It doesn't seem unreasonable to use one implementation > as a criterion for PS, since a criterion for IS under RFC 6410 is > multiple interoperable implementations. But we should not imply that > one successful implementation implies anything at all about > interoperability. I think this needs to be stated quite explicitly: > > Note that the existence of one implementation does not in any way > demonstrate the interoperability required for advancement on the > standards track [RFC6410]. Seems ok to me. Added to working copy. Changed the reference to BCP9 which includes 6410. > 3. However, I remember very bad experience some years ago with the > 6NET project attempting to deploy Mobile IPv6 based on implementations > of several different versions of the main MIPv6 draft. They simply > could not interoperate. There is a risk that fast-tracking a draft could > actually be damaging in such a situation. I think we would need a clear > consensus that the draft is stable as well as viable. I suggest adding > an item in section 4 something like this: > > The WG chairs and responsible AD must be satisfied that the draft is > in a stable state and that significant technical changes are unlikely > to be proposed in the near future. That would be reasonable to add, yes. But, there are lots of other similar things that could be reasonable to add, that cumulatively might result in the experiment not happening (e.g. things from Olafur and Stephan yesterday). While this one is less of a deal maybe, I'm still reluctant to add it because if we add everyone's favourite nugget of wisdom, then we'll likely end up with something unworkable. Would it be reasonable to either add a section on "stuff that came up in IETF LC that the IESG ought consider after the experiment" or else to put this kind of thing in the wiki for the experiment rather than state it as a rule or guidance in the draft? Cheers, S. [1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-ft-04.txt > > Regards > Brian > > >