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

Ben Campbell <ben@nostrum.com> Fri, 10 August 2012 19:31 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2264121F8666; Fri, 10 Aug 2012 12:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.45
X-Spam-Level:
X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boZ-YnG8a-Mp; Fri, 10 Aug 2012 12:31:16 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D346C21F865E; Fri, 10 Aug 2012 12:31:15 -0700 (PDT)
Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7AJVD13036521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 14:31:15 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Gen-ART LC Review of draft-ietf-mptcp-api-05
Date: Fri, 10 Aug 2012 14:31:11 -0500
Message-Id: <CCBAA297-B839-4AEA-BB24-F4D320200415@nostrum.com>
To: draft-ietf-mptcp-api.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
X-Mailer: Apple Mail (2.1485)
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Cc: General Area Review Team <gen-art@ietf.org>, IETF Discussion List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 19:31:17 -0000

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 a "standard" in an informational RFC might not be the best practice for solving that sort of process issue.


-- It seems like at least passing knowledge of the sockets API is needed to understand this document. I'm curious why the POSIX reference is informational rather than normative?

Nits/editorial comments:

-- 3.3.1, 1st paragraph: "This will provide greater bandwidth for an application. "

I assume this means "as great or greater", given the previous statements that MPTCP should be at worst no worse than normal TCP?

-- 3.2.1, 1st paragraph: "...while having TCP SYN/ACK ready to reply to..."

I had to think about this a while to figure out the meaning. Perhaps it could be rephrased?