Re: [ldapext] New LDAPEXT charter

[" Mark R Bannister " <[e-mail]>]

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" <[e-mail]>
To: "Michael Ströder" <[e-mail]>
Cc: "Mark R Bannister" <[e-mail]>, "ldapext" <[e-mail]>
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