Subject: DRAFT minutes for San Diego meeting

From: "John Strassner" <[email-masked]>
Date: Tue, 26 Dec 2000 15:24:00 -0800

Happy Holidays LDUPers,

below please find the draft meeting minutes for the San
Diego meeting. Please submit any comments and corrections to
me asap so that I can include these in the official minutes.
And thanks presenters, I already have all of your slides for
inclusion.

regards,
John

====================== SNIP HERE ==========================

Draft Summary and Meeting Minutes
LDUP Working Group Meeting
49th IETF, San Diego
Minutes recorded by John Strassner, December 12, 2000

The agenda was presented, and no adjustments were made.

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

The changes to the latest draft were presented by Richard
Huber.

There were no comments on the -04 version, other than Albert
Langer's. The -05 version includes responses to these as
well as responses to internal comments from various AT&T
reviewers. They were as follows.

First, there was some grammar and general language clean-up.
There were three important added requirements:

  - MM7: Multi-master conflict resolution MUST NOT
    depend on the in-order arrival of changes at a
    replica to assure eventual convergence.
  - AM7: It MUST be possible to add a 'blank'
    replica to a replica-ring, and force a full
    update from (one of) the Master(s), for the
    purpose of adding a new directory server to
    the system.
  - AM8: Vendors SHOULD provide tools to audit
    schema compatibility within a potential
    replica-ring.

There was one requirement that was deleted, which was
requirement M6. After simplifying the language, it was
indistinguishable from M5 (and therefore was deleted).

This version of the draft addresses Albert's comments.
Specifically, these points, and their responses, were as
follows:

  1. Albert recommended that Model 3 (the one
     defining "eventual consistency") should
     NOT be allowed, and that only model 2
     should be supported.

RESPONSE: This was discussed at the meeting, and the
room consensus was to keep this model to provide
additional flexibility for the administrator.

  2. The requirements should not become an RFC
     until there is a URP draft that supports
     eventual consistency.

RESPONSE: This was discussed at the meeting, and the
general consensus was that requirements must precede
drafts. If it is later found that a draft can not
meet the stated requirements, then the requirements
should be revisited.

  3. Atomicity issues.

RESPONSE: Albert wants all changes from a server to be
handled in an atomic fashion. This was basically the
same position as was argued in the last session
(please refer to the last minutes on this subject).
This requirement seems unreasonable. The obvious
counter-example is when multiple servers each write to
one or more attributes of the same entry. In a single-
master situation, one would hope that you would end up
with the cumulative changes, and there is no reason to
have a multi-master system not exhibit that same
behavior.

A side discussion ensued as to what happens when one
or more of the changes made to an entry (that had
multiple attributes changed by multiple servers) needs
to be rolled back. It was suggested that in the event
of 2 (or more) incremental changes that conflict, the
best that could be done is to log these occurrences
and ensure that an administrator would be notified to
take any further action that was deemed necessary.
Along these lines, it was asked how you could tell
between two conflicting changes and simply two updates.
This is part of a larger question, which is whether
there are two different applications that are writing
to the same entry or if it is one application. This is
why it is necessary to ensure that the administrator
has the opportunity to resolve such conflicts.

The room consensus was to keep the draft as is.

  4. The subentry draft may add new replication needs.

RESPONSE: While this is certainly true, the problem is
that if we don't freeze the requirements at some point,
we'll never be able to progress. It was suggested that
the current state of the requirements draft captured
all suggested major requirements that this working
group has discussed, and should be put forth for Last
Call.

This last issue brought up the subject of interoperability.
Mark Brown objected to not specifically stating limits for
LDUP interoperability, and kindly volunteered to add some
text to support this requirement. (Ed. note: Mark sent the
text on 20 December, thanks!).

One additional point was made that writers of new drafts
SHOULD ;-) consider the impact of their draft on LDUP. An
obvious example of this is the subentry draft, which does
affect replication. It was agreed to use this draft as a
model for other authors to see how to write their drafts
that would address replication needs.

