[shim6] FW: WG Last Call for draft-ietf-shim6-multihome-shim-api

[Shinta Sugimoto <[e-mail]>]

(let me forward the email from Michael Scharf. It seems that the email did not reach the ML) 

-----Original Message-----
From: SCHARF, Michael [mailto:[e-mail]] 
Sent: Friday, December 18, 2009 9:20 PM
To: [e-mail]
Cc: Shinta Sugimoto
Subject: RE: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

Dear all,

I had a look at draft-ietf-shim6-multihome-shim-api-11. Unfortunately, I have not followed the discussion before, and I am not an expert in SHIM6 and HIP. But I hope that my comments are still useful.


Summary:
--------

In general, I think that the document is already in a good shape, but some small modifications and clarifications are needed, as explained below.


Comments:
---------

> 1.  Introduction
>
>  HIP and SHIM6 have a commonality in their protocol design in the  
> sense that the semantic roles of an IP address, i.e., an identifier  
> and a locator, are distinguished.

It could maybe help to better understand the API if there there was an overview paragraph that explains which parts of the API can indeed be applied to HIP or SHIM6, respectively. While the slight differences are addressed various times in the API specification, an additional overall statement would make sense, e. g., in Section 5.

Also, the system model in Figure 2 seems to apply more to HIP than to SHIM6.

>   The distinction between "connected" sockets and "unconnected"
sockets
>   is important when discussing the applicability of the socket API
>   defined in this document.  A connected socket is bound to a given
>   peer, whereas an unconnected socket is not bound to any specific
>   peers.  That is, the destination of the user data is not known until
>   the application writes data to an unconnected socket.  TCP sockets
>   are connected, by definition.  UDP sockets are unconnected, unless
>   the application uses the connect() system call.

I would classify a TCP socket as "unconnected" before the TCP connection is established, i. e., before the connect()/accept() system call. Some of the socket API functions could indeed be called before the TCP connection is established (e. g., SHIM_DONTSHIM, SHIM_DEFERRED_CONTEXT_SETUP).

The document should more explicitly describe which of the socket options can be set for an "unconnected" TCP socket.

> 3.  System Overview
>
>   It may also be possible that the shim sub-layer interacts with the
>   transport layer, however, such an interaction is outside the scope
of
>   this document.

In addition to interactions, there could also be API conflicts with a multi-homing capable transport, which are probably outside of the scope of this document, too.

> 4.  Requirements
>   o  Turn on/off shim.  An application should be able to request to
>      turn on or turn off the multihoming support by the shim layer:
>      *  Apply shim.  The application should be able to explicitly
>         request the shim sub-layer to apply multihoming support.
>      *  Don't apply shim.  The application should be able to request
>         the shim sub-layer not to apply the multihoming support but to
>         apply normal IP processing at the IP layer.

I think that this is a quite important requirement and could be put first in the list.

> 5.11.  SHIM_LOCLIST_LOCAL
>
>   An application can get the locator list by getsockopt().  Note that
>   the size of the buffer pointed by optval argument should be large
>   enough to store an array of locator information.  The number of the
>   locator information is not known beforehand.

This leaves open what happens if the buffer size is not large enough to store all locators. I think there should be some comment what would happen in this corner case.

> 5.15.  Applicability
>
>   All the socket options for the multihoming shim sub-layer except for
>   SHIM_HOT_STANDBY are applicable for both connected and unconnected
>   sockets.

As already mentioned, this section should IMHO discuss in which state of a TCP connection the different socket options can be used.

> 6.4.  Notification from Multihoming Shim Sub-layer to Application

Based on the description, I am not sure if I really understand how this notification mechanism would actually work, and what it would imply.

> 11.1.  Naming at Socket Layer

This subsection could IMHO be moved to Section 9. Maybe there should also be a comment on potential implications of returning the EID in case of legacy applications.

> 11.2.  Additional Requirements from Applications

I am not sure why this subsection is needed.

> 11.3.  Issues of Header Conversion among Different Address Family 
> 11.4.  Handling of Unknown Locator Provided by Application

These two subsection should IMHO more clearly state what the open issue is.


Some editorial comments:
------------------------

* In general, I think that the use of articles ("a", "the") should be reviewed in some paragraphs. But I am not a native speaker.

* Page 8: Typo: [RFC5534]]

* Page 21: "An error EINVALIDLOCATOR is returned when an invalid locator is specified."


Best regards

Michael