Re: [ldapext] Schema for posixGroup successor (RFC 2307 bis)

Simo Sorce <idra@samba.org> Wed, 11 February 2015 11:29 UTC

Return-Path: <idra@samba.org>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988291A1B80 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 03:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNKlopFuqDP8 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 03:29:32 -0800 (PST)
Received: from mail.samba.org (fn.samba.org [IPv6:2001:470:1f05:1a07::1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E888D1A1B4A for <ldapext@ietf.org>; Wed, 11 Feb 2015 03:29:31 -0800 (PST)
Received: from mail.samba.org (localhost [127.0.0.1]) by mail.samba.org (Postfix) with ESMTP id 7E291AC0BB; Wed, 11 Feb 2015 04:29:31 -0700 (MST)
Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.samba.org (Postfix) with ESMTP id 2FA2FAC0B7; Wed, 11 Feb 2015 04:29:31 -0700 (MST)
Message-ID: <1423654170.11010.63.camel@samba.org>
From: Simo Sorce <idra@samba.org>
To: Michael Ströder <michael@stroeder.com>
Date: Wed, 11 Feb 2015 06:29:30 -0500
In-Reply-To: <54DB3BF8.7000909@stroeder.com>
References: <54DB27C7.3060409@stroeder.com> <1423653002.11010.62.camel@ssimo.org> <54DB3BF8.7000909@stroeder.com>
Organization: Samba Team
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.9 (3.12.9-1.fc21)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/pifbNzwVWYQ5s9X2Z-pU-hKj6_w>
Cc: ldapext <ldapext@ietf.org>
Subject: Re: [ldapext] Schema for posixGroup successor (RFC 2307 bis)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: simo@samba.org
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 11:29:33 -0000

On Wed, 2015-02-11 at 12:24 +0100, Michael Ströder wrote:
> Simo wrote:
> > On Wed, 2015-02-11 at 10:58 +0100, Michael Ströder wrote:
> >> Since Kurt expressed to follow very strict guide lines forbidding altering
> >> existing NAMEs and OIDs of schema descriptions especially in RFC 2307 the
> >> question is how to define a new object class for POSIX groups in RFC 2307bis
> >>
> >> To preserve backwards compability I'd like to propose the following:
> >>
> >> ( <OID TBD>
> >>   NAME 'posixGroup2'
> >>   DESC '<TBD>'
> >>   SUP ( groupOfEntries $ posixGroup )
> >>   STRUCTURAL )
> >>
> >> With this definition..
> >>
> >> 1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes,
> >>
> >> 2. the object class still can be found with (objectClass=posixGroup) and
> >>
> >> 3. the object class is STRUCTURAL and therefore one can assign a specific DIT
> >> content rule to it allowing to preclude either 'member' or 'memberUID' with
> >> NOT to meet local system requirements.
> >>
> >> 4. there's no conflict on LDAP servers with the old RFC 2307 schema already added.
> >>
> >> What do others think about this approach?
> > 
> > I'd call it posixGroupBis, but otherwise sounds like a good idea.
> 
> I have no strong opinion on the NAME.
> 
> > Does it have to be structural though ?
> 
> I expected this question. ;-)
> 
> Yes, it has to be STRUCTURAL and I already gave one rational with 3.  Note
> that DIT content rules, which are very helpful for defining local profiles of
> standard object classes, can only be assigned to STRUCTURAL object classes.
> Also DIT structure rules and name forms only work with this kind of object
> class.  And yes, I'm using all these schema elements. ;-)
> 
> > If it were an auxiliary I might be able to add it to a groupOfEntries
> > object to turn it into a posix group at a later time, that would be
> > nice.
> 
> Yes, I know. But please take note of Kurt's recent statements about IANA
> considerations for NAME 'posixGroup' etc.
> => when using NAME posixGroup anywhere the object class must be STRUCTURAL

Understood, all makes sense.

Simo.