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

Hi all,

I'm just trying to understand the scope of the MIF API and meaning of high/low level API. 

So, thinking about high-level requirements: IMU, the MIF API should address issues from the problem statement : DNS selection, source address selection and routing. Right? Considering these problems, the MIF API should be able to provide command/services to high level API (e.g. OMA-DM API), or even applications (if we imagine application with MIF management capabilities...). Typically, I'm thinking to the following requirements for the MIF API:

DNS selection:

-          bound some DNS servers to an interface and suffixes. 

source address selection: 

-          return the type of IP address (e.g. local, remote, mobile IP anchored 

-          provide a valid IP address with a given type on a given interface

routing / first-hop selection: 

-          the API should allow to differentiate the traffic (i.e. provide capability to configure traffic selector)

-          associate a routing table per type of traffic

Are we on the same page?

BR,

Pierrick

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui Deng
Envoyé : mardi 20 décembre 2011 07:14
À : Simon Perreault; MIF Mailing List
Objet : Re: [mif] Adoption of API document as the MIF WG document

This is a new recharter proposal which need to be discussed during next ietf meeting all together

thanks

-Hui

2011/12/20 Simon Perreault <simon.perreault@viagenie.ca>

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 <http://postellation.viagenie.ca/> 
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca <http://ecdysis.viagenie.ca/> 
STUN/TURN server               --> http://numb.viagenie.ca <http://numb.viagenie.ca/> 
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif