Subject: [ldapext] LDAP work at IETF...

From: Ludovic Poitou <[email-masked]>
Date: Sun, 25 Jan 2015 21:36:00 +0100

Hi Everyone,

Over the years, there has been a number of documents related to the Lightweight Directory Access Protocol (LDAP) that have been left unfinished or are slowly progressing.  

There are a number of individuals that have interest in re-forming an IETF Working Group around LDAP to finish some of the work and make them on the Standard Track. Howard Chu and I are ready to lead that effort.  

I’d like to poll the audience of this mailing list on the interest of seeing this progressing. I would also like to hear about volunteers to work on those documents, either contributing text or reviewing them carefully.  

Please find below the list of documents that have been considered for the working group to finalise and get published (in no specific order):  

draft-findlay-ldap-groupofentries  
draft-stroeder-namedobject  
draft-stroeder-hashed-userpassword-values (informational
draft-stroeder-mailboxrelatedobject  
RFC2307bis  
draft-behera-ldap-password-policy  
inetOrgPerson 2.0  

Ludovic  

--  
Ludovic Poitou
http://ludopoitou.wordpress.com

---

From: Gavin Henry <[email-masked]>
Date: Sun, 25 Jan 2015 20:40:55 +0000

> I would also like to hear about volunteers to work on those documents, either contributing text or reviewing them carefully.

I would like to help where I can.

Thanks.

-- 
Kind Regards,
Gavin Henry.

---

From: Michael Ströder <[email-masked]>
Date: Sun, 25 Jan 2015 22:03:35 +0100

> I would like to help where I can.

Glad to here that. Do you have any particular interest.

Everybody can start reviewing existing stuff.  Which could also mean that you
simply ask questions if something is not clear enough.

For inetOrgPerson 2.0 it would help if we collect a wish list and then compile
a realistic requirement list from that.

Ciao, Michael.

---

From: Clément OUDOT <[email-masked]>
Date: Sun, 25 Jan 2015 22:55:33 +0100

> a realistic requirement list from that.

Hi,

I am also volunteer to help, especially on the password policy draft.

Clément OUDOT.

---

From: Michael Ströder <[email-masked]>
Date: Sun, 25 Jan 2015 23:06:56 +0100

> I am also volunteer to help, especially on the password policy draft.

Would you be willing to act as an editor?

If yes, then simply start a new e-mail thread.

A good start would be to agree on a goal.

IMHO we should try to mainly document current state of implementations of
draft-behera-ldap-password-policy, but also have a closer look on Appendix A
of http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00

Digging the list archives could also help here.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Mon, 26 Jan 2015 19:16:17 +0000

> There are a number of individuals that have interest in re-forming an IETF Working Group around LDAP to finish some of the work and make them on the Standard Track. Howard Chu and I are ready to le…

Excellent!

> I’d like to poll the audience of this mailing list on the interest of seeing this progressing. I would also like to hear about volunteers to work on those documents, either contributing text or rev…

Count me in, particularly for groups and mail-related objects.
Note that there is some overlap between the groups work and later
drafts of RFC2307bis. I would like to see groups factored out into
a separate document as it has wider implications.

I can see some conflict developing between 'do it right' and 'document
current practice' - particularly in 2307bis, password policy, and
inetOrgPerson. This probably needs resolving early as it has potential
to derail the effort later. One option is to do both - possibly in
separate documents.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

---

From: Michael Ströder <[email-masked]>
Date: Mon, 26 Jan 2015 20:55:01 +0100

> Count me in, particularly for groups and mail-related objects.

Great!

> drafts of RFC2307bis.

Yes.

> I would like to see groups factored out into

+1

> current practice'

Yes. That's why I said we have to agree on goals for each of these.

Ciao, Michael.

---

From: Mark R Bannister <[email-masked]>
Date: Tue, 27 Jan 2015 12:03:06 +0000

> draft-behera-ldap-password-policy

Hi Ludovic,

The following internet drafts are intended to replace RFC2307 and 
RFC2307bis.  They were first released for review in August 2013, 
although lack of a working group left them largely unreviewed.  I did, 
however, receive many comments from this mailing list a year ago which I 
incorporated in later versions:

draft-bannister-dbis-mapping
draft-bannister-dbis-netgroup
draft-bannister-dbis-passwd
draft-bannister-dbis-hosts
draft-bannister-dbis-devices
draft-bannister-dbis-automounter
draft-bannister-dbis-custom

I have subsequently produced a reference implementation in Python, and 
we are close to having our first large-scale enterprise deployment of 
DBIS.  See http://dbis.sf.net

I would prefer to see RFC2307bis removed from the list to be considered 
above, and replaced by the DBIS drafts.

I am also very happy to volunteer my time to review or contribute 
further to the other documents you mention.

Please let me know.

Best regards,
Mark Bannister.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 27 Jan 2015 16:47:54 +0100

Mark R Bannister wrote:
> The following internet drafts are intended to replace RFC2307 and RFC2307bis. 
> [..]
> [..]
> I would prefer to see RFC2307bis removed from the list to be considered above,
> and replaced by the DBIS drafts.

This probably won't happen because there are so many RFC2307(bis) deployments
out there which cannot easily be migrated.

Also I have my own schema built on top of RFC2307bis (not published yet) which
differs much from DBIS for very good reasons. I aim to present it at LDAPcon
2015 in Edinburgh (in case the program comittee agrees). A preview version of
that is already in production for almost a year in a large data center.

So my suggestion would be to brush up RFC2307bis as much as possible (taking
care of Kurt's IANA comments) so that you can base DBIS on that, as I will
base my system on top of that.

How does that sound to you?

Ciao, Michael.

---

From: Mark R Bannister <[email-masked]>
Date: Tue, 27 Jan 2015 20:50:43 +0000

> out there which cannot easily be migrated.

DBIS supports maps defined in legacy RFC2307 or RFC2307bis format, as 
well as using the new format.  Migration is designed to be extremely 
easy.  In fact, it took me next to no time at all to start using 
directory entries defined in RFC2307 format from a DBIS installation, it 
really is just a matter of defining a few configuration maps that do the 
class and attribute remappings, and they are mostly standard.  See 
https://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/

> How does that sound to you?

DBIS is not a superset nor a child schema that inherits from RFC2307bis, 
nor is it built on top of RFC2307bis - it is a complete replacement and 
was designed as such.  RFC2307 and RFC2307bis can be completely retired 
and DBIS put in their place and there would be no omissions.  It's an 
evolution that began life by taking RFC2307bis and splitting it into 
logic units (separate internet drafts) that make for a less unwieldy 
document and make it easier for others to extend.  Then I standardised 
the client-side configuration, fixed some of the NIS incompatibilities 
that had been inherited from RFC2307, added a few much needed enterprise 
features, and that's it: a modern, modular, extensible, enterprise-ready 
RFC2307bis under another name ("2307bis" wasn't a very friendly name, 
after all, and I wasn't going to call my improvements "2307ter", but 
they could have been called that, because realistically that's what they 
are).

> How does that sound to you?

I don't see a reason to try to improve RFC2307bis, I think that would be 
a backwards step.  The improvements needed to RFC2307bis have already 
been made, I've done the work myself and named it "DBIS" because I 
couldn't wait for everyone else to catch-up, and I needed it last year 
:-)  I think if people started looking deeper into the DBIS internet 
drafts, making suggestions for improvement etc. we'd get to a much 
better end point than if you have people pore over RFC2307bis again.

Best regards,
Mark.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 27 Jan 2015 23:14:17 +0100

Mark R Bannister wrote:
> DBIS supports maps defined in legacy RFC2307 or RFC2307bis format, as well as
> using the new format.  [..]  See

It seems there was a misunderstanding, probably my wording wasn't clear enough:
The issue is that many LDAP *clients* are hard-coded to the RFC2307 or
RFC2307bis schema. The server's data can be IMHO way more easily migrated than
legacy client systems.

> DBIS is not a superset nor a child schema that inherits from RFC2307bis, nor
> is it built on top of RFC2307bis

Ok, I see.

> RFC2307 and RFC2307bis can be completely retired and DBIS
> put in their place and there would be no omissions.

Unfortunately, no.

> I think if people
> started looking deeper into the DBIS internet drafts,

I've looked into your drafts. But it differs very much from what I'm after. We
had this discussion before: IMO netgroups must die, die, die...

Ciao, Michael.

---

From: Mark R Bannister <[email-masked]>
Date: Tue, 27 Jan 2015 23:26:53 +0000

> RFC2307bis schema. The server's data can be IMHO way more easily migrated than

I don't see an issue with that.  Standards move on, old clients become 
legacy, and eventually they have to be weeded out.  Standards would 
never evolve if we could never cut the umbilical cord.  By the same 
token, NIS clients could not use RFC2307 because they were hard-coded to 
use NIS servers.  The latest standards are installed where the latest 
client installations are deployed.

At least DBIS gives you an option to mix old and new schemas.  You could 
start with new clients referring to old-style data.  Then you could 
introduce extra new-style data on the side that is only available to the 
new clients, and eventually phase out the old clients.  That is not an 
option with RFC2307bis.

>> put in their place and there would be no omissions.

 From a client perspective, yes.  An RFC2307/RFC2307bis client can be 
converted to a DBIS client using the old-style schema as described 
above.  DBIS simplifies migration.

> had this discussion before: IMO netgroups must die, die, die...

This contradicts your earlier assertion that clients are hard-coded.  In 
the same vein, clients are hard-coded to use netgroups, ergo netgroups 
cannot "die, die, die".  Actually a year ago you wrote, and I quote:

"Personally I also avoid netgroups (or I don't have a real use-case for 
them for now)."

... which is a lot more passive than "die, die, die".

Rather than attempting to kill off something that is used extensively, 
and has actually proved to be very useful in large UNIX/Linux estates 
(if a bit clunky), I've embraced them, rationalised them, defined them 
in a neater and queryable format, and complemented them with netservices.

Apart from netgroups, which you are not a fan of, how else does DBIS 
differ from what you're after?  I've made numerous updates to the 
internet drafts in the year since we last exchanged emails about it, 
many of those updates inspired by comments I received then, so what is 
remaining on your wish-list that I did not address?

Best regards,
Mark.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 28 Jan 2015 18:51:39 +0100

Mark R Bannister wrote:
> This contradicts your earlier assertion that clients are hard-coded.  In the
> same vein, clients are hard-coded to use netgroups, ergo netgroups cannot
> "die, die, die".

No contradiction, since IMO one can easily avoid using netgroups completely.

With my approach the ACLs on the LDAP server sort out what clients can
actually see. Therefore you get the flexible access control without the client
having to enforce e.g. login access control locally based on netgroups.

> Rather than attempting to kill off something that is used extensively, and has
> actually proved to be very useful in large UNIX/Linux estates (if a bit
> clunky), I've embraced them, rationalised them, defined them in a neater and
> queryable format, and complemented them with netservices.

I'd avoid them and convert access control rules based on netgroups into
another schema and let the LDAP server's ACL work through the data.

> Apart from netgroups, which you are not a fan of, how else does DBIS differ
> from what you're after?

My main objective is that not the client system evaluates all the stuff. The
client system should not see data not usable on the system. The client system
acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system
still enforces file access permissions etc. locally.

Ciao, Michael.