Subject: Draft minutes for LDUP

From: "John Strassner" <[email-masked]>
Date: Fri, 11 Aug 2000 15:26:11 -0700

are below. Please comment asap.

regards,
John

LDUP WG Meeting, Wednesday August 1, 2000
Meeting minutes recorded by John Strassner

0. Agenda discussed, and no changes were made.

1.  "LDAP Replication Requirements"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-
req-03.txt
Editor(s): Russ Weiser, Ellen Stokes

This is an expired draft and needs to be republished in
order for us to proceed with work on it. By republishing, we
mean that the document must be published, with no changes
other than an updated revision number. This is necessary so
that we can refer to it in the upcoming discussions. This
will be done this week

Action: republishing to be done this week; see item 12
below.

2. "LDUP Update Reconciliation Procedures"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.t
xt
Editor(s): Steven Legg, A Payne

This draft has undergone a minor revision, having been
updated to include the correct use of MUST and MAY as well
as a clarification resulting from the discussion with Albert
Langer. In addition, the
References and Security Considerations sections have also
been updated. In summary, it is ready to go to last call,
but can't until the requirements document is updated to
reflect the discussions with Albert Langer.

Action: none, pending resolution of requirements draft - see
item 12

3. "LDAP Replication Architecture"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04
.txt
Editor(s): Ed Reed, U. Srinivasan, John Merrells

There were open comments from the mailing list regarding
references in this draft to other drafts. We had a
synchronization problem with these other drafts, as these
normative references were moving and this draft was getting
out of sync. This has been corrected, and the normative
references removed.

The only remaining open issue in this draft is the
relationship between access control and the definition of
naming context. In LDUP, the naming context is the unit of
replication, but in access control, it is slightly different
(administration points are defined differently than naming
contexts). Once these changes are made, the document will be
ready for last call.

Action: this draft will be revised by the end of September.
Depending on the resolution of the issue above, it may be
ready for last call then.

4. "LDUP Replication Information Model"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-
01.txt
Editor(s): Ed Reed

No changes in this document as of now. Reference to ITU UUID
document was found and will be incorporated. General
reconciliation with the architecture document is now
necessary. One additional point is that access control
information needs to be replicated, but we don't want to
deal with inherited ACI yet. This issue needs to be taken to
the list.

Actions:
  1) Ed to lead discussion on the list regarding how to
handle
     replication of ACI.
  2) The next revision of this draft will be published by
the end of
     October.

5. "LDAP Subentry Schema"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry
-03.txt
Editor(s): Ed Reed

Basic problem is that the presence of a subentry causes an
administrative area to be defined. So the administrative
area may not exactly coincide with the naming context. The
subentry document needs to be updated to define what is
meant by each of these terms. The management of
administrative areas, and how this differs (if at all) from
the management of naming contexts, needs to be documented.

This challenges us to as to whether replication needs
semantic understanding of administrative areas. This seems
like a very thorny issue, and it was suggested that we treat
this as a version 2 problem in order to make progress with
the existing definition of LDUP. This draft will be revised
to make scoping of LDUP subentry more clear.

Open issue raised by Kurt is to use a control instead of a
filter mechanism to make subentries visible. This issue has
been posted to the list.

Action: The next revision of this draft will be published by
the end of October.

6. "The LDUP Replication Update Protocol"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol
-01.txt
Editor(s): G. Good, E. Stokes

A few open issues have been raised with respect to the
signatures of ReplicationStart and other commands. This will
cause the document to be revised.

The big problem is whether this document should or should
not use framing. This discussion needs to be taken to the
list.

Actions:
  1) Ellen and/or Gordon to lead discussion on the list as
to whether
     this document should use framing.
  2) The next revision of this draft will be published by
the end of
     October.

7. "Extended Operations for Framing LDAP Operations"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-
00.txt
Editor(s): G. Good, E. Stokes, Roger Harrison

This work will be subsumed into the grouping operations work
being done in LDAPEXT and produce a new framing document
(see below).

Action: This draft will be updated by the end of Septmeber.

8. Mark Wahl - Grouping operations

