[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] groupOfEntries object class proposal

Andrew,

Glad to see you following through on this.

> The LDAP groupOfEntries object class

I don't like the name of the class. It's not a group of entrys, but a group of names of objects (entries), in particular a group of distinguished names. I suggest the class be named 'groupOfDNs'.

Abstract

This memo describes the LDAP groupOfEntries object class 

I suggest:
	This memo describes the LDAP/X.500 'groupOfEntries' object class...


which is a
   replacement for the existing groupOfNames class.

I rather the I-D say:
... for representing groups. The new class is introduced as an alternative to the 'groupOfNames' class.


I dislike any language that suggests this new class deprecates the groupOfNames. I rather the I-D propose an alternative to groupOfNames, and leave the choice of which group class to use to directory applications (preferable stated in an applicability statement).

The new class
   permits the creation of empty groups.

I suggest:
Unlike 'groupOfNames', 'groupOfEntries' can represent a group whose membership is empty.



If approved as a Standards Track document, this document will update RFC4519 [2]

I recommend this I-D propose an extension, not an update any document (e.g., RFC 4519) which is part of the LDAP technical specification [RFC 4510]. In particular, I recommend this I-D not "update" RFC 4519. That is, I recommend this sentence be stricken.

(Editorial note: no citations should be used within the Abstract of the document.)

1. Introduction

I think the Introduction doesn't stand well be itself. That is, it seems to rely on information provided in the Abstract. I suggest the Introduction start by restating (in new words, with cites), and expanding upon, the Abstract.

A groupOfNames object class has existed since the earliest X.521 [1]
standard. It has an identical definition in LDAP (RFC4519 [2]).

I suggest the second sentence read:
An LDAP [RFC4510] description [RFC4512] for this class is provided in RFC 4519 [RFC4519].

I suggest you then include the LDAP description:
	That description is:
		      ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL
			MUST ( member $ cn )
			MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

The
class is used to define entries holding DN-valued member attributes, 

I suggest
	The class is used to represent groups of names.

each value pointing to an entry that represents a single member of
the group being described, or to another entry of type groupOfNames.

Suggest:
Each group object may contain a 'member' [X.520][RFC4519] attribute whose values are name members. Each value is a distinguished name of an object. The entity represented by the named object is consider a member of group. If the member attribute is not present in the object, the group membership is empty.


Which raises an interesting question which the I-D needs to address: how does a DUA determine reading a group returned without any member attribute determine whether the group is empty or wether the DSA was unwilling (or unable) to provide the membership? The DSA could, I guess, return member without its values to represent the group was non-empty and only return the entry less the member attribute if the entry didn't contain member. However, this is likely problematic. I think this needs further list discussion.

	


   groupOfNames is a structural object class, so it is often the only
   class used in the definition of group objects.

Experience has shown that the definition of groupOfNames causes
difficulties in practice. In particular, the fact that 'member' is a
mandatory attribute means that it is not possible to create an empty
group or to delete the last member from a group. This leads to
artificial tricks such as making every group a member of itself, or
adding a dummy member to every group when it is created. These
tricks in turn make the management of groups more complex and prone
to error. Groups are commonly used to control access to resources,
so management errors can lead to security risks.

Yes. For instance, if one adds the empty DN to a group is problematic as the empty DN is often used to represent anonymous users, hence adding an empty DN to member implies anonymous users are members of the group.


There does not appear to be any good reason for the 'member'
attribute to be mandatory. This memo describes a new object class
called groupOfEntries that is equivalent to groupOfNames in all other
respects but which makes 'member' an optional attribute.


2. The existing groupOfNames object class

I would fold this section into the Introduction. 

   RFC4519 [2] contains this definition:

   The 'groupOfNames' object class is the basis of an entry that
   represents a set of named objects including information related to
   the purpose or maintenance of the set.  (Source: X.521 [1])

I now notice this description is bit off. The X.521 description is better: "The Group Of Names object class is used to define entries representing an unordered set of names which represent individual objects or other groups of names." I rather include the X.521 text (early in the Introduction).


         ( 2.5.6.9 NAME 'groupOfNames'
            SUP top
            STRUCTURAL
            MUST ( member $
                  cn )
            MAY ( businessCategory $
                  seeAlso $
                  owner $
                  ou $
                  o $
                  description ) )

   The inclusion of 'member' in the 'MUST' section of the definition
   prevents empty groups from being created.


3. The groupOfEntries object class

I rather the description of this class instead be a rewording of the X.521 groupOfNames description. 

   The 'groupOfEntries' object class is the basis of an entry that
   represents a set of named objects including information related to
   the purpose or maintenance of the set.  It should be used in
   preference to the 'groupOfNames' object class.

I think the last sentence should be stricken (see above). 

         ( 1.2.826.0.1.3458854.2.1.1.1 NAME 'groupOfEntries'
            SUP top
            STRUCTURAL
            MUST ( cn )
            MAY ( member $
                  businessCategory $
                  seeAlso $
                  owner $
                  ou $
                  o $
                  description ) )

   This object class allows groups to be empty.  In all other respects
   it behaves like the groupOfNames object class.

The OID assigned to this object class is delegated by Skills 1st Ltd.


4.  Effect on other documents

   This draft deprecates the use of the groupOfNames object class in
   RFC4519 [2] and replaces it with the groupOfEntries class.


I think this section should be stricken (see above).

I suggest adding a section here addressing the 'interesting question' I raised above.

There should also be a section discussing nested group semantics. This needs further discussion I think. I'll be following up to comments others have made in this area.



5.  IANA considerations

   It is requested that IANA register upon Standards Action the
   groupOfEntries Object Identifier Descriptor and its associated OID.


6.  Security considerations

   Groups are commonly used to define access permissions to directory
   entries and resources in other services.  Allowing for empty groups
   avoids the risks associated with leaving a dummy placeholder member
   in group entries, so security is improved.

There may be some security considerations to note in regards to the 'interesting question'.


Appendix A. Acknowledgements 

Editorial: Should be a section, not an appendix.


   The author gratefully acknowledges the contributions of Michael
   Stroeder to the first draft of this document.




_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext