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 rev. 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
Draft 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
Review review-ietf-mptcp-api-05-genart-lc-campbell-2012-08-10
Reviewed rev. 05 (document currently at 07)
Review result Ready
Review completed: 2012-08-10

Review
review-ietf-mptcp-api-05-genart-lc-campbell-2012-08-10

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?