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

From: Dmitry Anipko <[email-masked]>
Date: Sun, 14 Jul 2013 04:24:16 +0000

Hi everyone.

I've just posted the first version of the MPD arch draft based on the teleconfs and list discussions we've had so far. If possible, please take a look before the Monday call and comment.

For some of the topics, which we touched but where I didn't feel like I had enough information, for now I created placeholder sections with little / no text.

Thank you,
Dmitry

________________________________________
From: [email-masked] <[email-masked]>
Sent: Saturday, July 13, 2013 9:19 PM
To: Dmitry Anipko
Subject: New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

A new version of I-D, draft-anipko-mif-mpvd-arch-00.txt
has been successfully submitted by Dmitry Anipko and posted to the
IETF repository.

Filename:        draft-anipko-mif-mpvd-arch
Revision:        00
Title:           Multiple Provisioning Domain Architecture
Creation date:   2013-07-13
Group:           Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-anipko-mif-mpvd-arch-00.txt
Status:          http://datatracker.ietf.org/doc/draft-anipko-mif-mpvd-arch
Htmlized:        http://tools.ietf.org/html/draft-anipko-mif-mpvd-arch-00

Abstract:
   This document is a product of the work of MIF architecture design
   team.  It outlines a solution framework for some of the issues,
   experienced by nodes that can be attached to multiple networks.  The
   framework defines the notion of a Provisioning Domain (PVD) - a
   consistent set of network configuration information, and PVD-aware
   nodes - nodes which learn PVDs from the attached network(s) and/or
   other sources and manage and use multiple PVDs for connectivity
   separately and consistently.

The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Jul 2013 15:46:26 +0000

> I've just posted the first version of the MPD arch draft based on the teleconfs and list discussions we've had so far. If possible, please take a look before the Monday call and comment.

Thanks for doing this, Dmitry.   Margaret and Deng Hui, I don't think a meeting invite has been sent yet...

---

From: Hui Deng <[email-masked]>
Date: Mon, 15 Jul 2013 01:09:10 +0800

Ted, 
 
Meeting invitation is keeping change, and has been updated 15th, and you have accepted it for 15th meeting already?
can you kindly help to check it again?
 
thanks and Best regards,
 
-Hui
 
> From: [email-masked]
> To: [email-masked]
> Date: Sun, 14 Jul 2013 15:46:26 +0000
> CC: [email-masked]
> Subject: Re: [mif-arch-dt] New Version Notification	for	draft-anipko-mif-mpvd-arch-00.txt
> 
> _______________________________________________
> mif-arch-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif-arch-dt

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Jul 2013 17:33:24 +0000

> can you kindly help to check it again?

Oops, you're right—thanks.   I was looking at the wrong week.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Jul 2013 18:11:58 +0000

Observations about the document:

In section 2, I think you should say "classically" rather than "usually," because I think "usually" is true right now, but probably won't be in the future.   There's probably a better way to put it, but that's the point I think needs to be gotten across.

I think also that the beginning of section 2 doesn't quite capture the definition of PVD because of the classical approach.   It might be better not to focus on that, and just talk about it in terms of a collection of information.

So maybe something like this:

   Provisioning Domain: a consistent set of network configuration
   information.  Classically, the entire set available on a single interface
   is provided by a single source, such as network administrator, and
   can therefore be treated as a single provisioning domain.   In modern
   IPv6 networks, multihoming can result in more than one provisioning
   domain being present on a single link.

   Typical examples of information in a provisioning domain, learned
   from the network, are:
   source address prefixes used on the link, IP address of DNS
   server, name of HTTP proxy server if available, DNS suffixes
   associated with the network etc.

   In some cases, other sources, such as e.g.  node local
   policy, user input or other out of band mechanisms may be used to either
   construct a PVD entirely (analogously to static IP configuration of
   an interface), or supplement with particular elements all or some
   PVDs learned from the network.

   As an example, node administrator
   could inject a not ISP-specific DNS server into PVDs for any of the
   networks the node could become attached to.  Such creation /
   augmentation of PVD could be static or dynamic.  The particular
   implementation mechanisms are outside of the scope of this document.

   PVD-aware node: a node that supports association of network
   configuration information into PVDs, and using the resultant PVDs to
   serve requests for network connections in a way, consistent with
   recommendations of this architecture.

