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

I am fine with that, the problem is that this framework document
is not sufficiently concise in the requirements area
so that I can go ahead and write code off of.

Specifically, it is hard to judge from this document, what is a MUST,
what is a SHOULD, and what is purely optional and esoteric.

Maybe we can add a final section to the document summarizing the
requirements, I would be happy to contribute to that.

Regards,

Bora

> -----Original Message-----
> From: James Kempf [mailto:[email protected]] 
> Sent: Friday, March 04, 2005 9:21 AM
> To: Jari Arkko; [email protected]; Tschofenig Hannes
> Cc: [email protected]
> Subject: Re: [Mobike] 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
> >
>