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