RE: LCUP applicability

["Chris Apple" <capple@xxxxxxxxxxxxxxxxxx>]

Note from the Co-Chair: I consider this issue to be worth discussing
regardless of the request from Kurt relating to the pending WG Last
Call initiation for LCUP. It will need to be resolved regardless of
the outcome of the WG considering his request.

Kurt,

One way of characterizing the problem(s) technology is intended
to solve is by including discussion about applications for which
that technology is a good (or a bad) solution.

That is clearly *one* way of documenting applicability. It has been
the most common way of doing so in many engineering documents I've
encountered in the past.

So far, its not clear what this particular disagreement is about.

Can you provide a few references for applicability statements
that are more like those you would prefer to see in the LCUP
document?

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple@xxxxxxxxxxxxxxxxxx

http://www.dsi-consulting.com

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@xxxxxxxxxxxx] 
Sent: Monday, May 26, 2003 11:50 AM
To: capple@xxxxxxxxxxxxxxxxxx
Cc: rmegginson0224@xxxxxxx; ietf-ldup@xxxxxxx; mcs@xxxxxxxxxxxx;
olgan@xxxxxxxxxxxxx; jeffparh@xxxxxxxxxxxxxxxxxxxxx
Subject: RE: LCUP applicability


I content that the I-D has not been updated to discuss
applicability.  That is, it has been updated to discuss
which applications are well suited to it and which are
not, and why.  The updates are mainly highlight implementation
constraints, and while useful, are not quite the same thing.

The applicability statement exercise purpose, I thought,
was to focus some the problem both I-Ds report to solve
and their suitability of each of the solutions.  To that
purpose, we still have a long way to go.

Kurt

At 09:00 AM 5/23/2003, Chris Apple wrote:
>Kurt,
>
>We'll be able to handle word-smithing during the WG Last Call for LCUP.
>
>However, with regard to this particular thread, I don't see support on
>the mailing list for your position that the applicability statement
>language is unclear.
>
>I therefore must conclude that the WG doesn't agree with your position
>and consider this particular issue closed unless reopened by other WG
>members during the upcoming LCUP WG Last Call.
>
>Chris Apple - Principal Architect
>
>DSI Consulting, Inc.
>
>mailto:capple@xxxxxxxxxxxxxxxxxx
>
>http://www.dsi-consulting.com
>
>-----Original Message-----
>From: owner-ietf-ldup@xxxxxxxxxxxx [mailto:owner-ietf-ldup@xxxxxxxxxxxx]
>On Behalf Of Rich Megginson
>Sent: Tuesday, May 06, 2003 11:03 AM
>To: Kurt D. Zeilenga
>Cc: ietf-ldup@xxxxxxx; mcs@xxxxxxxxxxxx; olgan@xxxxxxxxxxxxx;
>jeffparh@xxxxxxxxxxxxxxxxxxxxx; richm@xxxxxxxxxxxx
>Subject: Re: LCUP applicability
>
>
>Kurt D. Zeilenga wrote:
>
>>LCUP's applicability statement, I think, needs a bit of work.
>>The "will work best" phrase, I find a bit odd, seems these
>>are more "design assumptions".
>>
>I'm not sure what the difference is between an "applicability statement"
>and a "design assumption", but isn't that the whole point of the section
>anyway?  To provide suggestions to implementers about what types of
>server and client applications are best suited for LCUP?  I don't see a
>problem here.
>
>>Anyways...
>>
>>The first item implies that LCUP "works" when the server
>>maintains no historical information.  It should be clear,
>>that without historical information, the server can only
>>determine that change occurred since the time indicated by
>>the cookie, not what that change was.  Hence, only if there
>>were no changes in the context, the could the server could respond
>>successfully.  In any change occurred in the context, the
>>server would have to fail with lcupReloadRequired.
>>
>Well, that is "working".  Some definition of "working" is that the
>client does a full resync every time (or does nothing, if there is
>nothing to do).  I think the statement in LCUP is pretty clear without
>going so far as to "bash potential implementers over the head with
>implementation details".
>
>No problem here.
>
>>The second item says the client is not assumed to understand
>>the "physical information model" implemented by the
>>server, however it provides as instances of the physical
>>model "virtual attributes, operational attributes, [and]subentries".  I
>think the authors meant LCUP assumes
>>only knowledge of the "directory user information model"
>>[X.501(93)].
>>
>I think the wording is pretty clear and easy to understand as it is.
> The document provides as instances those items to provide clarity
>within the context without requiring the reader of the document to refer
>to other documents just to get an idea of what is being referred to here.
>
>>Anyways, I think LCUP does require the
>>client to understand directory administrative and
>>operational models in certain areas.  For example, as
>>LCUP doesn't support alias dereferencing during searching,
>>a user client desiring aliases objects has to understand
>>alias objects.
>>
>Right.  This particular "exception to the rule" was discussed a long
>time by the LDAP community, and it was decided that this particular
>exception was worthy of inclusion in LCUP.
>
>>I assume it does so to reduce complexity.
>>There are other cases where assuming or requiring client
>>knowledge of aspects of select administrative and operational
>>models would significant reduce complexity and/or chattiness.
>>
>Then the implementer can either choose to accept LCUP with its
>"chattiness in certan cases" or reject LCUP in favor of another approach.
>
>No problem here.
>
>>With regard to the third item, I think LCUP has significant
>>problems dealing with a number of everyday DIT update
>>situations and forces full reloads far too frequently.
>>
>Those situations are explicitly listed in the LCUP document, and the
>document lists the reasons that LCUP chose to handle them in the way it
>did.
>
>No problem here.
>
>>I'll post a more detailed discussion of this in a separate
>>message at a later time.
>>
>I look forward to reading it.  But what will be different than what we
>have already discussed at great length in the past?  Have you found
>several other new situations that you didn't know about 2 months ago?
>
>The point is that implementers can choose to accept these conditions or
>not.  At least they are explicitly spelled out in LCUP near the beginning.
>
>>Kurt
>>
>>
>>
>