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

From: Dmitry Anipko <[email-masked]>
Date: Tue, 7 Jan 2014 03:04:03 +0000

Reviving the discussion after holidays, since it doesn't seem it converged on something.

>> We seem to commonly refer to a user selecting an SSID and a PVD-ID following implicitly from that; so the PVD-ID is implicitly acquired, and the user may never need to see it.

In some cases this is possible, and the arch draft describes this as a possibility, but it's not the only possibility, and also, in some cases such selection is not possible - if there is more than one PVD on the link (2 ISPs at home).

>> 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,

To me it doesn't seem that explicit choice by end user is precluded, though I agree that it probably would not be common. That said, even when the end user can't or doesn't want to choose, there may still be a need to show to the user "descriptive information" about the PVD, which e.g. is currently used to access the Internet. 

>> Perhaps we need something in the draft to discuss the possible 'consumers' of PVDs?

Do you mean to the arch draft? If yes, if you send any rough thoughts on that, I'm happy to include in the next revision if that helps us move forward in making the scenario descriptions more specific and hence the requirements for IDs more specific.

-----Original Message-----
From: Tim Chown [mailto:[email-masked]] 
Sent: Sunday, November 24, 2013 6:11 AM
To: Ted Lemon
Cc: Marc Blanchet; Jouni Korhonen; Dmitry Anipko; [email-masked]; Suresh Krishnan
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

On 22 Nov 2013, at 21:17, Ted Lemon <[email-masked]> wrote:

> On Nov 22, 2013, at 3:38 PM, Marc Blanchet <[email-masked]> 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