Responses to some points below but I'd really like to ask
people to consider a few things here:
- what's proposed is an experiment, it'd likely get tried out
a few times and won't consume any huge resource anywhere
- its optional, WG chairs that want to try it could, those
that don't can just ignore the whole thing
- argument that there are other or better process issues to
address is misdirected
- on a meta-level, if every process proposal, even small
experiments like this, generates huge concerns then we're
not in a good place and it seems to me that we are in that
bad place (that's not an argument to do this experiment,
but just an observation)
On 01/25/2013 10:54 AM, Loa Andersson wrote:
Running code is valuable, but does not normally replace review.
This proposal doesn't "replace review." Its an optional way
to get some of that done in parallel with a few other rule
tweaks.
On 01/25/2013 10:30 AM, Brian E Carpenter wrote:
Speaking as a Gen-ART reviewer, I am indeed worried by this aspect.
I feel I would have to spend much longer reviewing a draft if I
knew it had not been through WGLC.
Its an experiment that would be used for a few drafts, your
concern might be justified if this were proposed as a
permanent change (it's not) that applied to many drafts (it
won't ever IMO, but certainly not during the experiment).
On 01/25/2013 10:02 AM, t.p. wrote:
This proposal asks the ADs and WG Chairs to do more work
It does not. WG chairs *choose* to take this route if they
want to. The timers and checking the implementation could
increase the workload for the responsible AD at a time not of
her choosing and its the timing that's more pertinent but not
so bad since ADs are already clearly gullible enough when
it comes to additional workload:-)
On 01/24/2013 06:34 PM, John C Klensin wrote:
As co-author of the process experiment model, I also object to
its use when it is not demonstrably necessary,
That's a really weird objection. I just re-read 3933 and it
says nothing whatsoever like that, in fact it says 'This
specification permits and encourages the IESG to adopt and
institute "process experiments"...' and the whole tenor of
the RFC is that stuff ought be tried out.
John also said:
this document moves a number of informal IESG
procedures -- including the DISCUSS criteria and even the
Shepherd report requirements (now Informational in RFC 4858 plus
a number of less formal "statements" and "templates" that have
sometimes changed rapidly) -- into the status of formal
procedural requirements
That's just wrong. It includes those as part of an experiment
that is optional to use which I don't think qualifies as
"formal process requirements" in any useful sense.
And lastly...
In my experience in the IETF, we almost
never allow a individual submission document that is obviously
very controversial to turn into a extended debate on the IETF
list with the author trying to refute every comment.
"Trying to refute every comment" is (IMO wildly) inaccurate.
This was proposed a couple of months ago. Some people liked
the idea of trying it out, others didn't. I'm following up
on that as described in 3933. Every proposal to do with
process seems this controversial unfortunately, even teeny
little ones like this. I'd love if it were otherwise.
And if Adrian or the IESG decide we should not go ahead and
try this particular experiment, that's just fine and the
world will not end. (And nor will it end if this experiment
is run.)
What's less fine, but I suspect is also the case, is that
any proposal for process change would get the same kinds
of negative reception from a similarly sized set of folks
and with similarly good, bad and irrelevant arguments
against whatever change or experiment is proposed.
Regards,
S.