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

["Miguel Sanchez" <[e-mail]>]

Hi Jukka,

I can see how different set of requirements may make a single workable
solution impossible. Having four application scenarios does not mean that 4
different protocols will be needed but we may end up with more than one
though.

If we look at the Internet routing we can see that several protocols are
being used.

Kind regards,

Miguel Sánchez, PhD Associate Professor [phone]
Computer Egineering Department (DISCA)
Polytechnic University of Valencia, Spain

On 5/30/08, 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? So it is a non-goal to have a unified vision of how
> routing in sensor networks in the broad sense should perform.
>
> 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.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.
> >
> > 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
>

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