OPEN ISSUE: Standards Track

Keith Moore moore at cs.utk.edu
Fri May 16 12:49:24 CEST 2003


I'm in general agreement that it's necessary to consider the role of 
internet-drafts (including working group drafts) when trying to
understand the problems with our current maturity levels.  And I'm also
in agreement that some working groups too easily adopt drafts as work
items - though my concern here is mostly about WG resources being spread
too thin.

I'm not sure it's appropriate to constrain WGs to only adopt drafts that
they believe will end up being products of the WGs.

And while it's fine for people to start implementing drafts (especially
if we'll benefit from the input of those implementing them)  it may be
that we need to find a way to discourage people from assuming that
they'll end up as standards.


> I've felt for some time that there is a need for a change in this
> area, but this analysis leaves out the issue of Working Group drafts,
> which I think is a critical component. Right now, they have grey area
> status. I've seen drafts move from individual contribution to Working
> Group status only because nobody on the mailing list spoke up when the
> Working Group chair put out the question about whether a draft should
> move to Working Group status or not. Many vendors start implementing
> when something becomes a Working Group draft, since realistically,
> they view that move as entry into the standardization process,
> regardless of what IETF's process RFCs say about it.
> 
> Arguments have been made on this list that we should not touch the
> current Proposed/Draft distinction, and I agree that the distinction
> is useful even if Proposed is treated as "standard" by vendors for all
> practical purposes (Full Standard, however, is largely useless except
> as a historical distinction). However, I think some attention is
> needed to how a draft becomes a Working Group draft. Perhaps that move
> is when a preliminary review is made on the design, so that movement
> to Working Group draft status does not happen for reasons that have
> nothing to do with the technical aspects of the design.

Keith


More information about the Problem-statement mailing list