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

[JP Vasseur <[e-mail]>]

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.
>> 

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll