Stephen did well to respond quickly! 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.farr...@cs.tcd.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. > 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. 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.) >... > 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. >> 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. 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. 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... >> 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! >> 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. ;^) >... > 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). 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!". -- John Leslie <j...@jlc.net>
