Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 24 November 2013 14:12 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ED51AE296 for <mif-arch-dt@ietfa.amsl.com>; Sun, 24 Nov 2013 06:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.746
X-Spam-Level:
X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AcUti3dRfJO for <mif-arch-dt@ietfa.amsl.com>; Sun, 24 Nov 2013 06:12:57 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3320C1ADF68 for <mif-arch-dt@ietf.org>; Sun, 24 Nov 2013 06:12:56 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAOECiaN017396; Sun, 24 Nov 2013 14:12:44 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rAOECiaN017396
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1385302364; bh=M0BIzm0LZDYEPNwwn9WjEfENjeg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=kgO/5OJgsOBoPfWy6Xle1c2rRFgbp0MbUuhJ7JqYBgRPHqmraXBGYs6Q8gY2Womph GqnSNNElBVcAfBMrTB9zBBV0zWC45EibdyiSZtg95no+0UnxiZ5Fzz7jbjHdv/bk4E TbeVDW4dwDDyKvvBvA5zcHWfw11x9jguZXIfjnYM=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id pANECh0959633875pv ret-id none; Sun, 24 Nov 2013 14:12:44 +0000
Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAOEBOWT019986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Nov 2013 14:11:25 GMT
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <1CC2DB29-E87A-4F86-BED7-8A1750B22720@nominum.com>
Date: Sun, 24 Nov 2013 14:11:24 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|7933263be2055c213c80f3b19e4c16f0pANECh03tjc|ecs.soton.ac.uk|19CBC9C7-1609-44D0-AA39-EC4EF0348B6B@ecs.soton.ac.uk>
References: <5267F29C.3010304@ericsson.com> <0010ca0ba1f44fe2a1b8fa5f110a00c0@SN2PR03MB077.namprd03.prod.outlook.com>, <41845B5F-8694-4368-B2F6-BA3BA0CFDD91@gmail.com> <ee10ff9826854918aebf0565c93ce5a9@SN2PR03MB077.namprd03.prod.outlook.com> <E07F8EDD-6BA5-4B7D-B307-C819B6AC2053@gmail.com> <6AC3097B-C63D-4DC6-80BE-29FEFE355D40@nominum.com> <E30067C3-A44D-478A-9D78-CA2D078A8A76@viagenie.ca> <1CC2DB29-E87A-4F86-BED7-8A1750B22720@nominum.com> <19CBC9C7-1609-44D0-AA39-EC4EF0348B6B@ecs.soton.ac.uk>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1816)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=pANECh095963387500; tid=pANECh0959633875pv; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: rAOECiaN017396
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, Jouni Korhonen <jouni.nospam@gmail.com>, "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt/>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2013 14:12:59 -0000

On 22 Nov 2013, at 21:17, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> On Nov 22, 2013, at 3:38 PM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
>> But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and
> 
> This is not that hard, and we shouldn't avoid it.   Of course names need to be human-readable. So encode them in UTF-8.   (I'm oversimplifying, because you still need a unique identifier, and that's likely _not_ the name.)

I think there’s many potential scenarios for PVD-IDs, and to what or whom they may or may not be exposed to or required by, be the 'consumer' users or applications.

We seem to commonly refer to a user selecting an SSID and a PVD-ID following implictly from that; so the PVD-ID is implictly acquired, and the user may never need to see it. The user device may however have multiple interfaces, e.g. WiFi and 3G. I believe that iOS7 runs MPTCP across both wired and wireless interfaces for Siri, which is an interesting example.

Another example is selecting and using a VPN; there is again an implicit PVD-ID associated with the connection when the user initiates the VPN (or the VPN auto connects). We said at IETF88 that certain applications should be configurable to run only if a certain VPN PVD is available.

In the case of a mutli-homed IPv6 site with multiple prefixes, from different providers, users on workstations with two IPv6 prefixes don’t currently make selections, rather they rely on address selection or some other policy to be applied.  In this PVD case, an application may again wish to only run if a certain PVD is available, e.g. one prefix is associated with a PVD for some IP TV service, the other prefix is used for general Internet.

The above behaviours don’t require users to select PVDs, except where they are already exposed today as SSIDs or VPNs, but applications seem more likely to be able to assert a certain PVD is in place?

Perhaps we need something in the draft to discuss the possible ‘consumers’ of PVDs?

Tim