Skip to main content

Sockets Application Program Interface (API) for Multihoming Shim
RFC 6316



(Jari Arkko)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)

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

Lars Eggert
Discuss (2011-03-01)
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.
Comment (2011-03-01)
Section 2., paragraph 1:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    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 IESG member
Yes ()

Adrian Farrel Former IESG member
No Objection
No Objection ()

Dan Romascanu Former IESG member
No Objection
No Objection ()

Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

Peter Saint-Andre Former IESG member
No Objection
No Objection ()

Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2011-04-30)
I'm satisfied with the changes in -16 and I've cleared my Discuss.

Robert Sparks Former IESG member
No Objection
No Objection ()

Ron Bonica Former IESG member
No Objection
No Objection ()

Russ Housley Former IESG member
No Objection
No Objection ()

Sean Turner Former IESG member
No Objection
No Objection (2011-03-02)
#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 IESG member
No Objection
No Objection ()

Tim Polk Former IESG member
No Objection
No Objection ()