Re: [ldapext] DBIS commentary

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

Hi Jordan,

This is all excellent feedback, thanks, I really appreciate the time you have taken to provide your
comments.  Many of the points you raise I did spend a long time considering myself when I was
writing the internet drafts, so I hope to provide you with more insight into my rationale and why
I decided to do things the way I did.

I hope you don't mind but I'm copying it to the ldapext mailing list, so that others can also
comment if they wish.  For others, Jordan is commenting from the DBIS/RFC2307
schema comparison and not directly from the internet drafts:

http://sourceforge.net/p/dbis/wiki/DBIS%20and%20RFC2307%20schemas/

Jordan Brown wrote:
> High-level comments:
> - In general, our direction is towards X.500 compatibility and Active Directory compatibility.  I would
>   resist new mechanisms that duplicate those.
> - As noted in more detail below, I consider case-insensitive processing to be the correct direction and
>   would resist moves towards case sensitivity.
> - Some of the mechanisms here (e.g. gecos mapping) seem to duplicate RFC 4876 profiles.

Thanks for the summary, I'll answer these points individually as I get to them below.

> 
> Footnote 1 says that published classes may not be redefined. Although not all changes seem permissible,
> some changes (e.g. addition of MAY elements) seem like they could be allowed.  Is there a reference for
> this restriction?  Note that between X.521-1993 and X.521-2012 the TelecommunicationAttributeSet had
> an attribute deleted.

I haven't looked for a reference to this restriction, I had learned it from seeing previous exchanges
on the ldapext mailing list with Kurt Zeilenga.  Here is one such exchange, regarding changing the
schema declaration of 'posixGroup' in RFC2307bis:

https://www.ietf.org/mail-archive/web/ldapext/current/msg02072.html

>
> posixAccount / posixUserAccount
> 
> en:  I consider the change from a case-sensitive name in NIS to a case-insensitive name in LDAP to be an
> improvement that should not be reversed.  It is telling that (a) there are no cases in the industry other
> than UNIX user names where user names are case sensitive, (b) that there are numerous examples in
> the industry of treating the left side of an e-mail address as case-insensitive, and (c) the X.520 "name"
> attribute, the base attribute for all naming, is case-insensitive.

NIS was case sensitive.  That led some firms to put entries in various maps that were the same except
for case.  I have examples here where this occurs in the passwd, group, netgroup and services maps.
Changing these entries would be a) very difficult indeed to the point of insurmountable as they've
been ingrained in many systems in a very large enterprise for over a decade and b) unnecessary had
the RFC2307 schema been 100% backwards compatible with NIS.  I explain this rationale further in my
DBIS paper:

http://ldapcon.org/2015/wp-content/uploads/2015/09/DBIS-Paper-2015.pdf

We had a few choices.  The one which we used for the past few years was to define our own custom
schema.  We had to invent three new custom attributes and seven new custom object classes to
get around this limitation.  It infuriated me that we couldn't use RFC2307 out-of-the-box because it
was not 100% compatible with the NIS schema, and this was one of the primary driving forces
behind me starting DBIS.

DBIS is my stake in the ground to say we MUST solve this problem.  I hear what you're saying,
but your arguments for case insensitivity disregard that UNIX is primarily a case-sensitive
operating system and that NIS was also case-sensitive.  Frankly, as RFC2307 was supposed to
be primarily getting NIS data into LDAP, it failed tremendously by bending to the Windows/AD
case insensitivity preferences.  UNIX will not change.  It will always be case sensitive.  Therefore
we need an LDAP schema that will respect that.

I hope this doesn't mean we end up with one schema for UNIX and one for Windows, perhaps
we can be creative, for example, encouraging Windows software to force all characters to
lowercase before adding entries to LDAP and constructing search filters, although this will
probably be prone to breakage.  Or perhaps we can define some special attributes where case
is handled differently depending on the capability of the client.  If the client claims it is
case sensitive, these special attributes are handled case sensitively, and vice versa if the client
claims it is case insensitive.  I see case sensitivity as an issue that will prevail forever, in the
same way that endianness will differ between architectures; they will never converge and
so we should not be accepting standards that do not provide a solution for both types.

>
> authPassword:  Imported from RFC2307bis-02 and thence from RFC 3112.  Partially, but only partially,
> duplicates userPassword (from X.509 via RFC2307).  Appears to completely duplicate userPwd (also
> from X.509).  May also duplicate encryptedUserPassword, mentioned in X.520 but not defined
> anywhere that I can find.

I added authPassword simply because I wanted those using RFC2307bis to be able to migrate
seamlessly to DBIS.  I made it clear in the drafts that there are better and more secure ways to store
passwords and these should be used in preference - authPassword was provided for backwards
compatibility only.

If you have an issue with authPassword being in RFC2307bis, now is the time to raise it, as it
is on the new LDAPEXT charter and the WG are planning to finalise RFC2307bis in the
next 12 months and give it its own RFC number.

>
> gecos:  Removed in DBIS with no explicit replacement.  DBIS recommends using its mapping capabilities
> to map gecos onto some other attribute, e.g. displayName.  While eliminating gecos seems desirable
> (as an unnecessarily UNIX-specific attribute), it seems desirable to explicitly specify a replacement
> rather than to rely on custom mapping.  (Note also that some implementations have encoded
> additional information, e.g. telephone number, into the gecos field.  This seems like an undesirable
> overloading of the schema.)

