Re: [mif] Server selection document is "band-aid" not solution

Brian,

I was thinking about class of applications that might be configured (by user or by administrator or e.g. by ISP using over-the-air provisioning technologies, etc) to work only with specific contexts. The API could make it easier to implement those apps.

But I agree with your email about bigger problem and difficulties on finding generic solution for that.

Best regards,

        Teemu

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: 17. marraskuuta 2011 11:05
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: ogud@ogud.com; mif@ietf.org
> Subject: Re: [mif] Server selection document is "band-aid" not solution
>
> Teemu,
>
> I don't see how we could define a helpful API until the generic problem of
> scope is solved (see my previous message). We have no general way for an
> application to know or describe the scope that applies to itself and the
> peer(s) it wants to talk to.
>
> Regards
>    Brian
>
> On 2011-11-17 15:47, teemu.savolainen@nokia.com wrote:
> > Hi,
> >
> > Thank you for your comment, but I don't really see what you are proposing.
> >
> > The current state document shows how some OSes provide means for
> applications to specify "context" (e.g. by apps explicitly specifying what
> network interface they want to use, which impacts to all stack behavior: DNS,
> address selection, routing). The system where *all* applications must
> specifically tell to OS what network interface to use is considered not to be
> very nice for most application developers..
> >
> > The DNS server selection document indeed assumes applications do not
> provide preference on what "context" they want to use - because generally
> applications just don't know that information, and we want to avoid
> bothering users with network selection UI dialogs.
> >
> > Perhaps the MIF API document could cover your concern? I.e. introduce an
> API for applications to specify "context" in a manner that it affects also DNS
> resolution procedure (or maybe it is there, I need to read it:) This explicit API
> could/would then override the DNS server selection information received
> from the network - for the application that knows better.
> >
> > Best regards,
> >
> >     Teemu
> >
> >> -----Original Message-----
> >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> >> ext Olafur Gudmundsson
> >> Sent: 17. marraskuuta 2011 10:12
> >> To: mif@ietf.org
> >> Subject: [mif] Server selection document is "band-aid" not solution
> >>
> >>
> >> I sorry for the late comment but it has taken me a while to be able
> >> to put my finger on what I feel is wrong with the document (and the
> >> discussion in the working group)
> >>
> >> If a node has multiple interfaces and the interfaces have different
> >> resolution contexts then the basic question is "How can the services
> >> on the node tell what resolution context an application wants to use ?"
> >>
> >> Right now the "server-selection" document The fundamental problem we
> >> have is that OS's have a built in assumptions that
> >> a) there is only one resolution context i.e. only single
> >> /etc/resolv.conf
> >>
> >> b) There is no way to label a process that it wants to be a part of
> >> certain resolution context or tell the resolution which context to use.
> >>
> >> c) Results of resolution do not indicate which context was used.
> >>
> >> _______________________________________________
> >> mif mailing list
> >> mif@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mif
> > _______________________________________________
> > mif mailing list
> > mif@ietf.org
> > https://www.ietf.org/mailman/listinfo/mif
> >