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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf