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

[Arifumi Matsumoto <[e-mail]>]

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,

On 2010/07/07, at 17:13, Arifumi Matsumoto wrote:

> 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,
> 
> On 2010/07/07, at 0:44, Tony Hain wrote:
> 
>> I can only do 7 or 8, and I can set up a webex.
>> 
>> Tony
>> 
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:addr-select-dt-
>>> [e-mail]] On Behalf Of Arifumi Matsumoto
>>> Sent: Tuesday, July 06, 2010 2:18 AM
>>> To: [e-mail]
>>> Subject: Re: [addr-select-dt] 2nd teleconference
>>> 
>>> 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 ?
>>> 
>>> On 2010/07/05, at 22:10, Tim Chown wrote:
>>> 
>>>> 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:
>>>> 
>>>>> 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: [e-mail]
>>>>> 
>>>>> _______________________________________________
>>>>> addr-select-dt mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>> 
>>>> _______________________________________________
>>>> addr-select-dt mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>> 
>>> 
>>> --
>>> Arifumi Matsumoto
>>> Secure Communication Project
>>> NTT Information Sharing Platform Laboratories
>>> E-mail: [e-mail]
>>> 
>>> _______________________________________________
>>> addr-select-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>> 
> 
> 
> --
> Arifumi Matsumoto
>  Secure Communication Project
>  NTT Information Sharing Platform Laboratories
>  E-mail: [e-mail]
> 
> _______________________________________________
> addr-select-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/addr-select-dt