Design draft role, implementation requirements (Was: latest draft snapshot)

>
>
>>/ > In general, I think rename this draft to be "Framework for MOBIKE." 
>/>/ > Then do a requirements draft that has as little text as possible.
>/>/ 
>/>/  i hope that we do not need a requirements draft since we 
>/>/ already came quite far and are hopefully finished with the 
>/>/ work in mobike. making progress would be a good thing. 
>/
>Well, I think the WG has a choice on this, I think this document is
>suitable as a framework document, for requirements, I think we need
>a more terse and succint document just pointing out what the implementation
>needs to do. That is of course my opinion.
>

Sure. But isn't that what a protocol spec document should
do? We don't have an official WG version of such a spec yet,
but that's certainly the plan. The spec will give exact
rules on what a MOBIKE implementation must/should/may
do. The behaviour of the protocol. We expect this to be
shorter than the design document.

The role of the design document is to act as
a problem definition and as a placeholder for talking
about the various design issues and tradeoffs.

Sometimes working groups also produce true requirements
documents, as their first step before developing the
protocol itself. The success of such documents has varied
a lot, however. They can be useful. But they also tend to be
lengthy, and unless they take the design tradeoffs into account,
its kind of easy to get a bloated design. I'd rather not get into
that process in MOBIKE.

--Jari