Subject: Comments on draft-ietf-dhc-ldap-schema-00.txt

From: Ryan Moats <[email-masked]>
Date: Thu, 5 Jul 2001 14:41:40 -0500

I find this to be much better than the -02 draft it was based on and
I have the following comments on this draft:

>The schema uses a few naming conventions - all object classes and
>attributes are prefixed with "dhcp" to decrease the chance that object
>classes and attributes will have the same name.  The schema also uses
>standard naming attributes ("cn", "ou", etc) for all objects.

This statement indicates that the schema uses standard naming attributes,
it does not *require* them.  Later in the object class descriptions,
it does in fact require them.  I would prefer strongly that the following
object class definitions do not require the "standard" naming attributes
as they will (IMHO) lead to administrator confusion (is this cn=... entry
a dhcpServer, a person, or something else?).  In general I suggest
the addition of dhcp*Name attributes as possible naming attributes.
This is the same approach that is being followed for the policy schema
work (draft-ietf-policy-core-schema-xx).

> 8. LDIF format for attributes and classes.

While not necessary, some line unfolding would make the LDIF easier 
to read.

In addition.  An example comparison of a ISC dhcpd.conf file and the
resulting objects would be of aid to implementors.

Ryan Moats

---

From: "Mark Meredith" <[email-masked]>
Date: Mon, 09 Jul 2001 13:39:41 -0600

We can change the wording to say it requires the standard naming attributes, but I think it is ok the way it is???  
 
I do not see a reason to add a new attribute just for naming when one exists that the majority of schema is using, The object class will show you what object you are talking about, so I do not understand how an administrator will get confused? So I propose that it we use CN, OU etc. because they are well defined and a standard schema for this purpose.
 
I agree with the folding issue we will work on making it fold better and easier to read.
 
I would like some more input on the example from a dhcpd.conf file to the resulting objects, before we add this.
 
-Mark

Mark Meredith
Senior Software Engineer
Novell Inc
1800 Novell Place, Provo UT 84606
[email-masked] 
801-861-2645
 
Novell, Inc., the leading provider of Net service software
www.novell.com 
 
---------------------
A boat in the harbor is safe, 
but that is not what boats are for.
--John A. Shed
---------------------

>>> Ryan Moats <[email-masked]> 07/05/01 01:41PM >>>

Ryan Moats

---

From: Ryan Moats <[email-masked]>
Date: Mon, 9 Jul 2001 15:58:31 -0500

On Mon, Jul 09, 2001 at 01:39:41PM -0600, Mark Meredith wrote:
| We can change the wording to say it requires the standard naming attributes,
| but I think it is ok the way it is???  
|  
| I do not see a reason to add a new attribute just for naming when one exists
| that the majority of schema is using, The object class will show you what
| object you are talking about, so I do not understand how an administrator
| will get confused? So I propose that it we use CN, OU etc. because they are
| well defined and a standard schema for this purpose.

Naming is very application/administration specific and schema (IMHO) should
be flexible.  Specifying only *one* naming attribute will lead to arguments
( like this :-) ).  Further, from my administration experience, overloading
the cn and ou (and other) attributes for classes other than what they were
initially defined for is a Bad Thing because it *does* leads to confusion.

Because of these reasons, the policy schema allows an administrator to use
cn *or* a different attribute. That is what I am looking for here: a schema
that I can use in my directory implementations.  With the present restriction
on naming, I have a barrier to using it.

| I would like some more input on the example from a dhcpd.conf file to the
| resulting objects, before we add this.

My point is that I *think* I know how this would work, because I've
implemented a partial dhc schema that looks similar.  However, one of
my big comments about the previous -02 draft was that it wouldn't be
clear to a new administartor (heck I couldn't figure that out) how
everything played together.  An example (could be in an Appendix) of a
(could be simple) dhcp.conf file and how it would be represented in
the directory would add clarity for folks not familiar with the schema.

Ryan

---

From: "Mark Meredith" <[email-masked]>
Date: Wed, 11 Jul 2001 12:32:20 -0600

My thoughts on the schema is this is the mandatory minimum specified, but it can be extended for different server requirements. So if you need to have a different naming attribute you should be able to add it to the May list and your server would use that attribute.  I do not see multiple (different vendors) servers accessing the same directory, although it could happen, but even with a specified multiple naming routine, the names would have to match so that all of the servers would access the same information.

In talking with different people about extending schema in general the feeling I get is that you should not create new attributes when there are existing attributes that will work.

-Mark

>>> Ryan Moats <[email-masked]> 07/09/01 02:58PM >>>

Ryan