Subject: Re: Policy conditions - a plea for simplicity

From: "Ken Roberts" <[email-masked]>
Date: Thu, 22 Apr 1999 15:27:41 -0700

Silvano,
I believe you have just illustrated my point for me! Policy can be
complicated and including computed (or non enumerated) predicates while
valid should be left for "future study".
I can and if necessary will drag out the work previously done contrasting
simple Vs complex rules and enumerated Vs non-enumerable attributes but
would prefer for now to re-iterate this is best left for now and efforts
concentrated on establishing a viable base first.
It is not my intent to argue that discussions on these issues should not
proceed (at least on an intellectual level) but surely it is in everyone's
interest to establish a track record first.

The example you used in your mail is somewhat analogous what consumed a
large amount of time (in years gone by). What if you wanted to establish
policy for all off-line network printers, how would you be able to establish
a jurisdiction within a large network? In the same way as establishing
whether John is "logged on" or not implies some mechanism to query in
real-time a "list" of logged on users or off-line devices. Bottom line (to
date) is jurisdiction establishment is "best effort" in that a list of NEs
that "should" satisfy the criteria can be obtained but when the operation is
applied to the candidate list some members may respond with "surprising"
results since their status has changed but not been reported as yet.

Within ISO it became clear that implementation of some policies would
involve quite large computing requirements - I believe this is certainly the
case for support of a general policy-enabled management model, and while I
believe this is exactly what the industry requires I would like to see QoS
managed first and then tackle the rest.

Regards,
Ken.
-----Original Message-----
From: Silvano Gai <[email-masked]>
To: Roberts, Ken (J.) [EXCHANGE:MPK:0470-I:NT] <[email-masked]>;
[email-masked]' <[email-masked]>
Date: Thursday, April 22, 1999 2:50 PM
Subject: Re: Policy conditions - a plea for simplicity

>At 10:16 AM 4/22/99 -0700, Ken Roberts wrote:
>>Hi Group,
>>
>
>...
>
>>
>>If you put it all together you get:
>>IF (current-time less 17:00 AND current-time greater 09:00) AND
>>     (originating-address equals 1.2.3.4 AND destination-address equals
>>2.4.6.8)
>>     THEN
>>               Mark(Premium, GOLD)
>>      ELSE
>>               Mark(Best-Effort)
>>Endif
>>
>
>According to my terminology and my presentation you have only used state
conditions and packet conditions. This is fine for me and I think we can
write effective policies in this way.
>
>What we don't have agrement on is how do we model/handle transitions/events
that change states. In the case of time, it is clear that we can immagine a
simple "implicit handler" that maps  transitions/events to states.
>
>The more complex case is:
>
>IF "user John is logged on" THEN
>
>where is the handler that set/reset the state "user John is logged on"?
>
>As David mentioned, the handler cannot be associated with the arrival of
the logon or logoff packets, but must take into account the execution of a
login/logout procedure that could be quite complex.
>
>I think we should introduce in the PDPs the concept of "explicit event
handlers". An Event handler is a procedure to map event/transitions into
states. I also think we should write the policies only in term of states and
packet conditions.
>
>-- Silvano
>
>
>Silvano Gai
>Cisco Systems                  Empowering the Internet Generation
>170 West Tasman Drive                         Tel. (408) 527 2690
>San Jose, CA, 95134-1706                      Fax. (408) 527 2690
>                                                   [email-masked]