Subject: comments on draft-zeilenga-ldup-sync (was Re: LDAP Client Update: consideration of alternative proposals)

From: Ryan Moats <[email-masked]>
Date: Sun, 1 Jun 2003 20:36:32 -0500

Well I've re-looked at these both and I've got concerns/questions about
each of them.  This first piece of mail addresses one process concern
(in two parts) and a technical concern that I have about
draft-zeilenga-ldup-sync-02:

Since the working group decided that replication protocols
should be experimental and this document is standards track, I'm
uncomfortable with the inclusion of "lightweight master-slave replication" 
in the possible use list.

Kurt has pointed out:

| "When I said:
| >While Jong and I certainly intend to use LDAP Sync as a basis
| >for single-master replication, this I-D does not attempt to
| >detail how LDAP Sync might be used for single-master replication.
| >(We saved that for a future draft.)
| 
| my point was that specification how a future LDAP Relication
| specification might use LDAP Sync is beyond the scope of
| draft-zeilenga-ldup-sync as draft-zeilenga-ldup-sync is
| intended to be a complete technical specification of the
| LDAP Content Sychronization Operation (a LDAPv3 client update
| protocol).  Jong and I do believe draft-zeilenga-ldup-sync
| is complete."

This is all well and good, but if a standards track document is going
to include "lightweight master-slave replication" as a possible use,
then said document should make reference to how it meets or does not
meet RFC 3384.

I could also live with that possible use being removed and introduced
in a self-contained experimental draft.

My technical concern is that this draft does not discuss the
implications of each client having an open connection to the server.
Sockets are one of the more precious OS resources, and so there needs to
be an applicability statement about this as well as a discussion
of what happens what a server terminates a persistent connection when
conserving resources.

Ryan

---

From: Ryan Moats <[email-masked]>
Date: Sun, 1 Jun 2003 20:50:36 -0500

Well I've re-looked at these both and I've got concerns/questions about
each of them.  This second piece of mail addresses one technical/process
concern I have with draft-ietf-ldup-lcup-05.txt.

There was a suggestion (from me) that the initial backoff period be
specified with the lcupResourcesExhausted error.  This had some support,
but I have never seen a reply on this issue.  

I still think that having the server specify the initial backoff time
(via an additional control) is superior to the current proposed method.

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 03 Jun 2003 17:15:00 -0700

At 08:37 AM 5/29/2003, Chris Apple wrote:
>Perhaps one source of difficulty in discussions
>related to this topic is that there is not
>agreement between yourself and the editors
>of LCUP as to how broad a range of applicability
>is appropriate for the LCUP deliverable?

It's my opinion that LCUP deliverable should be generally
applicable to directory applications needing content
synchronization facilities.  Both drafts seem to have the
same applicability in terms of directory applications they
apply to, how they differ significantly in the kinds of
constraints they place on their implementations.

I use the term constraint here instead of requirement to
highlight the distinction of fulfilling a need of the
directory applications versus of fulfilling a need of the
design of a protocol.

Our basic application requirement is that protocol provide
efficient and effective content synchronization, with modes
for polling for changes and listing for changes.  Efficient
implies a need to manage protocol exchanges to minimize
traffic in most cases while generally avoiding "overly"
chatty behavior.  Effective implies a need for a reasonable
level of data consistency.

Applications could care less of whether their requirement
was met using a history based approach or using state
indicators based approach, that's an server implementation
detail to them.   Hence, draft-ietf-ldup-lcup need for
servers to maintain and use history information is not an
application requirement but a design constraint.

I consider the draft-ietf-ldup-lcup's history design
constraint unreasonable.  This constraint certainly will
will have an impact on its wide adoption as a technical
solution to the general problem.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Thu, 5 Jun 2003 04:45:56 -0400

One goal in writing applicability statements
is to define constraints on how a particular protocol
should be used. You are defining different types of
constraints below. You can call one thing applicability
and one thing a constraint, but with respect to a protocol
specification that references requirements in an informative,
rather than a normative way, they really do and should
have the same effect on the protocol: to describe the
scenario(s) in which its use is considered appropriate,
scalable, efficient, effective, etc.

One type of constraint relates to the types of
applications for which LCUP's use is considered
appropriate. Another type might be related to
server design. There are many others...

I do not dispute that you have an opinion which is
counter to those of the authors of LCUP about the
historical constraint present in their document.

I do not see support for your arguments on the
mailing list that the LCUP draft's applicability
statement is flawed.

To keep this local instance of IETF process open and
fair with respect to LCUP and other LDUP deliverables,
we should let the consumers/users of this technology
decide if they are willing to live with the constraints
in such an applicability statement during an IETF Last Call.

And the Area Directors/IESG will have their say as well
before it gets there.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Tuesday, June 03, 2003 8:15 PM
To: [email-masked]
Cc: 'Ramsay, Ron'; [email-masked]
Subject: RE: LDAP Client Update: consideration of alternative proposals

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Thu, 05 Jun 2003 09:23:03 -0400

> (via an additional control) is superior to the current proposed method.

The response that Rich Megginson posted as part of the LCUP last call 
reply basically says that clients have sufficient flexibility. But 
thinking about this again, I think this is a valid concern and that it 
would be an improvement to have the server specify the initial retry 
delay. Clients of course should be free to wait even longer if they 
choose to do so, use any variety of retry strategies, etc.

For reference, here is the start of the relevant email thread:
      http://www.imc.org/ietf-ldup/mail-archive/msg01528.html

-Mark Smith
  Netscape

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Jun 2003 07:49:43 -0700

Let's give consumers and users of the technology a question
they care about.  They don't care about implementation details,
they care about whether or not the protocol is going to meet
their application needs.

In my opinion, applications need support for incremental
synchronization capabilities.  Hence, protocol should not
only support incremental synchronization, the specification
should say that servers are REQUIRED to support incremental
synchronization in general cases.  Otherwise, the protocol
and its specification are for not.

I prefer REQUIRE over RECOMMEND here as I view the behavior
of generally forcing full synchronization when incremental
synchronization was requested as being harmful.  I believe
RFC 2119 supports this view, it gives "limiting retransmisssions"
as an example of harmful behavior.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Thu, 5 Jun 2003 12:45:49 -0400

I define IT departments, managers, and staff as consumers of
technology, more particularly, consumers of implementations
and solutions based on technology; and they certainly care
about the constraints placed on that technology. They
will have to live with the impact of those constraints on the
user community for whom they provide services and support.

More savvy users, the one's who usually have some influence
over purchasing decisions for such solutions, also care about
constraints placed on technologies they use. They are
more likely than any other users to push the edges of what
is considered typical usage towards the boundary use cases
associated with any particular constraint.

So, it's a very relevant type of question to put forward.
And I assert, one that gets asked implicitly each time
a document is put through IETF Last Call.

On the more technical points you make below, I'm watching
the mailing list to see what others have to say in response
to it.

DSI Consulting, Inc.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Thursday, June 05, 2003 10:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: Applicability (Was: LDAP Client Update: consideration of
alternative proposals)

Kurt