Re: Distributing site-wide RFC 3484 policy

[YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>]

Hello.

Well, first of all, I'm not against having a suggestion or recommendation
about address selection policy table from network.  And "horrible" in my
previous mail might be too offensive.

Anyway, there are several points:

1. A implementation may support interface (or zone)
   index, but ifindex can vary on that implementation.
   Interface (or zone) index is too fragile for real use.

2. Applicability of distribution of "exact" policy table is too restricted.
   An implementation may want to have their own policy, or more attributes
   (probably, in addition to ifindex), e.g. traffic class or whatever.
   The ifindex should be assumed one of extensions to the "standard"
   policy table, and the details should be left to implementations.
   The policy announced from network cannot be set directly.

   I know that conflicts are common, but, I would say, the distribution
   should not (or cannot) be an exact one, but a "hint", "suggestion" or
   "recommendation".  I do think it is much better to have information as
   "relative" representation, but at least, we should make the interpretation
   clear.

   Of course, an implementation may assume such information an order from
   network, but the network policy can only be enforced by the network.

   If the interpretation of the "policy" is relaxed, we will have more
   chances to use such framework.

These do not mean that current framework does not work at all.
Wording or description issue(s), maybe...

Regards,

--yoshfuji

In article <20070728.073043.432840387.fujisaki@syce.net> (at Sat, 28 Jul 2007 07:30:43 +0900 (JST)), (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <fujisaki@syce.net> says:

> 
>  | >  | Anyway, the draft contains a horrible error, at least.
>  | >  | We CAN NEVER specify zone-index from outside the box.  It MUST be removed.
>  | > 
>  | > I'm not sure why the error(?) is 'horrible', but we discussed about
>  | > 'zone-index' in DHC wg ML.
>  | > 
>  | > http://www1.ietf.org/mail-archive/web/dhcwg/current/msg04683.html
>  | > 
>  | > If the site administrator knows the detail of a client, it may be
>  | > possible to specify that value for the client.
>  | 
>  | You CANNOT specify "zone" itself from out of the box.
>  |
>  | If an implementation supports a kind of "zone" in policy,
>  | the node may want to restrict the rule only on that "interface"
>  | (or zone) which the dhcpv6 message has arrived, but no other way.
>  | 
>  | Server may ask the node to restrict the policy within the interface,
>  | but it cannot ask the end-node to use another specific interface.
>  | 
>  | Or, are you suggesting to have mapping between fake "zone-index" and the
>  | real one?
>  | 
>  | 
>  | Anyway, I'd say, you CANNOT distrubute the polocy itself, but you could
>  | suggest a "hint" to end-nodes, with "virtual precedence" (or "relative
>  | precedence"), "virtual label" and "virtual zone-index" (or "zone label").
> 
> Do you mean node local information should not be given from outside ?
> 
> We think if a node is in an administrative scope and zone index value
> is static (not dynamically changes when node restarts), it is possible
> to deliver that value to the node.
> 
> And if there is a case that utilizes zone index delivery, we should
> remain zone index delivery as it is, and limit the usage in
> specification. If there is no case, delivering we should not deliver
> zone index.
> 
> --
> Tomohiro Fujisaki
>