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

Shinta Sugimoto <shinta@sfc.wide.ad.jp> Thu, 14 October 2010 05:33 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 7DC8C3A68BC for <shim6@core3.amsl.com>; Wed, 13 Oct 2010 22:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.895
X-Spam-Level: ***
X-Spam-Status: No, score=3.895 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FRT_STOCK2=3.988, 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 K0m7j3WsfnZS for <shim6@core3.amsl.com>; Wed, 13 Oct 2010 22:33:30 -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 578073A68B2 for <shim6@ietf.org>; Wed, 13 Oct 2010 22:33:30 -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 C275B27808F; Thu, 14 Oct 2010 14:34:44 +0900 (JST)
Message-ID: <4CB6951F.7040103@sfc.wide.ad.jp>
Date: Thu, 14 Oct 2010 14:29:03 +0900
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
User-Agent: Thunderbird 2.0.0.6 (X11/20070809)
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
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>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC4519C0@XCH-NW-10V.nw.nos.boeing.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'Miika Komu' <mkomu@cs.hut.fi>, 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: Thu, 14 Oct 2010 05:33:31 -0000

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)? The socket option can be described as follows:

- The socket option allows application to specify the destination IP 
address to send HIP I1 message.
- This socket option is accepted only when the multihoming shim 
sub-layer is HIP. Otherwise, EOPNOTSUPP is returned.
- There is no specific requirements about the type of socket to which 
the setsockopt() is called (but it should be in an unconnected state as 
I mentioned in my previous email).
- There is no specific requirements about the presence of shim context 
associated with the socket either. (but there should be no shim context 
associated with the socket because the socket option is supposed to be 
called at the very beginning of the session)

Please let me know if the above sounds reasonable to you, Miika and Thomas.

Regards,
Shinta