ietf
[Top] [All Lists]

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

2013-01-14 15:35:25

Hiya,

On 01/14/2013 06:52 PM, John Leslie wrote:
   Stephen did well to respond quickly!

Responsive with dodgy ideas - sounds like me:-)

   I will respond to most of his comments in private email, rather than
increase the noise-level on the <ietf> list. But a couple of points
deserve a better community understanding...

Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
...
Well WGLC isn't part of 2026, and others have argued that that means
that there's no need for this to even be a process-experiment...

   I think the Narrative Minutes show the IESG members questioned why
Stephen didn't simply bring things to IETF LastCall without a WG
LastCall. I invite readers to peruse the Narrative Minutes yourself
and see if it helps your understanding of what Stephen wanted beyond
that.

   But clearly the IESG has (not-yet-declared) consensus that Stephen
could do that without needing an experiment.

Sorry John, I'm lost. There was no WG here and hence no WGLC.
The IESG hasn't as far as I know reached any consensus for
or against this approach, whether declared or not.

The IESG chatted about this on an informal telechat just after it
was previously discussed on this list, and some ADs had concerns
about the experiment. Others seemed less concerned. Some changes
to the draft resulted from that discussion, but my guess is that
the existing concerns are not fully resolved.

On last week's telechat Adrian as sponsoring AD asked if anyone
felt this was implausible enough that an IETF LC ought not be issued
(as RFC 3933 says) and there was no objection to that. So we're
now at IETF LC for this draft. Again, there's no implication that
the IESG like or will approve this experiment.

My take on this is that yes, this is a proposal for an experiment
that changes what we do now with WGLC, and its one I think we ought
try.

   Clearly our process documents leave a lot of room for something
other than a formal WG LastCall -- but whatever is done is under the
management of the normal WG Chairs. 

As would be the case during this experiment. Its the WG chairs
that initiate the fast-track process and that's very clear in
the draft.

I don't really understand how
Stephen wants to change that; but the his draft reads as if he
wants to take over responsibility for any last WG comments from the
WG Chairs. (It's _hard_ to believe that's what he wants -- the AD
job seems quite large enough without taking on such responsibilities.)

Indeed that'd be hard to believe. Again, the WG chairs initiate
this, so I'm confused how you think I could think that. I think
the experiment would put some additional time-pressure on ADs
but doesn't really add to the absolute amount of text review work
for each draft except in terms of dealing with/checking the
implementation, which is new.

... 
Today, the convention is that the responsible AD ballots yes to
kick off the process of IESG review. This is just saying that
that AD might start IESG review with a different position (I
would guess a no-objection, though there are exceptions to
everything;-) because that AD hasn't had time to fully evaluate
the draft. That AD might e.g. have asked someone else to check
the implementation (allowed by this draft) but might want to
do a fuller review during IESG evaluation before presumably
balloting yes. Requiring the yes ballot up front is just a bit
too demanding with the fast track timers.

   This text would better explain what Stephen was trying to say
in item 7. I'm not convinced it needs to be said at all -- this
is about internal IESG process; and most IETF participants neither
understand internal IESG process nor have any desire to learn it.

Fair point. OTOH, I think its a real aspect of the experiment so
ought be mentioned even if that's not very useful for most readers.

I don't believe "running code" is even particularly helpful in
run-of-the-mill Proposed Standards. 

Right. I guess that's where we disagree.

I've seen it _seriously_ harm
the documents in cases where the "running code" has shipped and
there is reticence to change it: no matter how many weaknesses are
pointed out, you can't get WG consensus to change the spec.

I agree that happens. I don't think this'll change how often.

   At first blush, I would expect WG Chairs to try this experiment
when they happen to already have implementations (and not try for
it when they don't). The reticence to change shipping code is
both very human and good generic-management: I don't expect this
reticence to go away.

And that'd be fine. This experiment is not intended for all drafts.

   I _do_ think this experiment would make the problem worse. Any
change to shipping code involves some level of management decision;
and squeezing such management decision into two weeks ensures it
won't happen absent _customer_ complaints.

Reasonable point. But you've conflated shipping code and running
code and also code changes with product release cycles. All of
those can be independent things so I don't think your conclusion
holds.

   Am I being unfair to talk about squeezing that decision into
two weeks? Possibly I am... But this whole experiment _is_ about
squeezing the timeframe; and in my experience squeezing timeframes
tends to crowd out careful consideration. YMMV...

Not unfair, no. Just incorrect:-)

In cases where "running code" has proven helpful, it's my
honest opinion that the spec has become way too complicated (and
thus the "running code" has proven which parts are unworkable).

Hmm. I've had somewhat the opposite experience, so I guess
YMMV. I've not gone to dig up examples though but in DKIM I
think we ended up with a simpler spec. due to some folks
doing good work with running code before and during the WG's
processing of the drafts.

   Yes: DKIM clearly had become too complicated. Stephen and I
agree there!

Heh. I think DKIM is pretty simple in itself actually. Mail
of course isn't, nor is spam.


IMHO, we designed a separate "Proposed Standard" step to get
a specification published quickly without delving into the many
questions that arise when writing actual code. 

That's fair. I think this experiment partly reflects one way
in which the standards process theory and IETF practice have
diverged over the years. The bar for PS is mostly now much
higher than was the original intent. I think that in some
cases, this experiment might lower that bar a little.

   I'm always fascinated at the things folks think will "lower
the bar" for Proposed Standard. ;^)

Yep. Its a process-proposal, and thus involves tilting and
windmills:-)

But more to the point, I think that in a lot of cases where
the IETF has done a good job, there has been running code
before the WG even started...

   This perhaps explains where Stephen is coming from. Such
cases do exist; and it is arguable that the process Stephen has
describe in this draft are well-suited to such cases (though I
would still have to quibble about some details).

Right.

   I remain unconvinced, however, that fast-tracking the cases
that start from running code is a good use of WG efforts. Such
cases seem better suited to Independent Submissions from a
design team (which would _greatly_ speed the process). When
a WG is formed, IMHO, they should be encouraged to look at the
problem from some quite different angles, in search of a way
to "Simplify!".

Maybe. But that's a different proposal, perhaps a better one,
but a different one, and this is the one on the table right
now. (I make no claim that this experiment is the best
possible or anything like that.)

Cheers,
S.




--
John Leslie <john(_at_)jlc(_dot_)net>



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