DRAFT Minutes of the 51st meeting for your review

Greetings LDUPers,

below please find the draft meeting minutes for the London meeting.
Apologies for the late delay - apparently this was never successfully
delivered. 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 Strassner and Chris Apple
LDUP WG Co-Chairs

============================== SNIP HERE ==================================
DRAFT Summary and Meeting Minutes LDUP Working Group Meeting 51st IETF, 
London Minutes recorded by John Strassner and Tim Hahn
Tuesday, 7 August, 2001

0a) Review of Proposed Agenda

Patrik wanted to add a statement on the status of the Appeal.
Otherwise, no comments.

0b) IESG Appeal

Patrik Falstrom reported that there has been nothing further with
respect to the appeal made just before the last IETF.  He also 
noted that the official IESG response to the appeal had been 
mosted on the working group. Thus, this issue is now closed.

1) LDAPv3 Replication Requirements

http://www.ietf.org/internet-drafts/
draft-ietf-ldup-replica-req-10.txt

This draft passed WG Last Call, and a request has been sent
to the Applications Area ADs for IESG Review.

2) LDUP Update Reconciliation Procedures

http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt

The archive was recently polled to ensure that all open issues
have been answered. Since this has been confirmed, this draft 
will go to working group last call on Monday AFTER the IETF
(8/13). The last call will last for approximately 3 weeks.

3) LDAP Replication Architecture

http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt

Ed Reed reported that no work has been done since the last 
meeting, due to the requirements document not being finalized.
Now that the requirements doc is done, Ed has started going
thru the document doing a detailed compliance matrix. This is
about 50% done. The focus is to point out where the req 
document mandates a specific behavior and the arch document 
differs. This is also being done for the info arch document.
PDF to be mailed within 30 days.

4) LDUP Replication Information Model

http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt

Tim Hahn presented an overview of the current status of this draft.
The replicaSubEntry and replicaAgreementSubentry object classes 
were obseleted, and replaced by two new updated object classes
(replicaSubEntry2 and replicaAgreementSubentry2). Two new object
classes to control scheduling (replicaEventSchedule and 
replicaTimeSchedule), and their associated attributes, were
defined. Also defined where the replication context exists on the
server, and defined attributes that must appear in the server’s 
root DSE entry as part of the LDUP information model.

Clarified the notion that the updateVector is a replicated 
attribute and should be treated as such. Note that it has CSN
information for its attribute values. Also introduced the notion
that replicaAgreementSubentry2 entries represent constraints to
what is, by default, "immediate" replication session initiation.

(The following will be clearer if the reader refers to the
powerpoint presentation, slide 5, that is attached in the
proceedings).
Attributes in rootDSE (in dark blue oval) are there to define
the various replication contexts that exist in the server.
There are two replicas on this server with separate replication
contexts. There are two replica agreements for each replication
context. There are ldapSubEntry derivatives just below the
replication contexts that represent information about replication agreements. The default behavior is "fully-connected", "immediate"
replication. Note that there is a further constraint of a time
schedule for one of the replication agreements.  Added attribute replicaSubentries to point to the replica agreements.

Q: Why did you need the second attribute pointing to particular
   replica subentries?
A: Because there is a replication agreement for each replication
   context. One attribute specifies which replication area (naming 
   context), other specifies which replica subentry is being used
   (i.e., which policy is being used).
Q: does that lead to a relational integrity requirement on the 
   administrator?
A: Yes, but it was thought that the benefit outweighed the 
   extra overhead.

Comments that have been received are being incorporated into the 
next version of the draft. These include:

  - OIDs are incorrect
    (Will be updated in next revision)
  - Attrs1 and attrs2 attributes in replicaEventSchedule are too 
    generically named
    (Will be renamed to attrsForClassX)
  - A couple object classes that have been made obsolete were 
    accidentally removed from the draft
    (Will be fixed in next revision)

Ed Reed then noted that the policy information regarding 
scheduling and event-driven operations could be more richly 
defined. Policy is a "rich opportunity". The current draft has 
only defined a limited set of scheduling capabilities, the 
limits being limits on the time periods for which replication 
suppliers would initiate and define replication sessions. The 
authors haven’t defined how a replica would accept such 
connections. This was because the authors were looking forward
to a richer policy language that would be available in the future,
and to not preclude the use of such a language. Event-driven 
includes a default time period for defining replication. Policy-driven
includes a ptpCondition from RFC3060 (periodic, not event driven). 
These would be implemented as a control. ReplicaSubEntry has a 
Boolean that specifies offline or online – won’t start replicating 
till you turn it on.

The Info model document could be revised in a month – everything is 
editorial EXCEPT that it also depends on subentries. [editor's note:
the fate of subentries will be decided soon]. 

