Re: [ldapext] New LDAPEXT charter

Barry Leiba <barryleiba@computer.org> Fri, 20 November 2015 17:26 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 5E4041B39B4 for <ldapext@ietfa.amsl.com>; Fri, 20 Nov 2015 09:26:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.921
X-Spam-Level:
X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 VUole_c5oKDg for <ldapext@ietfa.amsl.com>; Fri, 20 Nov 2015 09:26:33 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349BA1B39B2 for <ldapext@ietf.org>; Fri, 20 Nov 2015 09:26:33 -0800 (PST)
Received: by iouu10 with SMTP id u10so132498639iou.0 for <ldapext@ietf.org>; Fri, 20 Nov 2015 09:26:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EaJSsTZUUekdSw0YEFKU558CpTDAb8OIIAop//mfhzI=; b=mh3HQU2Y1HiXmHauApFXU+woVaPQs8N3plH3oRySFfMyqZTylbcmiThI7NwSLoDUdj y0mUCgUsDkpNhuDRfNtB3Nr+YzxHh4pbksnZom7AlqgXHgsCTKFxUVruGK1nxDS0Nc7x gAG/RMVXVq9P1jSjFixryE3/PkketybG0YdTvePEfAWji22KwRS6fi1dUHnDG5kthdaO URsubYHS0dy+wgo24T9tzmqp+kWFlcIELL/zL8ZGpFlbsSM7RCnvxdD7Ydb2z7fDX0Yl WIKB50SCUEupwQIKQcFw239MKNmZQOyb13MaMuOk3UjMyzgy/OncytGrISxtfX39JSXz Xp+A==
MIME-Version: 1.0
X-Received: by 10.107.28.144 with SMTP id c138mr15184675ioc.15.1448040392611; Fri, 20 Nov 2015 09:26:32 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.107.181.202 with HTTP; Fri, 20 Nov 2015 09:26:32 -0800 (PST)
In-Reply-To: <564CE3FD.2030704@stroeder.com>
References: <564CA0C0.9010400@proseconsulting.co.uk> <564CE3FD.2030704@stroeder.com>
Date: Fri, 20 Nov 2015 12:26:32 -0500
X-Google-Sender-Auth: 1MzdfnSdU3WqgkqQv6c2OtZQIY4
Message-ID: <CAC4RtVAiQgSiCR720oBB99ju7Z6Ctk28ooM49GPjj=0Wf4ydYw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: =?UTF-8?Q?Michael_Str=C3=B6der?= <michael@stroeder.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/2y330cFtoBp4RU7YH06DDKxzRho>
Cc: ldapext <ldapext@ietf.org>
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: Fri, 20 Nov 2015 17:26:34 -0000

Here to clarify process:

>> 1. There is only a single implementation.
...
>> I'm a bit puzzled by (1), as I'm sure there are RFCs based on single
>> implementations.
...
> 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.

Indeed, it's puzzling, because working groups and technical areas vary
with regard to what's important for that work or technical area.  RFC
6410 re-defines the "Standards Track" into two levels (down from
three): Proposed Standard and Internet Standard.  It's the latter for
which we need multiple deployed implementations to give evidence of
both utility and interoperability.  For Proposed Standard, there is no
requirement for that -- no requirement, in fact, for any
implementations at all.  It's a proposal.

That said, there's not much use in a proposed standard that no one
wants to implement, and we've found that the best proposals are those
that are developed in parallel with implementations, having the
development of the specification and the code feed back on each other,
with interoperability testing along the way.

See RFC 6982 for one proposal for documenting implementations as the
draft is developing.  I strongly support that mechanism.

> 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

Exactly.  (1) is, of course, necessary for any work to proceed in any
working group.  While (2) is not strictly necessary according to RFCs
2026 and 6410, it's reasonable for a working group (and/or an Area
Director) to push for that in order to demonstrate that people are
sufficiently interested in the work to move it toward implementation
and deployment, and to improve the specification as I mentioned above,
by finding the bugs, gaps, and implementation problems early, before
the spec is published.

I would not want to see artificial road blocks being put up against
anyone's proposal.  At the same time, in order to proceed with any
proposal there do need to be enough people interested in working on it
to get it done and to make it a useful product of the working group.

Barry, ART Area Director