RE: PCELS draft
[email protected] Mon, 9 Feb 2004 18:24:23 -0600
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EF6C.3B7C1580 Content-Type: text/plain; charset="iso-8859-1" Kurt, > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:[email protected]] [...] > > 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 ------_=_NextPart_001_01C3EF6C.3B7C1580 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2657.73"> <TITLE>RE: PCELS draft</TITLE> </HEAD> <BODY> <P><FONT SIZE=2>Kurt,</FONT> </P> <P><FONT SIZE=2>> > -----Original Message-----</FONT> <BR><FONT SIZE=2>> > From: Kurt D. Zeilenga [<A HREF="mailto:[email protected]">mailto:[email protected]</A>]</FONT> <BR><FONT SIZE=2>[...]</FONT> <BR><FONT SIZE=2>> > 2) I noticed a number of places where the only description</FONT> <BR><FONT SIZE=2>> > of an application restriction upon the element (e.g.,</FONT> <BR><FONT SIZE=2>> > pcelsIPHdrVersion) was in a comment field (e.g., DESC) in the</FONT> <BR><FONT SIZE=2>> > formal language (RFC2252) description of the element. These</FONT> <BR><FONT SIZE=2>> > restrictions should be stated in prose.</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> The restrictions are fully documented by the information </FONT> <BR><FONT SIZE=2>> model (rfc3460). Are you suggesting that we should re-state </FONT> <BR><FONT SIZE=2>> their applicability to the LDAP Schema?</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> > </FONT> <BR><FONT SIZE=2>> > 3) As application restrictions upon values are not enforced</FONT> <BR><FONT SIZE=2>> > by the directory, the specification should state how</FONT> <BR><FONT SIZE=2>> > applications are to behave if they find values in the</FONT> <BR><FONT SIZE=2>> > directory which, per the application restrictions, are</FONT> <BR><FONT SIZE=2>> > invalid. For instance, how are applications to deal with</FONT> <BR><FONT SIZE=2>> > negative pcelsPriority values?</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> The last of the opening remarks for Section 5. (Note 5) </FONT> <BR><FONT SIZE=2>> indicates that:</FONT> <BR><FONT SIZE=2>> " if a constraint is violated, then the</FONT> <BR><FONT SIZE=2>> policy rule(s) /group(s) SHOULD be treated as being </FONT> <BR><FONT SIZE=2>> disabled, meaning</FONT> <BR><FONT SIZE=2>> that execution of the policy rule(s) /group(s) SHOULD be stopped."</FONT> <BR><FONT SIZE=2>> Do you find this insufficient?</FONT> </P> <P><FONT SIZE=2>Does the text below address the issues 2) and 3) (from your list)?</FONT> <BR><FONT SIZE=2>(candidate text for replacing Note 5 in section 5 of PCELS-04)</FONT> </P> <P><FONT SIZE=2>" Note 5: Some of the following attribute definitions MUST conform</FONT> <BR><FONT SIZE=2> to additional constraints on various data types (e.g. "Policy</FONT> <BR><FONT SIZE=2> priority. Valid values: any non-negative integer."). Just like</FONT> <BR><FONT SIZE=2> the attribute semantics, the definition of the value structures,</FONT> <BR><FONT SIZE=2> valid ranges, etc. is covered by [PCIM_EXT] for the corresponding</FONT> <BR><FONT SIZE=2> properties while in this document such constraints are only briefly</FONT> <BR><FONT SIZE=2> mentioned. In all cases, if a constraint is violated, the entry</FONT> <BR><FONT SIZE=2> SHOULD be treated as invalid and the policy rules or groups that</FONT> <BR><FONT SIZE=2> refer to it SHOULD be treated as being disabled, meaning that the</FONT> <BR><FONT SIZE=2> execution of such policy rules or groups SHOULD be stopped."</FONT> </P> <P><FONT SIZE=2>Thanks,</FONT> <BR><FONT SIZE=2>Mircea</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C3EF6C.3B7C1580--