Re: [ldapext] New LDAPEXT charter
" Mark R Bannister " <dbis@proseconsulting.co.uk> Tue, 24 November 2015 07:29 UTC
Return-Path: <dbis@proseconsulting.co.uk>
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 DB7A01A0204 for <ldapext@ietfa.amsl.com>; Mon, 23 Nov 2015 23:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.08
X-Spam-Level: **
X-Spam-Status: No, score=2.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 6Oz5zRk4Cyjs for <ldapext@ietfa.amsl.com>; Mon, 23 Nov 2015 23:29:48 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.141]) by ietfa.amsl.com (Postfix) with ESMTP id 305421A01A3 for <ldapext@ietf.org>; Mon, 23 Nov 2015 23:29:47 -0800 (PST)
Received: from dab-glb1-h-40-6.dab.02.net ([82.132.218.105] helo=[10.65.91.166]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1a182q-0008Sf-I7; Tue, 24 Nov 2015 07:29:46 +0000
To: Barry Leiba <barryleiba@computer.org>, Michael Ströder <michael@stroeder.com>
From: Mark R Bannister <dbis@proseconsulting.co.uk>
Date: Tue, 24 Nov 2015 07:29:44 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_0_1448350184254"
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Message-Id: <20151124072948.305421A01A3@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/lJXAhULcDjmpzXcztFHxianKq7k>
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: Tue, 24 Nov 2015 07:29:51 -0000
Thanks for the clarification, Barry.> For Proposed Standard, there is no > requirement for that -- no requirement, in fact, for any > implementations at all. It's a proposal. Ok, then I've trumped that, as I have an implementation already. > > 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 (1) should be possible. Is there an official process a reviewer needs to follow, in order to count as a reviewer for this purpose? (2) seems to contradict your first point about a Proposed Standard not even needing an implementation. Please help me understand this. It is either required or not required in my case? Many thanks, Mark. ----- Reply message ----- From: "Barry Leiba" <barryleiba@computer.org> To: "Michael Ströder" <michael@stroeder.com> Cc: "Mark R Bannister" <dbis@proseconsulting.co.uk>, "ldapext" <ldapext@ietf.org> Subject: [ldapext] New LDAPEXT charter Date: Fri, Nov 20, 2015 17:26 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
- [ldapext] New LDAPEXT charter Mark R Bannister
- Re: [ldapext] New LDAPEXT charter Sean Leonard
- Re: [ldapext] New LDAPEXT charter Mark R Bannister
- Re: [ldapext] New LDAPEXT charter Michael Ströder
- Re: [ldapext] New LDAPEXT charter Mark R Bannister
- Re: [ldapext] New LDAPEXT charter Chris Ridd
- Re: [ldapext] New LDAPEXT charter Mark R Bannister
- Re: [ldapext] New LDAPEXT charter Michael Ströder
- Re: [ldapext] New LDAPEXT charter Barry Leiba
- Re: [ldapext] New LDAPEXT charter Mark R Bannister
- Re: [ldapext] New LDAPEXT charter Barry Leiba
- Re: [ldapext] New LDAPEXT charter Mark R Bannister