Subject: [ldapext] New LDAPEXT charter

From: Mark R Bannister <[email-masked]>
Date: Wed, 18 Nov 2015 16:01:04 +0000

Hi,

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?

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

Also, I understood from last week that RFC2307bis will be on the 
charter, 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.  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.

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.

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.

Thanks & regards,
Mark Bannister.

---

From: Sean Leonard <[email-masked]>
Date: Wed, 18 Nov 2015 08:20:33 -0800

> list for those discussions, or is a new mailing list being set-up?

Yes, this will continue to be the mailing list for those discussions. 
(Note that I am one participant, not even a charter author or anything, 
and therefore only have one vote.)

If you find out any information to the contrary, please post it to this 
list so people can migrate elsewhere.

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

Haven't seen a thing.

Sean

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 18 Nov 2015 17:34:31 +0000

On 18/11/2015 16:20, Sean Leonard 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?

Apologies, of course I meant "last week" not "next week".

> (Note that I am one participant, not even a charter author or 
> anything, and therefore only have one vote.)
>
> If you find out any information to the contrary, please post it to 
> this list so people can migrate elsewhere.

Hence the point of my question.

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

Indeed, nor have I except for the brief discussion at LDAPCon.  I'm 
hoping that Ludovic or Howard will chime in.

Thanks,
Mark.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 18 Nov 2015 21:47:57 +0100

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

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

---

From: Mark R Bannister <[email-masked]>
Date: Thu, 19 Nov 2015 12:25:35 +0000

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

Time to wake up now, Ludo.  :-)

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

> Follow the references and you will also find many more docs describing the

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!

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

> the list of WG work items. I would like to base it on overhaul of RFC 2307

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

> 2. develop an independent DBIS implementation

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.

---

From: Chris Ridd <[email-masked]>
Date: Thu, 19 Nov 2015 12:45:36 +0000

On 19 Nov 2015, at 12:25, Mark R Bannister <[email-masked]> wrote:
> 
> 2. Is the bit I still don't understand.  Where is this rule written down?

I believe this is currently described in RFC 6410.

Chris

---

From: Mark R Bannister <[email-masked]>
Date: Thu, 19 Nov 2015 13:14:31 +0000

> I believe this is currently described in RFC 6410.

Excellent, thanks Chris, that's exactly what I'm looking for.

Mark.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 19 Nov 2015 22:57:23 +0100

Disclaimer: All my statements herein are solely my personal point of view.

Mark R Bannister wrote:
> 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.

Yes, that's my understanding too.

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

RFC2307bis in this form seems dead. But my multi-SUP solution for 'posixGroup'
simply works backwards-compatible.

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

The problem with RFC 2307 is not that it's experimental.
The problem is that there are issues considered real flaws with 'posixGroup'
being one of them.

> Indeed, and I followed Kurt's advice as given in msg02081 above, hence Barry's
> intervention.

Understood.

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

It's not an issue with the IETF in general. You simply have to convince
potential ldapext WG co-workers to work and support DBIS in some way. Their
support and contributions and WG consensus then would convince the IETF to
accept it to be published on standard tracks.

Ciao, Michael.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Nov 2015 12:26:32 -0500

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

> 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