Subject: RE: Policy Framework Core Information Model -- Version 1

From: "Jon Sjoberg" <[email-masked]>
Date: Mon, 31 Jan 2000 14:37:48 -0500

John,

Actually, my issue was with the simple nature of the aggregation not the
participants in the aggregation.  After re-reading the draft and with all
the discussion, however, I'm beginning to think my point was pointless :)

Sorry for the noise.

> -----Original Message-----
> From: John Strassner [mailto:[email-masked]]
> Sent: Monday, January 31, 2000 2:20 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Policy Framework Core Information Model -- Version 1
>
>
> Hi Jon, comments inline. Sorry about the weird address, it will be valid
> for only a couple of days. Please reply to [email-masked]
>
> regards,
> John
>
> At 05:45 PM 1/25/00 -0800, Jon Sjoberg wrote:
> 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.
>
> <jcs>
> Forgive me if I haven't had enough coffee yet ;-) but I fail to see how
> your examples listed below are different than, as you put it,
> aggregating a
> client and some network behavior. For example, if I look at the first
> example, I see a client (paying_customers), the traffic from that client
> (HTTP traffic ending up on landsend.com) and network behavior (priority
> treatment from special_servers).
> </jcs>
>
> 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.
>
> <jcs>
> But that same page defines other types of policies (e.g.,
> Configuration and
> Installation policies) that have nothing to do with aggregating clients.
>
> So if I'm reading you right, you're objecting to the emphasis of examples
> that focus on binding a client (human or otherwise) to a network service.
> Is that correct? If so, I'd be happy to add additional examples to balance
> things out. If not, please explain again.
> </jcs>
>
> 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.
>
> <jcs>
> All of these seem to fit the mold of client binding to network service. As
> another example, in the last example, the FTP traffic is generated by some
> person or application operated on behalf of a person (e.g., a client) and
> the service is, in this case, being denied.
> </jcs>
>
> 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.
>
> <jcs>
> The policy keywords, roles, etc. that are appropriate for these types of
> policies will necessarily be different for each application. The PFCIM
> deignated a small set of keywords and roles to standardize common,
> high-level concepts. If you look at these (pg 22), you'll see that they
> correspond to the types of policie that are described on page 6 (with
> "unknown" being a general catch-all).
>
> So, for the above example, if you treat a role as a selector, then you
> would want to define a set of policies that would select HTTP traffic and
> at least one other attribute (e.g., the set of IP addresses (for example)
> that map to landsend.com. Likewise, keywords are used to speed up
> searches,
> so you would define a set of keywords that would help you locate policy
> rules, conditions, actions, etc.
> </jcs>
>
> 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?
>
> <jcs> Already covered in another email I sent. </jcs>
>
>
> Jon
>
> _________________________________________________________
> fsmail - get your free web-based email at: www.fsmail.net
>
>
>
>

---

From: John Strassner <[email-masked]>
Date: Mon Jan 31 19:20:29 GMT 2000

regards,
John

1.)

<jcs>
your examples listed below are different than, as you put it, aggregating a

<jcs>
But that same page defines other types of policies (e.g., Configuration and
Installation policies) that have nothing to do with aggregating clients.

<jcs>

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.

<jcs>

that map to landsend.com. Likewise, keywords are used to speed up searches,

2.)
attributes that add no direct value (my opinion) to the problem domain, and

Jon