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

From: Ryan Moats <[email-masked]>
Date: Mon, 19 Nov 2001 16:42:28 -0600

On Mon, Nov 19, 2001 at 05:07:31PM -0700, Ed Reed wrote:
| 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.

Let me see if I parse this right (I have a nascent cold and so I'm
reduced to thinking in terms of short lists:
	1. the LDAP server has to support entryUUID as an operational?
	   attribute
	2. LDUP would specify the entryUUID on new entries via an
	   extendedOP

Am I close? If so, see below.

| 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

This comes as an extension to the first part above: are there going
to be operational attributes that need to be replicated between servers
(entryUUID, creatorsName, createTimestamp, modifiersName, modifyTimestamp
look like the obvious ones)?  Therefore, we need to be able to set
operational attributes and RFC 2251 says 

  "...Servers MUST NOT permit clients to add attributes to an entry unless
   those attributes are permitted by the object class definitions, the
   schema controlling that entry (specified in the subschema - see
   below), or are operational attributes known to that server and used
   for administrative purposes..."

and that creatorsName, createTimestamp, modifiersName and modifyTimestamp
are "automatically by the server and are not modifiable by clients"

Since the LDUP management console is a client, we started wondering if
LDAP will need a change.

Also, I can see that we need to be able to have operational attributes
returned as part of a search.  Now we can do that by listing the operational
attributes specifically, but is that the right approach?
| 
| 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-masked]> 11/17/01 08:43AM >>>
| 
| 
| On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <[email-masked]>
| 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
| 
| 
|

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Nov 2001 20:50:57 -0800

Ryan,

With mutual consent of both protocol peers, extensions can
significant alter the semantics of operations.  IMO, the
specification of a "disable NO-USER-MODIFICATION restriction"
control or a more general "manage replica" control would not
require a change to LDAP "core" specification.  (Some
clarification to "core" documents might be appropriate,
but we can and should defer consideration of and action
on such to LDAPbis.)

Kurt