headers
Chris Apple | 1 Sep 2002 18:49

WG Last Call: LCUP Draft


The purpose of this message is to initiate the LDUP
working group last call on the LDAP Client Update Protocol
draft.

WHAT DOCUMENT?

The document in last call is:

http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for Proposed Standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts Tuesday, September 3, 2002 and will
Last approximately two weeks.

It will end on Tuesday, September 17, 2002 at 1700 ET.

WHAT'S THE NEXT STEP?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jim Sermersheim | 3 Sep 2002 18:48
Picon
Favicon

LCUP Issue: UUID


The syntax of UUID is directory string, and moreover, the matching rule
is case ignore match. I see this as overly limiting and suggest that the
syntax be changed to octet string. This is made even more apparent by
the fact that this document leaves standardization of the value
generation to a future specification.
Permalink | Reply | 1 comment |
headers
Jim Sermersheim | 3 Sep 2002 19:01
Picon
Favicon

LCUP Issue: Cookie problem


Section 4.2 states: "The cookie value MUST be included except when a
client has no stored state; i.e., when the client is requesting a full
synchronization"

It's not clear whether this refers to a cookie in a
ClientUpdateControlValue, and/or a EntryUpdateControlValue , and/or a
ClientUpdateDoneControlValue.

Jim
Permalink | Reply | 0 comments |
headers
Jim Sermersheim | 3 Sep 2002 19:08
Picon
Favicon

LCUP Issue: lcupClientDisconnect result code


The draft defines a new result code called "lcupClientDisconnect". I
think the result code "canceled" defined in Section 7.3 of
draft-zeilenga-ldap-cancel-06.txt serves exaclty the same purpose and
is where this result code should be defined.

Jim
Permalink | Reply | 0 comments |
headers
Kurt D. Zeilenga | 3 Sep 2002 19:22

Re: LCUP Issue: UUID


At 09:48 AM 2002-09-03, Jim Sermersheim wrote:
>The syntax of UUID is directory string, and moreover, the matching rule
>is case ignore match. I see this as overly limiting and suggest that the
>syntax be changed to octet string. This is made even more apparent by
>the fact that this document leaves standardization of the value
>generation to a future specification.

I suggest a couple of comments regarding UUID.

First and foremost, UUID support needs to be mandatory.  The
protocol won't work otherwise.

I also suggest that, instead of returning the UUID as an
attribute value (which are subject to normal access controls),
it should be returned within the control (which *should* be
subject to some kind of access restrictions).  This to
avoid having to deal with no UUID as being a valid
response to a CRITICAL update request.  Instead, if the
server is unwilling to provide the UUID, the CRITICAL
request will fail.

I do believe a specification of how the server represents
UUIDs (and CSNs) in the directory should be standardized,
but suggest this be done in a separate document... as,
if UUIDs are passed in the control, LCUP doesn't depend
on the particulars representation in the DIT.

For the specifications of entryUUID (and entryCSN) I suggest
using either octetString/octetStringMatch or UUID/UUIDMatch
(Continue reading)

Permalink | Reply | 0 comments |
headers
John McMeeking | 3 Sep 2002 19:36
Picon
Favicon

Re: LCUP Issue: UUID


I think that some reasonable uses of the attribute warrant a string
representation.  For example, an application may want to search for an
entry with a specific entryuuid.  And some LDUP conflict resolution
procedures call for renaming an entry to have a DN like "cn=some value +
entryuuid=xxxx".  Constructing such search filters and DNs is much cleaner
if entryuuid has a string syntax.  Granted, a well-written application
should be able to construct search filters and DNs containing binary
values.  Case ignore match may be too restrictive.  Certainly, there is no
reason why an application can't use the entry uuid in the case provided by
the originating server.

That aside, don't we have to define what an entry uuid looks like?  The
remaining LDUP drafts, at least, requires that a given server be able to
generate a entryuuid that is unique across all entries on all servers.  I
don't see how a server can generate a unique entryuuid without knowing the
format or generation algorithm.  If we don't want to specify an algorithm
(DCE UUIDs have been bandied about, but there seems to be some reluctance
to agree to specify them), then we at least need to define a format that
includes the algorithm, and a mechanism for uniquely identifying the
algorithm.  A maximum size would probably be helpful to server vendors so
as to not have to provide a search and storage mechanism (DB table for
example) that has to support arbirary length values generated by other
servers.

