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

Joe Touch <> Fri, 17 August 2012 10:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF60E21F8473; Fri, 17 Aug 2012 03:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.493
X-Spam-Status: No, score=-105.493 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AKdD2r67lqFa; Fri, 17 Aug 2012 03:16:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2107021F8467; Fri, 17 Aug 2012 03:16:13 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q7HAFR8H023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Aug 2012 03:15:29 -0700 (PDT)
Message-ID: <>
Date: Fri, 17 Aug 2012 03:15:23 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
Subject: Re: Gen-ART LC Review of draft-ietf-mptcp-api-05
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
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: Fri, 17 Aug 2012 10:16:13 -0000

On 8/13/2012 7: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

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