In 4.2.1, I suggest the following change:
OLD:
   In either case, by default the node shall use for the following
   connection request the PVD, where the lookup results were obtained.
NEW:
   In either case, by default the node uses information obtained in
   a name service lookup to establish connections only within the
   same PVD from which the lookup results were obtained.

   For simplicity, when we say that name service lookup results were
   obtained from a PVD, what we mean is that the name service query
   was issued against a name service the configuration of which is
   present in a particular PVD.   In that sense, the results are
   "from" that particular PVD.

In 5.1, maybe the following change?
OLD:
   Applications are not PVD-aware in any manner, and only submit
   connection requests.  The node performs PVD selection implicitly,
   without any otherwise applications participation, and based purely on
   policies and/or user choice.
NEW:
   Applications are not PVD-aware in any manner, and only submit
   connection requests.  The node performs PVD selection implicitly,
   without any otherwise applications participation, and based purely on
   node-specific administrative policies and/or choices made by the user
   in a user interface
   provided by the operating environment, not by the application.

I'd like to see more text talking about the user interface aspect of this.   Section 5.3 suggests that the information configured by local policy or user interface is not visible to the application.   This is probably correct, but needs to be explored in more detail, IMHO.

I would suggest the following for the trust section, since there's no text yet:

6.1 Untrusted PVDs

   Implicit and explicit PVDs for which no trust relationship exists
   are considered untrusted.   Only PVDs which meet the requirements in
   section 6.2 are trusted; any other PVD is untrusted.

   In order to avoid various forms of misinformation that can be asserted
   when PVDs are trusted, hosts that implement PVD separation cannot assume
   that two explicit PVDs with the same identifier are actually the same PVD.
   A node that did make this assumption would be vulnerable to attacks where
   for example an open Wifi hotspot might assert that it was part of a well
   known PVD, and thereby draw traffic intended for that PVD onto its own
   link.

   Since implicit PVD identifiers are synthesized by the node, this issue
   cannot arise with implicit PVDs.

   Mechanisms exist (for example [RFC6731]) whereby a PVD can
   provide configuration information that asserts special knowledge about
   the reachability of resources through that PVD.   Such assertions
   cannot be validated unless the node has a trust relationship with
   the PVD; assertions of this type therefore must be ignored by
   hosts that receive them from untrusted PVDs.   Failure to ignore
   such assertions could result in traffic being diverted from legitimate
   destinations to spoofed destinations.

6.2 Trusted PVDs

   Trusted PVDs are PVDs for which two conditions apply.   First, a trust
   relationship must exist between the node that is using the PVD configuration
   and the operator that provided that configuration; this is the authorization
   portion of the trust relationship.   Second, there must
   be some way to validate the trust relationship.   This is the authentication
   portion of the trust relationship.   Two mechanisms for
   validating the trust relationship are defined.

6.2.1 Authenticated PVDs

   One way to validate the trust relationship between a node and the
   operator of a PVD is through the combination of cryptographic
   authentication and an identifier configured on the node.   In some
   cases, the two could be the same; for example, if authentication is
   done with a shared secret, the secret would have to be associated
   with the PVD identifier.   Without a (PVD Identifier, shared key)
   tuple, authentication would be impossible, and hence authentication
   and authorization are combined.

   However, if authentication is done using
   some public key mechanism such as a TLS cert or DANE, authentication
   by itself isn't enough, since theoretically any PVD could be
   authenticated in this way.   In addition to authentication, the node
   would need to be configured to trust the identifier being authenticated.
   Validating the authenticated PVD name against a list of PVD names
   configured as trusted on the host would constitute the authorization
   step in this case.

