On Thursday 10 August 2006 09:55, Dave Crocker wrote:
Michael Thomas wrote:
so I erred on less controversy.
Some of us believe, rather strongly, that this is a particularly important
"bias" to the development of the requirements list. It occurs, to me,
however, that it might not be clear whether there is working group
consensus on it.
I think being somewhat minimalist in the design and the final specification is
a good idea. I think that the requirements collection process should be
relatively open.
I would be interested in seeing statements of preference for, or against,
having the requirements be minimalist, and include only those items for
which there is clear rough consensus to include.
Against.
If an item engenders real wg controversy, it is *not* included.
Taken strictly enough, the only way to accomplish this is to do away with SSP
entirely.
The way I would approach it is along these lines:
Requirements phase:
Open to most any input. Only those requirements for which there is a rough
consensus to exclude or which inherently conflict with conflicts the WG is in
favor of should be excluded.
Design phase:
The protocol should attempt to meet all requirements. This will not be
possible.
As we work through the requirements, the requirements list to be implemented
in the design should be pruned based on WG rough consensus and complexity to
implement in design and code (i.e. if something is very simple, then I think
a small constituency is OK). When we run out of undesigned requirements, we
are done.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html