Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

[Tim Chown <[e-mail]>]

On 27 Jul 2013, at 03:05, Dmitry Anipko <[e-mail]> wrote:

> Hi Tim,
> 
> Thank you for review and comments. They were discussed during the call on Monday, and I will try to summarize below my understanding of what was agreed on during the call. Please let me know whether you agree/disagree with the proposed changes/actions or if it appears the comment was not understood correctly.

Hi, comments in line. I agree with anything I've snipped.

>>> Are PVD IDs unique per PVD, per association between the client and PVD, per location, or...? e.g. if I am with a WiFi provider, will I always see the same PVD when I use that provider, anywhere? Would a friend on that provider see the same ID? Can any assumptions be made? As yet I don't think this is stated.
> 
> [d.a.] It seemed at least two question are raised here: 1) whether the PVD ID should be the same or different across networks, operated by the same provider. 2) whether everyone on the same link should see same set of PVDs, or on the same link different nodes might see different PVDs. 
> 
> On the call, there seemed to be agreement:
> 
> For 1), that both are possible and that the architecture shall not constraint either way. 
> For 2), that in the current scope of the document on a single link, all nodes should receive information about the same PVDs. That said, individual nodes may have different policy/trust settings, based on which they decide to use different subsets of the received PVDs. Future extensions, where different nodes on the same link may see different PVDs from the network, are suggested to be out of scope for the current version of the architecture.
> 
> The clarifications for both points will be added.

OK. Although presumably nodes learning of PVDs via DHCP as per 2.1 may be on the same link but be given different PVD information.  That might be how an ISP "colours" different devices in a home network differently, perhaps.

Do we think PVD IDs would be exposed to users, to be able to make choices as we might today with 3G vs WiFi? I suspect users in general have seen enough hotspots etc to "get" SSIDs, and selecting a provider by SSID, for example.

On a related note, can PVDs be chained, or would hierarchies require different, non-overlapping PVDs? An example might be an LLN gateway attaching to an ISP via a homenet.  Here the LLN gateway would be provisioned by the homenet router, and may be unaware of what ISP(s) or other domains may be upstream of that. Would the LLN be just one of the homenet or ISP PVDs? Or could there be nested "onion"-style PVD scopes? Maybe this is something for Section 3.

>>> So if there is an explicit vs implicit distinction for learning PVDs, perhaps a similar model should be applied here, explicit being e.g. a user toggle (explicit choice, rather like 3G vs WiFi, as hinted at in section 2.3), the implicit being e.g. connectivity tests (Happy PVDs?).
> 
> [d.a.] It didn't feel like there was a common understanding of how this comment could be actioned on. Please feel free to elaborate or suggest specific text which you'd want to see in the document in this regard.

The question is given a set of PVDs, how the client chooses which PVDs to use for which services. It could apply some policy (explicit, like using the VPN PVD for corporate use), perhaps with user toggles/choices involved (as we do know with 3G vs Wifi), or it could implicitly try to figure out the best PVD to use via connectivity tests (4.3). Of course, if a policy is used, there may be conflicting policy…

>>> There may be cases for split PVDs, e.g. a host with VPN running, uses the VPN to the corporate network and the default provision for all other traffic (cue security comments...).
> 
> [d.a.] Sure, this seems to be one of the PVD use cases for different connections, but it was not clear how the text should be adjusted. Do you think the current text doesn't cover that or contradicts to that? If that's the case, can you suggest the specific changes?

I think this is part of section 4. Under 4.1 it can be noted that a node may learn of one or more PVDs, but need not use a single PVD for all services.  At this stage, we probably don't need to say more than that.

>>> eduroam is an interesting example here. Users authenticate to their home site using their home credentials, but the visited site then makes a provisioning (and authorisation) decision based on that result.  The visited site is the PVD, but the authentication is to the home site.  The authentication to eduroam can be mutual between the device and the visited network.

I'll have a think about that one.  I think something under 6.2 would be appropriate.

> [d.a.] Can you suggest more specific text which you'd like to see included?
> 
>>> And a final question for now - are we including application configuration in this work, or is it purely network services?
> 
> [d.a.] There didn't seem to be agreement on the call on this, and this was also discussed on previous calls. It may be good topic to talk about in the MIF meeting.

OK, I saw that that was on the slides.

Tim