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

From: Hui Deng <[email-masked]>
Date: Thu, 15 Dec 2011 20:09:35 +0800

Hello all
 
Based on last time IETF 82th MIF meeting, we are calling for the adoption of API document as the working group document in the mailing list.
Just want to conform if anybody have different opinion on this.
 
thanks
 
-Chairs

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Dec 2011 09:26:05 +1300

Um, exact draft name please?

Regards
   Brian Carpenter

On 2011-12-16 01:09, Hui Deng wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Hui Deng <[email-masked]>
Date: Fri, 16 Dec 2011 08:25:36 +0800

Thanks Brian, this is the link:
http://tools.ietf.org/id/draft-liu-mif-api-extension-06.txt

-Hui

2011/12/16 Brian E Carpenter <[email-masked]>

> > Based on last time IETF 82th MIF meeting, we are calling for the
> adoption of API document as the working group document in the mailing list.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Dec 2011 14:43:13 +1300

Thanks.

I think it's reasonable to adopt this draft.

Regards
   Brian

---

From: <[email-masked]>
Date: Fri, 16 Dec 2011 10:01:10 +0100

Hi,

I support the adoption of this I-D. IMHO, the proposed API model would allow to align our effort with the OMA-DM API. However, the liaison is to be clarified. 

Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de Hui Deng
Envoyé : jeudi 15 décembre 2011 13:10
À : [email-masked]; Margaret
Objet : [mif] Adoption of API document as the MIF WG document

Hello all

thanks
 
-Chairs

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 Dec 2011 11:25:03 -0500

On 2011-12-15 07:09, Hui Deng wrote:
> Based on last time IETF 82th MIF meeting, we are calling for the adoption of API
> document as the working group document in the mailing list.

I've always felt uneasy with this draft. At the Québec meeting I went to the mic 
and argued, perhaps incoherently, that this was not what we needed. Since then 
I've had time to understand exactly what caused my uneasiness.

As described in the RFC6419, applications currently do a lot of hackish (read 
"evil") things to try and guess what would be correct behaviour. Each app needs 
to reimplement this intelligence. Many apps get many things wrong. This is the 
mess we're in now.

I feel that the API draft tries to standardize the various incompatible APIs we 
have on various platforms, the very APIs that are currently used by apps for 
their hackish behaviour. I think it will make it easier for applications to 
implement hackish behaviour. It will perpetuate the mess we're in.

What is needed is a *very* high-level API, maybe based on happy eyeballs. This 
will avoid reinventing the wheel in each app. Something like a single function 
call, with flags to indicate desired aspects of the connection to be established, 
and the stack figures out the rest.

I don't think standardizing a low-level API such as is described in the API draft 
is useful. Actually, I think it could very well be harmful, by encouraging 
applications to reinvent the wheel.

And let me finish by preemptively addressing one possible rebuttal... Section 
3.3.2 says this:

3.3.2. High Level API

    Applications are generally expected to originate connections using
    some general-purpose high-level API suited to their particular
    function.  It is likely that different applications may use different
    high-level APIs to communicate, depending on their particular needs.
    We do not describe the functioning of such high-level APIs; however,
    one such API under current consideration is the Happy Eyeballs for
    MIF [reference].  These APIs are expected to be able to be
    implemented using functionality like that described in the MIF API.

This section does not say why a low-level API needs to be *standardized*. I agree 
it needs to *exist* for a high-level API to be standardized. Low-level APIs 
already do exist in various platform-dependent forms, as evidenced by RFC6419.

You can put this email in the "against adoption" bucket.

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Dec 2011 20:50:18 +0000

On Dec 16, 2011, at 11:25 AM, Simon Perreault wrote:
I feel that the API draft tries to standardize the various incompatible APIs we have on various platforms, the very APIs that are currently used by apps for their hackish behaviour. I think it will make it easier for applications to implement hackish behaviour. It will perpetuate the mess we're in.

This is the same point you raised at the meeting in QC, and it's wrong for the same reason: this API is not intended to be used by applications.   It is intended to describe all of the functionality that's required to implement a high-level API, which would then be used by applications.

There is pretty broad agreement that no single high-level API will address every use case: happy eyeballs is nice for certain use cases, but not for all, for example.   So we could try to enumerate every possible sort of high-level API and then document each of these, or we can try to tease out the functionality that any such API would require, and document that.   This spec is intended to serve the latter purpose.

The question of whether applications will program to this API is then orthogonal to the question of whether the API itself is useful.   You propose that if we don't define an API, applications will not use it, but in fact each operating system already has an incomplete API that looks something like what we are trying to document here.   So right now, applications can already misbehave in the way that you fear.

However, right now, if they do so, they will do so in a different way on each operating system, and indeed may simply not work on some operating systems because those systems do not provide any means to accomplish with a MIF-capable application needs to accomplish.   So by not documenting a low-level MIF API, what we do is make the scenario you are concerned about worse, not better.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Dec 2011 10:04:24 -0500

On 2011-12-16 15:50, Ted Lemon wrote:
> This is the same point you raised at the meeting in QC, and it's wrong for the
> same reason: this API is not intended to be used by applications. It is intended
> to describe all of the functionality that's required to implement a high-level
> API, which would then be used by applications.

Why not just specify the high-level API right away? Why is this intermediate step 
necessary? As you say, all the underlying functionality is already available on 
the various platforms out there.

I have the feeling that this will be the last step, and that no high-level API 
will be defined.

My point is that this document does not completely fulfill the API milestone 
because it is too low-level. The important part, the one that would have real 
potential to fix the mess we're in, is the high-level API.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Dec 2011 15:44:27 +0000

On Dec 19, 2011, at 10:04 AM, Simon Perreault wrote:
Why not just specify the high-level API right away? Why is this intermediate step necessary? As you say, all the underlying functionality is already available on the various platforms out there.

Which high-level API should we define, Simon?   There is no single high-level API that addresses all use cases.   And while there is piecemeal support for features of the low-level API, at the moment hardly anybody supports all the required functionality, as far as I can tell.   Also, a lot of the functionality is hidden under mid-level APIs that obscure features that would be required to implement the high-level APIs we want.   This is why I think this work is important.

My point is that this document does not completely fulfill the API milestone because it is too low-level. The important part, the one that would have real potential to fix the mess we're in, is the high-level API.

This is an easy problem for you to solve: write a document describing the high-level API you think we need.   Not everyone sees the problem the same way (obviously!) so this would be a very useful contribution, and I don't think it's wrong for the WG to advance both documents, since they solve different problems.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Dec 2011 10:49:58 -0500

On 2011-12-19 10:44, Ted Lemon wrote:
>> Why not just specify the high-level API right away? Why is this intermediate
>> step necessary? As you say, all the underlying functionality is already
>> available on the various platforms out there.
>
> Which high-level API should we define, Simon? There is no single high-level API
> that addresses all use cases.

I disagree, I think it is a solvable problem.

> And while there is piecemeal support for features
> of the low-level API, at the moment hardly anybody supports all the required
> functionality, as far as I can tell. Also, a lot of the functionality is hidden
> under mid-level APIs that obscure features that would be required to implement
> the high-level APIs we want. This is why I think this work is important.

Understood, thanks.

> This is an easy problem for you to solve: write a document describing the
> high-level API you think we need.

Yeah, I know. *sigh*

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.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Dec 2011 16:24:43 +0000

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.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Dec 2011 11:32:20 -0500

On 2011-12-19 11:24, Ted Lemon wrote:
>> place a "DONE" checkmark next to the API milestone. There is still API work to
>> be done.
>

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Dec 2011 16:42:08 +0000

On Dec 19, 2011, at 11:32 AM, Simon Perreault wrote:
I'd be happy with that. Something like...

[...]

Looks good to me!

What do the chairs think?

---

From: Hui Deng <[email-masked]>
Date: Tue, 20 Dec 2011 14:13:44 +0800

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

thanks

-Hui

2011/12/20 Simon Perreault <[email-masked]>

> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca/>
> ______________________________**_________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mif<https://www.ietf.org/mailman/listinfo/mif>
>

---

From: <[email-masked]>
Date: Tue, 20 Dec 2011 14:48:45 +0100

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 : [email-masked] [mailto:[email-masked]] 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

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: Simon Perreault <[email-masked]>
Date: Tue, 20 Dec 2011 09:10:46 -0500

On 2011-12-20 08:48, [email-masked] wrote:
> 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.
>
> -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
>
> -the API should allow to differentiate the traffic (i.e. provide capability to
> configure traffic selector)
>
> -associate a routing table per type of traffic

I think this is all low-level stuff.

Ideally, an application shouldn't have to deal with this stuff. It should be 
handled as automatically as possible by the stack. The high-level API should be 
as close to the "use case" as possible. For example, (I'm just inventing stuff 
now, not sure it makes sense), with an appropriate high-level API an application 
could just pass a flag saying "don't use a cellular interface".

The idea is that you don't want all apps to have to reimplement similar logic 
each time. The similar stuff can be abstracted away and put in the platform's stack.

Simon

---

From: <[email-masked]>
Date: Tue, 20 Dec 2011 15:25:34 +0100

> -----Message d'origine-----
> De : Simon Perreault [mailto:[email-masked]]
> Envoyé : mardi 20 décembre 2011 15:11
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]
> > I'm just trying to understand the scope of the MIF API and meaning of
> high/low
> > level API.
> >
> > imagine application with MIF management capabilities...). Typically,
> I'm thinking

Agreed.

> each time. The similar stuff can be abstracted away and put in the

I couldn't agree more :-) Your high-level API is what I use to name "a connection manager"... Whatever the terminology, I think this is the right way to go if want harmonization in the field. At least, it should be the default API model; however, some application developers may want to keep control of the connectivity and may want to have access to low-level API (I'm not sure it is desirable...). Let's see what the WG think.... 

Pierrick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Dec 2011 14:31:27 +0000

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.

---

From: <[email-masked]>
Date: Tue, 20 Dec 2011 15:59:53 +0100

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:[email-masked]] 
Envoyé : mardi 20 décembre 2011 15:31
À : SEITE Pierrick RD-RESA-REN
Cc : <[email-masked]>; <[email-masked]>; <[email-masked]>
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.

---

From: liu dapeng <[email-masked]>
Date: Thu, 22 Dec 2011 01:13:08 +0800

Hi Simon,

> If the charter was modified to something like the above then I'd change my

I am not sure what exactly the meaning of the "High-level API" here.
Since current API draft also "sepcify functionality intended for
applications's frequent tasks " and "abstract the tasks that need to
be perform" since we are not defining concrete API here.

regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu