Ben,
Thanks for your review.
The right status isn't clear-cut (I think), but when we (Chairs & Wes)
discussed it, Info seemed best
* mainly because precedent seems to be that API docs are informational, for
example socket API extensions for SCTP http://datatracker.ietf.org/doc/rfc6458/
* also the doc has two main parts - looking at the impact that MPTCP may have
on application performance - and describing a basic API for MPTCP-aware
applications. The first part seems clearly Informational. So if the API part is
not Info, there is the effort of splitting the doc. Pragmatically I think this
should only be done if clearly needed.
I'm afraid I don't know case history of how the IETF tries to extend non-IETF
standards.
On the status of Posix reference, which appears twice in the doc
The abstract specification is in line with the
Posix standard [17] as much as possible
One commonly used TCP socket option (TCP_NODELAY) disables the Nagle
algorithm as described in [2]. This option is also specified in the
Posix standard [17].
The guidance:
Normative references specify documents that must be read to understand or
implement the technology in the new RFC, or whose technology must be present
for the technology in the new RFC to work.
On its second appearance, I think [17] is definitely being used informatively.
The first appearance is less clear cut, I think. Am inclined to say this is
still informative - it's just explaining the style adopted for the abstract
specification (if [17] changed then it wouldn't be necessary to change this
doc).
Thanks also for the nits
Best wishes
phil
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: 10 August 2012 20:31
To: draft-ietf-mptcp-api(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: General Area Review Team; IETF Discussion List
Subject: Gen-ART LC Review of draft-ietf-mptcp-api-05
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?