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

I agree. I think the framework document should be sufficiently clear that a
separate requirements document isn't necessary. As I understand it, the
point of the framework document was to achieve some kind of concensus on the
basic architecture. I think that should be sufficient.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email protected]>
To: <[email protected]>; "Tschofenig Hannes" <[email protected]>
Cc: <[email protected]>
Sent: Friday, March 04, 2005 7:59 AM
Subject: [Mobike] 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
>
>
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>