Re: [ldapext] New LDAPEXT charter

Michael Ströder <> Thu, 19 November 2015 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9ECB71B361B for <>; Thu, 19 Nov 2015 13:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0akzasZ3hGe0 for <>; Thu, 19 Nov 2015 13:57:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4BC61B2EDD for <>; Thu, 19 Nov 2015 13:57:29 -0800 (PST)
Received: from srv4.stroeder.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer " Server CA no. 2009-07" (verified OK)) by (Postfix) with ESMTPS id 01FA41CED7; Thu, 19 Nov 2015 21:57:26 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local []) (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 4469C1D410; Thu, 19 Nov 2015 21:57:24 +0000 (UTC)
To: Mark R Bannister <>, ldapext <>
References: <> <> <>
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 19 Nov 2015 22:57:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090206060002050303020103"
Archived-At: <>
Subject: Re: [ldapext] New LDAPEXT charter
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 21:57:32 -0000

Disclaimer: All my statements herein are solely my personal point of view.

Mark R Bannister wrote:
> I understood from previous exchanges with Kurt that RFC2307bis couldn't be
> standardised as it stands because it attempts to redefine attributes or
> classes from RFC2307, and you're not allowed to do that.

Yes, that's my understanding too.

> However, if people
> are already using RFC2307bis then you'll be in a catch-22 situation, not being
> able to fix those problems without breaking it for existing users.  Ergo,
> RFC2307bis is dead in my opinion and will never be a standard.

RFC2307bis in this form seems dead. But my multi-SUP solution for 'posixGroup'
simply works backwards-compatible.

> Thanks Michael, I'm aware of all of the various tracks, but wouldn't want DBIS
> to fall into the same trap as RFC2307 did, being released as "experimental"
> but then being adopted everywhere, then being a real pain to fix up later.

The problem with RFC 2307 is not that it's experimental.
The problem is that there are issues considered real flaws with 'posixGroup'
being one of them.

> Indeed, and I followed Kurt's advice as given in msg02081 above, hence Barry's
> intervention.


>>> Re (2), given the internet drafts are already written and the reference
>>> implementation is complete and fully functional, I fail to see where the
>>> evidence comes from that suggests it will take more than 1 year to complete?
>>> Can you please provide a breakdown of the steps that would be involved and why
>>> you think DBIS will take more than 1 year.
>> As I understand (2) it's generally hard to reach WG consensus on complex
>> documents. BTW: For this particular reason I will *not* try to add my Æ-DIR to
>> the list of WG work items. I would like to base it on overhaul of RFC 2307
>> details though.
> Accepted, design by committee doesn't work.  But IETF working groups are not
> supposed to be designs by committee.  You speak of complex documents, but I
> don't see that the DBIS documents as complex, I think that is a rather
> subjective label.  Define complex?  I would be happy to make it less complex
> if people could suggest what they think is currently complicated about it.  If
> the IETF is unable to work with documents of the size of DBIS, then something
> is broken in the process I think, because each individual DBIS document is a
> lot smaller than RFC2307 (which I broke up to make it more manageable!).

It's not an issue with the IETF in general. You simply have to convince
potential ldapext WG co-workers to work and support DBIS in some way. Their
support and contributions and WG consensus then would convince the IETF to
accept it to be published on standard tracks.

Ciao, Michael.