6.2.2 PVDs trusted by attachment

   In some cases a trust relationship may be validated by some means
   other than described in 6.2.1, simply by virtue of the connection
   through which the PVD was obtained.   For instance, a handset connected
   to a mobile network will know through the mobile network infrastructure
   that it is connected to a trusted PVD, and whatever mechanism was used
   to validate that connection constitutes the authentication portion of
   the trust relationship.   Presumably such a handset would be configured
   from the factory, or else through user preference settings, to trust
   the PVD, and this would constitute the authorization portion of this
   type of trust relationship.

That's all I've got for today—I hope it helps.   Thanks for writing this up!

---

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Jul 2013 18:08:45 +0300

Hello,

Can we perceive this as some kind of a "virtualization" at the IP layer?

In order to handle "(3) is a use of employer-sponsored VPN connection for peer-to-peer connections, unrelated to employment activities.", PVD ID needs to be to exposed all the way to the application, and the application needs to explicitly request/bind to it. So, in a way, that virtualization needs to propagate all the way up to the apps. 

Alper

---

From: "Dapeng Liu" <[email-masked]>
Date: Thu, 18 Jul 2013 11:51:11 +0800

Hi Dmitry,

Thanks for posting the draft. I have a comment regarding how the PVD
identification works. As states in the draft, a PVD may have a PVD
identification with it, it may be a human readable identification. 
The question is: for each of the configuration elements, for example: DNS,
proxy, DHCP server etc there should be a PVD identification associates with
it or there is only one global identification for a PVD?

Thanks,
Dapeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dmitry Anipko
Sent: Sunday, July 14, 2013 12:24 PM
To: [email-masked]
Subject: [mif-arch-dt] FW: New Version Notification for
draft-anipko-mif-mpvd-arch-00.txt

Hi everyone.

I've just posted the first version of the MPD arch draft based on the
teleconfs and list discussions we've had so far. If possible, please take a
look before the Monday call and comment.

For some of the topics, which we touched but where I didn't feel like I had
enough information, for now I created placeholder sections with little / no
text.

Thank you,
Dmitry

A new version of I-D, draft-anipko-mif-mpvd-arch-00.txt has been
successfully submitted by Dmitry Anipko and posted to the IETF repository.

URL:
http://www.ietf.org/internet-drafts/draft-anipko-mif-mpvd-arch-00.txt

Abstract:

The IETF Secretariat

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 19 Jul 2013 23:36:47 +0000

Hi Dapeng,

Thank you for reading the draft.

>> The question is: for each of the configuration elements, for example: DNS, proxy, DHCP server etc there should be a PVD identification associates with it or there is only one global identification for a PVD?

My reading of the pre-draft discussions and my thinking was that there is a identification for PVD as a whole (I think what  you mean as the latter in your sentence). Is there some scenario which, you think, requires identifier for individual elements?

Thank you.

