RE: Comments on last call for simple caching scheme

[Steve Kille <S.Kille@isode.com>]

Tim,

Thanks for this detailed response.  Let me comment on the points where
you disagree with me

 >Steve Kille wrote:
 >
 >> Mark, Tim, Luke, Harald,
 >>
 >>      RE: LAST CALL: draft-ietf-asid-ldap-cache-01
 >>
 >> The last call prompted me to review the caching draft.   I apologise
 >> for not reviewing this sooner.
 >>
 >> A number of comments
 >>
 >> 1) I do not feel that there has been sufficient experience in this
 >> area to justify this specification being standards track.   I believe
 >> that it should be published as experimental, and a decision to move to
 >> standards track made subsequently based on experience.   The primary
 >> reason for this is that this function will have a complex interaction
 >> with other replication and caching schemes, and I do not think it
 >> makes sense to standardize this in isolation.
 >
 >I think there has been lots of experience with this,
 >though most of it has been with DNS. The spirit of
 >this proposal is very similar. 

I'll explain under 4 that pretty much the only think similar to DNS is
the name!

 >Our intention is for there
 >not to be any interaction with replication or server-to-
 >server caching schemes. If that is not clear in the
 >document, we should make it clear. It should be an
 >explicit goal that this be independent of other things.

Understood.  I think this is exactly the right thing for this spec to
do.

However, there is a key point (that ties in with other points later
on, which I perhaps didn't make clearly in my first message), that
replication at all parts of the system is related.  If there is a
server system with low performance and no replication, the client side
caching requirements are potentially very different to a highly
replicated service.  While it is important that the specification is
written "in isolation", the total system MUST be considered.  There
are lots of places that caching could be done with different control
algorithms.  

 >
 >As for the track, I still think standards track is appropriate,
 >for the reasons given. What do other people think?

I am clear that we do not have enough experience yet for standards
track.  I do think that this draft should be published ASAP.


 >>    - relationship to potential work on SERVER based TTLs
 >
 >Do you mean TTLs used in server-to-server communication?
 >Or something else? I don't think there should be a relationship.

I mean TTLs used between servers.   I think that IF this is done, and
IF it uses a mechanism which was cleanly accessible to clients, then
it might not make sense to duplicate the function.

 >
 >
 >>    - relationship to systematic replication schemes
 >
 >This is orthogonal, or should be. What did you have in mind
 >here as a problem?

This is an aspect of my "whole system" issue noted above.


 >
 >
 >> 4) I think that the attribute should NOT be called TTL, as those
 >> familiar with DNS will make incorrect assumptions about how it works.
 >> I would suggest that the attribute is called "Client Advisory Entry
 >> Caching Time Period".
 >
 >I like TTL for just that reason. It is pretty much exactly
 >like the TTL in DNS, so I see no reason to confuse things
 >by introducing a new term. How do you think this scheme
 >differs from the DNS scheme?

The timeout mechanism is the same.   However, I made incorrect
assumptions about this draft because of the TTL name, and I suspect
others will.  If we call them something else, the releationship can be
explained.   The key differences are:

1) TTLs are FUNDAMENTAL to the way DNS works, and are defined at the
lowest level of the architecture.   This is an application level
add-on.

2) TTLs are associated with every DNS record.  This just applies to an
entry.

3) TTLs are tied in with the procedures for distributd operation of
DNS, with notes on how server should manage and decrement them.   This
spec only affects clients.


 >
 >
 >> 5) I think that the problem of server caching is particularly
 >> important, and there will in practice be a relationship.   This needs
 >> a lot of work.
 >
 >We can't very well talk about this without talking about
 >the server-to-server protocols, which LDAP does not
 >specify. Though one could imagine a relationship between
 >a client caching scheme and a server caching scheme, it
 >is not necessary, and in fact I would argue a bad idea to
 >tie the two together.

The "whole system" argument again.


 >
 >
 >> I hope that this is useful input
 >
 >Very useful, thanks! Please let's keep the discussion going.
 >        -- Tim
 >

regards


Steve