In Adelaide, work was started on taking the existing LDUP
framing document (which LBURP was using) and generalizing it
so that other operations could use framing.

One possible use of framing was to add transaction support
to the directory protocol, but this was decided to be too
big to tackle. However, there is interest in the use of
framing in other areas (e.g., for the client to request
locking on entries, or for certain integrity constraints to
be maintained). One of the desired features is to change the
referential integrity enforced by a directory server, such
that instead of maintaining referential integrity on an
operation by operation basis, it instead changes to maintain
referential integrity on a set of updates (e.g., enforce it
at the end of the operations).

Mark believes that we need extended operations for
delimiting beginXX and endXXX operations, and need a
document to cover these associated semantics. Note that what
is being proposed is that there is a generic way of saying
Begin<insert operation here> and End<insert operation here>.

So the framing document needs to be generalized so that
everyone can use it. This should be done with a joint last
call with LDAPEXT.

Action: Mark and Roger to work on a revised draft, to be out
sometime in October.

9. Some deliverables still missing in action...

9a. Mandatory replica management (Ed Reed). Mark has given
us a starting draft; Ed will work with others and try and
issue this document in September.

9b. Master-slave and multi-master profile documents are
behind schedule. Uppilli will take the lead on this work.
Since work has stalled, the question was asked, is it
beneficial to have profiles that specify how replication
works for single-master vs. multi-master.

Actions:
  1) Uppilli to lead discussion on the list as to whether we
still need
     separate profiles for (at least) single- vs.
multi-master or not.
  2) The next revision of this draft will be published by
the end of
     October.

10. Charter Addition for LCUP?

"LDAP Client Update Protocol"
http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcu
p-01.txt
Editor(s): O. Natkovich, M. Smith, M. Armijo

The short summary is that LCUP is dirsync, persistent
search, triggered search, and LDUP replication. There is an
open issues section in the current draft. PLEASE COMMENT!

Room was polled, and a large majority of the room was in
favor of adding it (no one was actually opposed). Patrik
asked if this would conflict with or hold up existing work,
and the answer was no, there was already a dedicated group
of people ready to work on this that weren't involved in
other work. This question will therefore be taken to the
list.

Actions:
  1) Co-chairs to poll the list to ensure that no one
objects to adding
     adding LCUP to the LDUP charter.
  2) If no one objects, then co-chairs to propose new
charter to list;
     if acceptable to list, then to work with Ads to get our
charter
     officially amended.

11. Other business (besides discussion of Albert's
comments): LBURP

We also have an open question of adding LBURP to our
charter. This draft has been revised since the last meeting
(draft-rharrison-lburp-02.txt).

The changes to the -02 version include adding a new
operation, LBURPOperationPartialResponse (note name change
from slide). This tells you what operations have succeeded,
failed, or are still pending.

Remaining questions - after a brief discussion, it seems
like the ability to defer operations should be taken out, as
it causes more problems than it solves.

What is the relation between LBURP and the framing document?
Roger will try and move this document to keep it in sync
with the framing document.

Finally, there wasn't a lot of feedback as to whether LBURP
should be added to our charter or not.

Action: co-chairs to pose the question of adding LBURP to
the list or not.

12. Discussion of LDUP Requirements Document

Discussion about issues raised by Albert Langer. It was
impossible to judge how to proceed, based on the lack of
discussion that occurred on the list. So the co-chairs asked
for an independent review. This initial work was done by
Rick Huber and Ryan Moats. Both will be added as authors of
the requirements document as a result of this work.

Summary of Objections to Requirements

The big four points are as follows:
  - No requirement for convergence or eventual consistency
  - No requirement for atomic operations
  - No requirement to support mandatory operational
attributes of LDAP
  - Definition of updateable replica inconsistent with
multi-master
    replication

Taking these objections in order...

First point: These seem to be covered by requirements 5.2
and 5.7. But, since the draft goes to the trouble of
defining 5 different types of consistency. But, since the
draft goes to the trouble of defining five different types
of consistency, it would be a Good Thing if the requirements
were stated in those terms.

Action: Suggest adding a requirement for Eventual
Consistency.

