Two document stages: Proposed and Full

[Charles E. Perkins]

Hello Dave,

Dave Crocker wrote:

> One thought on component-vs-system is that we might want to make that
> distinction more explicitly and even formally, making it relatively easy
> to do component specifications, but still difficult to do system
> specifications.

I'm not exactly sure why it has to be difficult to do system
specifications, even though it's bound to be more complicated
than simple component protocols.   For the cases I had in mind,
it would be more the case that vendors could expect to get a
pretty full set of instructions on how to build the systems
they wanted to build, at least from the networking standpoint.
APIs and so on would still have to be done separately.  The
difference would be that a vendor using only a component protocol
would be left somewhat to their own devices when it comes to
filling in the missing pieces.

> With respect to your suggestion on standards classifications:
> 
> CEP> Proposed Standard: requires working group approval.  IESG comments
> CEP> taken into account, but full IESG approval not needed before
> CEP> publication.  Interoperability testing completed, no known
> CEP> flaws that present danger to the Internet.  Component protocols
> CEP> are O.K., as long as applicability (usefulness) is documented.
> 
> This is rather interesting.  Most Proposed specs, today, are not
> required to demonstrate interoperability, whereas Draft is.

I think that's a mistake.  I'd rather have it that Proposed Standard
requires interoperability.  Do you happen to know when the interoperability
requirement was relaxed?

> The question is whether the working group's reliably exert enough
> quality control on their output. For all that one might express
> legitimate concern about IESG push-back, there is also a legitimate
> concern about some working groups that produce poor work.

I don't imagine that the ADs will suddenly stop paying attention
to the working groups in their area.  Their contribution to the
discussion would be valued.  If something is going horribly wrong
and the working group is on the road to perdition, then maybe a
process of dechartering could be initiated before publication of
the offending document.  I don't think this would happen, though.
Furthermore, it is conceivable even that working groups would take
more pride in their work if their documents had to stand on their
own merits before ever getting to full IESG consideration.  I'm
sure that is debatable, but maybe we ought to at least try to
change things for the better.

I think if working groups are indeed producing poor work, then it's
better to recharter or disband instead of haggling over ill-fated
documents.  But, again, work with limited scope, or even incomplete
work, is not necessarily poor quality work.

> CEP> Full Standard: Full IESG approval required, according to current
> CEP> procedures.  Component protocols published as part of
> CEP> document suites, or separately, according to IESG discretion.
> 
> What is the market motivation for anyone to pursue this classification?

I'm projecting here, but the motivation would be that building to the full
protocol suite is more guaranteed to not have any missing features (from
the networking perspective).

> Note that the world lives on Proposed Standard now.  Though we might
> want to change the meaning of the term, so that it carries less import,
> but we have no assurance that the market will notice or respond to that
> change.

Assurances about the market seem scarce as hens' teeth.

> What about using existing language for Proposed, but adding the
> interoperability requirement, and changing the enforcement back to "no
> known bugs" rather than "no known bugs and contains full system
> features".

This would be a good subject for discussion when we get to
solution space.  I honestly don't know.  I thought that working
group approval would galvanize the interest, and free up the
IESG for focussing on the more global aspects of promulgating
full standards, reducing their workload.  They might again become
more functional working group members, and in this their experience
would be very, very useful.

Regards,
Charlie P.