Re: LDAPv4? (Was: Updating "core" specification)

Ryan -

w/r/t your item 2, below, I've assumed that (1) the entryUUID "thing"
was something that LDUP adds as an expectation of LDAP servers
supporting LDUP, and you could consider that an extension to the
core specifications, and (2) that management operations would
require and extended operation or control to assert the entryUUID
for an entry being created (like the replicaSubentry and 
replicationAgreementSubentry by a privileged operation).  This
control would invoke logic similar to that used by the server to receive
entries, including their entryUUID attributes, for creation on a replica
from LDUP.

As for 1, I'm unclear - do you mean a need to be able to scan or search
the directory for all operational attributes?  Surely LDUP needs to be
able to scan the local repository for data elements that need to be
replicated (in the case of a state-base replica scheme, at least), and
certainly a management application console might make good use of
such a thing.  But I don't guess I see that as a fundamental change
to the LDAP data model, as much as a desired behavior in servers
supporting LDUP.

I'll comment on Kurt's text separately.

Ed



=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Ryan Moats" <[email protected]> 11/17/01 08:43AM >>>


On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <[email protected]>
wrote :

> 
> All editors should respond with their opinions on Kurt's current text
> proposal for clarifying the charter to the WG mailing list ASAP.
> 
> I believe it reflects the strategy that we currently are
> pursuing because of LDAPv3 installed base at the time
> of initial charter creation. However, I want to hear from
> the editors if this language is too constraining based on
> what we know about the problems we still have to solve.
> 
> Chris.

I will quote from my mandatory replica announcement mail
(http://www.imc.org/ietf-ldup/mail-archive/msg01209.html) where
we ask at least 2 points where the core specification may need a
change:

| 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
| operational attributes as part of this operation? If so, LDAP will need
| a change.
| 
| 2. Section 4.6 currently requires that all replicaSubentries representing
the
| same server have the same entryUUID.  How is this accomplished?

I suspect that as we get deeper into MRM, we will turn up additional
places where the core specification may need changing, so I can't see
the core specification being "immutable".

Ryan