ietf
[Top] [All Lists]

Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

2013-01-25 10:37:58


--On Friday, January 25, 2013 15:34 +0000 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:

...
All of this points out one of my main concerns.  Almost as a
side-effect, the proposal formalizes a number of informal
procedures and mechanisms work pretty well most of the time
but, because they are informal, can be used flexibly without
a big fuss.  If we are going to formalize them, we really
should be asking questions about consensus, exception cases,
and so on... and risk another several steps in the direction
of trying to substitute procedures for judgment,
responsibility, and accountability.

I disagree that doing an experiment formalises these things.
I do agree that more thought would be needed if the
experiment turned up something that we did want to make
permanent.

If I correctly understand the above, it lies at the root of the
problem I was trying to describe.  This is really an experiment
if the effect of deciding we didn't want to make it permanent
was that we were at status quo ante, i.e., as if the experiment
had never been initiated.  If the experimental procedure doesn't
turn out to be useful but we then need to rethink things that
have changed, then we are in rather different territory.   In
other language, if the worst possible consequence of this
proposed experiment would be a harmless waste of time, then a
number of us who are now expressing reservations or opposition
would be saying "ok, try it and let us know how it works out".

To the degree to which you can modify the document to be clear
than the experiment has no permanent procedural side-effects
whether it is judged to be a success or not, the specification
becomes more attractive.

As an example, Barry has initiated an experiment in a different
shepherd write-up regime that moves away from the "yes, I
checked this and yes, I checked that too" format and toward
narrative about notable points.   Because the shepherd write-up
format and requirements have never been part of a formal
procedure, that particular experiment could be initiated without
a big fuss (and, in particular, without a 3933 procedure). I
don't know if the requirements on shepherd write-ups in item 11
of Section 4 is compatible with Barry's template, would require
modifications to it, or would require use of some other template
if one intended to use the Fast Track procedure.  Nor do I know
whether having this provision would frustrate other experiments
with shepherd templates during the course of the experiment.

Similarly, this experiment is heavily dependent on retention of
the IESG's current voting categories and DISCUSS criteria.  Does
it prevent changing those categories and criteria during the
course of the experiment?  Does it give them a status they don't
now have (I think it does, YMMD) and, if it does so, does their
status revert at the end of the experiment?

I think you could add language to the document that would
clarify these things and either eliminate those concerns or
bring them more clearly into focus.

All of that said, I'm about to go back to lurking but want to
make a prediction about a likely outcome of this experiment
(assuming it is approved) that the document doesn't mention.  A
document is moved into this procedure and fast-tracked.  Someone
concludes, as Thomas, Brian, and others have suggested, that
some aspect of the procedure has frustrated adequate review and
that there are bad associated consequences.  They appeal on the
grounds that the things that this procedure shortcuts are
insufficient to ensure fairness given the things that the claim
that there is a running implementation doesn't demonstrate
(e.g., as others have suggested, while "cannot be implemented"
would certainly indicate there is something wrong with a spec,
"can be implemented" doesn't show that the spec is correct or
does what is wanted).   The moment that appeal is filed, the
document in question moves from "fast track" to the slowest
track of all.

    john





<Prev in Thread] Current Thread [Next in Thread>