Subject: RE: Comments on draft-rajan-policy-qosschema-00

From: [email-masked]
Date: Thu, 5 Nov 1998 11:01:15 -0500

I appreciate Ryan's comments on uid and dc, but I'm not sure
much needs to be changed in this respect in qosschema-00.

The uid attribute was intended as a very convenient
RDN for users/persons, especially when a schema of existing
names easily slotted into uid. There wasn't an intent
to require uid to be THE way to assign RDNs to arbitrary
leaf entries or all leaf entries. The most avid fan of uid
naming (me) has to recognize that there is going to be stuff
out there named with cn because some standard and popular
schema (X.500) did it that way a long time ago. 

I think everything I've seen in qosschema-00 is properly named
using cn and I don't think anything useful would be accomplished
by making cn optional. This shouldn't preclude using uid as
the RDN of entries for users/persons in the same directory tree.

Ryan's comments on the dc attribute are quite appropriate if
this schema is going to constrain the layout of the DIT. This
is normally not done. For reasons unknown to me the DEN specification
invents and is written in a language that constrains where objects
of a particular class can be placed in the tree. This intrudes
into the qosschema only in the policyContainmentAuxClass. Delete
the reference to "POSSIBLE SUPERIORS" in the course of aligning
the schema specification to RFC2252 and the problem goes away.
Otherwise, I think a lot more discussion regarding naming and
DIT layout is needed in the document. -- al
	  <<Re: Comments on  draft-rajan-policy-qosschema-00>> 

Subject: Re: Comments on draft-rajan-policy-qosschema-00
From: [email-masked]
To: Ryan Moats <[email-masked]>
Cc: [email-masked]
Date: Wed, 4 Nov 1998 11:17:21 -0500

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

Hi Ryan,

 In your opinion, is it sufficient to make CN an optional attribute, or do
we
need to introduce other attributes? Could you send me a few lines suggesting
appropriate wording for RDNs and the relation to naming schemes? I am not an
LDAP expert and would be happy to receive your suggestions.

Regards,

raju rajan

ps: Other responses inline

[email-masked] wrote:
> 
> In reading draft-rajan-policy-qosschema-00, the following points have
> come up:
> 
> In RFC 2247, the "dc" component is introduced as a potential RDN.  In
> RFC 2377, this concept is extended by introducing the "uid" component
> as a potential RDN.  By requiring [MUST] "CommonName" as the RDN for
> all objects in this schema, you preclude anyone from building a naming
> plan based on "dc" and "uid". Rather, CommonName, DomainComponent, and
> UniqueIdentifier should all be optional [MAY].  This allows directory
> implementors more flexibility in setting up their naming plans.
> 
> In addition to this, it would also be useful if PolicyContainmentAuxClass
> also included the Domain class in the list of potential parents.

Will do so.

> 
> Now for the editorial comments:
> 
> TCPActionName is not included in the TCPAction Class declaration.
> 
> RSVPUserAuthPolicy is not included in the RSVPAction Class declaration.
> 

Will add these.

> Since most of the introductory classes are identical to
> draft-ietf-ipsec-vpn-policy-schema-xx,
> it makes more sense to refer to that draft and just discuss the name
> Classes (TCPAction, RSVPAction, DiffServAction, DiffServResourceGroup and
> RSVPResourceGroup)

A suggestion that has been actively discussed, is to move the core classes
to a
seperate document, which will be referenced from both existing drafts, as
neither is really more fundamental than the other. We will most likely be
doing
so.