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? 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. 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.