The chair then called for a room vote as to whether people
attending thought that this draft was ready for Last Call.
The large majority agreed that there was, and there were
no dissenters.

Action:
Last Call to be announced at the start of the new year.

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

Steven gave a short presentation, reiterating that there
were no comments to this version of the draft. The chair
asked if anyone had any comments or suggestions on this
draft, and no one did. An informal room vote was taken to
see if this draft was ready for Last Call, and the room
agreed that it was (but that the Requirements draft should
be issued first).

Action:
Chairs to announce Last Call after Requirements draft
returns from its Last Call

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

Uppili gave a short status update on this draft. There
appeared to have been posting problems with the draft; Ed to
mail John a copy of the draft and John will ensure that it
gets posted in the repository.

Issues from the last meeting have been addressed. Editing
was done to enable better alignment with X.500 terminology,
and instances of "Naming Context" were replaced with
"Replication Context". This addresses three important
points:

  - rigidly defines the area that will be administered
    for replication
  - defines this as an area that does NOT span DSAs
  - defines a directory area to be in only one
    replication context

It was noted that there are many different types of
administrative areas in the directory (e.g., access control
privileges), and other areas might not have the same
properties as the replication areas.

There is still one open question: which of the three models
for resolving replication versus other administrative areas
should be chosen? If we don't choose the first choice, it
seems like it defaults to the second choice (manual
administration). But note that if the access control policy
specifies how access control applies to multiple servers,
it is up to the access control application to copy this
information, not the replication application. Room
consensus seemed to indicate that the third model was best,
but this needs to be redone in the document and possibly
taken to the list.

Action: Uppili and Ed to revise this draft, target date is
end of February.

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

Ed presented a short status of this draft. There were no
major issues or comments.

Action: Ed to revise this draft, target date is end of
February.

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

This draft was twice recently updated, in order to get in
line with the other drafts. Ed presented two slides that
detailed actions still to be done to this draft.

Editor's note: PLEASE take the time to review this draft
and Ed's slides, and forward any comments and suggestions
to him. Thanks.

There were significant revisions to the Scope Discussion
as well as the Inheritance Discussion. Also, revisions
were made to Administrative Area alignment as well as to
Visibility Mechanisms.

Scope Discussion. Needed a default, and so the scope was
limited to the administrative area in which the ldapSubEntry
is defined. LDUP lets applications define their own admin
areas with the ReplicationContext aux class. Note, however,
that other scopes are possible, including an X.500-style
subtree specification. This is not addressed in this draft.

Inheritance Discussion. ACLs and various other policies
want policy to inherit down the tree, but such inheritance
needs to be controllable. For example, it may not be
desirable to inherit across organizational boundaries.
Therefore, a new structural subclass was defined, called
inheritableLDAPSubEntry. It has two attributes. The first,
Inheritable, is a MUST, and TRUE means that it may be
inherited by subordinates. The second, blockInheritance,
is a MAY, and TRUE means that the superior policy is
ignored (for now, FALSE is reserved). Note that this
latter attribute should not be inherited by subordinates.
There is no provision to REQUIRE inheritance by
subordinates, as this brings along a lot of complications.
Thus, the current proposal ONLY over-rides policy - it
doesn't augment or edit the policy.

Admin Area Discussion. LDUP defines a Replication Context
to be a subtree of a resident Naming Context on the server.
Replication Contexts do not overlap one another in the DIT.
A Replication Context must be entirely resident on a server
(not including definitions of sparse and fractional
replicas).
An admin area may be anything with a subentry subordinate to
it, anything marked with an administrative point in some way
(DSE, or other), or anything defined so by the application.

Visibility mechanisms. Defined a control, with the semantics
from X.511 commonArguments boolean value "subentries". It
applies to any subtree or container search that doesn't have
BaseObject scope. Search Filter (from previous drafts)
retained for backward compatibility and simple common sense,
though it MAY be deprecated in the future.

