On Sep 20, 2010, at 7:01 PM, Ted Hardie wrote:
On Mon, Sep 20, 2010 at 3:13 PM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
Those are the very people who need to be involved in cleaning up the
specification, but (depending on market conditions) they may see it as
mostly benefiting their competitors.
For protocols where interoperability with others' implementations is
important for your customers'
view of your product, there is probably enough benefit to get the
involvement; if you look bad because
other people aren't able to read the spec, you have some incentive. But that
may no longer be the
common case.
I think it's going to be different from one protocol to the next.
But I don't think that a prospective implementor cares (much) whether a
specification is Proposed, Draft, or Full, or perhaps even Informational or
Experimental. I think they care about whether the specification reflects
current widespread practice (or if the protocol is new, best known
practice), whether it's sufficiently precise to permit implementations to
interoperate, whether it's implementable with reasonable effort, whether its
encumbered by patents or other constraints, and whether it is deployable.
If I'm close to right about these things, maybe we would do well to rethink
our standards process along these lines. Rather than moving to Draft, then
Full, maybe we should periodically make an assessment about how well a
specification still reflects existing practice, how widely it is used, how
precise it is, and so on.
A periodic call for comments, say at 2 and 5 years out, with those judged to
be still useful moving up the ladder, for example?
I'm thinking more along the lines of every 5 years. Maybe more frequently to
start with, or more frequently for those protocols for which (in IESG's
judgment) the status might change quickly. But with no end to the periodic
review, as long as the protocol is still considered a standard. And I'm
thinking that the review should address the specific points mentioned above.
I don't think that there should be an expectation of the document being revised
and reissued for each review. It would be a bit more like having a new
applicability statement issued every few years, but even that should probably
not be an RFC unless the applicability is complicated to describe.
Nor do I see this as having the protocol advance in grade. Instead I see a
periodic re-evaluation of whether the protocol specification still should have
IETF's endorsement. And the endorsement is not just "yes, this is still a
standard" or "no, it's not", but rather things like whether the design is still
sound (especially where security is concerned), whether we have confidence that
the specification is sufficiently precise, whether implementing the
specification as written will produce an implementation that interoperates with
other implementations written to the specification, whether the specification
is appropriate for wide use or only in limited circumstances, whether the
specification is actually used widely in practice, etc.
(For that reason, where the default is "to advance" or not is not an issue for
me - because it's not about advancement. But the periodic evaluations should
have expiration dates. If someone is looking at a long-expired evaluation, and
there's not a more recent one, that tells them something about the currency of
the protocol specification.)
As a separate concern, I think I'd still like to see a two-step process before
IETF declares something a standard, and that it should still require
interoperability testing. But I don't think that a review process - where a
WG labors mostly in isolation for 2-3 years and then the rest of the community
looks at it only at Last Call - works very well. In cases where a WG starts
from scratch, I favor developing an Experimental prototype, having people
implement it, and then developing a standard version of the protocol based on
wide review of, and experience gained from, the prototype. The goal should be
to have initial prototype implementations no more than one year from WG
formation. There are two points to this: One, start implementing earlier.
Two, get wide community review early on, before the WG is so exhausted and
committed that it cannot change its thinking even for good reasons.
There could be multiple iterations of the prototype phase, or multiple
prototypes. The eventual standard should not break new ground as compared to
the last prototype on which it was based.
In cases where there's already a well-understood protocol that forms the basis
of the WG's work, the prototype stage could perhaps be skipped. But the first
stage in that case should be to accurately document existing practice.
Final last call and IESG review should not be a big step. There should be a
presumption that as long as the WG paid appropriate attention to review
comments at the prototype stage, addressed those concerns appropriately, and
the final standard doesn't deviate too much from the prototype in what it does
(though it shouldn't have to be strictly compatible) - the document will be
approved. That's not to say that IESG can't deny approval if significant
design flaws are found, but it would not be appropriate to hold up the
specification for trivial reasons at that stage. NIt picking about document
text should only result in nits being fixed in the specification. Those things
are important - especially when clarity is concerned - but shouldn't hold up
the specification's approval for very long.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf