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

From: "Ryan Moats" <[email-masked]>
Date: 17 Nov 2001 13:43:25 -0000

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: "Ed Reed" <[email-masked]>
Date: Mon, 19 Nov 2001 17:07:31 -0700

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-masked]> 11/17/01 08:43AM >>>

Ryan

---

From: "Ed Reed" <[email-masked]>
Date: Mon, 19 Nov 2001 17:20:56 -0700

I think this depends on "how much change is too much".

There has been so much variation in various vendors implementations of
LDAPv3 that I don't have any trouble at all in asserting, in LDUP, that
certain practices or conventions are expected from LDAPv3 servers that
support LDUP, even if such vary, in minor ways, from the canonical
core specifications.

To provide a "reasonable interpretation" of LDAP data consistency
constraints so that the LDUP protocol and URP can deliver utility to their
users seems "within scope".

Adding a SQL-like "JOIN" operation (which the X.500 community are
looking at, or have done something about), dictating universal support
of "families of entries", and so forth seem "out of scope".  LDUP should
not make such major expectations on solution providers, and should
not dictate their use, or changes to their definitions.  In fact, I don't
even worry too much about whether LDUP can support them.

Transaction support, as we've discussed, belongs in the experimental
arena, in my opinion, so changes to the LDAPv3 core specifications
to support them seem, for instance, out of scope for LDUP to me.

I think the consistency model and URPs ability to support it, or
the changes to it necessary for URP to work, are an important area
of discussion, here.  The Model (Architecture) document includes a
long addendum in which we have attempted to address such questions.
Its review would be welcome.

Bottom line - LDAPv4 is out of scope.  The subtle changes to LDAPv3
to work in a multi-master environment, with the necessary adjustments
to data consistency expectations clients should have when working
in multiple-writer/multiple-replica environments are in-scope.

With that in mind, Kurt's text...

  This group may extend the LDAPv3 "core" specification 
  as necessary to deliver LDAP Replication.  However,
  updating the LDAPv3 "core" specification is beyond scope
  of this working group.

makes sense to me, and is consistent with what I think I'm working to
accomplish.

Ed

Parenthetically, I can see the importance of reaching agreement on this in light
of Kurt's other responsibilities to LDAPv3bis.

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

>>> "Kurt D. Zeilenga" <[email-masked]> 11/16/01 05:56PM >>>

(This is a serious question, I am still trying to figure out
what is beyond scope of this working group.)

Is engineering a version 4 of LDAP within scope?

At 10:32 AM 2001-11-16, Chris Apple wrote:
>That's simple enough to do. We'll add...
>>   This group may update the LDAPv3 "core" specification
>>   as necessary to deliver LDAP Replication.

---

From: "Ed Reed" <[email-masked]>
Date: Tue, 20 Nov 2001 07:25:27 -0700

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