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

<pierrick.seite@orange.com> Tue, 20 December 2011 14:59 UTC

Return-Path: <pierrick.seite@orange.com>
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 612A221F8B01 for <mif@ietfa.amsl.com>; Tue, 20 Dec 2011 06:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level:
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 DF8dgY5ZSo3D for <mif@ietfa.amsl.com>; Tue, 20 Dec 2011 06:59:55 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3C21F8AFD for <mif@ietf.org>; Tue, 20 Dec 2011 06:59:55 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D2DF6E306C6; Tue, 20 Dec 2011 16:10:50 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id C7DE4E306A8; Tue, 20 Dec 2011 16:10:50 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 15:59:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBF28.07B3A292"
Date: Tue, 20 Dec 2011 15:59:53 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202169D99@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <0158B512-7C05-4F3D-8816-872035534E87@nominum.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mif] Adoption of API document as the MIF WG document
Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEACABFZmAIAACzCAgAABiwCAAAmzgIAAAiMAgADlfwCAAH8igIAAC+0A//9/mnA=
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><4EEF6714.40804@viagenie.ca> <CANF0JMBt=7rB0++NYxnMrfRLz2XJDg40OLMrgOPj6fYAUTWNYg@mail.gmail.com> <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> <0158B512-7C05-4F3D-8816-872035534E87@nominum.com>
From: pierrick.seite@orange.com
To: Ted.Lemon@nominum.com
X-OriginalArrivalTime: 20 Dec 2011 14:59:54.0213 (UTC) FILETIME=[08159150:01CCBF28]
Cc: 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: Tue, 20 Dec 2011 14:59:57 -0000

Thanks for clarifications, I think we are on the same page J 

 

Regarding routing manipulation, I think it should be included in API requirement; let's see what other people think.

 

Pierrick

 

De : Ted Lemon [mailto:Ted.Lemon@nominum.com] 
Envoyé : mardi 20 décembre 2011 15:31
À : SEITE Pierrick RD-RESA-REN
Cc : <denghui02@gmail.com>; <simon.perreault@viagenie.ca>; <mif@ietf.org>
Objet : Re: [mif] Adoption of API document as the MIF WG document

 

	Are we on the same page?

 

The high-level API probably shouldn't expose interfaces-it should simply attempt to make a connection when you hand it a name.   Two proposals for a high-level interface that have been discussed are the MIF Happy Eyeballs API, and the connect_to_name API.   With both APIs, you basically hand the API a name and it hands you back a socket connected to the host addressed by that name.   It does all the fiddling under the covers to figure out which interface to use and which DNS servers to use and which protocol to use.

 

What you described is more like the low-level API.   One distinction that you didn't mention in your description is that we intend have a lower level of granularity than the interface.   Because it's possible for more than one address family to be attached to an interface, and because it's possible for an interface to be attached to a multi-homed network, we've defined a "provisioning domain" which is the place where things like DNS server configuration happen.   There can be more than one provisioning domain per interface; provisioning domains never span interfaces.

 

You mention an additional concept in your summary: a routing table per type of traffic.   We have not talked about this, and I don't know that it's in scope.   I would very much like to know what other participants think about this, and how it might be used.   It's not really on my radar, but this is good: I'm by no means an expert on this problem space, and my hope was that people would read the MIF API doc and notice what's missing and bring it up here on the mailing list.