[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Initial "strawman" I-Ds revising LDAPv3
Date sent: Tue, 24 Oct 2000 18:05:34 -0700
To: ietf-ldapbis@OpenLDAP.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Initial "strawman" I-Ds revising LDAPv3
Priority: non-urgent
> I put forth the following simple proposal for producing
> initial I-Ds detailling LDAPv3 revised specification.
> These initial I-Ds would fulfill our November 2000 milestone
> and, more importantly, provide a basis for discuss at
> IETF#49.
>
> I suggest that for each RFC which comprises the LDAPv3
> "core" technical specification (RFC2251-56, RFC2829-31)
> that an I-D be produced which provides a "strawman"
> revision for that technical specification.
>
> For each specification, the Document Editor would be
> primarily responsible for determine what changes to propose.
> The editor should use this list, archives of various mail
> lists, and their own best judgement to produce the
> initial I-D. A 'Call for Document Editors' would be
> issued and initial editors selected per IETF WG guidelines
> and tradition.
>
> The general guidance, in accordance with our proposed charter
> and IETF#48 discussions, given to Document Editors would be:
> a) don't add any new features
> b) obsolete LDAPv2
> c) cut or absorb dependent LDAP/X.500 technical
> specifications which described in "core" documents
Kurt
whilst I agree with virtually all that you say above, point c) could be
a large amount of work (i.e. if you mean importation) as there is an
aweful lot borrowed from X.501 that would need to be re-written. It
generally is not a good idea to re-write something if what you are
referencing is already a standard and precise, as this can lead to
unintentional differences creeping in (just like maintaining two sets
of code in parallel). It would be better if we could precisely
reference those bits of X.501 that we want and specifically exclude
those features that we dont want. However, I do realise that there
are distribution problems, in that X.500 is hard to get hold of and
costly whilst IETF docs are easy and free. What PKIX has done to
circumvent this is to simply copy chunks of X.509 and put them say
in an annex. This would be a sensible alternative for LDAPbis,
rather than to re-write X.500, would it not?
David
>
> After each I-D is submitted as individual submissions (we
> don't have a working group yet), the worthiness for the
> proposal should be discussed. Based upon consensus of
> this list, the I-D would either be accepted as the basis
> for further work or rejected.
>
> Then, at IETF#49, we can discuss how best to proceed.
>
> I solicit your comments on this proposal.
>
>
>
>
>
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************