Just to get things started, I propose that we use the DCE UUID algorithms,
which have a well defined string representation.  And we should be able to
define a entryuuid syntax with a string representation, which is probably a
bit cleaner than using "directory string" or "octet string."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Liben, Michael (GTS | 3 Sep 2002 19:37
Picon

RE: LCUP Issue: UUID


My vote is to leave it as directory string. I do not see any significant server-side benefit from storing as
an octet string. And a directory string is far easier to debug.

-----Original Message-----
From: Jim Sermersheim [mailto:jimse <at> novell.com] 
Sent: Tuesday, September 03, 2002 12:49 PM
To: capple <at> dsi-consulting.net; ietf-ldup <at> imc.org
Cc: john.strassner <at> intelliden.com
Subject: LCUP Issue: UUID

The syntax of UUID is directory string, and moreover, the matching rule
is case ignore match. I see this as overly limiting and suggest that the
syntax be changed to octet string. This is made even more apparent by
the fact that this document leaves standardization of the value
generation to a future specification.
Permalink | Reply | 0 comments |
headers
Kurt D. Zeilenga | 3 Sep 2002 20:38

Re: WG Last Call: LCUP Draft


A month or so ago, I provided the authors with a laundry
list of technical and editorial comments.  Before I echo
each of these on the list (which I will before the end
of comment period), I like to raise what I consider my
biggest concern.

My biggest concern is that this protocol provide the
client will all the events necessary for it to "synchronize"
update its copy of the fragment of the DIT previously returned
to that which would be returned if the original request would
have been repeated.

In the worst case, a client repeating the original request
may find that the copy "synchronized" by LCUP is MOSTLY changed!

The protocol basically needs not only to send a copy of
all entries which are within scope which have significantly
changed, but also send a list of UUIDs and CSNs of all the
entries which have not changed.  This would not only allows
the client to determine the set of entries which have been
deleted from the fragment, but also determine if an entry
returned but not updated needs to be refreshed.  In which
case, it can request a copy of those entries which it
believes need to be refreshed.  This can be done out of
band with a persist operation.

The persist needs a bit of work as well.  Basically, the
server needs to be required to generate the set of
events necessary for eventual convergence of the client's
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Apple | 3 Sep 2002 22:56

RE: WG Last Call: LCUP Draft


Please do post the laundry list to the WG mailing list. I want to be in
a position to track all issues
raised shortly after the WG Last Call period is over.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple <at> dsi-consulting.net

http://www.dsi-consulting.com

-----Original Message-----
From: owner-ietf-ldup <at> mail.imc.org [mailto:owner-ietf-ldup <at> mail.imc.org]
On Behalf Of Kurt D. Zeilenga
Sent: Tuesday, September 03, 2002 2:39 PM
To: capple <at> dsi-consulting.net
Cc: ietf-ldup <at> imc.org; John Strassner
Subject: Re: WG Last Call: LCUP Draft

A month or so ago, I provided the authors with a laundry
list of technical and editorial comments.  Before I echo
each of these on the list (which I will before the end
of comment period), I like to raise what I consider my
biggest concern.

My biggest concern is that this protocol provide the
client will all the events necessary for it to "synchronize"
update its copy of the fragment of the DIT previously returned
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Apple | 3 Sep 2002 23:43

RE: Access Control Design Team Work Program


I'm running a few days behind on delivering a report to the WG on the
activities of the
Access Control Design Team. The work program schedule previously posted
to the WG mailing
list indicates that there is to be a report of the design team's
activities through the month
of August for discussion in September 2002.

Expect a report on the design team's progress by COB ET Monday,
9/9/2002. I want to give
the design team members a chance to review it for consistency with team
discussions before
posting to the WG mailing list.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple <at> dsi-consulting.net

http://www.dsi-consulting.com

-----Original Message-----
From: owner-ietf-ldup <at> mail.imc.org [mailto:owner-ietf-ldup <at> mail.imc.org]
On Behalf Of Chris Apple
Sent: Wednesday, June 12, 2002 8:29 AM
To: ietf-ldup <at> imc.org
Cc: John Strassner
Subject: Access Control Design Team Work Program
(Continue reading)

Permalink | Reply | 0 comments |

Gmane