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

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
  

At 02:42 PM 2001-11-19, Ryan Moats wrote:

>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 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
>| 
>| 
>|