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

["Tony Hain" <[e-mail]>]

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.




> -----Original Message-----
> From: Arifumi Matsumoto [mailto:[e-mail]]
> Sent: Thursday, July 08, 2010 6:45 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [addr-select-dt] 2nd teleconference
> 
> 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