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

gabriel montenegro <gab@sun.com> Fri, 25 March 2005 23:32 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 SAA29736 for <mipshop-web-archive@ietf.org>; Fri, 25 Mar 2005 18:32:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyO2-0002rI-JI for mipshop-web-archive@ietf.org; Fri, 25 Mar 2005 18:38:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEyHp-0000tO-37; Fri, 25 Mar 2005 18:32:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEyHn-0000tI-2K for mipshop@megatron.ietf.org; Fri, 25 Mar 2005 18:32:15 -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 SAA29722 for <mipshop@ietf.org>; Fri, 25 Mar 2005 18:32:12 -0500 (EST)
Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyNl-0002r2-7F for mipshop@ietf.org; Fri, 25 Mar 2005 18:38:25 -0500
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IDX002DGLDCNH00@mail-mta.sfvic.sunlabs.com> for mipshop@ietf.org; Fri, 25 Mar 2005 15:32:00 -0800 (PST)
Received: from [152.70.69.138] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IDX005ZPLD51ED0@mail.sunlabs.com> for mipshop@ietf.org; Fri, 25 Mar 2005 15:31:57 -0800 (PST)
Date: Fri, 25 Mar 2005 15:31:52 -0800
From: gabriel montenegro <gab@sun.com>
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones
In-reply-to: <456943D540CFC14A8D7138E64843F8535BAD06@daebe101.NOE.Nokia.com>
To: Basavaraj.Patil@nokia.com
Message-id: <42449F68.1030909@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Accept-Language: en-us, en
References: <456943D540CFC14A8D7138E64843F8535BAD06@daebe101.NOE.Nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
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: e472ca43d56132790a46d9eefd95f0a5
Content-Transfer-Encoding: 7bit

Basavaraj.Patil@nokia.com wrote:
> Hi Gabriel,
> 
> A few comments below:
> 
> 
>>Folks,
>>
>>Thanks for the excellent exchange so far. At this point, based on what I've
>>seen, I'd like to share with you how I'm seeing things.
>>
>>
>>MN-AR security
>>	seems like there is sufficient interest and this item is
>>	narrow enough to warrant further work on the SeND key
>>	reuse method as well as to develop a AAA-based solution.
>>	Whereas we believe there may be some IPR-issues to clarify
>>	with the SeND based approach (in spite of Jim's interpretation)
>>	we don't have the same clarity with respect to the AAA approach.
>>	Please come forward with your IPR disclosures on this. This is not
>>	optional.
>>	
>>	looking at 2 PS documents.
> 
> 
> The primary driver for MN-AR security is for fast handoffs. So given
> that I am not sure if it makes sense that the FMIPv6 protocol is
> experimental, yet one of the components of the overall handover
> solution (MN-AR security) is a proposed standard. Unless I am missing
> the driver for MN-AR security???

Raj,

I see in your message the same misunderstanding. I never suggested
we would not move FMIP to PS. The MN-AR security documents are there precisely
to enable that, yes.

> 
>>FMIPv6 itself
>>	I'd postpone this item given that we don't have a clear understandiung
>>	of what the exact relationship with DNA, CARD, 802.21 and the
>>	forthcoming 
>>	neighborhood discovery is (and heck, there's even a proposal for dhcp).
>>	I'm inclined not to include it for now
>>	until we know more, and look into it again until a few months have
>>	gone by and we have a better grasp of the security and the discovery
>>	portions. The former to continue here, the latter to continue elsewhere
>>	(e.g., mobopts).
> 
> 
> Agreed that there are a number of other pieces such as the ones you
> note above. However what does that have to do with moving the base
> FMIPv6 itself forward to PS? Based on some implementation experience I
> think it would be worthwhile to consider taking up the task of moving
> this forward to PS. All the surrounding stuff (DNA, CARD etc.) can
> proceed in their respective WGs without necessarily affecting the
> progression of FMIPv6 base.

never said we're not progressing FMIPv6 to PS. i'm just suggesting that
more work may need to happen before so, as per other threads on this alias.

> 
> 
>>FMIP-over-cdma
>>	This experimental document is a useful exercise to better understand
>>	deployment considerations and the above issues. It's also good in that
>>	it encourages another SDO to seriously think about this, even if it is
>>	in a preliminary manner (I don't believe they have firms and urgent
>>	deployment plans). I have heard of at least two groups of folks in
>>	the working group interested in this. You know who you are, and you
>>	should work together on one document. Highly desirable: go through the
>>	regular channels (ietf liaisons) and produce a document from 3GPP2
>>	on this subject.
>>
>>	looking at one informational document
> 
> 
> Why is there a necessity for a liaison from 3GPP2 to do this? I dont
> know if there was a liaison from IEEE when the FMIPv6 for 802.11 was
> done. I think it makes sense to work on this document irrespective of
> 3GPP2 interest or liaison statement.


it's tiring to have folks misinterpret text so regularly.
this is what i wrote (which is in the above snippet):

	Highly desirable

Is there any confusion about the meaning of that phrase? perhaps
you just missed it?

> 
> 
>>MN-MAP security for HMIPv6
>>	I'd like to think that such an item could be included, but we
>>	do need to see a draft on this subject in very short
>>	order. Conceptually, it does not seem a much more difficult
>>	problem than MN-AR security, so depending on how quickly the
>>	relevant draft can be produced, this could be entertained. It
>>	seems to me	that without this piece in place, talking
>>	about other HMIP work in MIPSHOP is premature (but it should
>>	continue elsewhere). Like FMIP, other work could be taken on later on.
>>
>>	perhaps (if a first solid draft appears shortly) one PS document
>>
> 
> 
> So do you see this draft as a precursor to making HMIPv6 a Proposed
> standard? 

Yes.
Just like MN-AR security is *a* precondition for FMIPv6 to PS,
it seems to me like a corresponding MN-MAP document is *a* precondition
for HMIPv6 PS.

> Dont necessarily think that there is a normative reference
> at this time.


not sure how to interpret this, could you please explain?

> 
> 
>>RO issues
>>	Not clear how much of EBU is new and how much is just further
>>	language on rfc 3775. At any rate, it does seem like a
>>	CGA-based scheme could be worked on (heck, the basic concept
>>	has been around for ages), using omip as a starting
>>	point. Highly desirable: go through the ietf channels and
>>	using the proper liaisons obtain a message from the SDOs
>>	reputedly interested in this item. This document would have
>>	the precondition for CBA (authenticated notification of CoA
>>	change to the CN). Ideally, we'd have a very simple CBA scheme
>>	in place as well.  Both of these mechanism would be optional
>>	(i.e., we're not in the business of replacing RR). 
>>
>>	looking at one PS document.
>>	
>>
>>This gives us a lot already, perhaps too much:
>>	(up to) 4 PS documents (perhaps 3)
>>	1 informational document
>>
> 
> 
> Some heavy lifting to be done no doubt :) But maybe some
> prioritization would make it easier to take on the work...

prioritization is what i'm suggesting. e.g., once we define
milestones, there is no mechanism to prioritize amongst
official WG milestones. the prioritization mechanism i can
see is: when some milestones are done or well advanced,
feed new ones into the list of official WG milestones.

...
> I think its a good start. I am still not sure why the WG would be
> shying away from standardizing (to PS) protocols 

i hope this confusion is clear now...

...

-gabriel

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