Re: [ldapext] New LDAPEXT charter

Michael Ströder <michael@stroeder.com> Wed, 18 November 2015 20:48 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 5C3BC1B2E3C for <ldapext@ietfa.amsl.com>; Wed, 18 Nov 2015 12:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtZUPmBK2uHc for <ldapext@ietfa.amsl.com>; Wed, 18 Nov 2015 12:48:04 -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 947D41B2E39 for <ldapext@ietf.org>; Wed, 18 Nov 2015 12:48:03 -0800 (PST)
Received: from srv4.stroeder.local (unknown [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" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 852EA1CED7; Wed, 18 Nov 2015 20:48:00 +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 9AA281D410; Wed, 18 Nov 2015 20:47:57 +0000 (UTC)
To: Mark R Bannister <dbis@proseconsulting.co.uk>, ldapext <ldapext@ietf.org>
References: <564CA0C0.9010400@proseconsulting.co.uk>
From: Michael Ströder <michael@stroeder.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <564CE3FD.2030704@stroeder.com>
Date: Wed, 18 Nov 2015 21:47:57 +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: <564CA0C0.9010400@proseconsulting.co.uk>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030107010805080808030304"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/U7FNfaM3MAT-eGJ8SBtCXkrdvXY>
Subject: Re: [ldapext] New LDAPEXT charter
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Nov 2015 20:48:06 -0000

Mark R Bannister wrote:
> Further to the announcement of the new LDAPEXT charter at LDAPCon next week,
> please can I confirm that this will continue to be the mailing list for those
> discussions, or is a new mailing list being set-up?

AFAICS up to now this will be *the* mailing list. I'd notify everybody here if
that would have to be changed due to IETF preferences.

> When will the new charter be published for all to see and comment on?

Ludo....! ;-)

> Also, I understood from last week that RFC2307bis will be on the charter,

Personally I see on charter simple solutions for common issues with
RFC2307bis, probably not a complete overhaul of RFC 2307.

> but DBIS (which is intended as its replacement) will not be, and the
> reasons given were:
> 
> 1. There is only a single implementation.
> 2. It would take more than a year to complete.
> 
> I'm a bit puzzled by (1), as I'm sure there are RFCs based on single
> implementations.

The term "RFC" is a bit blurry here. Starting here:

https://tools.ietf.org/html/rfc2418#section-7.3

   NOTE: The RFC series is a publication mechanism only and publication
   does not determine the IETF status of a document.  Status is
   determined through separate, explicit status labels assigned by the
   IESG on behalf of the IETF.  In other words, the reader is reminded
   that all Internet Standards are published as RFCs, but NOT all RFCs
   specify standards [4].

[4] Not All RFCs are Standards
    https://tools.ietf.org/html/rfc1796

Follow the references and you will also find many more docs describing the
various tracks etc.

> However, clarification of that rule will be helpful.  It
> will be very hard to convince others to produce their own software
> implementations of DBIS if the reference implementation already available does
> the job, so I'm not sure I understand the purpose of the rule.

Simple explanation:
If you try to reach standards track two independent implementations are needed
to prove interoperability. Maybe some IETF experts around could give you more
detailed advice if needed.

Kurt already gave us some good advice regarding all this in the near past:

https://www.ietf.org/mail-archive/web/ldapext/current/msg01951.html

https://www.ietf.org/mail-archive/web/ldapext/current/msg02081.html

https://www.ietf.org/mail-archive/web/ldapext/current/msg02053.html

> 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.

> I am in conversation at the moment with others regarding further features that
> could be introduced into DBIS to make it even better, I hope to bring those
> conversations to this mailing list soon, as I would be very interested in
> soliciting more opinions on this subject.

If you want to DBIS within IETG WG this you have to find people willing to

1. work on you on the documents as co-authors or at least reviewers

2. develop an independent DBIS implementation

Ciao, Michael.