headers
Ben Campbell | 10 Aug 2012 21:31
Favicon

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
(Continue reading)

Permalink | Reply |
headers
philip.eardley | 13 Aug 2012 16:14
Favicon

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

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
(Continue reading)

Permalink | Reply |
headers
Ben Campbell | 13 Aug 2012 22:58

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


On Aug 13, 2012, at 9:14 AM, philip.eardley <at> 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].  
>
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 17 Aug 2012 12:15
Picon
Favicon

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


On 8/13/2012 7:14 AM, philip.eardley <at> 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/

This has been a big mistake in the past, IMO.

A key part of the definition of any protocol is its API. It is exactly 
as important as the "on the wire" component and the endpoint state and 
semantics of message exchanges.

See RFC793 for a great example. What we know as sockets there is 
basically a direct implementation of the *specified* API for TCP.

I can't argue that this document is a reason for the IETF to correct its 
past mistake, but the sooner it does the better. APIs ought to be a 
*mandatory* part of any protocol specification. As such, they should be 
at the same level as any other part of that spec (e.g.., standards track 
or experimental).

Joe
Permalink | Reply |

Gmane