Subject: RE: [nemo] What kind of NEMO RO problem WG document we would liketo see

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 12 Nov 2004 17:46:13 +0100

Hi Thierry :)

> 
> > > 2. It does not matter how many pages the problem statement part
should
> > > be, but it must be
> > > to the core of the problem.
> >
> > I'm not sure that there is A problem to be singled out. Otherwise,
> > there's a lot of space between one liners and a book. One liners
might
> > tend to be opaque and books could cause endless controversies
because
> > there's always a sentence here or a word there that's not perfect,
while
> > the core content could be diluted. I tend to agree that a reasonably
> > short text is what we need here to get a correct understanding and
yet
> > reach consensus: Facts, but no literature.
> 
> I agree the problem is difficult to describe, but also, the more we
look
> into solutions, the more we find problems ....  So, IMHU, we should
> start by the 1st thing 1st. What's the problem if we don't have
> solutions i.e. what are the problem we want to solve (-> avoid
multiple
> tunneling; avoid extremely sub-optimal routing, etc. More below). And
> then only, investigate the potentials issues causes by proposed
> solutions (note that I call this "issues" and not "problem" so that we
> can draw a line between the 2). BU Storm is such an issue, introduced
by
> a specific type of solution.
> 

YES :)

This is the exact structure of the doc. Part 1 is problem statement,
then come the solution space and the issues (I'd rather say
pro/con/tradeoffs) with the known approaches.

The approaches are sorted out by applicability, which is imperfect since
sometimes a solution could apply cross domain. But there are advantages
on doing things that way; in particular, this form helps the reader
structure out his understanding of a globally complex problem.

> See more below under point 4.
> 
> 
> > > 3. The solution "space" analysis part must not just simply list
the
> > > previouly proposed solutions.
> >
> > Looks nice, but what's the limit? The imagination of the WG, maybe?
> >
> > Basically, all the domains that we as a group could think off and
was
> > willing to share was more or less explored in the last 2-3 years, in
the
> > form of solution proposals, and somewhat discussed already on the
ML;
> > this gave us some ground for the pro/cons/tradeoffs/applicability
> > discussion. This is why the solution space that we explore looks
like
> > the space of existing proposals made a bit more abstract. But that's
a
> > consequence, not a goal.
> >
> > The taxonomy draft has been there for 2 years for the ML to comment
and
> > propose additions. We received help from academic, ISP and corporate
> > people. If you see some space that was not covered please speak up.
It
> > will be added if there's a rough consensus that it makes any sense.
But
> > I do not see benefits in starting it all over.
> 
> I don't understand this thread as a "starting over". I rather
understand
> it as making sure the expected contents of the WG draft. I think there
> is a divergence on what people think should be included, so let's
speak
> about that, and not in a lengthy way, because we have some expertise
on
> the topic, haven't we ?

Cool. We need to have a target date, though.

> 
> > > 4. It should be able to analyze the complete solution space
including
> > the
> > > proposed and the new ones. (The completeness should be assured in
> > certain
> > > level.)
> >
> > The problem is that we do not not what's not invented yet. A WG doc
is a
> > state of the art and of the understanding of a WG at the time of its
> > publication. Does not mean it's forever perfect. Does NOT aim at
> > LIMITING the acceptable solution to a given space, either. But
rather at
> > helping the thought / creation process and saving newcomers time.
> 
> I tend to agree with Pascal here, for 2 reasons:
> - there are other proposals that have been published in conferences
and
> journals, but not submitted to the IETF
> - more proposals will be made
> 
> But, all solutions don't address the same problems, and do we have a
> comprehensive view of what the problem is ?

The PS aims at building that. We are beginning the WG draft, not
finalizing it...

We never know when we have a comprehensive view, do we? We do our best,
the rest is hopeful thinking. Do you understand what I mean :?)

> 
> About problems, but me "BU storm" is a problem with a specific
solution
> type in mind. I would call this problem as a "2nd level problems". On
> the other hand, the problem listed in
draft-watari-nemo-nested-cn-00.txt
> are "1st levels problems". The draft is a starting point with no
> solutions in mind (it presents the problem from the NEMO Basic Support
> perspective). Any problem statement should start from there.
> 
> According to me, 1st level problems are:
> - multiple encapsulation in nested networks
> - extremely sub-optimal routing
> - two VMNs in a NEMO cannot initiate communication if no tunnel is set
> up between root-MR and HA
> 
> Is there other "1st level problems" ?
> 

We add latency and fragmentation which you are not listing here, give it
some context and structure... and it's all done in 4 pages.

> 
> > Long as it's a draft, we are ready to add novelty anytime. Thomas'
draft
> > showed us that we did not treat MANET in a fair enough fashion.
Good! We
> > are working together on improving things, we'll add MANET text in
the
> > next issue, and this started an interesting discussion on the
comparison
> > of LMM and MANET based approaches, as they seem to provide similar
> > benefits.
> 
> Well, Pascal, this is a good intention, but don't you think that, from
> the other draft authors perspective, it may look like cutting the herb
> under their feet and making your draft a de facto WG doc ? Just wanted
> to point this out.
> 
I'm not the one who proposed to use the taxonomy as base (in fact, it's
Ryuji, who is a co-author of one of the alternate drafts). But there are
reasons to do that. There's quite a bit of experience in there (it's v03
already)...  and the more people describe what the WG draft should be,
the more I see it converging on the exact reasons why the taxonomy draft
has its current shape and content... Including this mail ;)

So, whatever we say about the base of the WG doc, I expect it will not
be very different from the taxonomy. As a consequence, we intend to keep
improving it, and to offer it as our contribution to the WG doc we are
ready and form an editorial group.

Pascal

---

From: "Fan Zhao" <[email-masked]>
Date: Sun, 14 Nov 2004 02:47:30 -0800 (PST)

Hello Eun,

Thanks for providing your comments.
Please see my reply below. Thanks.

Sincerely,
fan

> Hi Fan and all,
> 
> Please see in line comments.
> 
> > > 6. The solution space analysis does not judge on the strength and
> > > weakness of each solution.
> > 
> > An analysis should try to be as objective as possible.  That goes
> > without saying.  But what is the use of an analysis if it does not
> > points out the relative strength and weakness of each approach?  (I
> > prefer to use the term 'approach' rather than 'solution', as the 
latter
> > can often be interpreted as the 'solution described in
> > draft-foo-bar-xx.txt').  Instead, I think what you are trying to say 
is
> > that the analysis should not try to steer readers into thinking one
> > approach is better than the other.  The best way to ahieve this is for
> > it to list the weakness and strength of each approach.  True, the
> > initial version of that analysis may reflect only the views of the
> > author, and seems not impartial.  But through peer reviews, we would
> > ultimately leads to a piece of analysis to reflect the true streangth
> > and weakness of an approach.
> 
> I also think that the list of the weakness and strength of each approach
> support is useful in this draft, since this draft is for problem 
statement
> (not for requirements).
OK. Then we have to know the details of approach and consider the 
qualifiers.
 
> > > 7. The security analysis should be general rather than being 
solution-
> > > specific. Also it
> > > should be easy to apply to each solution.
> > 
> > Nope.  Not according to the WG charter.  There should be a general
> > security consideration section that will applies to most (if not all)
> > approaches, that I agree.  But why insisting on no security
> > consideration for specific approach puzzles me.
> 
> As Pascal commented, let's distinguish the term 'solution' 
and 'approach'.
> This draft is not supposed to analyze security in terms of any specific
> solution (draft-xx-.txt), but will consider security with the various
> approaches (as stated in NEMO WG charter).
> 
BTW does "approach" mean a kind of mechanism to solve the NEMO RO problem 
here? It is used just because we do not want the readers to link the term 
of "solution" with draft-xx.txt. Right?   

> Regards,
> Eun