Second point: there is a requirement for atomicity in LDAPv3
per RFC2251, section 4.6, and the referenced Tim Howes
quote. So the real question is whether this is covered in
sections 5.2 and 5.7.

Action: Suggest adding something more specific, as this
would avoid any later confusion.

Still on this point, we had an atomicity discussion.
Consider the following replication scenario. Servers A, B,
and C replicate with each other using multi-master
replication. On server A, attributes 1, 2, and 3 of entry E
are changed (an atomic operation). On server B, attribute 2
of entry E is changed. Without descending into the religious
{ ;-) } argument of which method is best, assume for the
moment that the change on B has a later time stamp than the
change on A.

There are three possible options: discard all changes from
A, make changes from A and ignore B, or make change from A
and then make change from B.

Note that this is an example of race conditions. If you want
to change attribute 2 based upon the value of attribute 1,
then since LDAP doesn't have a true read lock, you can't do
this. It was argued that LDAP does have a read lock by
virtue of doing a delete-add of the same value (which is
basically a test and set).

So, what should happen? There are three possibilities:

  1. The entire change from A is discarded since it is
atomic and
     was superceded by the change from B.
  2. The change from A is made and all attributes reflect
the values
     on A since the change was atomic, and B is deleted.
  3. Attributes 1 and 3 reflect the values from A, attribute
2 reflects
     the value from B.

Note that the third case is what would happen in the
single-server or single-master case. In addition, the third
choice seems to be the most reasonable choice according to
the time-honored Principle of Least Astonishment. ;-)  There
was overwhelming consensus in the room that this last case
was indeed what was expected.

This boils down to the following problem - if a set of
requests were submitted as a group, then the replication
system should treat them as an atomic group. However, each
operation should be processed on its own for conflict
resolution (as opposed to the group). Note that the word
atomic causes problems. In the example scenario, we want the
value to end up with {1, 2', 3}. It was noted that part of
the problem is in viewing this as entry-centric, as opposed
to being attribute-centric.

Action: this is a good example, summarizing many of Albert's
objections, and why it was felt that in this area his
objections were not reasonable. It should be included in the
new version of the requirements document.

The third point is that there was no requirement to support
the mandatory operational requirements of LDAP. Ryan and
Rick noted that ModifiersName is a MAY in 2251 and a SHOULD
in 2252. This is a Bad Thing, and Mark promised to fix this.

Action: Mark Wahl, please fix this. ;-)

However, it was noted that ModifiersName applies to Entries,
not attributes, so it is unclear how this specific example
applies. Summary: doesn't affect requirements draft, but
does affect LDAPBIS.

Action: Also recommended that Mark Wahl post to the list a
set of additional requirements on operational attributes
that must be maintained during replication.

Inconsistent Definitions. It was pointed out by Albert that
the definition of an updateable replica conflicts with
section 5.6.

Action: Change the definition of an updateable replica to:
"An authoritative read-write copy of the replicated
information". The room seemed happy with this.

Summary of issues between URP and MDCR, and resulting action
items:

1. Atomicity and related concepts

Action: Making some explicit statements about atomicity in
the requirements document would clear up this issue.

2. modifiersName and other operational attributes

Action: this point is moot

3. Change reports - Use ProtocolOps or Primitives

Action: no consensus, need further discussion on the list.
It was note that we need to include how each addresses (or
doesn't address) atomicity.

4. Eventual convergence - Version numbers or timestamps

Action: looks like a religious argument; no consensus
reached.

5. Oscillation

The claim has been made that MDCR oscillates. Everyone
agrees that oscillation is bad. Needs more discussion on the
list.

6. Implementation and performance issues

Action: There have been claims that URP and MCR have
comparable performance and implementation requirements.
Suggest that we accept this unless someone can prove that
this is not true, and prove it quickly.

7. Revocation notices

Action: unclear. MDCR could add them, and they aren't
applicable for URP. Suggest dropping this, there are bigger
fish to fry.

8. Strong consistency and transactions

Action: LDAP doesn't do transactions, so this is out of
scope. As a result of this, co-chairs will update the
charter to note that transactions are expicitly out of
scope.