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.farrell@xxxxxxxxx> 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@xxxxxxx> > >