RE: LDAP Client Update: consideration of alternative proposals

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 protected]

http://www.dsi-consulting.com

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


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