It is easy to state a functional "requirement" but it is often difficult to
explain why it is needed or to convince people that it is essential to support
that requirement.
The easiest way to handle this is to ensure that every functional requirement
is
explained in terms of a detailed usage scenario, so that the feasibility and
urgency of that usage can be considered by the working group.
Quite. Given the range and scope of the alternatives being discussed,
this sure feels like a green-field design environment.
I worry that we may not even have a very good handle on what is
actually wanted in the field, consequently we risk designing something
that targets engineers as the customer.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html