Gen-ART LC Review of draft-zeilenga-ldap-dontusecopy-08

[Ben Campbell <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-zeilenga-ldap-dontusecopy-08
Reviewer: Ben Campbell
Review Date: 2010-10-11
IETF LC End Date: 2010-10-11
IESG Telechat date: (if known)

Summary:

This draft is almost ready to be published as a proposed standard, but I have some comments that should be considered first.

Major issues: None

Minor issues:

-- General: 

(Let me preface my general comments with the admission that I am not an LDAP expert. Since this is a Gen-ART review, I'm approaching this as a generalist. If the answer is something like "Ben, if you new anything about LDAP this would all be obvious to you", that will not offend me in any way.)

I'd like to see more explanation of the problem this needs to be solved. I assume that there is concern that copied or cached data may not be up to date, or otherwise not be authoritative. Some comments to that effect, along with reasoning for why this may happen in the first place would be helpful. A quick scan of 4511 and 4512 didn't turn up much about this, other than some passing references that some servers may shadow or cache dats from other servers., and not to accept modification requests against cached or shadowed data. Is there any other specification about LDAP cacheing, maintaining cache freshness, etc?

I get a gut feeling that this extension effectively patches a hole in an implied delegation model for LDAP, but I don't find much in the way of explicit specification for that in the referenced docs (Maybe I should be looking at X.500 specs?). I'm not saying that this document should be burdened with a formal specification of the LDAP delegation model. But I think a little more context would be helpful.

I'd also like to see some more guidance on when it's reasonable to use this extension. For example, wouldn't a client always want an authoritative answer to an interrogation? Why wouldn't it use this extension all the time? Does it hurt anything if it does?

-- section 3, 2nd paragraph:

I think this paragraph might be better restated normatively.

-- section 4:

The security consideration comments seem to be about caching in general. Does this extension make things any better or worse? RFC4510 has nothing to say about security beyond referring the reader to the security considerations in the technical specs.

Nits/editorial comments:

-- General

There seems to be inconsistent use of the terms "copy", "shadow", "cache",  "original" , and "master" between this draft and RFC 4510 and 4512. Maybe adding these terms to the terminology sections would help.

-- Section 1, paragraph 3:

Please expand DN on first use.