-----Original Message-----
From: Dapeng Liu [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 8:51 PM
To: Dmitry Anipko; [email-masked]
Subject: RE: [mif-arch-dt] FW: New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Hi Dmitry,

Thanks for posting the draft. I have a comment regarding how the PVD identification works. As states in the draft, a PVD may have a PVD identification with it, it may be a human readable identification. 
The question is: for each of the configuration elements, for example: DNS, proxy, DHCP server etc there should be a PVD identification associates with it or there is only one global identification for a PVD?

Thanks,
Dapeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dmitry Anipko
Sent: Sunday, July 14, 2013 12:24 PM
To: [email-masked]
Subject: [mif-arch-dt] FW: New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Hi everyone.

Thank you,
Dmitry

A new version of I-D, draft-anipko-mif-mpvd-arch-00.txt has been successfully submitted by Dmitry Anipko and posted to the IETF repository.

Abstract:

The IETF Secretariat

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 20 Jul 2013 00:59:19 +0000

Hi Alper,

I think there are two parts to your question, as I understood it:

1.       Whether MPVD problem can be solved [possibly, you meant in the particular VPN scenario], by using the IP interface for grouping of configuration, instead of PVD.

2.       How could OS + app implement tying the connection to the specific set of parameters, and possible impact on APIs / application code.

Please let me know if I interpreted either or both questions incorrectly.

For the first question, RFC 6419 discusses that not all implementations keep interfaces in isolation from other interfaces. If the implementations consistently did that for configuration across layers (e.g. including DNS, HTTP etc), then I'd agree that a subset of MPVD problem, where 1 interface = 1 PVD would be solved. However even in that case, as RFC 6418 section 4.5 describes, there are cases where 1 interface may be attached to multiple PVD, and those (as well as the scenarios where PVD spans across interfaces) would not be solved by per-interface grouping.

For the second question, I don't think the question is specific to whether the grouping of configuration elements is done per interface or per PVD. In either case, something needs to ensure that the correct set of parameters, be it for a particular interface or for a particular PVD, is used for a particular connection and/or application. As I started outlining in the draft, section 5, there are different not exclusive (i.e. host could support all of them) approaches for how the API could look like. E.g. the "Basic" approach would imply that OS does all the work based on e.g. policies + on app identity, destination name / IP address etc. In "Intermediate" approach, the app could provide some PVD-aware input. I think the approach you described, falls into "Advanced" category, where the app does most of the work by itself.

If I've misunderstood what you meant with "virtualization", please clarify.

Thank you,
Dmitry

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Wednesday, July 17, 2013 8:09 AM
To: Dmitry Anipko
Cc: [email-masked]
Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Hello,

Alper

Hi everyone.

Thank you,
Dmitry

________________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, July 13, 2013 9:19 PM
To: Dmitry Anipko
Subject: New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
mif-arch-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mif-arch-dt

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 20 Jul 2013 01:49:04 +0000

Hi Ted,

Thanks for the review and feedback.

>> In section 2, I think you should say "classically" rather than "usually," because I think "usually" is true right now, but probably won't be in the future.   

OK.

>> It might be better not to focus on that, and just talk about it in terms of a collection of information.

Ok, I will update along these lines with slight modifications.

>> In 4.2.1, I suggest the following change:

OK.

>> In 5.1, maybe the following change?

OK, with an exception, that details about user interface would not be added. I'm concerned it can start a long and unconverging discussion (e.g. in-app interface vs outside of app interface - even in app interface could be provided by the OS without app knowledge), which I don't think will actually move the MPVD discussion forward.

>> I'd like to see more text talking about the user interface aspect of this

See my comment above.

>> Section 5.3 suggests that the information configured by local policy or user interface is not visible to the application.   

Actually, that's not quite what I meant. What I meant to say is that the parameters, provided by application to affect PVD selection / enumeration, are only respected to the extent which node policies and user choice allows. E.g. node policy may prohibit certain PVD from being used and/or enumerated, and then that will be the behavior, no matter what app has to say.

Whether or not those policies/user preferences by themselves are exposed to the app, is a different question to me, and 5.3 currently doesn't say anything about that - I will clarify the text.

>>6.1 Untrusted PVDs

OK, with one question. In " In order to avoid various forms of misinformation that can be asserted    when PVDs are trusted, hosts that implement PVD separation cannot assume   that two explicit PVDs with the same identifier are actually the same PVD." . Did you mean "when PVDs are NOT trusted"?

I will include the text on trust into the draft as a starting point, but I fully expect that there are better security experts than myself on the team / MIF group, and I encourage review and feedback on the proposed trust schema.

Thanks a lot for taking time to come up with suggestions, this is very helpful.

I will rev the draft in the next few days (hopefully before the teleconf).

Thank you,
Dmitry 

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, July 15, 2013 11:12 AM
To: Dmitry Anipko
Cc: [email-masked]
Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

6.1 Untrusted PVDs

6.2 Trusted PVDs

6.2.1 Authenticated PVDs

That's all I've got for today-I hope it helps.   Thanks for writing this up!

---

From: "Dapeng Liu" <[email-masked]>
Date: Sat, 20 Jul 2013 16:05:58 +0800

Hi Dmitry,

If there is an idendification for PVD as a whole, then how to identify one
particular configuration element(for example, one DHCP server) belongs to
that PVD?

Thanks,

Regards,
Dapeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dmitry Anipko
Sent: Saturday, July 20, 2013 7:37 AM
To: Dapeng Liu; [email-masked]
Subject: Re: [mif-arch-dt] FW: New Version Notification for
draft-anipko-mif-mpvd-arch-00.txt

Hi Dapeng,

>> The question is: for each of the configuration elements, for example:
DNS, proxy, DHCP server etc there should be a PVD identification associates
with it or there is only one global identification for a PVD?

My reading of the pre-draft discussions and my thinking was that there is a
identification for PVD as a whole (I think what  you mean as the latter in
your sentence). Is there some scenario which, you think, requires identifier
for individual elements?

Thank you.

-----Original Message-----
From: Dapeng Liu [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 8:51 PM
To: Dmitry Anipko; [email-masked]
Subject: RE: [mif-arch-dt] FW: New Version Notification for

Hi Dmitry,

Thanks,
Dapeng
-----Original Message-----

Hi everyone.

Thank you,
Dmitry

Abstract:

The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Jul 2013 17:52:07 +0000

> particular configuration element(for example, one DHCP server) belongs to

It's entirely possible for a single DHCP server to represent _more than one_ PVD.   That said, the question of what protocol drafts to write is something that we expect to _follow_ the architecture document, so we can't really answer those questions _in_ the architecture document. :)

---

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Jul 2013 10:57:02 +0300

Hi Dmitry,

> 1.       Whether MPVD problem can be solved [possibly, you meant in the particular VPN scenario], by using the IP interface for grouping of configuration, instead of PVD.

Actually, I didn't mean or suggest that.

I was just trying to give what we are doing a name. It appears like some sort of "virtualization" to me.

Let me explain:

Long time ago, there was just one IP network. When a host attached to the network, it was on the IP network.
It didn't matter which interface or what parameters were used, the apps would get the same reachability/connectivity service.

But later, with the invention of VPN, captive portal, etc., the question of which "IP network" became important. 
That's why I see this as virtualization: We need to decide whether an app shall use the IP network that is served by a VPN to the enterprise, or the IP network gated by a captive portal. 
They may all be going over the same physical interface (that used to equate to the "IP network"), but virtually separated. 

> For the first question, RFC 6419 discusses that not all implementations keep interfaces in isolation from other interfaces. If the implementations consistently did that for configuration across layers (e.g. including DNS, HTTP etc), then I‘d agree that a subset of MPVD problem, where 1 interface = 1 PVD would be solved. However even in that case, as RFC 6418 section 4.5 describes, there are cases where 1 interface may be attached to multiple PVD, and those (as well as the scenarios where PVD spans across interfaces) would not be solved by per-interface grouping.
>  
> For the second question, I don’t think the question is specific to whether the grouping of configuration elements is done per interface or per PVD. In either case, something needs to ensure that the correct set of parameters, be it for a particular interface or for a particular PVD, is used for a particular connection and/or application. As I started outlining in the draft, section 5, there are different not exclusive (i.e. host could support all of them) approaches for how the API could look like. E.g. the “Basic” approach would imply that OS does all the work based on e.g. policies + on app identity, destination name / IP address etc. In “Intermediate” approach, the app could provide some PVD-aware input. I think the approach you described, falls into “Advanced” category, where the app does most of the work by itself.

My point is, in order to handle that VPN example, we need to be using advanced category. 

Alper

>  
> If I’ve misunderstood what you meant with “virtualization”, please clarify.
>  
> Thank you,
> Dmitry
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Jul 2013 13:57:02 +0100

Hi,

Some quick comments, as I won't now be able to make the call today.

Overall, the draft is taking shape nicely.

Section 1

If we talk of common scenarios, should we list them? Should we pick a couple that can be drilled into as examples later in the document, or in an Appendix? We had some discussion on this previously in the calls, but did we agree, what if anything, should go in this text?

Section 2.1 

This explains how the PVD architecture can be incrementally deployed, with incremental benefit, which is a nice property - perhaps the title of that section can be tweaked, or the topic of implicit vs explicit PVD discovery separated?

Towards the end of section 2.1 it would be great to have heuristics to do better than putting all implicit PVD information into one bucket, e.g. where a host is multihomed, where in such a case the host would have some idea of this due to multiple global prefixes.

Section 2.3

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.

Section 2.4

The single PVD for dual-stack networks seems very sane. It is common today for a dual-stack host to get an IPv6 address and router via IPv6 RA, and other configuration information via IPv4 DHCP.

Section 4.2

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?).

