Re: [Mipshop] MIPSHOP discussion on new items and milestones

Jari Arkko <jari.arkko@kolumbus.fi> Thu, 17 March 2005 06:16 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17392 for <mipshop-web-archive@ietf.org>; Thu, 17 Mar 2005 01:16:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBoNT-0004y7-Hy for mipshop-web-archive@ietf.org; Thu, 17 Mar 2005 01:21:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBoGz-000371-Bx; Thu, 17 Mar 2005 01:14:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBoGo-00036k-4K for mipshop@megatron.ietf.org; Thu, 17 Mar 2005 01:14:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17148 for <mipshop@ietf.org>; Thu, 17 Mar 2005 01:14:08 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBoKy-0004ui-RN for mipshop@ietf.org; Thu, 17 Mar 2005 01:18:29 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9900A8981E; Thu, 17 Mar 2005 08:13:58 +0200 (EET)
Message-ID: <4239203B.7020101@kolumbus.fi>
Date: Thu, 17 Mar 2005 08:14:19 +0200
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: gabriel montenegro <gab@sun.com>
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones
References: <4238786E.9040202@sun.com>
In-Reply-To: <4238786E.9040202@sun.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Content-Transfer-Encoding: 7bit
Cc: mipshop@ietf.org
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Content-Transfer-Encoding: 7bit

Hi Gabriel, and thanks for considering some new work!
Here are my main comments:

- MN-AR security is a significant issue in current specifications,
and as such addressing it would be really useful. But I wonder
about the need to have two different solutions in this space.
Seems like James' draft would technically work in all scenarios.
What he said about the IPR sounded positive too (but I am not
a lawyer nor have I looked at the relevant patents).

- FMIP PS is a good idea. Need to think about sequencing of
work, however. Presumably this would come after MN-AR security,
right?

- 1X-Ev or 802.11 applicability draft would also be useful, probably
Informational though.

- I believe RR optimizations are of great interest to the industry.
Ericsson is planning to implement OMIP/CGA scheme in products,
but its not going to happen if there are no RFCs or allocated numbers.
So this would be my first priority. (The current IPR note on that
is RAND, I believe, but I'm not a lawyer. Note also that our lawyer
has had some trouble making that note appear on the IETF web,
despite it being sent from us. We are trying to work on that problem.)

As draft-irtf-mobopts-ro-enhancements states, there are some
relatively stable RR enhancements that are basically waiting for
deployment experience. And different optimizations target different
scenarios (e.g. tradeoffs between latency and amount of signaling).
So I wouldn't want us to end up debating which single scheme
we need to choose, or attempt to perform more measurements.

As for the individial schemes, EBU as in doing proactive HOTIs
is probably sufficiently documented in terms of RFC 3775
already. To me only the CBA variant of EBU is interesting, so I'd
consider only doing a combined EBU/CBA document if we are going
to do it.

--Jari

gabriel montenegro wrote:

>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
>Mipshop@ietf.org
>https://www1.ietf.org/mailman/listinfo/mipshop
>
>  
>


_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop