Re: [addr-select-dt] Update: draft-ietf-6man-addr-select-considerations-01

[Tim Chown <[e-mail]>]

On 12 Jul 2010, at 20:47, Arifumi Matsumoto wrote:

> Tim,
> 
> thank you for your generous efforts on this draft.
> Now this document is quite thorough. I really appreciate it.
> 
> When we finish this document, why not bring this and go out to 6man ML for discussion ?

Yes,we should do that.

> 4.5. Multiple Interface Nodes
>     ...
>   not.  In this case it is interesting to note the choice to use the
>   VPN tunnel for all, or just VPN home site traffic, is typically left
>   as a choice for the user via a tickbox selection.
> 
> From my experience, even the tick-box does not appear. If I install and launch VPN software, it changes several related settings as it wants. I think this is quite reasonable behavior of VPN software. The software interprets that it is given highest priority from the user by installing and launching the software.

Comment added.

> 6.3.  Manual Configuration?
> 
> I think this whole point is rather related to the solution section. 
> And especially in merging subsection. It is about policy merging or
> non-merging of default policy table or manually configured policy
> with the received policy.
> 
> 6.4.  Policy Conflicts
> 
> Again, this whole point also should be placed in solution space ?
> At least, it is not about when to obtain poicy.

Agree.   Both moved.

> 7.2.  Pull model
> ...
>   an administrator, is a more practical use of DHCPv6.  If future
>   methods offer additional 'hints' based on routing information, this
>   becomes part of the 'policy conflict' problem to be solved.
> 
> I do not know why hints based methods solve the policy conflict.
> As far as the destination address selection based on precedence is used,
> policy conflict can not be helped. In policy table based one, an entry
> in the table can conflict with others, and in hinsts based one, a hint
> can conflict with other hints. In my understanding, that's the only
> difference.

Sentence removed as it is ambiguous and unnecessary in the text there.

> 7.3.  Push model
> ...
>   However, we may
>   find that RAs may be a good place to indicate whether a default
>   policy is in place or not, to avoid hosts requesting non-existent
>   updates via DHCPv6.
> 
> I think I fail to see the reason why the O flag of RA is not enough.

OK.   Text removed.

> 7.4.  Routing Hints
> ...
>   The same thought seems relevant to address selection.  There's no
>   point selecting a source address whose prefix is not being advertised
>   in RAs.
> 
>   While routing and prefix hints may help a host make selection
>   decisions, we should consider to what extent we wish to 'burden' a
>   host with holding such information.  If a host is to determine and
>   cache routing hints, this may require an update of RFC 3484 policy
>   table syntax to support preference for address pairs.
> 
> In this section, what you suggest is to keep looking at RAs in order
> to know upstream network changes ? I think it is more helpful is
> it is described that way.
> 
> About the last sentence, I fail to guess what the routing hints are
> like, and therefore why we many need to update policy table.

Imagine an ICMPv6 query that could get an ordered list of address pairs as a response.    We do plan to write a draft based on the implementation we have done of that, just time has been an issue.

Tim