Subject: Re: Distributing site-wide RFC 3484 policy

From: YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]>
Date: Fri, 03 Aug 2007 19:34:47 +0900 (JST)

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 <[email-masked]> (at Sat, 28 Jul 2007 07:30:43 +0900 (JST)), (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[email-masked]> 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
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Aug 2007 13:21:50 +0200

On 2007-08-03 12:34, YOSHIFUJI Hideaki / $B5HF#1QL@ wrote:
...

>    chances to use such framework.

I agree that the IETF specifcation should not say that the central
policy takes priority over the host policy. IMHO we should provide
a mechanism (such as assigning a weight to each policy element),
so that it is a configuration issue whether the central policy or the
host policy wins.

    Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 08 Aug 2007 15:36:04 +0900

Hi,

> so that it is a configuration issue whether the central policy or the

About zone-index we don't hesitate to remove it from our specification
if there is no single case that utilize zone index or we cannot make
use of it because of it's characteristics.

About Brian's comment,
I agree that we should provide such a mechanism for changing
policy acceptance behavior at hosts. Although these issues should be
"implementation depenedent", IMHO it is better to describe several
possible and valid implementation approaches in the specification draft.

Whether the distributed values should be "relative" or "absolute"
depends on such a mechanism. If the mechanism allows a host's policy
to be fully overwriten, the distributed values can be used as absolute
values. They have to be taken as relative values if a user chooses
"merge mechanism", which can lead to policy collision in some cases though.

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