Subject: RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy)

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

Thanks Alex. This is exactly the kind of comments we need. 

> Pascal, the taxonomy draft-03 is a nice piece of work.  I had a
detalied
> look over it yesterday and wanted to make a detalied review later, but
> since you talk about it now, may I give high-level remarks.
> 
> The WG item on problem statement is good to be short 3-5 pages IMHO.
> How about deciding in advance about the max number of pages and stick
> to that.

Maybe it's a problemS statement, though. Understanding this might help
accept the prospect that we might not come up with THE solution; and
that we might come up with something a bit thicker then usual. Unless we
make several problem statementS. But I do not feel too comfortable with
that... because we might be able to come up with a core technology that
helps in most cases, and additional specific things that complete the
picture, as opposed to completely separate solutions. 

> The current draft could be shortened by removing entirely the
> comparative analysis of the various solutions, maybe that could be a
> separate draft.  IMHO only the abstract and the 1st section are
exactly
>
> If this is done, then it is no longer a "taxonomy" draft, it becomes
> more of a "problem statement" draft.> problem statement.

Yes, that would be my hopeful interpretation of Erik's word. But then,
what do we do with the second part? A NEMO RO "BCP" ? Does the WG want
to support that effort of does it die with 03?
> 
> The draft could be further shortened by reducing the big
> encapsulation/long path illustrations from 3 MR's to 2.  IT is enough
> for a reader to interpret the meaning of it by just using 1 and 2
> example MR's.   The logical extension from one and two to $n$ happens
in
> the reader's mind as easy as the extension from one and two and three
to
> $n$ and the description is shorter if only two MR's.  This reduction
> also reduces the risk of introducing spec errors.  Such an error is
> already there: HAofMR5 is talked about but not pictured; instead MR6
is
> pictured but not talked about.

Yes. I need to review all cases but this counds like a very good,
constructive comment.

> Second, there is a specific problem of NEMO Basic Support named
> "cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see
Section
> B.6; there it is shown how a specific mobility configuration (HA in
the
> moving network and moving networks exchanging their positions) is not
> supported by NEMO BAsic Support.  I see this mobility configuration
> problem as an important problem on the protocol itself, I mean the
> protocol does not support such a configuration.  In addition, there
may
> be other similar mobility configurations that are not supported by
NEMO
> Basic Support.

Good point. I hate myself for forgetting it :) It should be there in the
next version. Is that really a RO problem, or is that a NEMO problem
that RO could/should solve?

> Finally, about the current draft taxonomy 03 and Security
> Considerations.  There are important Security problems when discussing
> RO for NEMO; at the same time many security aspects of various
solutions
> have been discussed, but I'd keep these out of this document.  In the
WG
> RO item I'd only mention a unique Security Considerations section that
> only says what are the security risks of having a prefix at CN.  Not
to
> say the draft does not do it, but that the draft has too many security
> risks described, each attach to a single solution; it's too scattered.
> 

I believe we need to mention the security issues that some RO cases
might open, for instance things similar to what MIP6 has with CN, and
for which the RR test is what it is today, as part of the problem. But
NEMO could allow alternate approaches (such as the infrastructure doing
the job) for which the RR problem disappears, at the expense of an
imperfect RO.

I believe that ISPs might end up deploying some infrastructure RO,
implementing their own set of requirements. And that in the other end,
opensource/consumer products will implement something for mobile peer to
peer, router to router, with a different set of requirement. That they
might not trust each other for doing the job right well, and that both
could end up running over one another, or concurrently, or what.

It could be nice if we could understand these requirements and at least
build a set of common tools that could be adapted in both worlds and at
least not kill each other...

Pascal