Subject: [addr-select-dt] Status update in San Francisco

From: Brian Haberman <[email-masked]>
Date: Mon, 02 Mar 2009 09:53:56 -0500

DT,
     I have allocated a 15-minute slot in San Francisco for someone to 
give an update on the design team progress.  Let me know who will be 
doing the presentation.

Thanks,
Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 4 Mar 2009 17:03:37 +0000

> give an update on the design team progress.  Let me know who will be 

Brian,

I'm currently reviewing the list comments with a view to pushing out a new
draft update tomorrow.   I think there's been some good feedback.

I think the two main changes since last IETF are

a) a 'split' with the multi-interface problem and Marc's draft for that.
   This peeled us away from our original (I believe) view of a site
   network with multiple upstreams, to considering multi-interfaced
   hosts, including the case where one interface was a VPN connection.
   I think we agreed this was out of scope for the current draft.

b) venturing into solution space for the 'considerations' draft, and
   with that discussions about policy conflict etc.   I think we can draw
   some observations on that problem.

But I don't think we came to a firm conclusion on 'How Dynamic?', except 
that observing that administratively driven changes would be simpler to 
cover, at least in the first instance.   Tony also suggested adding 
nomadic systems within a site, which I think should be in scope.

What I'll try to do is capture the broad discussion points and - as I see
it - concensus to allow some focused discussion at the upcoming meeting.

As for the presentation, I could do it, unless someone else wishes to do so?

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Mar 2009 16:15:01 +0900

Hi,

>   I think we agreed this was out of scope for the current draft.

I'm not pretty sure about this split.
Does the split mean we have to wait for their (mif wg?) output ?
Or can we really work separately, i.e. can we make a decision about
how to solve the problems without mif's output getting ready ?

Though we and they look like sharing the same theme, depending on the
background problems, IMO the solution will not necessarily solve the
both sides of problems.

As far as I took a look at their drafts, I could not see any kind of
solution that meets our goal.

So, I suppose it is good for us to reach a conclusion about how to
solve the problems from our point of view.

Regards,

--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Mar 2009 09:13:31 +0000

> solution that meets our goal.

By 'split' I meant that it seems their focus seems to be on mobile nodes 
with multiple interfaces.  

Our focus seems to be settling more on the site/enterprise perspective,
but including nomadic nodes within a site where policy may be different
within parts of the site.

In both cases tools are needed to convey policy to nodes.  The question is
whether we focus on distributing *policy* to nodes or, as mif seems to be
doing (I need to read in more detail maybe!) offering routing and other
information to nodes via DHCPv6 to assist their decision.

> solve the problems from our point of view.

I agree.  I think we have some interesting initial proposals, e.g. using
an RA flag to indicate if policy is different to default, and of course
we have initial work on distributing policy by DHCPv6 (though as Tony has
shown we probably need to look more into the policy description/semantics).
In parallel it *may* be that some of the routing oriented proposals from
mif are applicable - that's something we need to discuss once we're agreed
on what our scope is (and how/if we complement the mif work).

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Mar 2009 19:29:31 +0900

Hi, Tim.

I found Brian was dropped from the CC list by me !
I don't know why. Sorry for that.

> within parts of the site.

The split sounds fine to me :)

> information to nodes via DHCPv6 to assist their decision.

Firstly, this dt is chartered to focus on a protocol to update RFC 3484
policy table. However, the underlying motivation for it is to solve the
problems we have and discussed, so I think we have to step back and
consider whole parts of the problems when we need to do so.

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Mar 2009 16:50:59 +0000

I have now uploaded the new -02 draft.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 10 Mar 2009 10:36:41 +0000

To confirm the new draft is available:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Considerations for IPv6 Address Selection Policy Changes
        Author(s)       : T. Chown
        Filename        : draft-chown-addr-select-considerations-02.txt
        Pages           : 17
        Date            : 2009-03-09

RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines
mechanisms for nodes to perform source and destination address
selection choices when faced with multiple addresses to choose
between when initiating a communication.  While RFC3484 recognised
the need for implementations to be able to change the policy table, a
requirement has now also emerged for administrators to be able to
dynamically change the policy tables from a central control point,   
and for nomadic hosts to be able to obtain the policy for the network
that they are currently attached to without manual user intervention.
This text discusses considerations for such policy changes, including
examples of cases where a change of policy is required, and the
likely frequency of such policy changes.  This text also includes
some discussion on the need to also update RFC3484, where default
policies are currently defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chown-addr-select-considerations-02.txt

-- 
Tim