[Policy] RE: PCELS draft

mpana@metasolv.com Tue, 10 February 2004 00:32 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05265 for <policy-archive@odin.ietf.org>; Mon, 9 Feb 2004 19:32:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLot-0006g8-37 for policy-archive@odin.ietf.org; Mon, 09 Feb 2004 19:32:07 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0W7gF025668 for policy-archive@odin.ietf.org; Mon, 9 Feb 2004 19:32:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLoo-0006fh-0G; Mon, 09 Feb 2004 19:32:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLoI-0006fH-Rz for policy@optimus.ietf.org; Mon, 09 Feb 2004 19:31:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05225 for <policy@ietf.org>; Mon, 9 Feb 2004 19:31:27 -0500 (EST)
From: mpana@metasolv.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLoH-00010M-00 for policy@ietf.org; Mon, 09 Feb 2004 19:31:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLnY-0000vt-00 for policy@ietf.org; Mon, 09 Feb 2004 19:30:45 -0500
Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLmz-0000je-00 for policy@ietf.org; Mon, 09 Feb 2004 19:30:09 -0500
Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id <1JJRMVLC>; Mon, 9 Feb 2004 18:28:29 -0600
Message-ID: <A33EE5A81E634B488B099FD31F65196101241C1E@srvotemail.metasolv.com>
To: Kurt@OpenLDAP.org
Cc: policy@ietf.org
Date: Mon, 09 Feb 2004 18:24:23 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF6C.3B7C1580"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60
Subject: [Policy] RE: PCELS draft
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-BeenThere: policy@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=subscribe>

Kurt,

> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
[...]
> > 2) I noticed a number of places where the only description
> > of an application restriction upon the element (e.g.,
> > pcelsIPHdrVersion) was in a comment field (e.g., DESC) in the
> > formal language (RFC2252) description of the element.  These
> > restrictions should be stated in prose.
> 
> The restrictions are fully documented by the information 
> model (rfc3460). Are you suggesting that we should re-state 
> their applicability to the LDAP Schema?
> 
> > 
> > 3) As application restrictions upon values are not enforced
> > by the directory, the specification should state how
> > applications are to behave if they find values in the
> > directory which, per the application restrictions, are
> > invalid.  For instance, how are applications to deal with
> > negative pcelsPriority values?
> 
> The last of the opening remarks for Section 5. (Note 5) 
> indicates that:
> " if a constraint is violated, then the
>    policy rule(s) /group(s) SHOULD be treated as being 
> disabled, meaning
>    that execution of the policy rule(s) /group(s) SHOULD be stopped."
> Do you find this insufficient?

Does the text below address the issues 2) and 3) (from your list)?
(candidate text for replacing Note 5 in section 5 of PCELS-04)

"   Note 5: Some of the following attribute definitions MUST conform
   to additional constraints on various data types (e.g. "Policy
   priority. Valid values: any non-negative integer."). Just like
   the attribute semantics, the definition of the value structures,
   valid ranges, etc. is covered by [PCIM_EXT] for the corresponding
   properties while in this document such constraints are only briefly
   mentioned. In all cases, if a constraint is violated, the entry
   SHOULD be treated as invalid and the policy rules or groups that
   refer to it SHOULD be treated as being disabled, meaning that the
   execution of such policy rules or groups SHOULD be stopped."

Thanks,
Mircea