Subject: Re: Questions/Comments on draft-rajan-policy-qosschema-00

From: [email-masked]
Date: Mon, 02 Nov 1998 17:51:37 +0000

The following is being forwarded to the policy mailing list.
Message originally sent by Raju Rajan <[email-masked]>
---------------------------------------------------------------------------

Debasish Biswas wrote:

> 
>                 Where in the tree will these commonly defined objects be ?
> If they are at a higher, more global level (reasonably so, because as per
> this schema policies all over the tree will be using them) then  the second
> level searches or reads will have to be wider and may have to even span
> across more than one directory servers. This willl be problem for
> implementors who intend to put LDAP clients on their boxes.

At this point there are no rules regarding the directory tree for storage of
policy objects. It is assumed that policyRules will be grouped using the
Auxillary grouping attribute, and referenced from the device/organization/etc.
classes.

You may choose to store commonly defined objects at a higher level, but other
constraints may make someone else store them in a different level of the tree.
Your objection holds irrespective of the structure of the policy hierarchy --
the same objection can be made saying that multiple rules may be stored across
more than one directory server, making it difficult for the decision points. 

> 
> 
>                 The problem with an auxiliary class is that you can
> instantiate objects
>                 with attributes drawn solely from the object class. Thus, if
> I want to
>                 create an object that depicts Gold Class Service, with an
> intention to
>                 later create policies that refer to this object, I will not
> be able to
>                 do so. Similiarly, I may want to delete a policy that says
> so-and-so should
>                 get Gold Class Service, without destroying the notion of the
> service itself.
>                 A seperate object lets us do that.
> 
>                 I agree there is a potential  advantage in that, but I also
> think there is an advantage in making the schema more flexible for adoption.
> Defining a structural object class is kind of against  that grain of thought
> because the implementor  cannot decide to collocate the DiffServ or Cos
> Action along with the policy even for a private but conforming
> implementation. I think a recommended schema should have room for such
> implementation optimization. Normally, how complicated will the action be ?
> May be one-two attributes ? 

Only ToS marking can be done with one attribute. But this is a small part of
diffServ. In the "regular" case where the traffic profile has to be identified,
the ToS marked differently for conforming and non-conforming traffic, and the
quality of service/resources allocated to the stream identified, you would need
about 15 attributes or so. Further, there is no "normal" case for IPSEc with one
or two attributes, and that is a mess to define using auxillary classes alone.

What is the problem in slapping them with the
> policy ? Same kind of argument exists for the conditions. This sort of a
> linked objects befit a database data model more than a directory service
> application

I sympathize with the "slap and go" approach for simple implementations. But
that leaves us no room to grow. To properly manage a network with even tens of
policy aware elements, and full-fledged Diffserv as well as IPSec, the simple
approach fails, IMHO.

Regards,

Raju Rajan
> 
>                 Hope this helps. Regards,
> 
>                 raju rajan
> 
>                 >
>                 > Thanks.
>                 >
>                 > Debasish Biswas
>                 > FORE Systems
>                 >
>                 >