[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf [Fwd: [Fwd: Policy Framework Core Information Model -- Version 1]]



Attached is a forwarded message from the policy group. It is one of a
couple I will send out since I know some of you are not on that list.

The relevance this has for snmpconf is that we are defining a MIB module
for capacity and capability. In some sense the discussion of roles and
rules (i think of them as policy) is  important to the definition of
this mib. For those that have not heard me say this before, part of what
we should accomplish with this mib module, is the expression for each
role combination of the remaining capacity and total capacity. For
example, say all the channelized OC-12 interfaces which connect to the
core and support 1:N APS. - I am attempting to sprinkle in some examples
in our discussions that are not all gold service since one of our goals
is to write a general module for SNMP based configuration management,
not just diff serv for this [the capabilities and capacities] module.

/jon


Since we talked about this the other day, I thought I would forward an
email which has a well posed question which illustrates current thinking
about what policy is.

I am not suggesting we get bogged down at all in any of these details.
This is just fyi.
/jon


A few comments the draft: "Policy Framework Core Information Model --
Version 1 Specification".

1.)
The general view that I get from the draft is that policy (as currently
being focused on by this WG, not in the most general sense) is being made to
apply to the aggregation of a client and some network behavior.  The
following statement, from the draft, sums up the "feeling" that I get:
"Service policies describe services available in the network. Usage policies
describe the particular binding of a client of the network to services
available in the network."

Often the draft uses examples like "so-and-so gets gold service" or "use
this scheme on this interface."  I appreciate these are only examples, but
they also further my opinion that this draft focuses on a simple
aggregation.

What I'm looking at is policies such as:
All HTTP traffic from paying_customers for landsend.com gets priority
network treatment from special_servers.
All HTTP traffic from browsing_customers for landsend.com gets priority
network treatment from unwashed_masses_servers.
All FTP retr traffic for landsend.com gets bulk-transfer network treatment
from unwashed_masses_servers.
All FTP stor traffic for landsend.com gets denied network treatment.

Clearly these can be represented as condition/action policy rules.  What I'm
not so clear on is all the other stuff that goes around these policy rules.
What policy keywords or roles are appropriate for these policies?  Where
does the definition of HTTP, paying_cutomers, FTP, etc. fit into the
repository or do they (I think I remember one incarnation of this draft or
the LDAP schema that sort of addressed this)?  Can some one enlighten me!
Thanks.

2.)
Usage of the CIM notation seems to add to the complexity of the problem
domain and to the complexity of this draft.  A conservative estimate of 15
percent of the document is devoted to describing CIM work-arounds, CIM
attributes that add no direct value (my opinion) to the problem domain, and
CIM "quarks".  Given that our intended protocol is LDAP, is there enough
value to the CIM notation to use it instead of some other more robust OO
representation (UML, Shlear-Mellor, etc.)?  I'm not suggesting holding up
last call over this (least I get shot), but perhaps we could re-work the
draft to track tighter to the essential complexity of the problem?

Jon