Re: [ldapext] DBIS commentary

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

Hi Jordan,



> On the case-sensitivity front:  we have a pretty fundamental disagreement.  I believe that UNIX names

> must eventually become case-insensitive, that it is only a matter of time until they do.



Yes, you're right, this is a pretty fundamental disagreement.  As I don't see anyone else entering the

debate supporting case sensitivity, I fear this will fail on a standards track.  I may just keep the

software available as an alternative, and those who want it can use it, but I think any hopes I had

that DBIS might one day be a standard have just been dashed.  I will continue to answer some

of your points anyway, just for completion.  Those who agree with me are either a) not speaking

up or b) not reading this mailing list.



However, I would point out that you will meet resistance (and/or disgruntled customers after the

fact) if you attempt to change UNIX to be case-insensitive.  Btw, what was your plan for case

sensitivity in filesystems?



> UNIX is not the whole world, and the entire rest of the world is clear that MARK, Mark, and mark

> are the same person.



With people, perhaps.  With people vs. service accounts perhaps not.  Perhaps I have a user with

a login name of 'sheila' but I also have a service account called 'SHEILA'.  I suppose next you will

be proposing to redefine the English language by saying that case is unimportant when starting

sentences, or when writing proper nouns vs nouns?  Be careful when you say "the entire rest

of the world", be sure you really know the entire rest of the world.  I don't claim to, but I do have

real examples of problems that DBIS is solving today.



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

>

> I recommend looking pretty hard at whether a new attribute is needed, given that there

> seem to be three other existing attributes.

>

> In general, it seems best to discourage making password hashes visible - perhaps even to

> the point of not standardizing them.



You might want to point that out in a separate thread, as I say, RFC2307bis is on the new

LDAPEXT charter but those running with the new charter may not be reading these email

chains in any depth.



> My key point here is that DBIS should specify what attribute should replace it, what attribute

> clients are expected to use to populate the pw_gecos field in struct passwd.



draft-bannister-dbis-passwd provides a suggestion already in 2.1.3.1:



   The posixUserAccount object class is auxiliary and must always be

   associated with another structural class.  One such class is

   inetOrgPerson [RFC2798].  If user accounts were given the

   inetOrgPerson class, then displayName might be an appropriate value

   for the dbisMapGecos attribute.



Given that the gecos field can encode anything in any format, I didn't think I could realistically

do any better than provide a suggestion.



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

>

> A subclass does.



I have people telling me groupOfNames doesn't work well for them because it can be a group

of anything.  Extra LDAP searches are required to figure out what type of object the members

are.  That leads to a rather inefficient system.



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

>

> Yes, it can... and for most purposes it has, in the form of groupOfNames.  If you have users

> represented in the directory, the natural way to group them is with groupOfNames.  If you

> have hosts represented in the directory, the natural way to group them is with groupOfNames.

> The only thing that there isn't an obvious way to group is "user X on host Y".  Not that I've seen

> a lot of concrete instances of netgroups, but I don't think I've seen one of those yet.



See previous reservations regarding groupOfNames.  Imagine trying to construct a search

operation to find just host members, or just user members.



However, I seem to be a lone voice again in favour of netgroups.  I've seen them used an awful

lot and with a bit of improvement, they'll be a lot more manageable.  I know how painful it will

be for folk to try to move away from them, so in the spirit of making things easy for people

I have been proposing incremental improvements rather than just dumping them and

doing something completely different.  Everyone else commenting on this list seems to hate

them.  Another fundamental difference we have ...



> Having two names that differ only in case lead to different port numbers seems like a

> spectacularly bad idea.  If there's an organization that has somehow found themselves

> in such a mess then I'm very sorry for them



<rant>

Wait.  NIS permitted this.  If folk have done what NIS allowed them to do, and it

fitted their working practice, then you can't blame them for that.  If you don't like it

and want to label it "a mess", that's fine you can do that, but I do not want to leave

people behind.  If you wish to call it a mess, then Sun Microsystems created the mess,

but it's infrastructure and we're stuck with it.  Imagine if the electronics industry in America

started selling devices with only English three-pin plugs<https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=http%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&usg=AFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>, citing that the original was a

“bad design” and anyone who has found themselves in such a mess as to have

incompatible wall sockets, well very sorry for them but that’s just tough luck.

Right.  You’d cause an outcry.  Same thing applies here.  With NIS a particular

working practice was absolutely fine.  Now it isn’t.  And people are left to fix it

themselves.  I think that’s very bad.  (And for those who say “NIS is dead”, that’s

absolutely not true, there are large organisations still using NIS and who haven’t

yet migrated to LDAP, perhaps because the migration to LDAP is too hard for

them in the present climate).

</rant>



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.