Sockets Application Program Interface (API) for Multihoming Shim
draft-ietf-shim6-multihome-shim-api-17
Discuss
Yes
(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 Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2011-03-01)
Unknown
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.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
(was Discuss)
No Objection
No Objection
(2011-04-30)
Unknown
I'm satisfied with the changes in -16 and I've cleared my Discuss.
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2011-03-02)
Unknown
#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
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown