Subject: RE: [nemo]RO taxonomy

From: "Fan Zhao" <[email-masked]>
Date: Fri, 12 Nov 2004 00:42:37 -0800 (PST)

> So I have questions for the WG:
> 
> Q1 Should we split? 
It is OK for me to put problem statement and solution space
analysis in one document.

> Q2 Is the doc fair enough WRT possible approaches?
The solution space analysis should be complete.
Please see my other emails.

> Q3 And BTW did we miss any?
You might miss some new solutions. Please see my slides.
As the result is still preliminary, it might be too early
to talk about it.

Sincerely,
fan

> 
> Unless they are so pervasive that it can not be fixed, I suggest we fix
> whichever partiality issues is found (if any), incorporate the relevant
> text from the other drafts (mostly the MANET aspect that was really
> understated) and propose the doc again for WG consideration, either on
> one or 2 pieces.
> 
> Pascal
> 
> > -----Original Message-----
> > From: Chan-Wah NG [mailto:[email-masked]]
> > Sent: jeudi 11 novembre 2004 23:52
> > To: Alexandru Petrescu
> > Cc: Pascal Thubert (pthubert); IETF NEMO WG; Vijay Devarapalli; Ville
> Nuorvala; Erik Nordmark
> > Subject: Re: (was Re: Multiple address in RH type 2, now back to:)
> [nemo]RO taxonomy
> > 
> > Hello Alex,
> > 
> > Thank you for reading the draft immediately after the WG session, and
> I
> > appreciate you comments.  It is these comments that allow us to
> improve
> > our work.
> > 
> > If I recall, you were the one who referred us to the WG charter.
> > Contents of version -03 of the ro-taxonomy draft is exactly tailored
> > according to what is spelt out in the WG charter. (Unless the WG
> charter
> > is once again changed and I wasn't aware of ....)
> > 
> > Now people are complaining the draft is too long.
> > 
> > >From the WG charter, we are not required to come up with a *short*
> > problem statement draft.  We are, however, required to come up with a
> > *detailed* problem statement *and* looks at various approaches to
> > solving the problem.
> > 
> > I am not against a concise problem statement draft that is short and
> > sweet.  I like that too.  In fact, I would say that the problem
> > statement section of the draft-ro-taxonomy is quite short (3-5 pages,
> as
> > you and Hesham suggested).  If the WG changes the charter to reflect
> > that, I will gladly copy and paste the appropriate sections from
> > ro-taxonomy-03.txt to a new short problem statement draft.
> > 
> > However, IMHO, we should not remove the WG charter on coming up with
> an
> > informational document on ro solution space analysis.  It is a useful
> > document that records the WG experiences on the route optimization
> > solution space.  If the WG wants a short problem statement draft, then
> > let's have a WG problem statement draft *and* a WG
> > solution-space-analysis draft.
> > 
> > About your last comment on secuirty risks, I agree we should have a
> > general security consdierations text that is not solution-space
> > specific.  I will add this in -04.  But, I will not remove the
> security
> > risks discussions specific to each approach.  Again, as pointed out by
> > the WG charter (the charter that I know of, anyway): "security
> > considerations for the various approaches will also be considered".
> > 
> > /rgds
> > /cwng
> > 
> > On Thu, 2004-11-11 at 23:56, Alexandru Petrescu wrote:
> > > Pascal Thubert (pthubert) wrote:
> > > > The world did not freeze the day NEMO as a WG decided to focus on
> > > > basic.
> > >
> > > Oh didn't it :-)
> > >
> > > > We as a WG could afford some catching now. In fact, that is one
> goal
> > > > if the taxonomy draft, and dismissing that could be a huge waste.
> > >
> > > 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.
> > >
> > > 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
> > > problem statement.
> > >
> > > If this is done, then it is no longer a "taxonomy" draft, it becomes
> > > more of a "problem statement" draft.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > Alex
> 
> 
>