[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDUP Working Group Agenda - Summary of objections to requirem ents draft
This is good and should be discussed.
Lets put the goals down first - can the LDUP and URP standards make
scaleable, reliable directory information systems for business use?
I aggree and have voiced the opinion that once we go "sub atomic" on
directory objects/entries - then that is implementation - not
standardisation. For instance we dismantle in every DSA a complete DSAs
NameSpace into RDB tables (32 patents) - so we can automatically index, 2
phase commit, etc.. we can do database replication (sub atomic - product
feature) and ,DISP and DSP writethrough (standards feature).
Can any vendor/person on this list confirm their desire to do directory
entry sub - atomic interoperability testing.. and waht are the tests when
they can do that.
The rules of the IETF (IMHO) state that 2 or more implementations must
interwork - to make an RFC.
Can those involved say so.. otherwise - please consider..
Something which is "lightweight" cannot be "Unpredictable" and
"Preposterously complex".
regards alan
-----Original Message-----
From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org]
Sent: Thursday, July 27, 2000 4:16 PM
To: 'Christopher Apple'; ietf-ldup@imc.org; ietf-ldapext@netscape.com
Cc: agenda@ietf.org; johns@cisco.com
Subject: RE: LDUP Working Group Agenda - Summary of objections to
requirements draft
[Chris]
I. WG Deliverables Review
"LDAP Replication Requirements"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt
Editor(s): Russ Weiser, Ellen Stokes
[...]
III. Discussion of LDUP Requirements Document
[Albert]
I am also sending this to LDAPEXT as the direction taken by LDUP could have
major consequences for LDAPEXT (eg the current proposals for ACL simply will
not replicate correctly and future support for transactions will be
difficult if not impossible).
Above link shows:
***
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on July 17, 2000.
***
A copy of the "final" version, which expired on 21 April 2000, is in the
LDUP email archive at:
http://www.imc.org/ietf-ldup/mail-archive/msg00471.html
Despite assurances from at least one person who should know, I remain quite
convinced that members of the LDUP WG have NOT read it carefully. It is
especially unlikely that anybody else has read it recently, since it expired
two months ago and has now been deleted.
In view of agenda item III, I strongly urge that you do read it again,
carefully.
As I cannot attend the discussion, I have included a summary of my formal
objection to it below.
SUMMARY OF OBJECTIONS TO REQUIREMENTS DRAFT
The three key points are:
1) There is no requirement for convergence or "eventual consistency".
This looks like just poor expression, but in fact the LDUP architecture and
Update Reconciliation Procedures do specify proposed standards that
guarantee long term divergence by relying on timestamps and allowing DSAs to
transmit changes out of order and drop changes when clocks are out of sync.
This is easily fixed, once a requirement to fix it is agreed on.
Details on how to fix it based on the Coda replication protocols also
adopted by Active Directory, and a semi-formal proof that the fix would be
robust in the face of DSAs crashing and being restored from backups, network
partitioning etc etc, is included in my draft below. That fix is also
consistent with the rest of the current architecture and URP and would not
require major re-work of existing drafts.
2) There is no requirement for atomic operations.
Again this is obscured by poor expression and nonsensical definitions, but
in fact the architecture and URP drafts merge changes to individual
attribute values made concurrently at different replicas. The fact that this
obviously breaks the ACL standards being developed in LDUP, despite an
overlap in authorship between the two documents, strongly confirms that the
consequences for existing applications are simply not understand and should
be studied through a requirements analysis by actively explaining the
implications and soliciting input from other areas (operations etc) that may
be affected.
Fixing this would require substantial changes to the current architecture
and URP. I have sketched one possible way to do so in the draft below.
3) There is no requirement to support mandatory operational attributes of
LDAP.
The operational attribute "modifiersName" cannot be supported meaningfully
as nobody in particular can be said to be responsible for a change that has
in fact been merged from two or more concurrent changes made independently
and without knowledge of each other. This severely complicates system
administration as the first thing anybody would want to know after receiving
a problem report is "who changed what".
I believe that point 1) would be taken for granted by anybody thinking about
LDUP requirements. Until somebody presents an argument against convergence
or "eventual consistency" I see no point in even trying to present an
argument for it. The current approach is simply absurd.
Point 3) is also pretty obvious and is just one of many consequences of
point 2.
On point 2, there are plausible arguments (which I disagree with) for
breaking the current LDAP/X.500 data model. If the WG does intend to do
that, it has an obligation to clearly explain its intentions in a
requirements draft and actively solicit input.
I cannot express the argument against doing so more clearly than has already
been done, long ago, without adequate response, in the following comments
"Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December
1998):
***
"Each LDAP operation (add, modify, delete, moddn) as
a whole is atomic. The whole operation either happens
or it doesn't. Changes cannot be half-applied to any
single LDAP server.
The replication consistency model must assume and
build on this basic fact to define how multiple LDAP
replicas converge to the same state over time, in
the absence of additional changes. This kind of loose
consistency model is pretty fundamental to the notion
of a directory.
My two cents on what's important in a replication
consistency model are that it must be 1) predictable,
and that it should 2) make some kind of sense to
people using the system.
All this talk of consistency at different levels
(e.g., between applications using the directory at
the same time) is a red herring. Our job is to define
a consistency model for the directory itself. Some
applications may find this model sufficient for their
needs. Others may have to build more elaborate models
on top. But let's start with the basics. -- Tim"
http://www.imc.org/ietf-ldup/mail-archive/msg00214.html
***
In my view, both an explicit requirement for atomic operations and a
requirement that the results be 1) predictable and 2) make some kind of
sense to users, should be in the final requirements draft.
The consistency model of URP, was summarized in Alison's "Contribution to
Profiles Document (Consistency Discussion)":
http://www.imc.org/ietf-ldup/mail-archive/msg00548.html
The attached Word version, with more easily read tables, is:
http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc
In my view it is:
1) Unpredictable. See the explanation of "Extraordinary States" and
"Transient Extraordinary States" above.
2) Preposterously complex. See the extensive use of procedural pseudo code
for a protocol that simply defies plain description, in the URP draft:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt
In reviewing the LDUP archives I noted that a number of people had expressed
various reservations, especially concerning the consistency model for
replication,
but subsequently ceased active participation. Hopefully some of them may
still be
involved in LDAP-EXT and could therefore see this and decide to take part in
the
discussion.
See also my individual submission to LDUP:
http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt
and my response to the WG chair's request for status reports, which contains
links to all relevant discussion of that objection prior to the
document expiring:
http://www.imc.org/ietf-ldup/mail-archive/msg00561.html
Subsequent discussion can be seen by following from the thread of
that message in the archive.