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

Yes, Ryan - those are the sorts of "minor adjustments" to the model
to accomodate LDUP.  Essentially, we recognize that a Server
operating against another server is a "special kind of client", which
may, for instance, be operating on behalf of someone else as a
proxy, or may be doing server-to-server like stuff, including replication.

As such, a management console that needs to help debug and repair
replication must also be a special kind of server, able to do things not
allowed to regular clients, like set the creation and modification times
on entries, etc.

I don't think such requires modification to the core specification, either,
and would be happy for notes of such adjustments being possible
or necessary under some conditions to take place in LDAPbis.

Ed

>>> "Kurt D. Zeilenga" <[email protected]> 11/19/01 11:50PM >>>
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
>| 
>| 
>|