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@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf