headers
Steven Legg | 1 Feb 1999 03:30
Picon
Picon

Re: ldup crp draft comments: add entry


John,

> Steven,
> 
> Thanks for getting such an excellent draft out. I found parts of
> it difficult to follow, but the flow charts in the x.500 document
> helped answer most of my questions.

When you get the time, let me know which bits were difficult and I'll see what
I can do to improve those sections.

> But, I still have a few things I'd like you to clarify for me, and
> hopefully you'll address them in the document too.
> 
> Firstly, Add Entry. I don't fully understand why each entry has a
> set of addition CSN's, rather than a single CSN. Could you describe
> a scenario which shows why this is useful? I'm not certain which
> section of the document this would appear in. Perhaps near the start
> of the 5.2.x section.

The extra CSNs arise from supporting the possibility that an entry could be
re-added, as an administrator action to correct a mistake, or appear to
be re-added, because entry moves can be translated into adds and removes for
partial replicas.

Life would be much easier if an entry never reappeared since any replication
primitives which showed up after an entry is deleted could simply be ignored.
However if an entry is permitted to reappear then we need a consistent way
to deal with the updates that are timestamped between, and after, an entry
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Legg | 1 Feb 1999 03:54
Picon
Picon

Re: ldup crp draft comments: add entry


Alan,

> I am afraid I found the whole concept a worry. 
> The issue of CSNs, creation CSNs used as well as the entry's standard
> operational attributes re date/time created and modified is unclear.
> Are these correlated, checked, ignored or replaced by any CSN activity?

I already had a note to myself to add a description on how to manage
operational attributes to the next draft of the URP document.
The treatment is straightforward. When a DSA processes a user update request
it will also create and/or modify operational attributes in the entry. These
changes are represented by additional replication primitives, which are
timestamped with the same CSN as the rest of the primitives resulting from
the update operation. For the purposes of update reconciliation the values
of the operational attributes have no special meaning. They are sorted out
by the update reconciliation procedures in the same way as any user
attribute would be. Receiving and applying replication primitives from
another master DSA does not cause a DSA to revise the create/modify timestamps
or creator/modifier names. These revisions are already explicit in the
primitives being received.

Regards,
Steven

> 
> Does this mean that an entry in one DSA when it is modified has its
> date/time modified  and modifier name updated - the modification is then
> pushed through this protocol to other DSAs that have could have a
> conflict in some DSAs and not in others - with and their date time
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Lloyd | 1 Feb 1999 04:25
Picon

RE: ldup crp draft comments: add entry

Stephen - Comments in line.

> -----Original Message-----
> From:	Steven Legg 
> Sent:	Monday, February 01, 1999 1:55 PM
> To:	Alan.Lloyd <at> OpenDirectory.com.au
> Cc:	ietf-ldup <at> imc.org
> Subject:	Re: ldup crp draft comments: add entry
> 
> 
> Alan,
> 
> > I am afraid I found the whole concept a worry. 
> > The issue of CSNs, creation CSNs used as well as the entry's
> standard
> > operational attributes re date/time created and modified is unclear.
> > Are these correlated, checked, ignored or replaced by any CSN
> activity?
> 
> I already had a note to myself to add a description on how to manage
> operational attributes to the next draft of the URP document.
> The treatment is straightforward. When a DSA processes a user update
> request
> it will also create and/or modify operational attributes in the entry.
> These
> changes are represented by additional replication primitives, which
> are
> timestamped with the same CSN as the rest of the primitives resulting
> from
> the update operation. For the purposes of update reconciliation the
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Merrells | 6 Feb 1999 02:40
Picon

Re: CRP- Not present distinguished values


David W Chadwick wrote:
> 
> Steven Legg wrote:
> 
> > David,
> >
> > I think there are two things we are debating here. One is the question of
> > what to do with a delete of a distinguished value. The current proposal
> > saves up the delete indefinitely until the value becomes non-distinguished.
> > Your counter proposal is to ultimately ignore any delete which occurs while
> > a value is distinguished.
> 
> Absolutely.
> This is because the existing X.500/LDAP service forbids a ModifyEntry
> operation to delete a distinguished attribute value. You are proposing to sanction
> an operation that has always been forbidden. I see no reason to support this.

I don't think that Steven is suggesting that this operation should be
supported for LDAP clients, but that it should for LDRP clients. Because
of the interleaving of operations during replication you could get into
this situation of having to delete a distinguished attribute value. To
preserve the LDAP consistency model we mark the value as deleted but
still present because it's distinguished... and once the value becomes
no longer distinguished, because of a ModRDN, then the value can be
really deleted.

Consider an example. 

Time 0 : An entry exists on two updatable replicas A and B.
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Merrells | 11 Feb 1999 00:16
Picon

ldup urp draft comments


Here's some feedback on the URP draft...

1) At first I didn't realise why the distinguished-present and
   distinguished-not-present tags were needed.  There is a paragraph
   which explains this. But, I didn't really get it until I worked
   out the example I mailed out earlier.

2) In the Unique Identifier section it states that both the root and
   lost+found entries will have pre-allocated known UUIDs.  This 
   seems like an implementation detail.

3) The draft states that a replication log will maintaned. The LDUP
   architecture delibrately avoids saying how or where updates should
   be stored.  This is implementation defined.

