Subject: RE: Consensus ?

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 2 Dec 1999 09:48:55 -0500

I have a bit of concern with the meaning of "user interface" as it is 
evolving in this discussion, and that it might send the wrong message 
to people who have not been participating in this discussion.  In 
some messages, it's even been called a "console" to the master 
archive/policy repository.  I think that conveys more of a sense of 
direct interaction with the MA then is necessarily desirable.

It's a good assumption that the MA function is "dumb" while the PA is 
"smart."  There is room and need for another smart function, that 
becomes involved in the non-real-time loading of the policies into 
the MA. For the time being, call that function the Policy Counselor, 
which interacts with the policy-writing-person.   Just as the MA has 
a potential need for multivendor interoperability, it's reasonable to 
assume that knowledge about policies could also be shared among 
different implementations.

Leaping into a discussion with a bit of trepidation, let me suggest 
another element that might help, and some alternate naming.

                                      Operational Interface (OI)
                                    /  (2)
                                   /              |
                                  MA              | (1a)
                                   \  (1b)        |
                                    \   Policy Counselor (PC)

The PC is a non-real-time function that contains knowledge about 
policy writing.

The Operational Interface is the point of interaction between the 
policy writer and the policy system. It may interface directly to the 
MA (2), or indirectly through the PC (1a).

---

From: John Schnizlein <[email-masked]>
Date: Thu, 02 Dec 1999 10:42:22 -0500

Howard,

Your concern is valid. The need for analysis of the contents of
the policy repository, along with other information such as the
capabilities of devices and topology of the network, is a functional
requirement that often gets omitted from discussion. If the policy
is feasible for implementation on the actual network might require
significant computation and a variety of information.

The functional decomposition of the requirements for a policy system
is what we agreed to focus on at the Washington meeting. We should
avoid the temptation to elaborate (or even restate) architectural
compositions of components that might implement these functions.

One kind of distinction that might be useful, especially since we
have still not defined the term "policy" very carefully, is the
distinction between policy information and other information that
would be necessary in the design of a system that deploys policy.
Part of the reason to identify these different kinds of information
is that they might lead to discovery of design constraints or
opportunities that are not exposed by early architectural attempts.

I was involved in the discussion of Ma, Pa, and Ed (the kid), but
regarded it as a joke spawned by fumes or a long and less-conclusive
session than anticipated. We really do not need new names for the
repository and deployment components of a policy system. What we do
need (and is underway on the [email-masked] list) is consensus
definition of the terms and concepts already involved in the discussion.

John

---

From: Shai Herzog <[email-masked]>
Date: Thu, 23 Dec 1999 16:45:47 -0500

>definition of the terms and concepts already involved in the discussion.

Being the source of the "Joke" my intention was not to actually
invent terminology but because it is assumed to be temporary (for
the sake of discussion) it would free us from getting hung up on
names rather than debating functionality.

However, it looks like these names are taking root ;-)

Shai

> >MA (2), or indirectly through the PC (1a).

__________________________________________________________________
Shai Herzog, Founder & CTO     IPHighway      Cell: (917) 449-7889
400 Kelby St. 16th Fl                         Tel : (914) 654-4810
Fort-Lee NJ 07024                             Fax : (212) 656-1006

---

From: Shai Herzog <[email-masked]>
Date: Thu, 23 Dec 1999 16:33:40 -0500

Howard,

Great input! I think you are absolutely right.

At 09:48 AM 12/02/1999, Howard C. Berkowitz wrote:
>evolving in this discussion, and that it might send the wrong message to 
>people who have not been participating in this discussion.  In some 
>messages, it's even been called a "console" to the master archive/policy 
>repository.  I think that conveys more of a sense of direct interaction 
>with the MA then is necessarily desirable.

I agree that the term UI isn't very good. Perhaps what we need is to
think of it in terms of "non real-time creation/modification of the
policy". In the spirit of MA, PA and ED, perhaps we should call it
PC (Policy Creator) (Policy Counselor would be too similar to policy
advisor, PA). The idea is that the policy is created using some tool
(what was known as UI) which may take any non-real-time criteria as
input in the policy creation).

so UI -> PC (Policy Creator)

This creation can be done either by humans (GUI), scripts, or
some network planning/provisioning AI (Artificial Intelligence)
program. PC can include one of those or any combination
(script + GUI for instance).

Does that make sense?

Created policy can be fed to MA (using LDAP) in a multi-vendor
case, or if both PC and PA are of the same vendor, they may communicate
directly and then one of them MUST feed MA with the rules.

Shai

>"smart."  There is room and need for another smart function, that becomes 
>involved in the non-real-time loading of the policies into the MA. For the 
>time being, call that function the Policy Counselor, which interacts with 
>the policy-writing-person.   Just as the MA has a potential need for 
>multivendor interoperability, it's reasonable to assume that knowledge 
>about policies could also be shared among different implementations.
>
>The PC is a non-real-time function that contains knowledge about policy 
>writing.
>
>The Operational Interface is the point of interaction between the policy 
>writer and the policy system. It may interface directly to the MA (2), or 
>indirectly through the PC (1a).