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

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

Hi Chan-Wah,

Please see my reply in line. Thanks.

Sincerely,
fan

> Hello Fan,
> 
> > 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.
> >  
> 
> I agree with you ... partially.  Without setting up a new WG document,
> your proposal on first listing the contents and structure of the WG
> document will ultimately lead to all authors of the four drafts
> submitting four different drafts based on the same contents and
> structure, ... and that is a duplicate of effort.
>
I agree to set up a new WG document. But we have to be careful to 
choose the base (if we decide to do that) otherwise we probably have 
to make modifications later again and agian. In this thread I want to
 focus on the high-level views about what NEMO RO WG document should be 
rather than the content and structure which should be the next stage.
IMHO the problem statement part is quite well understood. But the 
solution space analysis part needs to be baked more. 
     
> It is not necessary a bad thing, since that way, it is easier to merge
> all 4 drafts.  I am just saying that your point on less/no duplicate
> efforts is unlikely to happen.
> 
> 
> > Below is my vision about NEMO RO problem WG document: 
> 
> As I mentioned, you are welcomed to describe your opinions, but
> ultimately, we must use the WG charter as the guideline to be adhered
> to.  So, in general, I agree with your list, until those parts that are
> not in agreement to what the current charter states.
> 
Sure. I definitely agree that we have to adhere to the charter. But also
 remember the charter is made some time ago (I do not know when.) and we
 are keeping improving our understanding about NEMO RO since then. So 
let's adhere to the charter and don't forget to address the new issues
 and needs if necessary.
 
Secondly, the charter defines the scope of work (problem statement,
 approach analysis, tradeoff and security consideration etc.) but there
 are ways and ways to do that. There is no doubt that different method
 generates the different quality of work. What I argue about draft-
taxonomy in another email is that the method used to analyze the solution 
space is on the weak side. See also http://www1.ietf.org/mail-
archive/web/nemo/current/msg01689.html, Thierry has raised his concerns 
about the completeness (Am I right, Thierry?). So I want to describe the 
desirable properties in this email. If you read my slides, you will find 
the vector <from, to, initiator, method, ...> could be used to describe
 the solution space completely and in a mutual exclusive way. 
     
> > 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.)
> > 2. It does not matter how many pages the problem statement part 
should 
> > be, but it must be
> > to the core of the problem.
> > 3. The solution "space" analysis part must not just simply list the 
> > previouly proposed 
> > 
> > solutions. 
> > 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.)
> > 5. The method to categorize the solution space must be able to make 
one 
> > category not
> > intersect with any other category (mutual exclusive).
> 
> That may be desirable, but difficult to achieve.  
Nothing is easy and nothing is impossible. Let's try our best.
 
> It runs the risk of
> being in conflict with your point #4 above.  To strictly demand mutual
> exclusiveness will often leads to incompleteness.  
I do not understand why. Can you explain about it?

> To me, having mutual
> exclusive approach is only something that is preferable, but not of high
> priority.  Instead it is the completeness that we should try to achieve.
> (Your choice of words "should" in #4 and "must" in #5 seems to indicate
> you felt otherwise).
> 
Mutual exclusion avoids the duplication and redundency. Also it provides
the clear comparison and contrast between the different categories. The
completeness and mutual exclusion are independent and equally important.

> What advantages does mutual exclusive solution space partitioning gives
> us?
>
The ideal solution space partition should look like this:

Base on a certain criterion, the whole solution space is partitioned into 
for exmaple A and B. And based on another criterion, A is partitioned 
into for example, A1 and A2. B is partitioned into for example B1, B2 and 
B3 based on the same or a different criterion. In this way it is easy to 
see the commonness and difference among the solutions and avoids the 
duplicated analysis.
 
> >  
> > 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?  

The reasons I list this are 

1) IMHO this might be the way going into the details of solution too 
much. Also since you have to have the detailed solution in mind, your 
analysis does not include the new solution, which voids the completeness. 

2) I do not see how your taxonomy draft can give a thorough evaulation 
without any formly defined qualifier. It could generate a lot of emails 
like "comments on the evaluation part". 
http://www1.ietf.org/mail-archive/web/nemo/current/msg01677.html
http://www1.ietf.org/mail-archive/web/nemo/current/msg01689.html
http://www1.ietf.org/mail-archive/web/nemo/current/msg01692.html
(Thierry and Pascal if I misunderstand your email, please correct me.)

3) As when I was writing this email, I recall the similar concerns 
expressed on the ML. 
(http://www1.ietf.org/mail-archive/web/nemo/current/msg01657.html,
http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html, Am I 
right, Alex?) 
I am not saying it is impossible that the evaluation can not be done 
nicely in a reasonable level of fairness and correctness. But at this 
point, as we have not understood the whole solution space, it might be 
too early to do it.  

> (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').  
Do you mean "approach" is a kind of mechanism to solve the RO problem, 
right? As Thierry also suggests the term of "issue". My understanding 
about the differences between "issue" and "approach" is that "approach" 
tries to solve the whole NEMO RO problem while "issue" is related to only 
some part of problem. 

> 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.  
Yes, this is too.

> The best way to ahieve this is for
> it to list the weakness and strength of each approach.  
But following this line of thinking, it could still make the readers into 
thinking one is better than another.
 
> 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.
> 
> > 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.
> 
The security consideration is kind of evaluation too. So my arguments 
about #6 also applies here. The charter says "Furthermore, security 
considerations for the various approaches will also be considered."
My understanding is that the charter does not limit the security 
consideration to be based on each specific approach either. So let'd 
think about it after the complete solution space is done. Some security
issue might be specific to approach.
 
> > 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.
> > 
> 
> You then run into the danger of being too vague.   There is a reason why
> different solutions are being proposed that seems to carry the same core
> idea.  Often, this occurs because one proposal improves some small
> deficencies of a previous proposal (while at the same time containing
> new deficiencies).   It is through documenting these subtle differences
> that we would be documenting the WG's experiecne on route optimization. 
>
Then you run into the danger of being too lenthy and not well-structured.
:-) I understand there must be differences between various solutions. But 
if the difference is just minor, will you list them in the first class? 
The core idea should be grasped firstly and then come the second-tier 
differences, and so on till a reasonable level of granularity.
For me the RO solution just has to do the two things: 1) set up the 
Anchor Point close to CN or MNN 2) inform the Anchor Point of the full 
binding information to either the Internet infrastructure or a specific 
router.    

> 
> <snipped>
> > Your comments are very welcomed.
> > 
> 
> Oh, you will definitely get my comments once I get back to my own
> time-zone.  Can't think critically with a highly-caffinated mind .... ;)
>
Thanks. Look forward to hearing from you.
 
> /rgds
> /cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 14 Nov 2004 19:57:35 +0100

>>points out the relative strength and weakness of each approach?  
[...]
> http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html

First, everyone can, and should, write any draft one likes.  But if one 
wants to have a draft useful for the WG, i.e. a WG item, then think what 
exactly can be re-used from the draft.  IMHO, a draft author should 
think as if it is _not_ him or her that will actually use it, but 
somebody else.  Very often the link between the person who writes a 
draft and the person that actually uses it is very loose, never met, no 
email conversation, etc.  So don't expect everyone to embrace what the 
RO problem statement draft says just because it's a WG item.

Risking being blunt, let me give examples: there was often a tendency to 
force the requirements and terminology drafts as strict precursors and 
strict guidelines for the Basic Support.  What actually happened is that 
both drafts were refined simultaneously, and that currently there are 
inconsistencies.  They're mostly in agreement but: some requirements 
were written after some of the Basic Support ideas were put on paper, 
and some terminology is defined but not useful for the Basic Support.

Another more humble example is a security analysis draft on Mobile IPv6 
and proposals for secure RO to which I remotely participated somehow. 
When I did I was thinking the same, that _that_ draft will be the 
guideline for the ultimate secure RO solution.  Well, not so!  And for 
good reason.

My personal bottom line is that problem statement and analysis of 
solution space drafts are done in order to show that we - as a WG - do 
understand the actual problem and are capable of working on a IETF 
solution.  Would anyone care if that particular WG item does not 
actually become an RFC?  And of course, even if a good understanding of 
the problem exists - there still needs to be a deployment need for it, 
without which it's all just another academic exercise.

Until we figure this out, why don't we just have a short PRoblem 
Statement (no solution analysis) draft, float it around and get 
consensus and positive feedback on it.

End of blah-blah let me get back with some specific comments on the draft.

Alex

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 17 Nov 2004 17:20:57 +0800

Hello Fan,

Sorry for replying late.  See reponses in-line:

/rgds
/cwng

> I do not understand why. Can you explain about it?

By strictly demanding mutual exclusivity, you are demanding the division
of an area into two non-overlapping areas.  It runs a risk of having
area not covered by the two areas.

> completeness and mutual exclusion are independent and equally important.

I am not saying mutual exlcusivity is not good.  I like mutual
exlusivity, but not at the expense of completeness is my point.

> see the commonness and difference among the solutions and avoids the 

AH ... your a and B do overlaps, don't they?  SO what you are proposing
is this, suppose we come up wth 2 criteria, A and B, so you would
partitioned the solution space into 4 quadrants: Q1: A & B, Q2: !A & B,
Q3: A & !B,  and Q4: !A & !B.

Right?  Interesting proposal, seems to be along the line of the way we
classify mutlihoming cases ...

> analysis does not include the new solution, which voids the completeness. 
Nope, given what you have defined in the solution space you are
describing, an analysis should point out the strength and weakness of
that solution space.  For instance, your solution space might be: 

a; require sending of BU with prefix to CN, 
!a: does not require sending of BU to CN.

Then it should point out that (a) requires changes to CN, which is
generally undesirable.

> (Thierry and Pascal if I misunderstand your email, please correct me.)

No, we are not trying to evaluate solutions.  That's not the purpose of
the solution space analysis.  It simply is an analysis to help whatever
WG (new, or the re-chartered NEMO WG) that is going to develop and
specify a standardized NEMO Extended Support.

> tries to solve the whole NEMO RO problem while "issue" is related to only 

Nope, for me,  "approach" is a general way to solve a particular problem
(like solve this problem using routing header), a "solution" is
draft-xxx-xxxx that specifies details of an approach (like use Reverse
Routing Header).  If you like, you can call "solution" a "proposal".

My understanding of what Thierry is concerned is the confusion of issues
and problems.  He want to use "problems" to refer to problem with NEMO
Basic Support that leads to the need for RO; and "issues" to refer to
the potential problems that a particular RO approach might face.

/rgds
/cwng