LDAP is so much better at representing all kinds of random information than NIS was, and the passwd
flat-text file.  Just because there was a random "throw in any information you like" including an
implied encouragement in Sun Microsystems' training courses to include telephone information
in the gecos field, does not mean that when you move to a much more structured system such
as LDAP you have to keep the general purpose nonsense.  If you want to encode a telephone number, 
there is an attribute for that.  If you want a surname, or a first name, there are attributes for that
too.  "Gecos" is not a unique piece of information, it is a container for an assortment of data, which
will differ from one firm to the next.  The equivalent to "gecos" is an LDAP object.

>
> description:  Removed from explicit mention in DBIS, but inherited from Person if inetOrgPerson is
> used as the base class.  Not clear how it fits into the UNIX/NIS schema.

I removed it because I saw no purpose for it on a passwd entry, and as you say you can get it
back again if you include another auxiliary class which you probably want to do
anyway to have something to map gecos to.

>
> Structural User Account:  changes from "account" (RFC 4524) to "inetOrgPerson" 
> (RFC 2798).  While this is an obvious simplification, it does not seem correct.  
> An account may be associated with more than one person, and one person may be associated with
> more than one account.  (However, associating it with "account" 
> leaves it unclear where to collect a gecos/display name, except perhaps
> "description".)

Quite, "account" doesn't have a field where you can sensibly put the descriptive
name of the user, whereas inetOrgPerson does.  In a previous project where we
were migrating NIS to AD, we used displayName to hold the contents of the
gecos field, and that is what swayed my choice of inetOrgPerson here.

> 
> posixGroup / posixGroupAccount
> 
> X.521 groupOfNames seems like a more appropriate basis for the definition of a group.

But that doesn't allow for GID number.

> 
> en:  See above.

Reply above.

> 
> exactUser:  Ties into the case-sensitivity question.  If case-insensitive, "memberUid" is reasonably
> appropriate, because in the LDAP world "uid" means "login name".

"uid" meaning "login name" is a really bad choice.  I've always thought that, and I've pushed to get
away from it in DBIS.  UID is a number, it should always be a number, why anyone thought it would
be a good idea for that to actually be a name escapes me.  I've discussed the case sensitivity
issue already, and I called this "exactUser" to follow-on from the idea of exact case, and to
follow a similar line as "exactName" (en).

>
> manager:  although not inappropriate, X.520 "owner" seems more appropriate.  (And note that
> groupOfNames includes "owner".)

As "manager" was already in RFC2307/2307bis for host and network entries, I just expanded
the support to many other entries, as it seemed a sensible thing to do.  Having some entries
use "owner" and some use "manager" would be wrong, removing "manager" from
host and network entries would add an unnecessary step when migrating from an RFC2307
to a DBIS schema, and allowing both "owner" and "manager" seems excessive.

>
> nisNetgroup / netgroupObject
> 
> Although not a perfect match, groupOfNames seems like it might be a better basis for
> grouping computers.

netgroups are a specific construct, trying to squeeze them into something else that is
not a perfect match would be a suboptimal decision.  LDAP can represent netgroup
data better, so let's represent it better.

>
> All of the changes here seem to relate to issues described above.
> 
> ipService / ipServiceObject
> ipProtocol / ipProtocolObject
> 
> The changes here all appear to be similar to those described above, with the note that case
> sensitivity here seems especially pointless.

Not at all pointless given that we have real world examples of service names,
one in uppercase, one in lowercase, which have two different port numbers assigned.
If DBIS did not have an answer to that, we'd be back to using a custom schema,
which defeats the object of the exercise.  NIS was case sensitive, DBIS aims to be
100% compatible with the NIS schema, as previously discussed.

> 
> oncRpc / rpcObject
> 
> ONC RPC is only one kind of RPC, so leaving "ONC" in its name seems appropriate.

RFC5531 is titled "RPC" not "ONC RPC", and there is no other type of RPC defined in an
RFC as far as I am aware.  To me it was obvious what RPC referred to.  I needed a new
class anyway, and calling it oncRpcObject seemed unnecessary when rpcObject was
clear enough.

> 
> Again, the changes here all appear similar to those above.
> 
> ipHost / ipHostObject
> 
> This schema doesn't seem to allow for a host that has both IPv4 and IPv6 addresses, nor for one
> that has no addresses.

Mixing IPv4 and IPv6 should just be a case of assigning both the ipv4HostObject and ipv6HostObject
classes to the same entry.  A host with no IP address, if we need to support that, I suggest
we change ipHostObject to be STRUCTURAL rather than ABSTRACT.

> 
> While I could see using an LDAP directory as the back end for a DNS server, I could not see using
> it as the client's primary source for address<->name mapping.  
> In fact, ripping that capability out of our LDAP support is on my list of things to do - it adds essentially
> zero value and occasionally causes problems.

I agree, but DBIS must be backwards compatible.

> 
> ipNetwork/ipNetworkObject
> 
> As above.
> 
> automountMap / AutomountMapObject
> 
> As above.
> 
> automount / automountEntry
> 
> If we're going to change definitions, we should ensure that the new definition allows for SMB
> references in addition to NFS references. That suggests a URL form.

I actually added automountMapType to the draft but didn't update the comparison table.
This was so that we could also support amd-style entries.  I suppose that is where we
could also state that entries were smb-style entries too, and provide different
attributes that are SMB-friendly.

>
> Note that splitting automountInformation into automountLocation and automountOption means
> that you can't have multiple locations with different options.

You're right, but why would you do that?

>
> automountMulti
> 
> I don't yet understand what this class is for.

I've renamed this to automountMultiMount in the draft and didn't update the table.
This is for Solaris-style multi-mount entries.  I think they're being referred to as
hierarchical mounts now, but see some example entries here:

http://sourceforge.net/p/dbis/wiki/Map%20Entries/

Best regards,
Mark.




--------------------------------------------------------------------------------

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.