Subject: Policy Framework Core Information Model -- Version 1

From: "Jon Sjoberg" <[email-masked]>
Date: Tue, 25 Jan 2000 17:45:37 -0800

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

---

From: Jon Saperia <[email-masked]>
Date: Wed, 26 Jan 2000 07:34:15 -0500

> draft to track tighter to the essential complexity of the problem?

One of the reasons I like your suggestion (especially about UML) are
that there are some very good tools around that generate UML and for
some of us at least, would help with design code and other reasons.

/jon

---

From: "John C. Strassner" <[email-masked]>
Date: Sat, 29 Jan 2000 22:28:41 -0800

Remember that an Information Model is repository-independent. So our 
intended protocol is most certainly not limited to just LDAP. Rather, we 
define a set of mappings (in other documents) that translate the data in 
the information model to a form suitable for implementation using a 
specific repository.

It would be more correct to say that the mapping of the information in the 
PFCIM to a form suitable for implementing in a directory using (L)DAP is 
documented in the following draft:
   draft-ietf-policy-core-schema-06.txt.

With respect to your comments about UML and CIM, CIM does try to use UML. 
Granted, it strays from strict UML representation in some places, and uses 
the notion of "weak" associations, but I'm struggling to understand why 
both of you think that this is not UML. Please explain with specific examples.

With regards to CIM quirks (or quarks, which I guess is a really big quirk 
;-)  ) I agree. This comes from trying not to have dueling object wars, and 
trying to use CIM 2.2 (which is released and publically available).

With respect to certain CIM "value-less attributes", you are probably right 
in many respects. But this is more of a result of CIM being specifically 
designed to be used for many problem domains. We have a very specific 
problem domain defined, and therefore are stuck with some of these more 
generic attributes that aren't directly applicable. We can fix this, at 
least in a directory mapping, by ensuring that these attributes are all 
marked as optional.

So I personally would be happy to help rework the draft to "track tighter", 
as you put it, but in order to do that I need specific examples, especially 
concerning its not being compliant with UML. SO please supply examples, and 
I'll give it a shot.

respectfully,
John

---

From: "Jon Sjoberg" <[email-masked]>
Date: Mon, 31 Jan 2000 06:57:55 -0800

John,

> concerning its not being compliant with UML. SO please supply

Here is a list of differences between CIM and UML.  If you need any help
re-working this, let me know.

1.) We don't use the inheritance of associations, so it is just more words
that add little value to our problem.   Lets lop it out of the document.

2.) Associations with attributes is not used in UML and seems un-necessary.
Standard information modeling says:
    For one to many associations the key attribute(s) of the association go
to the one.
    For the one to one association the key attribute(s) can go to either.
    For the many to many associations then there is an associating object
that can hold the key attributes plus any other attributes of the
association (the only case that is somewhat like the current "associations
with attributes").

This eliminates a whole nest of sections on associations and provides just
secondary key attributes.  Note that where the association keys go is just
an analysis tool and has NO relevance on the implementation.

3.) CreationClassName:  Do we need this?  I understand why CIM uses it, but
UML uses the concept of categories to provide name scoping.  We have the
category of the base PCIM.  All names within in it are scoped to be unique
(PCIM.PolicyGroup).  There is a whole paragraph plus a bunch of attribute
descriptions for CreationClassName that are not part of the essential
problem.  Perhaps the UML category idea would be lighter weight?  Besides,
in all honesty, I don't quite get the whole "weak association" thing but
what I do get leads me to believe it is not intrinsic in the policy problem.

The above three deviations from UML add, what I would consider,
non-essential complexity to the document.

<soap box>
If, as Ed implied, we are using CIM to play nicely with others, then there
is merit in that.  To minimize the impact on us, perhaps we could move some
of the CIM specific text to appendices, just refer to the CIM modeling
language document (if it is publicly available), or a combination of the
two.

If we are using CIM because it is the modeling tool best known by the
authors, I would assert that it is not the best tool for the job.  UML would
be better, Shlear-Mellor would be best.

NON-SEQUITOR:  UML is not a bunch of boxes and arrows and therefore the use
of boxes and arrows does not make it UML.  UML is an approach to system
architecture, design, and even, to extremes, implementation.  CIM is NOT
UML, or even very much like UML.  This does not mean CIM is evil, but on
several occasions I have heard the statement the CIM is UML (or so similar
as for there to be no distinction) as a defense.  This statement is
inaccurate and should probably not be used.
</soap box>

Jon

P.S.  Yes "quark" was supposed to be "quirk".  The spell checker was
checking what I typed, not what I meant.