Without responding point-by-point, I'll just say that I'm all for
figuring out how to get earlier and wider implementation, and also wider
early review, and also for minimizing late process glitches. (I used to
say a WG was in FIN-WAIT status when it was all but done but waiting for
some bit of process to finish). A lot of calendar time that a WG
spends prior to RFC publication isn't adding value to the document
because of pipeline stalls.
And it's very difficult to stop vendors from shipping pre-RFC protocols.
We don't have a protocol police, and we move too slowly. If we don't
adapt, other SDOs will do more of our work.
yup, it's a race to the bottom :(
That's not a good argument for not attempting to improve the rate at
which we get things done.
Again, all for improving the rate but only if we're doing quality
work. If we're not doing quality work, everything else is
pointless. And quality isn't measured by the number of RFCs we
produce, perhaps closer to the opposite.
So the way we get more review is to encourage deployment even earlier in the
draft cycle? Seems like an odd way to do it.
It's the opposite. In order to get to "deploy earlier" (see below),
first get more review than you would have had we not had that option.
Well, that certainly sounds a lot better than just having a WG tag its
documents in a way that will effectively encourage early deployment
without review.
Mind you, a stability attribute needn't be about deployment, but a) a
guide to participants about what changes are considered acceptable going
forward, b) an indication to implementors that the protocol is mature
enough to implement (not necessarily deploy).
Making a clear distinction between "ready for test implementation" and
"ready for deployment" sounds like a step up from what we're doing now.
But maybe something like this: What if WGs labeled drafts with
"preliminary" (not ready for implementation), "ready for outside review"
(after WG thinks the overall shape of the proposal is good, inviting
explicit review/feedback from IETF in general and others), "ready for test
implementation" (after favorable review and IESG approval), "WG last call
Eh?? Can't test until you have IESG approval? Did you really mean
that?
To clarify, people can certainly test at any time, but I think having
cross-area review and IESG approval is about right before the WG can
publicly declare it's stuff ready for testing. The point is that if
people are going to invest significant implementation effort there
should be some reason to believe that the WG really is going in that
direction and the broader community will back it. I'm not saying it
should be the same degree of IESG approval that happens prior to RFC
publication. It's more like "ok, now that we think we know what this
protocol is going to look like, let's get community buyin on this
direction". Part of the idea would be to get early feedback about how
this protocol might, say, fail to adequately deal with security, or
conflict with some other protocol, or have scaling problems, or be
abusive of lower layers, or be difficult to manage. Much better to get
that feedback early than at IETF-wide Last Call when it's generally too
late to fix anything. And IESG's role here might usually not be saying
yes or no (though sometimes no would probably be the right answer) so
much as providing direction (e.g. "you really do need a
mandatory-to-implement codec/ciphersuite/whatever" to ensure
interoperability)
Also that was just off the top of my head, and I'm sure that it could be
improved by some tweaking.
candidate" (after favorable implementation and interop tests), and finally
"IETF last call candidate"? Probably not in the doc name itself, but in
the tracker, and in the document text when appropriate.
I wouldn't mind some such designations, no, but these should probably be
Data-Tracker metadata, and probably set by the WG chairs, not the
authors. Any designation about stability should probably also be
Data-Tracker metadata, and set by the responsible AD and/or an assigned
expert reviewer whose responsibility is to ascertain the likelihood that
future reviews will require backwards-incompatible changes.
Sounds about right. I'm thinking most such state changes should be up
to the WG chair, perhaps after getting a hum or show of hands (or the
email equivalent) from the WG.
Keith
