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

Michael Ströder <michael@stroeder.com> Wed, 11 February 2015 11:24 UTC

Return-Path: <michael@stroeder.com>
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 01C921A1B61 for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 03:24:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Tj84Y3mgPsze for <ldapext@ietfa.amsl.com>; Wed, 11 Feb 2015 03:24:55 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2431A017F for <ldapext@ietf.org>; Wed, 11 Feb 2015 03:24:55 -0800 (PST)
Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id 8517F1CF9B; Wed, 11 Feb 2015 11:24:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id B43831D36D; Wed, 11 Feb 2015 11:24:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at stroeder.local
Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxlqOfZEIt3j; Wed, 11 Feb 2015 11:24:42 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 38A841D251; Wed, 11 Feb 2015 11:24:40 +0000 (UTC)
Message-ID: <54DB3BF8.7000909@stroeder.com>
Date: Wed, 11 Feb 2015 12:24:40 +0100
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32.1
MIME-Version: 1.0
To: Simo <s@ssimo.org>
References: <54DB27C7.3060409@stroeder.com> <1423653002.11010.62.camel@ssimo.org>
In-Reply-To: <1423653002.11010.62.camel@ssimo.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030901000509020401050705"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/br9OJaND6kRBXnAcX_d_11HDEvA>
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
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:24:58 -0000

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

Ciao, Michael.