Re: [ldapext] New LDAPEXT charter

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

On 18/11/2015 20:47, Michael Ströder wrote:
> 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.

Good to hear it.

>
>> When will the new charter be published for all to see and comment on?
> Ludo....! ;-)

Time to wake up now, 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.

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.  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.  So let's not cry over spilt milk, let's move on and 
embrace DBIS!! (Ok I'm stirring trouble here, and I'm biased, but I have 
a valid point).

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

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.  I do want DBIS to become a proper ratified standard, 
and for that to happen, as Kurt said in his posting in December last 
year, I need the advice of an area director.  I approached Barry Leiba 
on this very subject in August, and it is partly because I approached 
him that the LDAP working group is being kick-started again.  But with 
DBIS off the agenda!

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

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

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

1. Is not hard to do, I think I could find people.
2. Is the bit I still don't understand.  Where is this rule written 
down?  I'm all for due process, and I can work with due process, esp. if 
it is well documented, but at the moment I feel that people are just 
shifting goal-posts to keep DBIS out.

Best regards,
Mark.