The major remaining open question is in the handling of
subentries. Ed didn't feel empowered ;-) to make it a MUST.
It should also be noted that currently this is NOT an
LDAPv3bis issue. The room consensus was that the MAY should
be eliminated, as it seems to imply that this is how a
subentry may look.

Action: Ed to revise this draft, target date is end of
January.

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

Editor's note: as this is an essential draft, PLEASE take
the tie to review it, and forward any comments and
suggestions to the authors. Thanks.

Ellen presented the status of this draft. The major changes
to be incorporated are:

  - include requirement to understand URP to send and
    receive updates correctly
  - place returnConsumerUpdateVector BEFORE the optional
    replicaUpdateVector to make BER decoding easier
  - the consumer server should only send the
    replicaUpdateVector of requested data by the
    supplier server
  - section 6 (full and incremental update semantics) needs
    to be written
  - Remove section 8, as it is covered in the model draft,
    section 10.3
  - Remove section 9, as it is covered in the model draft,
    section 6.1
  - Fill out Security Considerations section
  - Move section 11 (CSN algorithm) to model draft section
    4.5 and further articulate in plain English
  - Misc editorial updates

Two major issues are still being investigated. The first is
consumer-initiated replication through a firewall, and the
second is to add a sequence number into every operation
except start.  (This is needed by the receiver, not the
sender.) If anyone has any thoughts on this, please post to
the list (or at least mail the authors ;-) ).

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

The authors decided to combine this discussion with the
Grouping Operations discussion. Kurt gave the status.

An engineering team met to determine whether to merge
the framing and grouping drafts. Kurt found that it was
hard to do this as he started writing the merged doc, so
he just edited the grouping doc. The rough consensus from
LDAPEXT yesterday was to take on the Grouping doc as a
new charter item.

So what's the difference between the two operations?
Framing was defined as a sequence of operations where
there is a clear starting operation, followed by a sequence
of operations, followed by a clear ending operation.
Grouping is defined as an arbitrary collection of operations
that may be interleaved and/or nested (framing explicitly
prohibits these semantics).

LDUP and LBURP could use grouping instead of framing, but
grouping contains more semantics than LBURP needs. The only
real difference was that framing did not allow for nesting.
Mark thinks that it is perfectly acceptable for grouping to
specify additional semantics such as whether nesting is
allowed or not, though Kurt expressed some doubt from an
implementation point-of-view.

Note that this also affect Gordon and Ellen, as this will
affect the timing of their draft.

Action:
Kurt and other interested parties to examine this once
again.
New draft due by end of February.

8. "LDAP Client Update Protocol"
http://www.ietf.org/internet-drafts/
draft-natkovich-ldap-lcup-02.txt
R. Megginson, Editor, O. Natkovich, M. Smith, M. Armijo,
authors

Richard gave a status update on this draft. Changes since
the first version included:

  - Client Side Consideration section - added a note and a
    question concerning referral and continuation
    reference handling. (Editors note: LDUPers, please read
    and respond on the mail list. Thanks)
  - Client Update Control Value section (4.1) - clarified
the
    meaning of keepConnection and added a table summarizing
    the effects of different values of keepConnection and
    changesOnly.
  - Stop Client Update Request and Response - added section
    4.4 describing this extended operation.

There is still one major open item, which is what to do
about
referrals and continuation references being returned?
(Editors note: LDUPers, please read and respond on the
mail list. Thanks)

Action Item:
Draft to be updated by the end of February

9. Some deliverables still missing in action...

9a. Mandatory replica management

Ed is over-burdened, so Jim and Alison, along with Tim Hahn,
expressed interest in taking this over.

Action item:
Please try and produce a draft before the March meeting in
Minneapolis.

9b. Master-slave and multi-master profile documents

Uppilli is also over-burdened, but Rick Huber volunteered
to take this draft over.

Action item:
Please try and produce a draft before the March meeting in
Minneapolis.

11. Revised charter discussion

The dates were reviewed with the authors, and the chairs
will issue a revised charter by the first of the year.

12. Any Other Business

No other business, meeting concluded.