Re: [Roll] Some thoughts on the requirements documents [2nd try]

[Jukka MJ Manner <[e-mail]>]

Hi JP,

Some answers below.

Jukka

JP Vasseur wrote:
> Hi Jukka,
> 
> 
> On 5/29/08 4:17 AM, "Jukka MJ Manner" <[e-mail]> wrote:
> 
>> [2nd try, 1st one bounced for some reason]
> 
> You need to subscribe to the list.

I quite well know, thanks - I've been hanging around in the IETF for 
quite some time. And I was subscribed on the list, too.

> 
>> Hi
>>
>> I went through the various requirements documents and I'm a bit puzzled.
>> In general the drafts are easy to read and we have many interesting
>> scenarios described that open up nicely the environment. Yet, the drafts
>> list similar requirements, there is very little difference in what they
>> expect the routing service to do.
> 
> Two comments here:
> (1) I think that there are significant differences between the requirement
> set forth in the IDs, in term of functionality (e.g. constrained based
> routing, scale, ....)

To me the documents looked, in terms of _requirements_ very, very 
similar. Sure, there are small differences, but most of the things are 
the same.

> (2) There is no issue in having some similar routing requirements spelled
> out in the IDs. This is a good news.

The point is: what is the value of saying similar things many times?

> 
>> If we are to work on a solution later on, it is somewhat challenging to
>> find out the what our goals truly are.
> 
> Sounds fairly obvious to me. How can you select/define a solution w/o
> knowing what the requirements are ?

The point was that the current drafts talk about usecases and list
requirements in a mixed way, and repeat the same things. For the work to
proceed, we eventually need to gather a single set of requirements, in
particular to make the work more focused. The WG charter lists three
usecase/reqs drafts, so does that mean we need to interpret all three
concurrently while drafting solutions? Reading a single list of
requirements would be easier, IMHO.

E.g., one draft says we need to support couple hundred nodes, another 
one says we need to support couple thousand, one drafts says we could 
support multicast, another says that multicast is a must. Then there are 
those performance requirements (see below).

> 
>> IMHO, the requirements documents should focus on the scenarios and use
>> cases of sensor networks, and list in general what the routing subsystem
>> aught to do. These drafts should not use RFC 2119 language.
>>
> 
> No. "Requirements" and "Use cases" (what we usually call "Applicability
> statement" at the IETF) have very different purposes and what we need to do
> according to our charter is first to spell out the requirement documents.

The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN,
6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one
requirements/goals document describing in a single place what the work 
is tackling. Roll has 3 documents, it doesn't make it any simpler for an
outsider, or probably even the WG, to figure out the requirements of the
work.

> 
> Note that RFC 2119 is very much appropriate in requirement documents.

RFC2119 only talks about language issues, it doesn't tell how one should
present requirements.

> 
>> We need a separate document that lists the concrete goals of such a
>> routing subsystem/protocol/architecture/service/whateveryouwanttocallit.
> 
> Not sure what you mean here.

Use the current drafts as the use cases for Roll (without RFC2119 
language). Then take out the requirements, use RFC2119 language and 
formulate a single document that can then be used to steer the design of 
a solution.

> 
>> Here there is also a clear need to separate functional and performance
>> requirements. Typically performance values and goals are mutually
>> exclusive, e.g., we can't have low power and high performance at the
>> same time (with some definition of what is low and what is high).
> 
> One of the key reasons why the Internet has been so successful is that we
> avoid to specify performances, so I disagree with your vision here.

I kinda know that... Again, the point is that the drafts already do 
that, i.e., they specify absolute performance values to be achieved. I 
don't want to have strict performance values, but the WG documents 
already do that. Should these then be taken out from the existing drafts?

> 
> Of course, we will use performance related metric during our protocol survey
> evaluation.

If the various WG requirement documents list performance values, then 
the WG must achieve those. (I would expect an eventual AD and/or IESG 
review to ask you to remove those performance requirements, though.)

> 
>> This latter document is used in both analysing the existing schemes and
>> drafting a potential solution.
> 
> See 
> http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt

Yes, I know the draft.

> 
> I would expect that we end up with one
>> general solution, where the parameters can be tuned to certain direction
>> to make it fit different use cases.
> 
> Absolutely.
> 
>> Actually, we also need to document the threats we see in the
>> environment, and focus on the routing subsystem. The current drafts have
>> some thoughts about that, but its only a beginning.
> 
> Please elaborate.

Well, the industrial use cases draft already talks about trust issues 
and compartmentalizing things. The urban reqs also hints at some threats 
that would be present in that environment. The home reqs doesn't list 
any, yet. Several WGs have a separate document that highlights the 
threats, c.f. RFC4081 or RFC4832.

Maybe I'm just the only one having difficulty in seeing where the work 
of the WG as a whole is going and what the goals are. In that case you 
can just neglect my questions and suggestions.
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll