Sam,
SH> Hi. For the past few plenary meetings, people have gotten up to the
...
SH> I disagree.
SH> The point of proposed standard is not to throw a document out there
SH> and get comments, although of course we're always willing to listen to
SH> comments on our documents.
SH> The point of proposed standard is to throw things out there and get
SH> implementation experience.
Your statements do not run contrary to the complaints that are being
lodged.
These statements do not propose that Proposed is for being to "get
comments".
SH> If specs are unclear, then we're not going to get implementation
SH> experience; we are going to waste time.
Let's inspect RFC 2026's language:
4.1.1 Proposed Standard
...
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
Let's take note of the non-social requirements:
Stable.
Resolved _known_ design choices.
This does not mean that the failure of the Security section to provide
a tutorial on security is required.
This does not mean that all of the uses and dynamics of the protocol
must already be understood.
It does not even mean that the writing in the specification must be
perfect.
And it most certainly does not mean that the design choices must
coincide with the design preferences of the cognizant AD.
Yet all of these have been reasons for delaying documents from
achieving Proposed.
SH> Similarly, if the review process will never successfully conclude,
SH> then having the review early is good.
Review early. Review often. Yes!
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>