ietf
[Top] [All Lists]

Gen-ART LC Review of draft-ietf-mptcp-api-05

2012-08-10 14:31:37
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?

<Prev in Thread] Current Thread [Next in Thread>