Subject: RE: Questions on schema inheritance and naming

From: "Yoram Snir" <[email-masked]>
Date: Thu, 12 Aug 1999 16:50:41 +0200

Please see comments inline.

Yoram Snir
Cisco Systems
mailto:\\[email-masked]
Tel. 972-9-9700085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Thursday, August 12, 1999 1:13 PM
> To: [email-masked]
> Subject: Questions on schema inheritance and naming
>
>
> Hello
>
> I am new to the policy arena as well as LDAP and modelling in general.
> However after looking through the drafts for the core policy
> schema and the
> qos extensions (draft-snir-policy-qos-infomodel-00.txt) I
> couldn't help
> thinking that some of the classes are superflous. The inheritance vs
> composition argument?
>
> For example there is policyGroup, qosPolicyRepository,
> qosPolicyDomains,
> qosPolicyDomain and qosNamedPolicyContainer. These all appear to be
> basically the same thing to me. Namely a structural class
> which is used as a
> container and or a place to attach auxiliary classes. The only real
> difference that I can see is the name. But shouldn't that just be an
> attribute value? One single class ie policyGroup could be
> used for all of
> these. Albeit with a name change, maybe policyContainer ?
>
Each of these classes has some propriety attributes. The qosPolicyDomain has
the following: qosPolicyGlobalNamedContainer:DN
qosPolicyPHBSet:DN
qosPolicyGlobalNamedContainer:DN
The qosNamedPolicyContainer has the following:
NamedPolicyContainerPriority
PolicyRuleMatchMethod

The class definitions in draft-snir-policy-qos-infomodel-00.txt are missing
some of the attributes, will be fixed in the next version. In general, each
of the above container is more then a policy container, but serves a
specific role in the hierarchy of policy definition and defines the
namespace that each policy belongs to.
It was decided to define those 3 classes also to allow extensions of the
schema to have the same structure and get the required attributes in each
class, Place holders for extensions.

> The only new attributes that are defined in the subclasses
> are user friendly
> names. Therefore why not add a user friendly naming attribute
> (friendlyName
> or perhaps just name) to the policy class, then the policyGroupName,
> qosDomainName, adminDomainName etc attributes can be dispensed with.
>
> If required the policyKeywords attribute could be used to distinguish
> between the types of data held inside the container. So if an
> ldap client
> wants to retrieve all the policy domains it can use the
> appropriate keyword
> in the search filter.
The policy keywords is something to be used by the network administrator to
place key word related to the policy itself not for the schema builder.
Keywords like "Critical application" or "VOIP".
>
> Like I said above I'm new to modelling, so if my thinking is
> all wrong then
> please educate me!
>
> I also found the naming of some of the classes and attributes a little
> strange. As a software developer I believe that descriptive
> names are very
> important. For example the name policyInstance would suggest to me one
> complete instance of a policy ie everything that comprises
> one complete
> policy. But in the core model it is used as a structural
> class to attach
> policyCondition or policyRule auxiliary classes. It
> represents a part or
> component of a policy and not the whole thing as the name
> would suggest.
>
> Another example is qosNamedPolicyContainer, the definition of
> which states:
> quote
> This class represents an administrative policy rule container.
> unquote
>
> followed by
> quote
> The "namedQosPolicyContainer" fills the fole of a diff-serv
> "Role" object.
> unquote
>
> Therefore I would expect the class name to more accurately
> reflect what the
> class is / does.
>
The NamedQoSPolicyContainer is a container for qos policy rules, it must be
named to be associated with the Doff-Serv Role object. As for the
definition, you are right, we will make it clearer in the next version.

> Some of the auxiliary class names end with "AuxClass" but
> others don't, why?
> It would be nice to have a more consistant naming strategy.

The AuxClass is only used for auxiliary classes defined in the core schema,
that are not to be instantiated (using PolicyInstance). For example policy
condition is an auxiliary class to support simple rule attachment, but may
also be instantiated and referred by SDN, so it does not include AuxClass in
its name.
The qos policy schema does not contain auxiliary classes that may not be
instantiated using PolicyInstance, so "AuxClass" ending is not used.

>
>
> On another note, I haven't noticed any discussion on any actual
> implementations of these schema or attempts to write ldap
> clients to access
> them. Or have I missed something somewhere. As this is
> basically what I'll
> be doing over the next few weeks I would be interested to
> hear of other
> peoples experiences on this.

The qos-policy-infomodel tries to define the information model and LDAP
schema and only touches implementation, data integrity for example. It tries
to define what's required to get a consistent system but does not restricts
the implementation.
Some additions to the qos draft will deal with improving LDAP operation
efficiency, mainly where and how objects should be placed and how they
should be fetched.
Actual implementation techniques are important, but I am not sure that
should be part of the draft.

>
>
> Vince Suttle
> Network Management Research
> British Telecommunications Plc
> BT Advanced Communications Technology Centre
> Adastral Park
> Marlesham Heath
> Ipswich
> UK
> [email-masked]
> +44 (0)1473 605458
>
>
>
>