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?