Subject: [Mobike] Design draft role, implementation requirements (Was: latest draft snapshot)

From: Jari Arkko <[email-masked]>
Date: Fri, 04 Mar 2005 17:59:20 +0200

>
>
>>/ > 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-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "James Kempf" <[email-masked]>
Date: Fri, 4 Mar 2005 09:21:05 -0800

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-masked]>
To: <[email-masked]>; "Tschofenig Hannes" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 04, 2005 7:59 AM
Subject: [Mobike] Design draft role, implementation requirements (Was:
latest draft snapshot)

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 4 Mar 2005 09:24:16 -0800

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-masked]] 
> Sent: Friday, March 04, 2005 9:21 AM
> To: Jari Arkko; [email-masked]; Tschofenig Hannes
> Cc: [email-masked]
> 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
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 4 Mar 2005 09:49:34 -0800

> so that I can go ahead and write code off of.

A framework document isn't ever sufficiently concise to write code off of.
It should be sufficiently concise to guide the design of the protocol, which
should be sufficiently precise to write code off of. Or, at least, that is
my understanding of the usual relationship between framework documents and
code design (i.e. Proposed Standard) documents.

            jak

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 4 Mar 2005 09:50:16 -0800

Do you disagree with putting a summary of requirements section
somewhere in the framework? 

If you do disagree, why?

Bora 

> Sent: Friday, March 04, 2005 9:50 AM
> To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes'
> Cc: [email-masked]
> > 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.
> >
> 
> It should be sufficiently concise to guide the design of the 
> protocol, which should be sufficiently precise to write code 
> off of. Or, at least, that is my understanding of the usual 
> relationship between framework documents and code design 
> (i.e. Proposed Standard) documents.
> 
> 
>             jak
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 4 Mar 2005 09:59:06 -0800

No, that's fine. The document needs to be concise as to what is required of
the protocol, and the architecture.

I was just commenting on what seemed to be an assumption in your email that
the document was intended to be the protocol design, rather than to guide
it, unless the intent of the WG in this case is to not abide by that
customary relationship.

            jak

----- Original Message ----- 
From: "Bora Akyol" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "'Jari Arkko'"
<[email-masked]>; "'Tschofenig Hannes'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 04, 2005 9:50 AM
Subject: RE: [Mobike] Design draft role, implementation requirements (Was:
latest draft snapshot)

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 4 Mar 2005 10:00:30 -0800

Thanks, I did not mean to imply that this document should be the design of
the protocol,
just that it would be nice to have a summary of the requirements in this
doc.

Bora

> Sent: Friday, March 04, 2005 9:59 AM
> No, that's fine. The document needs to be concise as to what 
> is required of the protocol, and the architecture.
> 
> I was just commenting on what seemed to be an assumption in 
> your email that the document was intended to be the protocol 
> design, rather than to guide it, unless the intent of the WG 
> in this case is to not abide by that customary relationship.
> 
>             jak
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 04 Mar 2005 20:20:29 +0200

>so that I can go ahead and write code off of.
Yes. We are not there yet, its in the future protocol doc!

>requirements, I would be happy to contribute to that.
Thanks for offering to contribute! I can see two potential
items where additional contributions like this would be useful:

- A summary table at the end of the design document that
  lists the design choices and features that are needed.
  This is just a list or a table; not something that you can
  write code from. But it could help people grasp easier
  what conclusions the document has reached. Something
  like:

      - Indicating support for MOBIKE: Use FOO feature from IKEv2.
      - Storing peer addresses: Store multiple, not just one
      - ...

- Another protocol spec proposal. We do have already some,
  but additional ones are very welcome too.

--Jari