Subject: Re: [addr-select-dt] 2nd teleconference

From: Suresh Krishnan <[email-masked]>
Date: Thu, 1 Jul 2010 06:18:31 -0400

Hi Arifumi,
  7/2 works well for me and I can make 7/5 if necessary. The other days do not work for me.

Thanks
Suresh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Arifumi 
> Matsumoto
> Sent: Wednesday, June 30, 2010 11:42 PM
> To: [email-masked]
> Subject: [addr-select-dt] 2nd teleconference
> 
> All,
> 
> I'd like to schedule the 2nd telecon.
> For the 2nd telecon, we should look into concrete items to be 
> included in our consideration document, and maybe in my 
> document about policy conflict.
> 
> And, I have some things that I want to share with you all.
> 
> As everybody is in different place, so why not have a telecon 
> at the same time as the previous one.
> 
> That is,
> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
> 
> 7/2,5,6,7 work for me.
> 
> Regards,
> 
> --
> Arifumi Matsumoto
>   Secure Communication Project
>   NTT Information Sharing Platform Laboratories
>   E-mail: [email-masked]
> 
> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 5 Jul 2010 14:10:58 +0100

Hi, 

Sorry for the late reply.   Now, only 7/7 would work for me.

Thursday or Friday this week are OK at the same time.

Tim

On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:

> For the 2nd telecon, we should look into concrete items
> to be included in our consideration document, and maybe
> in my document about policy conflict.
> 
> As everybody is in different place, so why not have a
> telecon at the same time as the previous one.
> 
> That is,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Jul 2010 18:17:32 +0900

All,

would you all please let us know 7/8 and 9 work or not.
Please e-mail by 7/7.

Tony, can you setup WebEx again ?

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 6 Jul 2010 08:44:07 -0700

I can only do 7 or 8, and I can set up a webex.

Tony

> From: [email-masked] [mailto:addr-select-dt-
> [email-masked]] On Behalf Of Arifumi Matsumoto
> Sent: Tuesday, July 06, 2010 2:18 AM
> Subject: Re: [addr-select-dt] 2nd teleconference
> 
> All,
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 7 Jul 2010 17:13:24 +0900

All,

let me fix the telecon for 7/8 at the same time as before.
>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.

Tony, would you please setup the webex ?

The cut-off for the revision draft is just ahead of us.

We should discuss about the actual text or something close to it
to make it for the cut-off.

I'll try to put together some candidate texts, so that we can 
just choose one from the candidates.

A brief agenda off the top of my head is,

- Design Team merger with draft-troan-multihoming-without-nat66.

- Applicability statement in our draft.

- Updates for conflict draft.

- Strategy for IETF78 presentation.

- [please add here]

Best wishes,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 8 Jul 2010 22:45:08 +0900

Hi,

some of my thoughts below.

* general rule for conflict and merge

  There is a design choice of
  1. the mechanism should allow the merge of two or more polcy sets even if there is a conflict between them.
  2. the mechanism should allow the merge if there is no conflict.
  3. the mechanism should not allow the merge of multiple policy sets.

 As studied in my conflict draft, it is not easy to merge two policy sets even if there is no conflict.
 So, IMO, we should separate every case of policy merge from the basic spec.
 It means also the merge of a received policy set and the default policy and the merge
 of any policy sets with manually configured policy set.

 That is, one policy set is treated as one atomic information just like a DNS server option.
 
 In that case, we should define/endorse the relation between auto-configured policy, 
 and manually configured policy and default policy.
 I think it should be configurable by user which to choose between auto-configured policy
 and manually configured policy. These policy sets should override the default policy.
 And, by default, a host should use auto-configured policy.
 These relation should be implementation dependent, though.

* applicability

  If we can agree on above, the applicability statement should be something like:
  
  This mechanism SHOULD be used only when the administrator of a site can make
  sure that the address selection information receiver will not receive the same kind
  of information from any other entity, or the receiver can accept and process the received
  multiple policy sets correctly, e.g. by using pre-configured information.

 Even if we define the applicability as above, the mechanism itself helps a lot of
 important problems, stated in RFC5220 and draft-troan-multihoming-without-nat66, etc.

* what happens if multiple policy sets are received

 Even if we decided as above, it would be helpful if we can define the behavior when
 a node received multiple policy sets, and it minimizes the bad effect from it.

 I think the best way for it is to use a policy set received on the most preferred interface.
 The most preferred means manual configuration, and OS dependent value.
 As studied in mif wg, a lot of implementation has metric value for each interface, and
 makes use of it to tie-break.

 I think we can follow the manner of them here to minimize the damage.

Regards,

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 8 Jul 2010 06:59:30 -0700

For some reason the webex announcement never would go to the list. 
Here is another try:::

Anthony Hain invites you to an online meeting using WebEx.

Meeting Number: 206 537 572
Meeting Password: addr-select

-------------------------------------------------------
To join this meeting (Now from iPhones and other Smartphones too!)
-------------------------------------------------------
1. Go to
https://ciscosales.webex.com/ciscosales/j.php?J=206537572&PW=NZjgyYmUwY2Rl
2. Enter the meeting password: addr-select
3. Click "Join Now".
4. Follow the instructions that appear on your screen.

> From: Arifumi Matsumoto [mailto:[email-masked]]
> Sent: Thursday, July 08, 2010 6:45 AM
> To: [email-masked]; [email-masked]
>   1. the mechanism should allow the merge of two or more polcy sets
> even if there is a conflict between them.

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Jul 2010 16:30:47 +0100

Tony, Arifumi and I attended the teleconference.

We discussed various topics, with the policy merging/conflict handling issue taking most of our time.   We agreed the principles of Arifumi's text below were good, though Tony thought it should be scoped to 'within the local network'.

Because of the complexity of this topic, and the need to publish the address selection considerations draft, we agreed to document the conflict/merging problem concisely in the draft and move work on solution(s) to a new text.   This would allow policy distribution in networks without policy conflict to be progressed.   Tim will refresh the dt draft before the IETF78 cutoff.
http://tools.ietf.org/id/draft-ietf-6man-addr-select-considerations-00.txt

The conflict/merge problem is hard.   Conflict implies choice, which a general user may not be able to make, and merging may produce a suboptimal or even unusable result.   The most common 'problem' scenario is probably the VPN one, where a user in a coffee shop or enterprise network wishes to use a VPN.   It was noted that VPN clients typically have a user choice in 'send all data via VPN' or 'send only home network data via VPN' tickbox.

It was felt that the dt could work with the authors of the multihome-without-nat66 draft to bolster contributions to the problem space.   While the Troan draft considers many of the issues the DT is concerned with it does not include policy conflict/merger. 
http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00

The question arose again if whether RFC3484 should be per node (as now) or per interface.

Arifumi agreed to refresh the 3484-bis draft before the cutoff, and Tony offered to send some comments over the weekend.    Ideally we would like to get 3484-bis to a publication-ready state as soon as possible.   Many vendors/implementors have already implemented many of the changes in the current 3484-bis draft.

Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 12 Jul 2010 19:55:42 +0900

Tim,
thank you for your memo.
Several thoughts below.

We are having good discussion here in this ML.
As far as time allows, I want our draft reflect this discussion.

And after the cut-off, I want to continue making progress and present better output to the 6man people in Maastricht.

> We discussed various topics, with the policy merging/conflict handling issue taking most of our time.   We agreed the principles of Arifumi's text below were good, though Tony thought it should be…

So, the Tony's suggestion was putting *local* like below.

>> of information from any other *local* entity, or the receiver can accept and process the received

I came to think that this applicability seems reasonable.

- First of all, the mechanism does not provide a standard way of merging, so the network SHOULD NOT distribute policy sets from multiple entities. This restriction seems to be acceptable for the network administrator.

- As in enterprise network, the network administrator can restrict users's network environment so that they do not do multi-home. But, as in access network and wifi spots, he cannot restrict what they do. Does this inhibit him from using this mechanism ? I do not think so. This matter is just the same as other DHCP options like DNS server address option. It is also the host-wide information, but it has not became an obvious problem, mainly due to implementation measures, such as interface prioritization as studied in mif wg.

> The conflict/merge problem is hard.   Conflict implies choice, which a general user may not be able to make, and merging may produce a suboptimal or even unusable result.   The most common 'problem…

We should not say "we do not do this, because this problem is difficult."
We should day "we do not do this, because there is no perfect or practical solution for doing this."

I think we can say the latter, because the destination address selection based on precedence value does essentially conflict with other precedence value coming from other policy source.

We understand there are some cases where they need policy merge. So, we should do further work on producing most practical way of policy merging. But, I suppose the output should be experimental or informational RFC, in that we really have to see the output is acceptable and operational in reality.

One more point about this separation.
If we do this separation, what do we have to have now ?

I think it is basically ultimately a receiver's choice whether it does policy merge or not.
Here, I'm wondering if there should be a way to guide a receiver whether it should merge or not. In this case, there should be a bit to show this preference of policy sender.
But, we may do not have to discuss this, we just need a bit of reserved field in the option.

> http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00

As confirmed in their ML, they are happy with non-merge-capable solution.

> The question arose again if whether RFC3484 should be per node (as now) or per interface.

As far as it is used for destination address selection, it has to be per host.

> Arifumi agreed to refresh the 3484-bis draft before the cutoff, and Tony offered to send some comments over the weekend.    Ideally we would like to get 3484-bis to a publication-ready state as soo…

I'll update it from now :)

If everyone agrees, I want that draft to be this DT's output.

Regards,

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Jul 2010 23:17:05 +0100

> And after the cut-off, I want to continue making progress and present better output to the 6man people in Maastricht.

Agreed.

> - First of all, the mechanism does not provide a standard way of merging, so the network SHOULD NOT distribute policy sets from multiple entities. This restriction seems to be acceptable for the ne…

In saying different entities, we're in effect saying different mechanisms.   If the solution for enterprises is DHCPv6-based policy distribution, this should be the case.

> - As in enterprise network, the network administrator can restrict users's network environment so that they do not do multi-home. But, as in access network and wifi spots, he cannot restrict what t…

Well, can an enterprise avoid a user running a VPN to their home network while visiting?   I don't think our visitors would be happy if we did that :)

> I think we can say the latter, because the destination address selection
> based on precedence value does essentially conflict with other precedence value coming from other policy source.

I agree - a much better way to phrase it.

> But, we may do not have to discuss this, we just need a bit of reserved field in the option.

Tony I think suggested some per-provider unique reference to identify/verify the source of the policy.   This might make it easier to provide the user with a choice they could understand.

> As confirmed in their ML, they are happy with non-merge-capable solution.

I suspect they have had similar discussions :)

> As far as it is used for destination address selection, it has to be per host.

Yes, though I understood the points Tony was raising.

> If everyone agrees, I want that draft to be this DT's output.

I have just seen it published, thank you.

Tim