Re: [mif] Adoption of API document as the MIF WG document

Simon Perreault <simon.perreault@viagenie.ca> Mon, 19 December 2011 16:32 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890CF21F8B50 for <mif@ietfa.amsl.com>; Mon, 19 Dec 2011 08:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599]
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 hgoTf9OS7aHT for <mif@ietfa.amsl.com>; Mon, 19 Dec 2011 08:32:51 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7438821F84C9 for <mif@ietf.org>; Mon, 19 Dec 2011 08:32:51 -0800 (PST)
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A737F20E64; Mon, 19 Dec 2011 11:32:20 -0500 (EST)
Message-ID: <4EEF6714.40804@viagenie.ca>
Date: Mon, 19 Dec 2011 11:32:20 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <COL118-W224376376AE7A3CC854753B1A30@phx.gbl> <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> <4EEF5D26.3080203@viagenie.ca> <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com>
In-Reply-To: <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] Adoption of API document as the MIF WG document
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2011 16:32:52 -0000

On 2011-12-19 11:24, Ted Lemon wrote:
> On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote:
>> I just don't want the WG to see this document as something that allows us to
>> place a "DONE" checkmark next to the API milestone. There is still API work to
>> be done.
>
> Well, an easy fix for this is to add a milestone that addresses this concern.

I'd be happy with that. Something like...

   3) MIF API: While no changes are needed for applications to run on
   multiple interface hosts, a new API could provide additional services
   to applications running on hosts attached to multiple provisioning
   domains. For instance, these services could assist advanced
   applications in having greater control over first-hop, source address
   and/or DNS selection issues. This API will be defined as an abstract
   interface specification, i.e., specific details about mapping to
   operating system primitives or programming language will be left out.

     3.1) Low-level API: This API will specify base functionality that a
     platform needs to make available for the high-level API to be possible.
     It is intended to be used by applications for most tasks: that will be the
     high-level API's role. Applications could still call into the low-level API
     to perform complex, infrequent tasks.

     3.2) High-level API: This API will specify functionality intended for
     applications' frequent tasks. The term "high-level" means that it will
     abstract the tasks that need to be perform and minimize an application's
     knowledge of a node's network configuration. It should be easy to use and
     appropriate for most of tasks commonly performed by applications.

If the charter was modified to something like the above then I'd change my 
position to "support"...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca