On Sep 20, 2010, at 7:01 PM, Ted Hardie wrote: > On Mon, Sep 20, 2010 at 3:13 PM, Keith Moore <mo...@network-heretics.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
