Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)
draft-ietf-ldapext-matchedval-07

[Ballot comment]
From OPS Directorate review:

The editorial quality is not too good.

As one nit, there should not be numbered references in the boilerplate
to RFC2026, that'll go awry when rfc-editor remvoes the boilerplate..

Registrigration of the Matched Values control as an LDAP Protocol

==> s/Registrigration/Registration/

Bert adds:
- IANA considerations:
    This document uses the OID 1.2.826.0.1.3344810.2.3 to identify the
    matchedValues control described here. This OID was assigned by
    TrueTrust Ltd, under its BSI assigned English/Welsh Registered
    Company number [13].
  Probably OK? I am not sure. In any event we should decide consciously.

- no IPR section. Would that not be usefull to have, to make sure that
  individual submitter understands that he needs to file any IPR that
  he/she may have?

[Ballot comment]
In reply to Ned's Discuss:  AttributeDescriptionList is defined in RFC2251, and is part of the core
LDAP spec.  The RFC is referenced as [2] in this draft.  I suspect the community of developers
working won't have an issue with it, but just in case, would "(see [2])" at the first mention
of AttributeDescriptionList solve the problem?

[Ballot discuss]
The note at the end of section 2 says:

  Note. If the AttributeDescriptionList is empty or comprises "*"
  then the control MUST be applied against every user attribute.
  If the AttributeDescriptionList contains a "+" then the control
  MUST be applied against every operational attribute.

But "AttributeDescriptionList" appears nowhere else in the document,
nor is it part of any of any of the components of SimpleFilterItem.
I assume this is referring to the attributes field of the search
request this control is attached to, but this really needs to be
made more explicit.

More generally, an interesting side effect of this control is
that it doesn't seem to be possible to say "return only the values
of these attributes that match these criteria but return all values
of all other attributes". Is this going to be a problem? And even if
it isn't a problem, some text describing this limitation would
seem to be in order.

Nits:
 
  The first example uses the domains hotmail.com and sun.com. These should be
    changed to our customary example domains.
  Section 7. "Registrigration" -> "Registration".
  Copyright boilerplate has (date) rather than an actual date.
  Section 12 should be marked as needing to be removed prior to publication.

Further discussion:

  We now have a number of LDAP controls that apply to searching (2891 - server
  side result sorting, 2696 - paged results, 2649 - signed results). I believe
  I can argue that the utility of being able to specify any of these in an LDAP
  URL is questionable, and that wanting paged results, sorted results, or
  signed results is a function of the underlying application and not of the
  URL the application is processing. But I cannot make the same argument stick
  for this document -- it seems quite reasonable to want to be able to
  construct an LDAP URL that says "return only the attribute values that match
  these criteria". As such, I wonder if it would not be appropriate to define
  an LDAP URL extension that allows this control to be specified. (Is this why
  ABNF for specifying a string version of this control was worked out so
  carefully?)

State Changes to Last Call Issued                                  from New Version Needed (WG/Author)                    by scoya

State Changes to New Version Needed (WG/Author)                    from AD Evaluation                                    by Patrik Faltstrom