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.