[Netext] next steps for netext

> 
> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
> host" can leverage that feature. As we discussed earlier, we have a major
> terminology problem, on what is "modified" vs "un modified". If I use
> Windows SDK and implement a virtual interface, no one can claim the host
> is now modified. Its an application, or a configuration such as using
> bridge ctl utuility in Linux. Its not changing any of the IETF
> specifications. We also need to revisit this in the context of connection
> mgr requirements in both client-based and network-based mobility models,
> which is a common requirement, or other intefaces such as MIF, for
> flow template push to the terminal.

=> I think you're distinguishing between modified and unmodified based on
whether the modification affects IETF protocols or not. That's fine, but for
those that did not attend the BoF, our conclusions were that you will either
end up modifying the host (i.e. Adding new SW) and adding new signalling on
L2 to handle the multihoming cases, or you can stick with MIP.
My opinion, and at least half the room's was that this is not a good way to
go and that it's better to stick with MIP instead of relying on a solution
that will:
- work on some L2s and not others,
- Require additional SW and config on the host which is not done anywhere
today, and
- Require L2 signalling which is out of our scope in IETF

This is why I think we should stick with the charter that Jari sent.

Hesham

> 
> I share the same view with respect to all your other comments. We need
> to seperate the cases of flow mobility vs basic handoff as allowed in
> 5213. In the BOF, we discussed mostly flow mobility and not the basic
> handoff cases supported today in 5213.
> 
> Sri
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext