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

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

> 
> Dear NEMO WG members,
> 
> IMHO, draft-thubert-nemo-ro-taxonomy-03 is far from what NEMO RO
problem
> Wg document
> should be. (Sorry, Pascal and Chan-Wah, please see the following text
and
> my another
> email about comments on your solution space analysis part.)
> 
> I feel at this moment WG should consider What
> kind of NEMO RO problem WG document we would like to see rather than
> which
> draft should be picked as the WG item. Once we reach the consensus on
> that,
> we can go back to see if any existing draft meets or is close to meet
our
> needs
> then it can become WG document without question, otherwise if there is
no
> one,
> we have to work on the new document that we want to see. We already
have
> four
> NEMo RO problem related drafts that all are good inputs to the WG
> document.
> It is inefficient if we spend the duplicate efforts on the same
subject.
> 
> Below is my vision about NEMO RO problem WG document:
> 1. NEMO RO problem draft should be written in an abstract way rather
than
> solution-specific.
> (from calos's email on the ML if I am not wrong.)

Yes, I do not think we are in contradiction here, are we? This is why we
moved solutions to appendix. Like the bibliography, it's a tentative for
additional help and time saving to the reader.

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

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

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

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.

> 5. The method to categorize the solution space must be able to make
one
> category not
> intersect with any other category (mutual exclusive).

Yes, that would be nice. Making a single category achieves that. But
might leave things out. I understand your proposition like let's make a
document that shows the solution space of everything yet to be invented,
and then partition it in non overlapping categories. There are names
like GRAAL for that sort of things; the rest of us do what we can in the
time frame we have.

I read your draft and I liked it very much. IMHO, it's a good start, we
must keep it and build on it. The way I read it, I found it relevant as
a foudation for a requirement draft more then a problem statement. We
are not there already, since we did not recharter or anything. 

On the to-be-discussed side, some things were a bit cryptic to me, like
the reason why you discuss the data-plane method thing, and why you want
to formalize the nested NEMO in a PS draft. Also, I'm not sure we want
to mix RO and multihoming (the DAG thing).

> 6. The solution space analysis does not judge on the strength and
> weakness of each solution.

We disagree here (I have to disagree somewhere ain't it true?). I see
the PS/solution space draft as a tool, not as a limiting boundary (as
opposed to the requirements will be specifying what we have to cover). I
believe that the pro/cons/tradeoffs/applicability discussion is at the
core of the value of that tool.

> 7. The security analysis should be general rather than being solution-
> specific. Also it should be easy to apply to each solution.

You might want to list of the threats in the world in a separate
chapter, or maybe in an encyclopedia. But the problems to be addressed
are inherent to the solution space. Examples in the nested nemo case:
trust in MANET approach, MITM/Time-shifting attacks in MR-proxy, etc...

> 8. The solution space analysis part must focus on the core idea
because
> there could be an infinite number of solutions that are in the
different
> forms.

We did not find them all, then :) But yes, we tried to abstract things
and leave the specifics to the solution drafts in reference and
eventually appendix. The only solution that we really detail is Erik's
text on proxy. The reason is that it's very educational. Again, this is
a tool, not a book of law.

> We also have to think about the content of WG document.
> 
And word your thoughts to the ML :)

Pascal

---

From: Thierry Ernst <[email-masked]>
Date: Sat, 13 Nov 2004 00:34:29 +0900

Hi,

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

See more below under point 4.

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

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

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" ?

> of LMM and MANET based approaches, as they seem to provide similar

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.

> are not there already, since we did not recharter or anything. 

I tend to agree here too that requirements are too early at this stage,
since we haven't decided to produce solutions for RO.

> And word your thoughts to the ML :)\

Thierry.