Sockets Application Program Interface (API) for Multihoming Shim
draft-ietf-shim6-multihome-shim-api-17

Note: This ballot was opened for revision 17 and is now closed.

Lars Eggert Discuss

Section 5., paragraph 2:
>    o  Providing locator information to applications.  An application
>       should be able to obtain information about the locator pair which
>       was actually used to send or receive the packet.

  DISCUSS: What do you mean by "the packet"? Applications see sockets
  out of which they read data. With UDP, you could add a sockopt to get
  information about the last packet sent or received, but with TCP, I
  don't see how this is supposed to work? Or do you mean the addresses
  the shim layer is currently using for the socket?


Section 6.2., paragraph 3:
>    Default value is set as 0, which means that the shim sub-layer
>    performs identifier/locator adaptation if available.

  DISCUSS: I don't think an Informational API document is the place to
  specify mandatory default protocol behavior. (If this default behavior
  is in the protocol specification, please rephrase this and refer to
  the text there.) Note that there are several sections below (6.3,
  6.12, etc.) that define "default" protocol behavior, and this issue
  occurs whenever the default value for an option turns protocol
  behavior on or off (i.e., it doesn't apply in cases where the default
  merely affects the behavior of the API itself.)


Section 8.2., paragraph 0:
> 8.2.  Path Exploration Parameter

  DISCUSS: This section needs to use a RFC2119 MUST whenever it talks
  about what do do with parameters from RFC5334. It's not up to an
  Informational API document to weaken what is mandated there.

Section 2., paragraph 1:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].

  This document is very inconsistent with its use of RFC2119 terms.
  There are many lower-case instances of those terms that I think should
  be capitalized. There are other cases where wording changes to use
  RFC2119 terms would clarify things.


Section 6., paragraph 0:
> 6.  Socket Options for Multihoming Shim Sub-layer

  In many of the subsections under Section 6 that discuss the individual
  options, the explanatory text doesn't always explicitly state if what
  is being described is when an option is used with setsockopt vs. with
  getsockopt. The (unstated) default seems to assume setsockopt. It
  would be very good to explicitly clarify this, maybe even by
  explicitly adding subsections for set and get under each.

(Jari Arkko; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Peter Saint-Andre; former steering group member) No Objection

(Ralph Droms; former steering group member) (was Discuss) No Objection

I'm satisfied with the changes in -16 and I've cleared my Discuss.

(Robert Sparks; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Sean Turner; former steering group member) No Objection

#1) Why assume only one shim sub-layer is active at a time?  Wouldn't the most useful thing for this API to work when WiFi and GSM data are both usable? (Or maybe I'm misunderstanding the text.) In any case, it'd be useful to say why handling both being active is hard or out of scope.

#2) I'm curious why there are no requirements to expose security related information, esp IPsec? If it's available wouldn't it be good to provide that?

(Stewart Bryant; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection