Re: [ldapext] empty-groupOfNames-issue

[Simo Sorce <[e-mail]>]

On Fri, 2015-12-04 at 13:47 +0000, Andrew Findlay wrote:
> On Fri, Dec 04, 2015 at 12:17:49PM +0100, Michael Ströder wrote:
> 
> > 1. Modified standard schema descriptions for 'groupOfNames' and
> > 'groupOfUniqueNames':
> > 
> > This is the work-around already chosen by various vendors:
> > The MUST member or MUST uniqueMember is turned into MAY.
> > 
> > + it just works, no interop-problems seen so far.
> > + no change required in LDAP clients
> > + no change required in access control rules
> > + no change required in other client or server-side code dealing with groups
> > 
> > - It violates standardization best practices, most notably IANA considerations.
> > - It could serve as a bad example to change standard schema at will.
> > 
> > Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA
> > considerations.
> 
> I don't think there is an IANA consideration here. The modified schema
> is (currently) incorrect according to RFC4519 or is alternatively an
> experiment leading to a proposed change to a standard. In the latter
> case it would have to be accepted by IETF and published in a new RFC
> that obsoletes 4519. At that time, IANA would update the reference in
> the Object Identifiers table to point to the new document but would have
> no other involvement.
> 
> In practice I cannot see such a change ever being accepted into the
> standards track. If anything, the relatively wide distribution of
> non-conformant implementations makes a stronger case for deprecating
> these objectclasses for new deployments.
> 
> The definition of groupOfNames goes right back to X.521(1988) and it was
> already broken at that point:
> 
> a)	member was a mandatory attribute
> 
> b)	Nested groups were mentioned in the text but the semantics
> 	were left undefined
> 
> > -------------------------------------------------------------------------
> > 
> > 2. new object class 'groupOfEntries'
> > 
> > Andrew kindly wrote an mini I-D defining a new structural object class
> > 'groupOfEntries' simply with MAY member instead of MUST meant as direct
> > replacement for 'groupOfNames'.
> > 
> > http://tools.ietf.org/html/draft-findlay-ldap-groupofentries
> > 
> > + Very simple
> > + Fully compliant to standardization best practices
> > 
> > - It's not clear whether it was widely adopted in deployments.
> 
> Maybe not in the exact form I described in that I-D, but functionally
> equivalent objectclasses have been in most of my customers' systems.
> It could be argued that the corrupted form of groupOfNames described
> above is actually proof of widespread deployment of an analogous class.

My 2c:
An auxiliary class may be a better choice for a standard.

> > - small change required in LDAP clients for searching group entries
> > - small change required in access control rules
> > - small changes required in other client or server-side code dealing with groups
> 
> Andrew


-- 
Simo Sorce * Red Hat, Inc * New York