5) LDAP Subentry Schema

http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt

Ed Reed reported on this work. 

Version –8 created after last IETF in Minneapolis. Removed the 
inheritance model that was in the previous version of the draft and 
added an administration model which was a subset of X.500, except 
that it used LDAPSubentries. Autonomous admin area may have 
specific admin subareas, which may be (but don’t have to be) 
partitioned into smaller areas for specific uses.

There was quite a bit of discussion on subEntries on the list. Ed 
notes that LDAP subentries were created, consciously, as a subset
of the X.500 subentry model. So, why not just use X.500? There are
three main reasons.

First, wanted to use name subordination to describe explicit 
relationships through nested subentries – this approach seemed 
more elegant than maintaining a set of DNs, and it is easier to 
maintain referential integrity. X.500 doesn’t allow nested 
subentries today (though this may be relaxed in the future through 
means such as families of subentries). So without nesting, it 
would require "dn-pointers" which bring other problems with respect 
to referential integrity.

Second, naming flexibility – X.500 mandates the use of CN for 
naming, and some people in the LDAP community want more flexibility.

Third is scooping: purpose of LDAP subentry is to define a profile of X.500. It doesn’t allow refinements, and Ed is worried that this is too powerful a tool for too naïve an audience.

This last point leads into refinement. It was thought that the 
X.500  refinement mechanism may be too powerful a gun to hand 
to 65,000 MCSEs and NCSEs to use to manage file access 
(for instance), must less to the managers and secretaries to 
whom they delegate ACI management to.

The full X.500 administrative model provides DSETypes to mark 
special entries. The X.500 administrative model also explicitly
expects SINGLE master today ...and therefore some invention is 
required to go with LDAP MULTI-master. 

On the other hand, if X.500 subentries -> DSETypes, and
DSETypes -> DSP (chaining), and DSP -> multimaster DISP, and
multimaster DISP -> interoperable HOB, then maybe a converged 
X.500/LDUP is the distributed directory service that is needed.

There are two obvious alternatives:

  - just do X.500, which implies that we form a new workgroup to
    achieve X.500/LDAP/LDUP convergence
  - adopt the useful subset defined in ldapSubEntry work. This
    means that we should work with the X.500 group to converge 
    on nesting, and decide whether CN (or some other attribute)
    should be used naming

Kurt: in order to split some issues apart to effectively manage,
you need SOME sort of "refinement mechanism" - without it, you can't
do delegation and coalescing of policy information. Requirements for
access controls also seem to require a "refinement mechanism".

Ed: Disagrees. For example, Novell and Microsoft don’t do this.

Kurt: Then it isn’t compliant with 2820. In addition, if 
access control chooses another mechanism, then this would be 
bad. Kurt volunteers to define an alternate approach.

Mark Wahl: RFC 2251 does not REQUIRE you to implement X.500
subentries/refinement. The use of CN is a bad thing for 
applications that want to automatically create these things 
without collision. Why not choose some "subset" of the 
refinement in the X.500 subentry refinement capability?

Ed: we did - the "NULL" refinement implies the "whole subtree
until the next subentry"

LOTS of discussion on this item, but no concensus was raised.
Therefore, this discussion will be taken to the list. John and 
Chris will arrange a meeting with the LDAPext and LDAPbis 
co-chairs to mutually discuss what should be done regading
LDUP subentires. The implication to this (the infomod) document
is that ALL replication agreement infomration would have to be 
under a single "root entry" (i.e. peers) and delimited by 
(perhaps) names of the subentries.

This boils down to:
  - allow nesting - X.500 shouldn't have a problem
  - allow other naming besides cn - X.500 shouldn't have a problem
  - not have refinement - X.500 probably would NOT like this ...
    and thus LDAP would diverge from X.500 ... and this is not good

Skip Sloan (X.500 rep) indicated that X.500 would be amenable to
adding nesting and non-cn naming

Action: co-chairs will respond to the list after the minutes. 
Need to talk with other co-chairs about an overall strategy.

6) General Usage Profile for LDAPv3 Replication

http://www.ietf.org/internet-drafts/
draft-ietf-ldup-usage-profile-01.txt

<no editors present>

Steven: what is the document actually trying to accomplish? It 
doesn’t seem to address how LDUP is used. It instead seems to
describe some of the operating characteristics/concerns when
using replication. It should instead show what/how replication 
SHOULD be used/set up.Example: unordered changes – if someone 
is using an implementation with unordered changes, then they 
haven’t implemented URP and aren’t using the replication 
architecture.

Kurt: thought that this was supposed to be an applicability 
statement to define the minimum requirements needed to support 
LDUP. This document clearly doesn’t do this (in fact, it is 
informational). So where is the applicability statement, we need one.

Chris: this seems to be correct, this info will be taken back to the
authors. You should post these comments to the list also.

7) LDAP Client Update Protocol

http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-01.txt

Mark Wahl reported on behalf of the authors that the LCUP changes
from –00 to –01 consisted of adding an OID to specify the algorithm 
for making the cookie. Also added an operational attribute to 
specify the supported algorithms.

Kurt: can this document define A cookie format, leaving it open to
allow other drafts to create OTHER cookie formats - and then let 
this workgroup attempt to limit the set of cookie formats defined.

Roger Harrison - sounds like we're starting to try to allow 
potentially more than one server to be able to interpret a single
cookie instance ... and this is not the intent.

Rick recommends that we declare this explicitly OUT of scope

Jim Sermersheim: there is some language implying that re-connection
(to some other server possibly) and re-start/re-use of the cookie
is supported

Kurt: we need to narrow the focus of what LCUP specification does;
maybe explicitly add that the cookie is NOT reusable to a 
different server

One technical comment: why isn’t the list of supported cookies in 
the RootDSE. It seems reasonable to make this change.

OID issue:
  1) don’t standardize and hope for the best
  2) standardize a minimum subset of OIDs that vendors must 
     support, which gives you interoperability among the OIDs,
  3) LCUP cookies don’t matter (VLV cookie interoperability).

Kurt: have LCUP specify "a" cookie format, and leave it open for 
other cookie formats to be specified in the future.

Co-Chairs will have to re-examine the mailing list and make a recommendation.

Some additional concern as to what we allow the cookie to be used 
for. But first, we need to define the applicability of first, 
the protocol, and second, the cookie. For example, if it is just
one client and one server, then you wouldn’t need to define the 
format of the cookie at all. On the other hand, if you want to 
share the cookie between servers, that’s a completely different 
case and would probably require the specification of a cookie.

8) Adding LCUP Cookie Scheme(s) to LDUP WG Charter as Deliverables?

The discussion of this item was merged with item 7).

9) LDAP Access Control Model Work

The focus of this agenda item was to ferret out any concerns that 
people had on the ACM work to ensure that these would not affect LDUP.

It was noted that the model document does not define how access 
control will work in a replicated environment. The LDUP general 
usage profile document is a good job of indicating lots of things
(besides access control) that are affected when replication is added
to the environment.

Open question to group by Chris Apple with respect to what
outstanding problems people have with the access control model
and replication?

Kurt: model document still lists access control as not defined 
how access control works in a replicated environment. There is 
a need for LDUP folks to read and comment on the current 
ACL model draft.

10) Definition of an object class to hold LDAP change records

Mark Wahl reported that this draft by Ludwic describes the old 
changelog format. It is useful in some of the previous sync tools, 
such as persistent and triggered search, that have now been 
folded into LCUP. This document is not suitable for a server that
is doing LDUP with multi-master. However, if you are doing LCUP 
or another constrained environment, it is useful.

It was proposed that this should be progressed as an INFORMATIONAL
RFC. LDUPers are encouraged to comment on it.

10) General Charter Review

The following updates can be made to the charter:

  - update the repl reqs to WG last call date
  - update reconciliation procedures to WG last call 
    to be August
  - update the multi-master replication profile,
    master-slave replication profile are by the 
    same authors as general usage profile - so need
    a new date for all or drop them
  - information model: +30 days from decision on ldapSubEntry
    (i.e., if ldapSubEntry stays, then this document will be
     submitted in 30 days from that decision; otherwise, a 
     new approach and date will be defined)
  - architecture: +30 days from information model
  - LDAP mandatory replica management draft "up in the air" - need
    to get current status from Ryan Moats
  - LDAP update replication protocol to be published +30 days from
    now (8/7/2001)
  - LDAP Extended Ops for Framing can go to WG last call, though
    it is co-dependent on Kurt Zelienga's grouping I-D, so they
    will be last called together within 30 days from now
  - LCUP I-D to WG last call no later than December 2001

The time left in the meeting was spent on discussing how to better
align with X.500.

Chris Harding (from The Open Group) stated that many customer 
requirements are requesting alignment between X.500 and LDAP.
How's it going to happen?

Ed: it is time and appropriate for the LDAP community to reciprocate
with what the X.500 team has started, i.e. LDAP alignment. One thing
to help interoperability - where solutions were created that are 
aligned closely with X.500 solutions - we shouldn't create new ones.

Skip Sloan - common solutions are good - but where not practical,
proper subsets are preferable.  Where not possible, please advise
Skip that a difference exists and LDAP has gone "above" X.500.

Ed Reed and Kurt Zelienga recommended NOT making this a part of

The End.