On Aug 13, 2012, at 9:14 AM, philip.eard...@bt.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. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
