Re: A more radical approach to 2307

--===============3964604261898355573==
Content-Type: multipart/alternative; boundary=001a114eed62f4a0230526166c1f

--001a114eed62f4a0230526166c1f
Content-Type: text/plain; charset=UTF-8

I tend to agree with Andrew.

--
-jim
Jim Willeke

On Fri, Dec 4, 2015 at 10:00 AM, Andrew Findlay <
[email protected]> 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/                +44 1628 782565     |
> -----------------------------------------------------------------------
>
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext
>

--001a114eed62f4a0230526166c1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I tend to agree with Andrew.</div><div class=3D"gmail_extr=
a"><br clear=3D"all"><div><div class=3D"gmail_signature"><div><span style=
=3D"background-color:rgb(153,153,153)">--</span></div><span style=3D"backgr=
ound-color:rgb(153,153,153)">-jim<br>Jim Willeke</span></div></div>
<br><div class=3D"gmail_quote">On Fri, Dec 4, 2015 at 10:00 AM, Andrew Find=
lay <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]=
" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">RFC2307, 2307bis and DBIS all start from t=
he NIS/YP/files-in-etc model<br>
and represent the data in LDAP with varying degrees of fidelity.<br>
Is this actually a good idea? I rather think not.<br>
<br>
The big value of LDAP and related things in complex organisations is<br>
that it allows a single abstract representation of &#39;important stuff&#39=
;<br>
that can be used by many systems. To work in this environment the<br>
systems have to be flexible, with minimal built-in assumptions about the<br=
>
data. We have already established that no abstract representation can<br>
provide the full generality and semantics of each system&#39;s native<br>
database so compromise and simplification is essential.<br>
<br>
With this in mind (and donning my best flameproof suit) I suggest a<br>
radical approach to the task in hand:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Throw out most of the 2307 NIS-like definitions=
.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Consider what an Enterprise-level LDAP service =
might really<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contain *before* any OS-specific or app-specifi=
c requirements<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are imposed on it.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Create new schema if needed to support a clean =
representation<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of that Enterprise data.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Create new AUXILIARY classes to support the att=
ributes needed<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for POSIX systems.<br>
<br>
The resulting set of attributes and classes would be *much* smaller than<br=
>
the 2307 set. Some whole categories could just vanish, e.g.:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 All the shadow password stuff (draft-behera is =
difficult enough<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and we don&#39;t need to duplicate its function=
 on the client side)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 memberUid (we really *dont* need a POSIX-specif=
ic way to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 represent groups, and the syntax of memberUid d=
oes not even<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 match that of uid)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Most of the less-used NIS-map attributes and cl=
asses could be<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hived off into separate documents, or even dump=
ed in favour of a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 generic structural lookup table with explicit c=
ase ignore/case<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sensitive semantics.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Andrew<br>
--<br>
-----------------------------------------------------------------------<br>
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From Andrew =
Findlay, Skills 1st Ltd=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
| Consultant in large-scale systems, networks, and directory services |<br>
|=C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.skills-1st.co.uk/" rel=3D"norefe=
rrer" target=3D"_blank">http://www.skills-1st.co.uk/</a>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"tel:%2B44%201628%20782565=
" value=3D"+441628782565">+44 1628 782565</a>=C2=A0 =C2=A0 =C2=A0|<br>
-----------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Ldapext mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ldapext" rel=3D"noreferrer=
" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ldapext</a><br>
</font></span></blockquote></div><br></div>

--001a114eed62f4a0230526166c1f--


--===============3964604261898355573==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext

--===============3964604261898355573==--