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

[Arifumi Matsumoto <[e-mail]>]

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 ?


Several comments below.

 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.


6.3.  Manual Configuration?

   There are scenarios where a host may wish to ignore conveyed policy.
   For example, the manager of a mobile node may not want to have its
   preferences changed by a visited network.  In such a case one might
   argue that the mobile node should use MIPv6 with whatever its home
   network policies are.

   The implication again is that there could be value in having a flag
   of some kind to inform a host whether network it is in uses the
   default RFC 3484 policy, which would then allow each end system to
   decide if it should get an (overriding) local policy or not.  One
   problem with this though is that some operating systems already
   implement 'modified' RFC 3484 behaviour, so we would have to be sure
   that all nodes have common understanding of what the 'default' is (in
   principle, that all nodes implement any future revised RFC 3484
   default policy table).

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.


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.

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.


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.


On 2010/07/12, at 2:13, Tim Chown wrote:

> For info, I have updated the dt draft with the output of the two telecons we've held:
> 
> http://www.ietf.org/id/draft-ietf-6man-addr-select-considerations-01.txt
> 
> If there are any additional changes you feel are needed before the cutoff, please email me.
> 
> Tim
> 
> _______________________________________________
> addr-select-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/addr-select-dt