Re: [ldapext] A more radical approach to 2307

[Jim Willeke <[e-mail]>]

I tend to agree with Andrew.

--
-jim
Jim Willeke

On Fri, Dec 4, 2015 at 10:00 AM, Andrew Findlay <
[e-mail]> wrote:

> RFC2307, 2307bis and DBIS all start from the NIS/YP/files-in-etc model
> and represent the data in LDAP with varying degrees of fidelity.
> Is this actually a good idea? I rather think not.
>
> The big value of LDAP and related things in complex organisations is
> that it allows a single abstract representation of 'important stuff'
> that can be used by many systems. To work in this environment the
> systems have to be flexible, with minimal built-in assumptions about the
> data. We have already established that no abstract representation can
> provide the full generality and semantics of each system's native
> database so compromise and simplification is essential.
>
> With this in mind (and donning my best flameproof suit) I suggest a
> radical approach to the task in hand:
>
>         Throw out most of the 2307 NIS-like definitions.
>
>         Consider what an Enterprise-level LDAP service might really
>         contain *before* any OS-specific or app-specific requirements
>         are imposed on it.
>
>         Create new schema if needed to support a clean representation
>         of that Enterprise data.
>
>         Create new AUXILIARY classes to support the attributes needed
>         for POSIX systems.
>
> The resulting set of attributes and classes would be *much* smaller than
> the 2307 set. Some whole categories could just vanish, e.g.:
>
>         All the shadow password stuff (draft-behera is difficult enough
>         and we don't need to duplicate its function on the client side)
>
>         memberUid (we really *dont* need a POSIX-specific way to
>         represent groups, and the syntax of memberUid does not even
>         match that of uid)
>
>         Most of the less-used NIS-map attributes and classes could be
>         hived off into separate documents, or even dumped in favour of a
>         generic structural lookup table with explicit case ignore/case
>         sensitive semantics.
>
> Andrew
> --
> -----------------------------------------------------------------------
> |                 From Andrew Findlay, Skills 1st Ltd                 |
> | Consultant in large-scale systems, networks, and directory services |
> |     http://www.skills-1st.co.uk/                [phone]     |
> -----------------------------------------------------------------------
>
> _______________________________________________
> Ldapext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ldapext
>