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
