IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Thu, 17 November 2011 04:54 UTC

Return-Path: <Ted.Lemon@nominum.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 7918D11E80C7 for <mif@ietfa.amsl.com>; Wed, 16 Nov 2011 20:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.563
X-Spam-Level:
X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 65eDpBjxqk-L for <mif@ietfa.amsl.com>; Wed, 16 Nov 2011 20:54:21 -0800 (PST)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 605E011E80BA for <mif@ietf.org>; Wed, 16 Nov 2011 20:54:21 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTsSTfKBZFVLlfgKiDATIOknQHH4j5mV3@postini.com; Wed, 16 Nov 2011 20:54:21 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 511261B82E2 for <mif@ietf.org>; Wed, 16 Nov 2011 20:54:20 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4301A19005D; Wed, 16 Nov 2011 20:54:20 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 20:54:20 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [mif] Server selection document is "band-aid" not solution
Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5Ww4w+AgAAE1gD//5hqNA==
Date: Thu, 17 Nov 2011 04:54:18 +0000
Message-ID: <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com>
References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com>
In-Reply-To: <4EC479E0.6030704@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mif@ietf.org" <mif@ietf.org>
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 04:54:26 -0000

On Nov 17, 2011, at 11:05 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> 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.

It seems to me that applications "knowing" what scope they want to talk to is a very isolated special case.   E.g., perhaps your set-top box knows that it needs to go through your cable ISP's provisioning domain to get streaming video.   But generally speaking, your application wants to connect through whatever provisioning domain works best, which is something no provisioning domain can claim to know; it is something only the host can determine.

v2.23.0 | Report a Bug | By Email