Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api

Shinta Sugimoto <shinta@sfc.wide.ad.jp> Fri, 15 October 2010 04:45 UTC

Return-Path: <shinta@sfc.wide.ad.jp>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91473A686E for <shim6@core3.amsl.com>; Thu, 14 Oct 2010 21:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.233
X-Spam-Level: **
X-Spam-Status: No, score=2.233 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I7vrWad0lyu for <shim6@core3.amsl.com>; Thu, 14 Oct 2010 21:45:48 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id BA2663A68B6 for <shim6@ietf.org>; Thu, 14 Oct 2010 21:45:47 -0700 (PDT)
Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E6C77278083; Fri, 15 Oct 2010 13:47:05 +0900 (JST)
Message-ID: <4CB7DB72.4010800@sfc.wide.ad.jp>
Date: Fri, 15 Oct 2010 13:41:22 +0900
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
User-Agent: Thunderbird 2.0.0.6 (X11/20070809)
MIME-Version: 1.0
To: Miika Komu <mkomu@cs.hut.fi>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@ cs.hut.fi> <4535F52C-8E78-4CBE-8983-DD7195722865@apnic.net> <4C69DE84.8010 7 06@sfc.wide.ad.jp> <4C91D119.5010101@cs.hut.fi> <4C91E946.6080807@sfc.wide.ad.jp> <4C920431.2090603@cs.hut.fi> <86C69B19-D385-46A9-B116-5EE198273305@apnic. n e t> <4CAA425E.2070906@piuha.net> <4CAEB35B.3020107@cs.hut.fi> <4CAEDEAD.9060407@piuha.net> <4CAF01F6.3030905@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC451999@X CH-NW-10V.nw.nos.boeing.com> <4CB53CCC.3080903@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC4519A4@XCH-NW-10V.nw.nos.boeing.com> <4CB68883.7070408@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC4519C0@XCH-NW-10V.nw.nos.boeing.com> <4CB6951F.7040103@sfc.wide.ad.jp> <4CB76C19.208@cs.hut.fi>
In-Reply-To: <4CB76C19.208@cs.hut.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: shim6 <shim6@ietf.org>, "kristian.slavov@ericsson.com" <kristian.slavov@ericsson.com>
Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Oct 2010 04:45:50 -0000

Hi Miika,

Miika Komu wrote:
> Hi,
> 
> On 10/14/2010 08:29 AM, Shinta Sugimoto wrote:
>> Hi Miika and Thomas,
>>
>> Henderson, Thomas wrote:
>>>
>>>> -----Original Message-----
>>>> From: Miika Komu [mailto:mkomu@cs.hut.fi]
>>>> Sent: Wednesday, October 13, 2010 9:35 PM
>>>> To: Henderson, Thomas R
>>>> Cc: shim6; kristian.slavov@ericsson.com
>>>> Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
>>>>
>>>> Hi,
>>>>
>>>> On 13/10/10 17:23, Henderson, Thomas R wrote:
>>>>
>>>>> Yes, but the HIP native API draft does not say anything about
>>>>> overriding the rules in the shim6 API specification concerning
>>>>> the need for shim context. Maybe that should be clarified in
>>>>> the HIP API draft.
>>>> I think it would have been simpler to keep the exception in the SHIM6
>>>> draft rather than changing the HIP draft which is in editor queue
>>>> (blocked by the SHIM6 draft)?
>>>>
>>>
>>> You raise a good procedural point; I would also be fine with editing
>>> the shim6 draft if Shinta is OK with it.
>>
>> I see.
>>
>> I would like to keep the socket option (to specify the initial locator,
>> i.e., where to send I1 message) separate from SHIM_LOC_PEER_SEND because
>> they are semantically different. Are you fine with adding a socket
>> option something like SHIM_INITIAL_PEER_LOCATOR in the multihome shim
>> API document (this one)?
> 
> procedurally, I'm not really fine with this because then we have to 
> change anyway the native HIP API. It is already referring to 
> SHIM_LOC_PEER_PREF, SHIM_LOCLIST_PEER and SHIM_LOC_PEER_SEND:
> 
> http://tools.ietf.org/html/draft-ietf-hip-native-api-12#section-4.6

Ok, I read section 4.6 of the HIP Native API document.

> Technically, I am not convinced if having a separate constant for 
> initial locator is really needed.

Well, the feature is the same. But the requirements and pre-requisites 
are different. Anyway, let's resolve this.

> It seems that we have the following options:
> 
> 1. Override the statement in the native HIP API draft
> 2. Remove the statement in the SHIM API
> 3. Cross-reference the native HIP API draft
> 4. Document the exception for HIP in the SHIM API
> 
> I would be in favor of 2 and perhaps 3. What about others?

By 2, you mean updating the texts in the SHIM API document, correct?

What about updating the texts for Section 13.1.2 (replacing the second 
paragraph) as follows:

If the shim sub-layer turns out to be HIP, the HIP implementation MUST 
reject the request (SHIM_LOC_PEER_SEND as cmsg_type) for using a unknown 
destination locator. There is, however, an exceptional case where the 
HIP implementation SHOULD accept the request provided that the message 
to be sent by sendmsg() contains an I1 packet. In this exceptional case, 
the kernel SHOULD accept the request even if there is no shim context 
associated with the socket.

Does this sound reasonable?

Regards,
Shinta