On May 3, 2013, at 8:59 AM 5/3/13, Thomas Narten
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:
Just a few points...
Michael Richardson <mcr+ietf(_at_)sandelman(_dot_)ca> 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(_at_)sandelman(_dot_)ca> 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(_dot_)tschofenig(_at_)gmx(_dot_)net> 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(_at_)psg(_dot_)com> 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