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

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

Hi,

thanks for the clarification. So we work in parallel tracks for now, but 
then the hard part comes, when we try to figure out what are the 
commonalities, and whether we need separate solutions (and how many), as 
Miguel mentioned.

The whole point of my initial message was to try to make this second 
phase, to look into the commonalities, start a bit earlier, to have more 
time to find a rough consensus.

Regards,
Jukka

JP Vasseur wrote:
> Hi,
> 
> 
> On 5/30/08 10:16 AM, "Jukka MJ Manner" <[e-mail]> wrote:
> 
>> Hi JP,
>>
>> Don't get me wrong, I'm not complaining as you seem to think.
>> Application driven approach is fine. I'm trying to understand how four
>> sets of requirements (in the broad sense incl. security), partly
>> mutually excluding, are used in the future. Is the WG in fact going
>> towards 4 distinct parallel tracks in the survey, and specification of
>> the architecture?
> 
> No, the survey will look take into account all the requirements spelled out
> in the 4 requirement documents. And of course, the architecture ID and
> potential protocol work will not have parallel tracks.
> 
> So it is a non-goal to have a unified vision of how
>> routing in sensor networks in the broad sense should perform.
> 
> This only place whether we'll have parallel "tracks" is for the routing
> requirements, which makes sense by essence.
> 
> Thanks.
> 
> JP.
> 
>> Regards,
>> Jukka
>>
>> JP Vasseur wrote:
>>> Hi,
>>>
>>>
>>> On 5/30/08 7:26 AM, "Jukka MJ Manner" <[e-mail]> wrote:
>>>
>>>> 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.
>>> Just to take one example, the specification of a routing protocol for a few
>>> dozen of nodes (Home Automation) and several hundreds of thousands (urban
>>> networks) is not exactly the same and has strong implications on the design.
>>>
>>>>> (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?
>>> Please look at the history of the WG. We decided to be application driven.
>>> Thus the task consists of analyzing the routing requirements of (in our
>>> case) 4 applications. If it turns out that several applications have similar
>>> requirements, this is a perfectly good outcome, that will simply the task of
>>> the WG to select or specify a new WG.
>>>
>>>>>> 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,
>>> 4
>>>
>>> so does that mean we need to interpret all three
>>>> concurrently while drafting solutions? Reading a single list of
>>>> requirements would be easier, IMHO.
>>> The super-set of requirements will be taken into account in the protocol
>>> survey and then protocol selection/design.
>>>
>>>> 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.
>>> Ah so you saw some differences ....
>>>
>>>
>>> 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.
>>> This is the approach that we took. Note that other WGs took the same
>>> approach (e.g. PCE, ...) and have been very successful.
>>>
>>>>> 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.
>>> Please look around and you will see many requirements documents with RFC
>>> 2119 language.
>>>
>>>>>> 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.
>>> No, the requirements will make use of the RFC 2119 language.
>>>
>>>>>> 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?
>>> They are indicative.
>>>
>>>>> 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.tx>>>>
> t
>>>> 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.
>>> All comments are most welcome. But indeed, I haven't received any other
>>> similar complaints. This is indeed quite the opposite with many comments
>>> from regular contributors finding that the WG formed a few months ago was
>>> moving fairly quickly. There is still quite some work on the requirements
>>> IDs but we're getting close to our Milestone.
>>>
> 

-- 

Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Fax:    +358+(0)9+451 2474
Department of Communications      Office: E309 (Otakaari 5)
and Networking                    E-mail: [e-mail]
P.O. Box 3000, FIN-02015 TKK      WWW:    www.netlab.tkk.fi
Finland                           Private:+358+(0)50+320 3018
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll