Comments inline, some content snipped.
On Tue, Oct 5, 2010 at 5:54 AM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
On Oct 4, 2010, at 4:16 PM, Barry Leiba wrote:
While this is true as far as it goes, I'd like to point out a good
example of where "the common case" may be less common than we'd like
to think.
ACAP, RFC 2244, is a Proposed Standard put out in 1997. There's a
core of us who think it's a good protocol and a useful one, but it's
had very scanty implementation. At this point, even most of its
champions think it might as well go to "Historic".
I think part of the problem is that our current "maturity" labeling scheme
conflates several things:
- quality of the protocol itself (is the design good and without significant
known flaws relative to its intended/expected use?)
- quality of the specification (is it written clearly and precisely enough to
encourage interoperability?)
- currency of the specification (does the written specification still reflect
current and/or desirable practice?)
- applicability of the protocol (how broadly should it be used?)
- initial/continued acceptance/deployment of the protocol
I think this is a key point, both to this discussion and to the "how
many grades" discussion.
The current labels represent more than one axis of evaluation, and we
may have to agree
on which one is the most important in order to get clear labeling.
This may mean that
we add a second label (or potentially a third) to get full
descriptions. But I don't think
even that would require us to go the full "commentary document" route
where the core
spec was surrounded by attached commentary built up over the years.
I think the "document quality" metric, assessed in relation to interoperabity
is at the core of this. Can you go from this document to an
implementation? We can assess that in a variety of ways, but that's my
take on the most important bit to retain for the system.
The "is it in use" question could be handled by an increase in statuses like
"Historic" which could be applied simultaneously to the document set.
So you could have ACAP be both a full standard and historic; the meaning
would be "The IETF strongly believes that you could go from this document
to an interoperable implementation, but that you would find few other
implementations
in use". Historic is probably not the right designation, given the
past experience.
But something like "FULL, Niche deployment" or "FULL, Wide deployment" could
be useful.
To my way of thinking, the "quality of the protocol" question is
inevitably bound up with
the "intended/expected use" issue--which means that the same protocol
could have multiple
different evaluations. HTTP would get one as a hypertext transport,
for example, and completely
different one for streaming--both uses in the wild now.
The actual energy in the community to make change here actually seems
to me pretty low,
though, both for this and Russ's document. I'm not sure whether a
proposal like either of
them should "default advance" with this level of energy.
regards,
Ted
...which is why, instead of "advancing in grade" from PS to DS to FS, I'd
like to see a periodic re-evaluation of the last three. There are protocols
today which are Full Standard for which the specifications are not being
well-maintained and which don't reflect good current practice. There are
also protocols which are Proposed Standard for which the specifications are
reasonably current and reflective of good practice. There's a disconnect
between our labeling of these standards and their "goodness" to the
community, and that harms IETF's credibility.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf