Subject: Re: Draft Minutes for the LDUP WG meeting

From: "Ed Reed" <[email-masked]>
Date: Mon, 10 Apr 2000 08:48:05 -0600

It's actually the cron(1) directory schema I was hoping to avoid, or at least to
punt towards a separate document.  The rationale is this...

1) replicationAgreements may be scheduled in any number of different ways;
2) replicas who initiate replication sessions need to know how to interpret the
schedule policy elements which govern their session initiaion behavior - others
do not need to interpret such data, though it would be usefule for management
purposes for others to set or read such policy information, it's not necessary for LDUP
3) schedule policy information may take many different forms, and each be
represented in many ways - defining just one seems too limiting, and if there
are more than one, each should be in it's own document.

So - that's what's going through my head.  

On the one hand, this is an easy place to reduce scope of the LDUP schema
document - refer to schema policy information entries whose schema is defined
elsewhere.  

On the other hand, is there some real interoperability issue?  It doesn't "feel" like
it to me - ftp doesn't have an interoperability problem because the schedule by
which file transfers are initiated can't be inspected or set via ftp protocols.  Why
then replication?

Thus, my proposal:  scheduling policy information MAY be described in published
schema and be referenced by replicationAgreementSubentries governed by
entries (or groups of entries) using such schema descriptions, but such schema
descriptions are outside the scope of LDUP, and will generally be implementation
specific until concensus develops on what constitutes good schema design for them.

It's a stretch, I know - I'd like to have a couple of schedule policy information 
schemes defined to encourage their use...but again, to have them defined
outside the infomod document itself.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.OnCallDBA.COM

>>> Harald Tveit Alvestrand <[email-masked]> 04/10/00 05:02AM >>>
At 18:56 09.04.2000 -0700, John Strassner wrote:
>Please review and comment asap.
One note, which is to substance, not to minutes (which seem fine):

>Ed notes that the process of trying to describe scheduled
>policy is really hard. We can start to do this by perhaps
>defining a cron-like process with hysteriesis. However, it
>isn't clear that this is suitable for all applications. In
>fact, the Engineering Team is favoring leaving this
>undefined.

OTOH, a specification that allows repeating events, but with no way to
specify their repetition, is incomplete. Incomplete specs are bad,
because we then guarantee noninteroperability.

I suggest stealing a repetition definition from CALSCH, if necessary
limiting it to something easy to implement. (Didn't CALSCH have a draft
on how to represent appointments in LDAP entries?)

If necessary, steal it from the man page of cron(1).

                   Harald

                    Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Apr 2000 19:34:44 +0200

>which file transfers are initiated can't be inspected or set via ftp 

Because replication is trying to define consistency between LDAP servers.
FTP got into a lot of trouble as a basis for mirroring arrangements because 
they did not determine the syntax of a date.

If you don't provide at least one format of a schedule, you say that a 
client from one vendor has no standard way to define a schedule for a 
product from another vendor.

And that means that it has no way of controlling the consistency between 
the servers involved.
That's bad.

                  Harald