[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mif] problem-statement: api



Hi,

> -----Message d'origine-----
> De : Zhen Cao [mailto:caozhenpku at gmail.com]
> Envoyé : mardi 10 novembre 2009 05:10
> À : SEITE Pierrick RD-RESA-REN
> Cc : marc.blanchet at viagenie.ca; mif at ietf.org
> Objet : Re: [mif] problem-statement: api
> 
> Hi,
> 
> Although i was not at the meeting site, i attended the meeting using
> the audio streaming service and was clear that people agreed to
> elaborate the API issues more clearly in the PS draft.
> 
> There is a subsection 3.6 talking about socket API, you might want to
> merge your text into that section? 

You're right.

For the text you provided, I
> suggest we describe in a way that is more problem oriented. IMO, the
> problem is two fold, (a) we do not have advanced API to support some
> MIF features and (b) different implementations deliver different
> higher level API, so there is a harmonization problem between them.
> 

That makes sense, thanks.

> I provided the text as follows:
> 
> "First, TCP/IP stack currently does not provide advanced API to
> specify the source IP address or to set preferences on the address
> selection policies for both IPv4 and IPv6 address family. Secondly,
> differently operation system implementations delivery different set of
> high level API, some exported with connection managers to address
> connection issues to multiple provisioning domains. These mechanisms
> do not necessarily behave the same way in the presence of the MIF
> problems [draft-ietf-mif-current-practices]. This results in the
> inconsistence problem and makes application developers confused when
> they want to develop application across different platforms"
> 
> -Z
> 
> On Tue, Nov 10, 2009 at 12:25 AM,  <pierrick.seite at orange-ftgroup.com>
> wrote:
> >
> > Hi,
> >
> > I couldn't attend the meeting, so I don't know exactly what it has been
> said. However, I agree the ps should address API/Connection manager.
> Actually, I think this feature is worth a dedicated section. So, based on
> Marc's proposal, I'd propose the following text, please feel free to
> comment/modify:
> >
> > x. Connection management
> >
> > Some implementations, specially in the mobile world, have higher-level
> > API, and/or connection managers, to address IP configuration issues in a
> context of multiple provisioning domains. Depending on the implementation,
> and/or OS, these mechanisms do not necessarily behave the same way in the
> presence of the MIF problems [draft-ietf-mif-current-practices].
> Therefore, at least, standardization of such an API should be considered
> in order to facilitate implementation of mechanisms addressing MIF issues.
> In the same way, harmonized behaviour of connection manager across
> different implementations and/or OS would bring more consistency for MIF
> users; in such a case, standardization of a framework for connection
> manager, would be valuable.
> >
> > Then in section 5, I'd reword a little bit the Marc's text:
> >
> > * When available, implementation of multiple interfaces API and/or
> connection managers do not necessarily behave the same way in the presence
> of the MIF problems. API and/or framework for connection managers should
> be standardized for the sake of harmonization in addressing MIF issues.
> >
> > Feel free to comment.
> >
> > Regards,
> > Pierrick
> >
> >> -----Message d'origine-----
> >> De : mif-bounces at ietf.org [mailto:mif-bounces at ietf.org] De la part de
> Marc
> >> Blanchet
> >> Envoyé : lundi 9 novembre 2009 07:56
> >> À : mif at ietf.org
> >> Objet : [mif] problem-statement: api
> >>
> >> Hi,
> >>   following the two comments on the mic about adding some text in the
> PS
> >> about API/Connection manager, here is first text proposal that would be
> >> added to section 5.
> >>
> >> "Some implementations, specially in the mobile world, have higher-level
> >> API and/or connection managers. These mechanisms are not standardized
> >> and do not necessarily behave the same way in the presence of the MIF
> >> problems. Therefore, a standard API could be considered."
> >>
> >> Please put more meat around the bone...
> >>
> >> Regards, Marc.
> >> _______________________________________________
> >> mif mailing list
> >> mif at ietf.org
> >> https://www.ietf.org/mailman/listinfo/mif
> > _______________________________________________
> > mif mailing list
> > mif at ietf.org
> > https://www.ietf.org/mailman/listinfo/mif
> >

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.