IETF Logo Mail Archive

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

<teemu.savolainen@nokia.com> Thu, 17 November 2011 02:47 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E88211E80C4 for <mif@ietfa.amsl.com>; Wed, 16 Nov 2011 18:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ts3EX59ie3R for <mif@ietfa.amsl.com>; Wed, 16 Nov 2011 18:47:54 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9658E11E80BC for <mif@ietf.org>; Wed, 16 Nov 2011 18:47:54 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAH2loHQ021520; Thu, 17 Nov 2011 04:47:53 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 04:47:46 +0200
Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 17 Nov 2011 03:47:46 +0100
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.114]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Thu, 17 Nov 2011 03:47:45 +0100
From: teemu.savolainen@nokia.com
To: ogud@ogud.com, mif@ietf.org
Thread-Topic: [mif] Server selection document is "band-aid" not solution
Thread-Index: AQHMpM8cTOsAnc2+q0G6xead7mSgZZWwWtgQ
Date: Thu, 17 Nov 2011 02:47:45 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>
References: <4EC46D52.8030909@ogud.com>
In-Reply-To: <4EC46D52.8030909@ogud.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvaJJ98g1xw6ajjuiF5UmoaKq8umyOZD9ad1l9N9r5NECFByLs3Bt4g/wwz9DRSIrWcYYm/Bxz8jzPZSzkZKbcL6NxnhI1RPliqW0jzeRbuL1oJrP8kVNbdFK55Mc64BpIeQuLJZlzWof4BIfLou3+V+5CFJ8VS+22nuHJ+0vFjp3f8Ktn85v83tq/aZf2WmtrrMr6VJ/V6Qak1iUgJ84h1XIJW/kr0d9poZJ6ObP/udljFrDe65ZjHLpeBXDaJfXQ==
x-originating-ip: [10.163.117.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Nov 2011 02:47:46.0890 (UTC) FILETIME=[49BA42A0:01CCA4D3]
X-Nokia-AV: Clean
Subject: Re: [mif] Server selection document is "band-aid" not solution
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2011 02:47:55 -0000

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

v2.23.0 | Report a Bug | By Email