On May 3, 2013, at 8:59 AM 5/3/13, Thomas Narten <narten@xxxxxxxxxx> wrote: > Just a few points... > > Michael Richardson <mcr+ietf@xxxxxxxxxxxx> writes: > >> I'll repeat what has been said repeatedly in the newtrk and related >> discussions. The step from ID to "RFC" is too large because we are >> essentially always aiming for "STD" rather than "PS". > >> If we are unwilling to bring "RFC" back to a place were it does not >> equal STD, then we need to create a new category of document which >> amounts to "fully baked ID". Things like IANA allocations could occur >> at that point. > >> In the days of dot-boom it was not unusual to see widespread >> implementation very early in the ID process and even interop and >> experimental deployment. While this still occurs for quite a number of >> things (and sometimes it's a problem that the ID can not be changed as a >> result), there is an equal amount of "wait for the RFC to come out". > > I suspect there is a bit of rose colored reminiscing of history. > > The world has changed, significantly. > > For example, there has been massive consolidation in industry. There > simply are fewer entities doing implementations today. 15 years ago, > it was common to see a half dozen or more implementations from > different (often smaller) entities, even before a document got out of > a WG. Nowadays, the cost of doing an implementation (for a company) is > in some sense much higher, and business realities make companies > *very* selective in what they implement and put into a product. Adding a little detail - those implementations have to be prototypes, with the implementing entities willing to make changes in the code prior to shipping product. Once the code has been shipped to customers, there is a lot of resistance to making changes to the specification. > I suspect that the notion that if the IETF published documents more > quickly industry would implement them more quickly/frequently is > wishful thinking. > > Michael Richardson <mcr+ietf@xxxxxxxxxxxx> writes: >> It's what Carsten said. > >> 1) this idea is baked enough for cross-area review to make sense. >> 2) the protocol is not going to change significantly, one could >> implement. >> 3) any future changes need thus to take into account impact on >> existing implementations... BUT that doesn't mean that we can't >> change things. > > Like it or not, 2 and 3 are contradictory. From an interoperability > perspective, the difference between "not change significantly" and > "change a lot" is irrelevant once you have deployments. Change (in the > behavior or wire format) is change and breaks interoperability, no > matter how big or small. Right, so declaring a document a "fully baked ID" might have the perverse effect of freezing specifications at a point where there are still problems. The key issues are the investment in an implementation, the cost of updating an implementation and, perhaps most importantly, the cost of making changes to code that has been shipped in products. > > Hannes Tschofenig <hannes.tschofenig@xxxxxxx> writes: > >> b) There is no interest to research where delay really happen. > > I don't think that is true. Jari has pointed to his work. I think > there is actually quite a lot of understanding of where the delays > are. But fixing them is really really hard. Blaming the "tail end" or > "the IESG" for the problems has always been the easy target. The > reality (IMO) is that the place where improvements are needed is > within the WG and on having authors be more responsive. But history > suggests there are no easy fixes here. > > Randy Bush <randy@xxxxxxx> writes: > >>> A basic question, then, is whether we think these absolute numbers and >>> these proportions of time are reasonable and appropriate for the IETF >>> to be/remain effective? > >> seems pretty reasonable to me. from personal experience, the iesg and >> rfced add useful value. > > +1 It would be interesting to understand the cost of that useful value, and whether the same useful value could be provided elsewhere at reduced cost. "Cost" in this case can be tricky - the useful value in IESG review comes at the cost of asking the members of the IESG to invest 10s of hours per week in careful review of every document. That time requirement contributes to the notion that being an AD is a full time job, which in return reduces the diversity of the pool of candidates willing to volunteer for an AD position. So, there is useful value, but can we get that same value by distributing the load out to the larger community? > > Like everyone, I wish things moved more quickly, but every attempt > I've ever seen that tries to speed things up ends up reducing the > quality or having some other undesirable side effect. > > The bottom line is that getting a good spec requires iteration, and > reviews from a broad set of parties. That is best done > *sequentially*. And given the limited cycles the (volunteer) community > as a whole has, you can't easily change these dynamics. We've seen > many attempts to reduce the overall time by trying to overlap reviews > and steps, but that has the side effect of losing *sequential* > *iteration* (where each new review reviews the previous set of > additions/changes). IMO, overlapping steps is dangerous and leads to > poor quality. > >> being in a many-year process of getting a technology through the >> saussage machine, it's the wg that feels to me to be the most >> inefficient part of the process. i attribute this to email not being >> the best medium, and meetings being too short and too far between. but >> that is purely subjective. > > If you want to speed up the process, focus on how to *increase* the > amount of iteration you get (i.e., revised drafts) while at the same > time *reducing* the time between revised drafts. > > If you look at the delays documents encounter (both in WG and in IESG > review), the killer is long times between document revisions. Focus on > understanding the *why* behind that and what steps could be taken to > make improvements. This claim sounds right to me. Can we document it? The long delays, I'll bet, can be a result of a feedback loop - a long delay before a new revision is might tend to increase the number of changes in the new rev and the details of the draft have dropped out of short-term memory for those who are following the draft. So, reviewing the new rev becomes lower priority and there's a longer delay before comments are published. In general, the draft seems less important and gets a lower priority... > > And finally, a big reason the IESG review is where things happen is > that it *really* is the last time one has to verify that a document is > ready to go. With the limited cycles we all have, there will always be > a tendancy to not deal with a document until the point of "this is > your last chance". Nothing like a *real* deadline to motivate people > to finally deal with a document, before it's too late. And, I'll suggest there is a lack of accountability toward everyone who was supposed to have contributed to a document that is ready to publish when it gets to the IESG . Suppose, for a moment, the IESG approved a document for publication with a serious technical flaw? Who would be accountable? A large percentage of documents reviewed by the IESG receive at least one DISCUSS position. What are the consequences to the document authors, the WG and the IETF? - Ralph > > Thomas >