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

[Shinta Sugimoto <[e-mail]>]

Let me forward another email as well.

Regards,
Shinta 

-----Original Message-----
From: SCHARF, Michael [mailto:[e-mail]] 
Sent: Friday, January 15, 2010 12:23 AM
To: Shinta Sugimoto
Subject: RE: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

Dear Shinta, 

I briefly scanned through -12. All in all, it seems to be OK for me.

Concerning the out-of-band stuff, it could be convenient to have the reference to one of the Stevens books in the draft; maybe other readers may find a reference helpful, too. But that's a comment of the category "would be nice to have".

Feel free to forward the mail to the list.

Michael 
 

> -----Original Message-----
> From: Shinta Sugimoto [mailto:[e-mail]]
> Sent: Wednesday, January 13, 2010 3:03 AM
> To: SCHARF, Michael
> Subject: RE: [shim6] WG Last Call for 
> draft-ietf-shim6-multihome-shim-api
> 
> Dear Michael,
> 
> Thank you for the comments. Please find my answers inline.  
> BTW, I hope you do not mind if I forward this email to the
> SHIM6 WG mailing list.  We (the WG) need to confirm that all the 
> comments/issues raised during the WGLC are addressed in the revision 
> of the document.
>
> > -----Original Message-----
> > From: SCHARF, Michael [mailto:[e-mail]]
> > Sent: Friday, January 08, 2010 9:25 PM
> > To: Shinta Sugimoto
> > Subject: RE: [shim6] WG Last Call for 
> > draft-ietf-shim6-multihome-shim-api
> > 
> > Dear Shinta,
> > 
> > some small clearifications inline.
> > 
> > > > Also, the system model in Figure 2 seems to apply more to
> > > HIP than to
> > > > SHIM6.
> > > 
> > > Why do you think so?  In my understanding, the system model
> > depicted
> > > in Figure 2 can be applied to both HIP and SHIM6.
> > 
> > I was a little bit confused by the IPv4 boxes in that figure. 
> > I thought that SHIM6 is IPv6-only.
> 
> Ok, I see.  Yes, SHIM6 is basically only for IPv6.  
> Identifiers must be IPv6 as SHIM6 as the security mechanism to prove 
> identity ownership is based on cryptographically generated addresses 
> (CGA/HBA).  On the other hand, it is possible (in theory) to use IPv4 
> locators although it is not specified in the protocol specification.  
> The possibility of using IPv4 locators was discussed several times on 
> the SHIM6 WG mailing list in the past.
> 
> > > > 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.
> > > 
> > > True.  This was pointed out by Brian and we agree to mention that:
> > > 
> > > - it is not recommended to apply SHIM6 (or HIP) and any other 
> > > multihoming mechanism to the IP flow by referring to 
> > > draft-ietf-shim6-applicability
> > > - we recommend SCTP and multipath TCP to have API to turn
> > on/off the
> > > multihoming feature (so that the TCP/IP stack can avoid
> conflicting
> > > use of multihoming mechanisms)
> > 
> > Fine for me.
> > 
> > For MPTCP, this essentially means that the API must turn off the 
> > multipath transport, right?
> 
> Yes.
> 
> > > > > 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.
> > > 
> > > This is to notify the application about the locator
> change within a
> > > multihome shim context.  Suppose if applications that run
> on host 1
> > > (H1) and host 2 (H2) are communicating each other.  Let's
> > assume H1 is
> > > multihomed and has two locators, L1_H1 and L2_H1, and H2 is
> > a single
> > > homed host which comes with a single locator L2_H2.  
> Suppose if the
> > > applications use L1_H1 and L2_H2 to send user data.  Now,
> > reachability
> > > between L1_H1 and L2_H2 is lost for some reason and the
> multihoming
> > > shim sub-layer decides to re-home the application
> session.  The H1
> > > changes its locator from L1_H1 to L2_H1.  The notification
> > defined in
> > > this section is sent to the application in this kind of
> > circumstance,
> > > i.e., whenever the locator change happens within a
> multihomed shim
> > > context.  The reaction of the application upon receiving this 
> > > notification is outside the scope of this ID, but we believe such 
> > > notification is useful, e.g., for application that are
> sensitive to
> > > characteristics of the communication channel.
> > > Does this make sense?
> > 
> > Yes, this is indeed a relevant use case.
> 
> Ok.
> 
> > But I struggled with the description of the realization the 
> > out-of-band notification, which is AFAIK a rather unusual
> sockets API
> > mechanism. It would help if there was a reference to a 
> > description/tutorial of this out-of-band mechanism
> (Steven's book?). I
> > have not found many examples for the usage of the forth argument of
> > select() so far, but maybe I have searched in the wrong places.
> 
> I see.  To be honest, I am also not so familiar of the use of 
> out-of-band data handling.  For instance, the out-of-band data is used 
> in Telnet to send interrupt signalg (e.g., Ctrl-C).  Yes, detailed 
> explanations are given in Steven's book.  Besides, Section 24 of the 
> book titled "UNIX Network Programming" (by Stevens, Fenner, and 
> Rudoff) also gives detailed explanation about out-of-band data 
> handling.
> 
> We've submitted revision (version 12) of the document which reflects 
> all of your comments. I'd appreciate if you could check the document 
> to see if changes made are fine from your p.o.v.  Thanks!
> http://tools.ietf.org/id/draft-ietf-shim6-multihome-shim-api-12.txt
> 
> Regards,
> Shinta
>