On Aug 13, 2012, at 9:14 AM, philip(_dot_)eardley(_at_)bt(_dot_)com wrote:
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/
I'm willing to accept that there is precedent for doing this in an
informational. (I wonder about the rational used previously, but that's
probably neither here nor there.)
* 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.
Agreed.
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).
Agree that the 2nd appearance is informational. But the paragraph containing
the first citation also contains the language "
The de facto standard API for TCP/IP applications is the "sockets" interface.
This document provides an abstract definition of MPTCP-specific extensions to
this interface." It seems to me that one needs to understand the sockets api
in order to understand an extension to the sockets api. . (And, as an
additional nit, the first quoted sentence could probably also use a citation to
[17])
Thanks also for the nits
You're welcome :-)
Thanks!
Ben.