Re: Comments on last call for simple caching scheme

[Tim Howes <howes@netscape.com>]

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. 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.

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


> 2) The title should be changed from "a simple caching scheme...." to a
> "a simple CLIENT caching scheme....".

Agreed. This should help to clarify things.


> 3) The note needs to make clear:
>    - relationship to potential work on per-attribute TTLs

Agreed. Suggest we add text saying that future work in
this area could happen. I doubt we know the exact relationship
without doing the work though. But that's not a reason to
hold up this draft (how would we ever get anything out? :).


>    - 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.


>    - relationship to systematic replication schemes

This is orthogonal, or should be. What did you have in mind
here as a problem?


>    - that dynamic entries will NOT use this

Agreed. We should make this clear.


> 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?


> 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.


> I hope that this is useful input

Very useful, thanks! Please let's keep the discussion going.
        -- Tim