RE: Applicability (Was: LDAP Client Update: consideration of alternative proposals)

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.

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: Thursday, June 05, 2003 10:50 AM
To: [email protected]
Cc: [email protected]
Subject: Applicability (Was: LDAP Client Update: consideration of
alternative proposals)


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


At 01:45 AM 6/5/2003, Chris Apple wrote:

>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