David Chadwick | 1 Mar 16:56 1999
Picon

Re: CRP- Not present distinguished values

Date sent:      	Fri, 05 Feb 1999 17:40:08 -0800
From:           	merrells <at> netscape.com (John Merrells)

John
Apologies for my delay, I have been away for 2 weeks and am 
catching up on the backlog

My proposal was to mark the delete operation as "ignored" in the 
log, rather than to mark the RDN as deleted. Here's how it would 
work with your example

> Consider an example. 
> 
> Time 0 : An entry exists on two updatable replicas A and B.
>          It has a dn of x=1 and one attribute x with values 1 and 2.
> 
> Time 1 : A receives a ModRDN to change the dn to x=2
> 
Same

> Time 2 : B receives a Delete of x=2
Same

> 
> Time 3 : B replicates to A.  Since x=2 is distinguished we can't delete
>          it (yet) so it's marked as distinguished but deleted.

The delete is marked as ignored by A, since you cannot delete a 
distinguished value.

(Continue reading)

John Strassner | 1 Mar 22:31 1999
Picon

LDUP Meeting Time

LDUPers,

just got word back from the IETF - we are schedule to meet
on Thursday, March 17 at 1300-1500

Other groups scheduled at that time:
  dhc, conneg, saag, manet, disman, rsvp, mboned

regards,
John

John Strassner | 2 Mar 16:59 1999
Picon

About the LDUP Meeting time...

  ...it is Thursday the 18th (not Wed the 17th) at 1300-1500

Other groups scheduled at that time:
  dhc, conneg, saag, manet, disman, rsvp, mboned

regards,
John

Steven Legg | 3 Mar 08:57 1999
Picon
Picon

Re: CRP- Not present distinguished values


David,

> Date sent:      	Fri, 05 Feb 1999 17:40:08 -0800
> From:           	merrells <at> netscape.com (John Merrells)
> 
> John
> Apologies for my delay, I have been away for 2 weeks and am 
> catching up on the backlog
> 
> My proposal was to mark the delete operation as "ignored" in the 
> log, rather than to mark the RDN as deleted. Here's how it would 
> work with your example
> 
> > Consider an example. 
> > 
> > Time 0 : An entry exists on two updatable replicas A and B.
> >          It has a dn of x=1 and one attribute x with values 1 and 2.
> > 
> > Time 1 : A receives a ModRDN to change the dn to x=2
> > 
> Same
> 
> > Time 2 : B receives a Delete of x=2
> Same
> 
> > 
> > Time 3 : B replicates to A.  Since x=2 is distinguished we can't delete
> >          it (yet) so it's marked as distinguished but deleted.
> 
(Continue reading)

John Merrells | 4 Mar 21:23 1999
Picon

ldup arch draft


Ah... I resubmitted the architecture draft with the
new name draft-ietf-ldup-model-00.txt... but I failed
to note that the requirements of the boiler plate text
have changed. So, they bounced it :-( See below... I
guess we should go with option one.

The draft was basically unchanged, so no big deal.

John

=====

Since your Internet-Draft does not comply with our
requirements (with the newly updated boilerplate),
please check the new template:

        http://www.ietf.org/ietf/1id-guidelines.txt

All Internet-Drafts should begin with ONE of the following three
statements:

        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.

        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026 except for the
        right to produce derivative works.

        This document is an Internet-Draft and is NOT offered in
(Continue reading)

David Chadwick | 5 Mar 13:14 1999
Picon

Re: CRP- Not present distinguished values


Steven,
thankyou for your long explanation.

> > The name is changed to x=1, and x=2 either remains in the entry, or is
> > deleted if asked to be in the ModifyDN operation. With your model you
> > can argue that this user would be mistified if he changed the RDN, did
> > NOT ask for the oldRDN to be deleted, but found that it was.
> 
> This sort of mysterious side-effect is already a possibility with current
> single master setups. Between the rename and the subsequent read which
> would be necessary to detect that the old RDN had been deleted anything
> could have happened to the entry.

This is different, as it is the effect of additional operations happening 
in rapid succession, that have not been considered in either of the 
previous cases. It is obviously the case that two users can 
sequentially make opposing updates very close together, that will 
cause one of both of them to be mystified.
But what we are considering here, is that way in the past (it could 
have  been years ago) some user deleted a value that was the RDN, 
and this delete is remembered by marking the RDN deleted. Then 
years later a user changes the RDN, asking to keep the old value, 
but find that it is deleted.

> If on-change replication agreements are
> used between master DSAs then I would expect the chance of the user
> detecting some wierdness due to URP to be only slightly greater than the
> chance to see something weird due to the absence of multiple operation
> transactions in LDAP and X.500.
(Continue reading)

Alan Lloyd | 7 Mar 16:15 1999
Picon

RE: CRP- Not present distinguished values

Some (nicer) comments. 

----------
From: David Chadwick
To: Steven Legg; ietf-ldup <at> imc.org
Sent: 3/5/99 10:14:30 PM
Subject: Re: CRP- Not present distinguished values

Steven,
thankyou for your long explanation.

Alan: Thanks David - this is the real issue - explained very well.

I think this is the crux of the matter. We have two models. Either

a) there is one definitive logical virtual master entry, which is the 
result of applying all the updates in time related order using the 
existing rules for atomicity. Each update is played in sequence 
against this virtual entry by each replica, thereby ensuring that all of

