[apps-discuss] Apps Review Team review of draft-zeilenga-ldap-dontusecopy-08

Ted Hardie <ted.ietf@gmail.com> Thu, 14 October 2010 17:04 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=M3TsMDdOGMZsQgd6UamCATRDgqIPDgowlfK1amqjZsUI0t1PVPh6r5l2qnu0VQPpzD k8pgQCHZissCGzV68CdquyU0lr/KvVGr3B1hD23qtwzFEIYjD0qhaBLnt6068QfdwZ06 sF0ylJvN/jGa9BVJnIcRCcfQifr/Nr19DpwBo=
MIME-Version: 1.0
Date: Thu, 14 Oct 2010 10:06:06 -0700
Message-ID: <AANLkTikk1kHpPndjfDBvRZkKrZKbEqdf6uW65KLAVH1z@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Apps Discuss <discuss@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>, Kurt.Zeilenga@isode.com, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] Apps Review Team review of draft-zeilenga-ldap-dontusecopy-08
Precedence: list

I have been selected as the Applications Area Review Team reviewer for
this draft
(for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive.
Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-zeilenga-ldap-dontusecopy-08
Title: The LDAP Don't Use Copy Control
Reviewer: Ted Hardie
Review Date: October 14, 2010

Summary: This document is basically ready for publication on the
standards track, with one
clarification needed and some editorial issues.

Major Issues:

In section 3, the document currently says:

   If original (master) information for the target or base object of the
  operation is not available (either locally or through chaining), the
  server MUST either return a referral directing the client to a server
  believed to be better able to service the request or return an
  appropriate result code (e.g., unwillingToPerform).

The LDAP referral syntax permits the use of URIs other than LDAP,
provided they are believed capable of performing the operations
(see RFC 2251 section 4.1.11).  But it is not clear
how a referral using a different URI scheme would handle
a request for authoritative data only.  I believe the author should
consider whether restricting referrals to LDAP URIs
would be useful in this case or whether real-world deployments
make non-LDAP URIs sufficiently rare to make this superfluous.
Text describing the case would be useful for either approach.

Since the control is based on an X.511/DAP control, it is possible
to get this same functionality there, but the IANA does not appear to list
any URI scheme for this, making its use in a referral also apparently
unlikely.

Minor Issues: None seen.

Nits: The background section has a number of cases where multiple
parenthetical expressions are used.  Some re-writing to remove them
may increase the readability. For example:

  If the server has access to
  the original (master) information (directly or through chaining), it
  performs the operation against the original (master) information and
  return compareTrue or compareFalse (or an error).


  If the server has access to the original (master) information
directly or through chaining,
  it performs the operation against the original (master) information and
  returns compareTrue,  compareFalse,  or an error.

These can be resolved in cooperation with the RFC Editor's application
of the style guide.

[apps-discuss] Apps Review Team review of draft-z… Ted Hardie
Re: [apps-discuss] Apps Review Team review of dra… Kurt Zeilenga