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

Ben Campbell <> Mon, 13 August 2012 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4422721F867C; Mon, 13 Aug 2012 13:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kkgScxprJuPW; Mon, 13 Aug 2012 13:59:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 82C5421F8671; Mon, 13 Aug 2012 13:59:47 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q7DKwOPu081872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 15:58:26 -0500 (CDT) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-mptcp-api-05
From: Ben Campbell <>
In-Reply-To: <>
Date: Mon, 13 Aug 2012 15:58:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
X-Mailer: Apple Mail (2.1485)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Aug 2012 20:59:48 -0000

On Aug 13, 2012, at 9:14 AM, 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 

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.


> 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 :-)