Skip to main content

Last Call Review of draft-ietf-mptcp-api-05
review-ietf-mptcp-api-05-genart-lc-campbell-2012-08-10-00

Request Review of draft-ietf-mptcp-api
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-08-14
Requested 2012-08-03
Authors Michael Scharf , Alan Ford
I-D last updated 2012-08-10
Completed reviews Genart Last Call review of -05 by Ben Campbell (diff)
Genart Telechat review of -06 by Ben Campbell (diff)
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-mptcp-api by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 07)
Result Ready
Completed 2012-08-10
review-ietf-mptcp-api-05-genart-lc-campbell-2012-08-10-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-mptcp-api-05

Reviewer: Ben Campbell
Review Date: 2012-08-10
IETF LC End Date: 2012-08-14

Summary: This draft is almost ready for publication, but I have questions about
its intended informational status.

Major issues: None

Minor issues:

-- Section 5 specifies an abstract "basic" API for MPTCP. The draft
characterizes this as an extension to the sockets API. On it's face, this
sounds like it's creating a standard, or will at least have the effect of
creating a standard. Is that the intent? If so, I wonder why the intended
status is informational rather than standards track? If not, it would be useful
to explicitly state the intent. (For example, is this intended as an input to
inform a standardization effort?)

I realize that the sockets API is not an IETF standard. I don't know if that is
part of the reason for making this draft informational, nor am I familiar with
precedent for extending non-IETF-native standards. But at the risk of attacking
a straw man, I am concerned that putting something that could be interpreted as
a "standard" in an informational RFC might not be the best practice for solving
that sort of process issue.

-- It seems like at least passing knowledge of the sockets API is needed to
understand this document. I'm curious why the POSIX reference is informational
rather than normative?

Nits/editorial comments:

-- 3.3.1, 1st paragraph: "This will provide greater bandwidth for an
application. "

I assume this means "as great or greater", given the previous statements that
MPTCP should be at worst no worse than normal TCP?

-- 3.2.1, 1st paragraph: "...while having TCP SYN/ACK ready to reply to..."

I had to think about this a while to figure out the meaning. Perhaps it could
be rephrased?