Section 4.2.1

A host may pick multiple PVDs intentionally to use MPTCP; it may explicitly want to ensure it is using different channels per path.

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…).

Section 5.1

Perhaps in addition to connection requests by applications the applications will first do DNS lookups, which is where the PVD selection is first used?

Section 6

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.

And a final question for now - are we including application configuration in this work, or is it purely network services?

Tim

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 27 Jul 2013 02:05:14 +0000

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.

>> If we talk of common scenarios, should we list them? Should we pick a couple that can be drilled into as examples later in the document, or in an Appendix? We had some discussion on this previousl…

[d.a.] People felt we should not duplicate the scenarios between the problem statement document and architecture. A text referring to detail scenarios in the problem statement will be added.

>> This explains how the PVD architecture can be incrementally deployed, with incremental benefit, which is a nice property - perhaps the title of that section can be tweaked, or the topic of implici…

[d.a.] Ok, will try to do that.

>> Towards the end of section 2.1 it would be great to have heuristics to do better than putting all implicit PVD information into one bucket, e.g. where a host is multihomed, where in such a case th…

[d.a.] There seemed to be agreement that it's not the main goal of the architecture to magically improve without explicit PVDs how such multi-homing on single link works; and that there may be no clear way how to do that, actually. That said, Suresh said that he will suggest some text on this, and this issue may be a good topic to discuss in the MIF meeting.

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

>> The single PVD for dual-stack networks seems very sane. It is common today for a dual-stack host to get an IPv6 address and router via IPv6 RA, and other configuration information via IPv4 DHCP.

[d.a.] OK, I can add that as additional rationale.

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

[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.

>> A host may pick multiple PVDs intentionally to use MPTCP; it may explicitly want to ensure it is using different channels per path.

[d.a.] Good point, folks agreed to add text that for some transports and depending on PVD information, node may decide to use connections over multiple paths / PVDs (however for each connection, the operations still need to be done consistently within the particular PVD).

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

>> Perhaps in addition to connection requests by applications the applications will first do DNS lookups, which is where the PVD selection is first used?

[d.a.] Sure, I will add specific text about name lookup, as a possible step where selection is done (it may be not necessarily the first step, however - because e.g. PVD selection could be done based on app identity).

>> 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 tha…

[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.

-Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Monday, July 22, 2013 5:57 AM
To: [email-masked]
Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Hi,

Section 1

Section 2.1 

Section 2.3

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.

Section 2.4

Section 4.2

Section 4.2.1

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...).

Section 5.1

Section 6

Tim

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 31 Jul 2013 05:59:16 +0000

Per Hui's suggestion, please find a draft of slides for the pre-meeting discussion.

Thank you.