[Ldap-dir] Re: [ldapext] Re: Review of draft-wahl-ldap-adminaddr

Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Wed, 30 May 2007 19:39 UTC

Return-path: <ldap-dir-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU1L-0004d5-Ct; Wed, 30 May 2007 15:39:47 -0400
Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1HtU1K-0004ct-Jw for ldap-dir-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 15:39:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU1K-0004ca-0F; Wed, 30 May 2007 15:39:46 -0400
Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtU1I-0003z4-Iy; Wed, 30 May 2007 15:39:45 -0400
Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Rl3S=QBlQKBt@rufus.isode.com>; Wed, 30 May 2007 20:39:43 +0100
X-SMTP-Protocol-Errors: NORDNS
In-Reply-To: <465DA809.9020306@informed-control.com>
References: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> <465DA809.9020306@informed-control.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1E9A40B4-C10B-44C7-B64E-5710CB71F4B0@Isode.com>
Content-Transfer-Encoding: 7bit
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
Date: Wed, 30 May 2007 12:39:37 -0700
To: Mark Wahl <Mark.Wahl@informed-control.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Chris Newman <Chris.Newman@Sun.COM>, Ldapext <ldapext@ietf.org>, ldap-dir@ietf.org, apps-review@ietf.org
Subject: [Ldap-dir] Re: [ldapext] Re: Review of draft-wahl-ldap-adminaddr
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
Errors-To: ldap-dir-bounces@ietf.org

On May 30, 2007, at 9:36 AM, Mark Wahl wrote:

> Kurt Zeilenga wrote:
>> I reviewed this draft on behalf of the Apps Area Review team and  
>> the LDAP Directorate.
>
> Thanks for your comments on these drafts! I'll be reviewing your
> emails and will respond shortly with more details.
>
>> I do find the uses of SHOULD in the Security Consideration section  
>> kind of odd.  Use
>> of RFC 2119 keywords should be limited to specification of  
>> implementation requirements.
>
> If so, then RFC 2119 should be revised to incorporate that limitation,
> as I don't see that stated in 2119, and I observe in recently  
> published
> proposed standard RFCs the use of RFC 2119 terminology in the security
> considerations sections to make statements beyond implementation
> requirements, e.g., RFC 4875 "Specifications of applications within  
> the
> IETF MUST specify this mechanism" or RFC 4872 "RSVP signaling MUST be
> able to provide authentication and integrity".

There are plenty of examples of RFC 2119 keywords being oddly used...
(including RFC 2119 itself).  As I wasn't intending to start a debate on
use of RFC 2119 keywords,  I suggest you can take my RFC 2119  
comments as
indicating a concern that the document may not be clear as whom its
requirements are placed upon.  For instance,
   "The server's access control policy SHOULD allow this information to
    be visible to a suitable administrator in the same organization.

can be taken to mean:
    The server SHOULD restricted allowable access control policies to  
those
    which cause this information to be visible to suitable  
administrators in
    the same organization.

Which, if implemented in a server, would be quite bad.

To avoid such confusion, I recommend you only use RFC 2119 keywords  
to impart
requirements upon implementations of the specification and to word  
recommendations
to server administrators as guidance.

-- Kurt



_______________________________________________
Ldap-dir mailing list
Ldap-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/ldap-dir