4) I like the idea of creating a glue entry under the lost+found 
   entry to represent an entry that has been deleted and it's 
   children have become orphaned.  This make it much easier for
   the administrator to recover a whole subtree.

5) The document describes how each LDAP operation is broken down
   into primitives, and provides an algorithm for how each primitive
   is applied to the consumer.  But, I think there's some subtle
   things hidden in the code, which should be explained:

5a) The RenameEntry function assumes that if the entry has children
    that they will move with the parent and not stay where they are.
    I know this may sound odd... but in our server, and I think some
    others, this isn't actually a natural thing to do. Stating the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steven Legg | 11 Feb 1999 08:13
Picon
Picon

Re: ldup urp draft comments


John,

John Merrells wrote:
> Here's some feedback on the URP draft...
> 
> 1) At first I didn't realise why the distinguished-present and
>    distinguished-not-present tags were needed.  There is a paragraph
>    which explains this. But, I didn't really get it until I worked
>    out the example I mailed out earlier.

I'll take this as part of the general request to put more about the
rationale behind the design into the URP draft. It isn't conventional to
put such justification into a standard specification but I can see the
value of it. I will seek to isolate and clearly mark any discussion of
design choices so that no one gets confused about exactly what is specified.

> 2) In the Unique Identifier section it states that both the root and
>    lost+found entries will have pre-allocated known UUIDs.  This 
>    seems like an implementation detail.

An implementation detail for the realization of the protocol perhaps.
I was thinking it would be useful to be able to tell the difference between
an ordinary move and a move to Lost & Found. One way to do that is to 
to use a specific Unique Identifier for Lost & Found. An alternative is to
indicate the difference in the protocol. Maybe we don't need to be able to
tell the difference anyway. We have this concept of a Lost & Found entry
but we haven't nailed down exactly where it is yet so the question is
somewhat open.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Apple | 11 Feb 1999 22:12
Picon

WG drafts

I was looking at the WG web pages and noticed that there are
no I-Ds reflected there.

The reason for this is that all drafts you've been discussing
are not under the LDUP WG part of the I-D namespace.

Please send a note to the I-D Editor about any documents that
are really WG deliverables indicating that the file name
be changed from:

	draft-<author_name>-*.txt

to:

	draft-ietf-ldup-*.txt

Thanks!

Chris Apple
Permalink | Reply | 0 comments |
headers
Alan Lloyd | 15 Feb 1999 00:34
Picon

RE: ldup urp draft comments

comments in line.

> -----Original Message-----
> From:	Steven Legg 
> Sent:	Thursday, February 11, 1999 6:13 PM
> To:	merrells <at> netscape.com
> Cc:	ietf-ldup <at> imc.org
> Subject:	Re: ldup urp draft comments
> 
> 
	snip

> DISP has a concept of information planes. Each replication agreement a
> consumer DSA has with a supplier DSA corresponds to one plane of
> information
> within the consumer DSA. Think of each plane as a separate virtual DSA
> within
> one physical DSA. The updates for a particular agreement will always
> be sent in order but if a consumer DSA has two or more agreements
> covering
> the same set of entries (e.g. secondary shadowing through differing
> intermediary DSAs) then it may potentially see the updates out of
> order
> when viewed without regard to the agreements. 
> 
	Is this theory?
	In the real world - one would direct a replica update from a
master portion of the DIB to those replica nodes that require it. ie its
in the system design that determines this. I think one would be guilty
of poor system design if one directed two or more DISP updates with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 18 Feb 1999 18:38
Picon
Favicon

I-D ACTION:draft-ietf-ldup-urp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Duplication/Replication/Update Protocols 
Working Group of the IETF.

	Title		: LDUP Update Reconciliation Procedures
	Author(s)	: S. Legg
	Filename	: draft-ietf-ldup-urp-00.txt
	Pages		: 27
	Date		: 17-Feb-99
	
   This document describes the procedures used by directory servers to
   reconcile updates performed by autonomously operating directory
   servers in a distributed, replicated directory service.

   These procedures are a joint development of the IETF and ITU-T for
   use in LDAP directory replication (LDUP), and the X.500 Directory
   Multi-master Replication Protocol (DMRP) [N11034].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-urp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Legg | 19 Feb 1999 07:07
Picon
Picon

Re: ldup urp draft comments


Alan,

Alan Lloyd wrote:
> 
> comments in line.
> 
> > -----Original Message-----
> > From:	Steven Legg 
> > Sent:	Thursday, February 11, 1999 6:13 PM
> > To:	merrells <at> netscape.com
> > Cc:	ietf-ldup <at> imc.org
> > Subject:	Re: ldup urp draft comments
> > 
> > 
> 	snip
> 
> > DISP has a concept of information planes. Each replication agreement a
> > consumer DSA has with a supplier DSA corresponds to one plane of
> > information
> > within the consumer DSA. Think of each plane as a separate virtual DSA
> > within
> > one physical DSA. The updates for a particular agreement will always
> > be sent in order but if a consumer DSA has two or more agreements
> > covering
> > the same set of entries (e.g. secondary shadowing through differing
> > intermediary DSAs) then it may potentially see the updates out of
> > order
> > when viewed without regard to the agreements. 
> >
(Continue reading)

Permalink | Reply | 0 comments |

Gmane