Re: [ldapext] why posixAccount MUST contain 'cn'?

Michael Ströder <michael@stroeder.com> Sun, 14 December 2014 22:49 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 0CF4D1A0334 for <ldapext@ietfa.amsl.com>; Sun, 14 Dec 2014 14:49:51 -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 jTPe9bn7OHOW for <ldapext@ietfa.amsl.com>; Sun, 14 Dec 2014 14:49:49 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8D31A0217 for <ldapext@ietf.org>; Sun, 14 Dec 2014 14:49:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 34380602E3; Sun, 14 Dec 2014 23:49:46 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZAOvg3nQTjm; Sun, 14 Dec 2014 23:49:38 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 3D1706027E; Sun, 14 Dec 2014 22:49:38 +0000 (UTC)
Message-ID: <548E13FF.7070103@stroeder.com>
Date: Sun, 14 Dec 2014 23:49:35 +0100
From: Michael Ströder <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version: 1.0
To: Kurt Zeilenga <kurt.zeilenga@isode.com>
References: <548DB67C.5060009@stroeder.com> <CF47C8D4-038D-4232-96F8-5EDE3A62C7D2@isode.com> <548DCA51.7080002@stroeder.com> <778E83EE-875A-486A-8A98-6DF3C309C292@isode.com> <548DE82E.3010103@stroeder.com> <5C9BE5D8-44CA-4CFC-9D63-36C702391B87@isode.com> <548DF0E9.6080405@stroeder.com> <B9B85122-D283-4B88-A3E7-F0B023795961@isode.com>
In-Reply-To: <B9B85122-D283-4B88-A3E7-F0B023795961@isode.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms090106050105090800000502"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/1FHo1Zmevaeed5agUw5P5TYa_cM
Cc: ldapext@ietf.org
Subject: Re: [ldapext] why posixAccount MUST contain 'cn'?
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: Sun, 14 Dec 2014 22:49:51 -0000

Kurt Zeilenga wrote:
> 
>> On Dec 14, 2014, at 12:19 PM, Michael Ströder <michael@stroeder.com> wrote:
>>
>> Kurt Zeilenga wrote:
>>>
>>>> On Dec 14, 2014, at 11:42 AM, Michael Ströder <michael@stroeder.com> wrote:
>>>>
>>>> Kurt Zeilenga wrote:
>>>>>
>>>>>> On Dec 14, 2014, at 9:35 AM, Michael Ströder <michael@stroeder.com> wrote:
>>>>>>
>>>>>> Kurt Zeilenga wrote:
>>>>>>>> I'd be in favour of relaxing this to MAY cn in RFC2307bis.
>>>>>>>
>>>>>>> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing previously published schema definitions.
>>>>>>
>>>>>> Yes, but RFC2307bis also changes posixGroup schema.
>>>>>
>>>>> Don’t expect I-Ds which violate BCPs to become RFCs.
>>>>
>>>> Are you saying that draft-howard-rfc2307bis will never become an RFC because
>>>> it changes the declaration of 'posixGroup' ('member' instead of 'memberUID')
>>>> defined in the experimental RFC 2307?
>>>
>>> I won’t say “never” as well BCPs themselves are subject today…   but I can
>>> tell you that I, as the IESG’s appointed LDAP registries expert to IANA,
>>> have and will reject requests to register LDAP parameters which purport to
>>> modify previously published LDAP schema definitions.  Of course, such
>>> actions are appealable.
>>
>> So RFC2307bis must start over with completely new NAMEs
>> for e.g. posixGroup?
> 
> Yes, as posixGroup has already been published, if you don’t want to use it
> as published, you need to create a replacement for it… and that replacement
> has to have a new OID and a new NAME.

Hmm, I respect that decision and thanks for the clear words.

But it's clearly a problem with all the existing NSS LDAP client
implementations/deployments which already use RFC2307bis posixGroup>member
draft schema.

So the question is: How to correctly push that forward?

Some more nitpicking:
The RFC 2307 defined OIDs are not listed here only the base OID:
http://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml

Ciao, Michael.