them are always in sync after they have applied the same updates, 
but this will require rewinding the update logs as you say, if an 
earlier one suddenly arrives, or...

b) there is no definitive logical virtual master entry, but rather there

are a lot of replicas that each hold part of the full picture depending 
upon which updates were first applied by it, and  no replica knows 
what the full picture is, but by applying the updates in the more or 
less random order that they are received, and using the URP, we 
(Continue reading)

Sanjay Jain | 10 Mar 03:32 1999

Re: draft-ietf-ldup-infomod-00.txt


Ed Reed wrote:

> Please publish the attached work group document for the LDUP working group...suggested name is
draft-ietf-ldup-infomod-00.txt.  It contains editorial changes (work status, document name, email
addresses, expiration date changes) from draft-reed-ldup-infomod-00.txt.

Ed
    Few clarifications/comments:

    1. In section "2. Abstract": what's the meaning of "common administrative
    authority" ?

    2. In section "2. Abstract" (dynamic generation of LDAP referrals) and in
    section "5. Directory Knowledge" (replica info used for name resolution
    operations): Do we need some examples in this doc which illustrate how
    replica and replica agreements info can be used for these purposes ?

    3. In section "5. Directory Knowledge":  Why do we need 'nameContext'
    object class ?  Why is DSE name context attribute not enough to identify
    naming context root objects ?

    4. In section "5. Directory Knowledge":  In "the LDAP search filter which defines
    what object classes it holds", should it be just objects instead of object classes ?
     LDAP search filter can create holes (non-leaf entries missing while their children
     are present) in the DIT.  Somewhere we need to specify how searches, additions
     etc. need to be handled in such DITs.  E.g. if somebody tries to add an entry below
     a non-exisiting node, what happens ?  In searches, if base object is missing but children
     are present, what should be the behavior.

(Continue reading)

Ed Reed | 13 Mar 05:20 1999
Picon

Re: draft-ietf-ldup-infomod-00.txt

My revision, too, was clobbered by the RFC2026 language requirement.  You have, in a previous note, the doc,
though.  It will be edited further before resubmission.

>>> "Ed Reed" <ED_REED <at> novell.com> 02/26/99 02:50PM >>>
Please publish the attached work group document for the LDUP working group...suggested name is
draft-ietf-ldup-infomod-00.txt.  It contains editorial changes (work status, document name, email
addresses, expiration date changes) from draft-reed-ldup-infomod-00.txt.

Synopsis:

Directory schema is extended to provide object classes, subentries, and attributes to describe areas of
the namespace which are under common administrative authority, units of replication (ie, subtrees, or
partitions of the namespace, which are replicated), servers which hold replicas of various types for the
various partitions of the namespace, which namespaces are held on given servers, and the progress of
various namespace management and replication operations.  Among other things, this knowledge of where
directory content is located will provide the basis for dynamic generation of LDAP referrals for clients
who can follow them.

Ed Reed

----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320

Chris Harding | 15 Mar 21:15 1999
Picon

Open Group Directory Program

Hi -

As those of you on TOG mailing lists will already know (and my apologies
for telling you again), The Open Group has started a new Directory Program
which will carry out the activities planned to be done by the Internet
Directory Consortium, and more.

You can find details at http://www.opengroup.org/directory/ or, if you are
at the IETF this week, I am there also and will be happy to talk with you
about it.

Regards,

Chris
+++++

-------------------------------------------------------------------------
           Chris Harding
  T H E    Development Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:c.harding <at> opengroup.org   Ph: +44 118 950 8311 x2262
           WWW: http://www.opengroup.org    Fx: +44 118 950 0110  

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.
-------------------------------------------------------------------------


Gmane