Subject: [nemo] review of the nemo basic spec

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 19:26:45 +0200

I recently read the Nemo spec and have some questions and comments,
embedded in the document itself:

http://www.arkko.com/publications/mipv6/nemo/nemo_basic_review.txt

For your convenience, I have copied the main questions and
comments below:

       Technical: This is pretty solid work (especially for an -02) but
       I still had the a number of issues with it. Here are the main
       ones:

          o  Why is there support for so many alternative ways to
	    deliver route information? Note that due to the current
	    security mechanisms, static config of routes would
	    probably be sufficient. Or stick with just the prefix
	    option, and don't support the static and routing protocol
	    variants.

	    I understand that these alternatives can be useful in some
	    specific contexts. But reducing them would contribute to a
	    shorter and easier-to-implement spec.

          o  Probably makes sense to have just one moboption.

	 o  It is unclear to me why the MR needs to behave as a
	    (limited form of a) router on the home link, and whether there are
	    any implications of this.

          o  A related issue is in which order do the various
	    things take place? When do you decide you are
	    in the home network and can act as a router,
	    and when do you join various router-related
	    multicast addresses, for instance?

          o  Some error cases are missing.

          o  It probably makes sense to be more explicit about
	    the relationship of this document to MIPv6. Does
	    a MR have to support everything in MIPV6, or just
	    some parts? Or say at least that you MUST support
	    everything...

	 o  I'd like understand loop detection better. Or
	    at least why its not required.

          o  I don't like the fact that MIPv6 HAs can accept
	    and R=1 registration and no one notices anything.
	    An approach that uses moboptions, even in the
	    response, would probably work smoother.

          o  Something unclear with regards to Status value
	    treatment in Sections 5.3 and 5.4, perhaps
	    related to the above issue.

       Management: My main concern are the IPRs. A lot of people I have
       talked with have worried about the NEMO IPRs, particularly the
       ones that Cisco claims to have. If I remember correctly, the
       Nokia IPRs are also free only for public domain implementations
       which isn't good. We need to decide whether this work should go
       forward given this situation, unless some better license
       conditions can be provided. If I had a choice I would rather
       change the design, if that would help to avoid the existing
       IPRs.

       Editorial: The document is well written, but in some cases you
       could have formulated it in a simpler way. A number of
       suggestions below. The structure of the document is good.

--Jari

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 1 Dec 2003 11:19:25 -0800

>       change the design, if that would help to avoid the existing

We have had several discussions about this, the latest one being at the 
IETF58 meeting. The group consensus so far is to move forward with the 
current technical solution, and monitor the IPR situation and further 
patents that are issued.

Right now, there are many unknowns, including (but not limited to) what 
claims are in the pending patent applications from cisco, whether cisco 
will be willing to change their licensing on this technology (so far 
the answer is an unresounding no), and whether Nokia would change their 
licensing terms, if there were a consensus to ask for this (so far, 
there isn't).

So, to answer your question whether the work should go forward, the 
answer so far from the WG is yes.

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 1 Dec 2003 11:19:25 -0800

TJ