Ted,
Responding to your scope question.
Actually, we are walking a fine line with the scope. At the time that
this work got chartered, we did not have a good understanding of all the
issues. After two years of development and analysis there are some parts
of the problem space that we understand better. One of these issues
relates to being able to provide a Netlmm service without breaking
existing hosts. In 2007 it became apparent that we actually have to
understand the semantics of the host's attachment in order to not cause
a problem in situations like having two interface cards in the same host
both connected to the same Netlmm domain. Fortunately, this information
is available in certain major use cases of Netlmm. For instance, in
cellular networks the link layer actually knows what is happening when a
host moves around and can distinguish new vs. moved attachments. The
support for multihoming/cross-access handovers in the document is
actually very limited, merely building on this. Its a side effect of
having to prevent a problem. As I have required that the WG not cause a
problem I also have to accept the implications. I think avoiding the
problem is more important.
(By the way, the multiple interfaces question is not the only scope
issue in the WG; they also want to work on IPv4 support. A rechartering
process is in progress for this and possibly some other extensions.)
With regards to host modifications for handling multihoming and all
types of cross-technology handovers: the current document supports
limited forms of this, and requires support from link layer to do this.
As I mentioned above such support exists in the networks that are prime
customers for this work. However, I think there is interest for an L3
solution, and I think it would be interesting work. From the perspective
of the current document that would merely be an additional source of
information. But at the same time I think it would be beneficial to look
at other issues around the multiple interfaces/handovers question. I
would support adding something along these lines to the new charter, and
have the WG produce extensions for this.
However, this should be seen as an option for relatively limited class
of networks that can actually assume host changes. For instance,
networks with purpose built handsets. I still believe in the current
charter's core idea that unmodified hosts must be able to plug into
Netlmm domains and work at least as well as they would without Netlmm.
In fact, I would go as far as stating that requiring host modifications
would be a complete non-starter for most of the applications of Netlmm
that I am aware of. As a result, I am against extending mn-ar-if with
new functionality and making its support a requirement for mobile nodes,
if that's what you meant.
I am on the other hand supportive of such extension. I'm even supportive
of it eventually becoming even mandatory to implement on the network
side. Perhaps this is actually what you wanted? Note that there is
really no interoperability issue with making such an extension from day
one vs. later. Hosts do not know Netlmm is running in the network, and
obviously they cannot assume they will only visit Netlmm-based networks.
As a result, whatever additional service they wish to get from the
network would have to be negotiated anyway.
Hope this clarifies,
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf