Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones

From: [email-masked]
Date: Fri, 18 Mar 2005 09:17:38 -0600

Hi Gabriel,

The interest to take on some new work by rechartering the MIPSHOP WG
seems to be of some significant interest. At least if the number of
emails were to be used as a measure.

I think the proposal for MN-AR security, FMIPv6 to PS and application
of FMIPv6 to EV-DO seems like a good start. It should keep the WG
quite busy for sometime in the near-term. 

Return routability enhancement and new route optimization techniques
are topics that are probably worth more thought. One possibility that
has been discussed previously is that the RO and RR enhancement work
be discussed in a focused and scoped manner in the MOBOPTS RG. And
based on a better understanding from such an exercise we could
standardize them in either MIPSHOP or MIP6. 
I think there is some hesitation in taking up work in MOBOPTS (IRTF
has a bum rap, I guess). But I think it is quite possible to get work
done in Mobopts and bring it back into the IETF WGs if we do this
right and if we have the proper setup between the mobility WGs in the
IETF and Mobopts. 

Taking on a limited set of work items as you have proposed will
probably ensure that the work gets done quickly and milestones are
met. After all MIPSHOP has an excellent track record so far in meeting
its milestones.

-Basavaraj

>
>Folks,
>
>As you may be aware, the working group's current milestones are
>all done.
>
>I spoke with Margaret Wasserman (taking over from Thomas Narten
>as our advising AD) during IETF week, about possible next steps
>for MIPSHOP.
>
>It seems like there is sufficient interest and plenty of potential
>work items to keep the working group going. Possible items
>Margaret and I talked about include the following areas:
>
>Further work on FMIPv6
>----------------------
>
>- work on MN-AR security. For example:
>
>   - AAA-based keys for handovers - the need/desirability for such
>	an item was brought out in Jari's presentation in MOBOPTS.
>	even though this item does not yet exist in the form of
>	an I-D, it seems we should not have major difficulties
>	identifying interested parties to work on it.
>	This item is limited in terms of the deployment scenarios
>	it supports, but the carrier/service provider scenario it
>	caters to seems important enough to warrant work on it.
>	perhaps for PS?
>
>   - derive key from SeND for fmip (Rajeev/Kempf draft)
>	despite the IPR implications because of the use
>	of CGA (from SeND), this could target PS
>
>- work on FMIPv6 itself:
>
>   - The above items will go a long way towards solving the security
>	issues in FMIPv6. The current lack of such solutions is
>	perhaps the major issue why FMIP is currently experimental
>	and not PS. Given the above items, the WG could also take
>	on the effort to revise the base FMIP to PS. This effort
>	will clearly benefit from the fact that there are several
>	implementations of FMIPv6 (including publicly available
>	ones), so feedback from these effort will surely help in
>	cleaning it up towards PS.
>
>   - Apparently, the CDMA folks (in particular, those working
>	on "1x-EV evolution" have some interest in using FMIPv6.
>	Another potential WG item could be a document to describe
>	how FMIPv6 would work over such a link. This document
>	would be analogous to our current FMIPv6 over 802.11
>	document, and would similarly target informational.
>
>RR optimizations
>----------------
>I must confess to me these seem less coherent and ready as a group than
>the above group. E.g., it's not clear to me whether a standards-track
>document would end up mixing different proposals, and how.
>
>- CGA type idea from OMIP
>- CBA (credit-based) maybe no 'spot checks', just the basic stuff
>	as is being applied to HIP, for example. this could complement
>	other proposals like CGA or preconfigured MN-HA SA, for example.
>- EBU - but have heard concern that this *increases* signaling cuz it adds
>	messages, what we want is less (not more) signaling.
>
>----
>
>These are the two areas I see most probable for continued work.
>Nevertheless, there are other items people have mentioned. Feel
>free to propose additional items if you consider they are ready for
>standardization. This is diffucult to judge, but the following
>are things to keep in mind (of course, they are *not absolute
>requirements*):
>
>- are the proposals mature (e.g., plenty of discussion, several
>	revisions taking into account WG feedback, published
>	results, existing implementations, etc)
>- is there interest in the proposals (e.g., are folks interested
>	in deploying, perhaps because the proposal enables certain
>	scenarios, is there interest from *more than one party*, etc)
>- is IPR resolved (at least RAND as per IETF rules, hopefully
>	royalty free of course)
>
>Items not ready *now* may of course be ready later on. In the meantime,
>those items may continue being discussed in other working/research groups,
>as individual submissions, etc.
>
>I have spoken with some of you about the above (thanks for the feedback).
>Even if you have privately expressed your opinions, please send your
>comments on the above items to the list. Besides expressions of
>support, negative opinions are equally important. I have purposely
>listed perhaps more items than we'll be able to take on, so we
>will probably have to cut the list a bit shorter. Hence, any
>comments to help in that respect are also very useful.
>
>So please consider the rechartering discussion for MIPSHOP open
>(hopefully the directions mentioned above are close enough).
>
>Comments?
>
>-gabriel

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Mar 2005 17:47:34 +0200

Hi Basavaraj,

>standardize them in either MIPSHOP or MIP6.
I'm trying to understand your proposal. Is your suggestion that the
Charlie's
and Francis' work on RO security methods be moved to the IRTF? Or are
you suggesting some kind of a split where some methods are pursued in
the IETF while some others are sent to IRTF and standardized only later?

If its the latter, what kind of criteria do you think we should apply in
selecting work that gets done now vs. later? (From where I stand it
looks like we have the wrong priorities. But it would be helpful if we
could discuss the priorities, and the reasons for them, rather than
just saying that something goes forward and something does not.
Then no one would need to guess what the motives are. And we
might even learn something about the applicability and limitations
of various schemes.)

--Jari