RE: PCELS draft
[email protected] Mon, 9 Feb 2004 15:07:43 -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_01C3EF50.C27D92DC Content-Type: text/plain; charset="iso-8859-1" Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:[email protected]] [...] > > 1) I noticed a number of RFC 2252 schema definitions > (e.g., pcelsIsMirrored) not accompanied by prose which detailed > the schema element. While an RFC 2252 schema definition should > be provided for each schema element, providing such should not > be viewed by itself to provide a complete technical > specification of the schema element. The prose needs to detail > all aspects of the schema element, such as application syntax > and semantics, not covered in the RFC 2252 schema definition. > It is also good to echo aspects of the RFC 2252 schema definition > in the prose. In the opening remarks for Section 5. we indicate that: " The semantics for the policy information classes that are to be mapped directly from the information model to an LDAP representation are detailed in [PCIM_EXT]. Consequently, this document presents only a brief reference to those semantics." In your opinion, is this not sufficient? Are you suggesting that the we should duplicate some of the text from rfc3460? > > 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? > > 4) I don't understand the meaning of pcelsPriority > DESC note that says: "Default value: 0". Does this mean that > if pcelsPriority is not present in the entry, then the > application is to assume a 0 priority? Also, since > pcelsPolicySetAssociation MUSTs pcelsPriority, when would > pcelsPriority need a default value? Indeed, we have overlooked this detail. In the next revision we will remove "Default value: 0" from the DESC if the pcelsPriority attribute definition. > I suggest you remove > these defaults from the DESC field and instead detail how > applications are to behave when an optional (MAY) attribute > is not present in the object. All the default values defined in PCELS for LDAP attributes, they are directly mapped from information model (rfc3460) property defaults. I'm thinking of adding a general note on default values for optional attributes to the opening remarks in Section 5. Would that be acceptable? > > 5) I note that a number of attribute types are described as > holding "lists" while some are described as "unordered sets". > The term list implies an ordering of its members. And, in > LDAP, all sets are unordered. I suggest you always use the > term "set" or always use the term "unordered set" when > referring to values of a attribute type. This was indeed poorly worded. The intention was to refer to *sets* of values. (Unordered obviously.) We will fix this in the next revision. However, PCELS defines several items with "List" in the name. This is because of the names of the corresponding information model items. I don't think that we can change the names without creating confusion. > > 6) I note that a number of attributes of syntaxes/matching > rules which behave properly (ensure same value (in different > representations) is not stored twice, ensure matching of > different representations match) for the kinds of > application-restricted values placed in them. For instance, > it seems a bit odd to use case ignore directory string > matching for IPv6 addresses. I am not sure I understand what this issue is. For instance the attribute pcelsIPv6AddrList is a DirectoryString and it is mapped from a property defined by rfc3460 in section 6.14.2. Among other things, this property can be a hostname hence case insensitive. Is there anything wrong with that? > > 7) The I-D should detail delegations it makes under the OID > to be assigned by IANA. That is, the x in IANA-ASSIGNED-OID.2.x > should be specified so that the RFC-Editor can simply replace > IANA-ASSIGNED-OID with the assigned OID throughout the I-D > to produce the RFC-to-be. Since we might still see some minor changes to the set of classes and attributes, the plan was to fill-in the numbers after locking down the content but before advancing the document to the next stage. And last but not least, thanks a lot for revising this document Thank you, Mircea. > > -- Kurt > ------_=_NextPart_001_01C3EF50.C27D92DC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2657.73"> <TITLE>RE: PCELS draft</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Kurt,</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Kurt D. Zeilenga [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]</FONT> <BR><FONT SIZE=3D2>[...]</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 1) I noticed a number of RFC 2252 schema = definitions</FONT> <BR><FONT SIZE=3D2>> (e.g., pcelsIsMirrored) not accompanied by = prose which detailed</FONT> <BR><FONT SIZE=3D2>> the schema element. While an RFC 2252 = schema definition should</FONT> <BR><FONT SIZE=3D2>> be provided for each schema element, providing = such should not</FONT> <BR><FONT SIZE=3D2>> be viewed by itself to provide a complete = technical</FONT> <BR><FONT SIZE=3D2>> specification of the schema element. The = prose needs to detail</FONT> <BR><FONT SIZE=3D2>> all aspects of the schema element, such as = application syntax</FONT> <BR><FONT SIZE=3D2>> and semantics, not covered in the RFC 2252 = schema definition.</FONT> <BR><FONT SIZE=3D2>> It is also good to echo aspects of the RFC 2252 = schema definition</FONT> <BR><FONT SIZE=3D2>> in the prose.</FONT> </P> <P><FONT SIZE=3D2>In the opening remarks for Section 5. we indicate = that:</FONT> <BR><FONT SIZE=3D2>" The semantics for the policy = information classes that are to be</FONT> <BR><FONT SIZE=3D2> mapped directly from the information = model to an LDAP representation</FONT> <BR><FONT SIZE=3D2> are detailed in [PCIM_EXT]. = Consequently, this document presents only</FONT> <BR><FONT SIZE=3D2> a brief reference to those = semantics."</FONT> <BR><FONT SIZE=3D2>In your opinion, is this not sufficient? Are you = suggesting that the we should duplicate some of the text from = rfc3460?</FONT> </P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 2) I noticed a number of places where the only = description</FONT> <BR><FONT SIZE=3D2>> of an application restriction upon the element = (e.g.,</FONT> <BR><FONT SIZE=3D2>> pcelsIPHdrVersion) was in a comment field = (e.g., DESC) in the</FONT> <BR><FONT SIZE=3D2>> formal language (RFC2252) description of the = element. These</FONT> <BR><FONT SIZE=3D2>> restrictions should be stated in prose.</FONT> </P> <P><FONT SIZE=3D2>The restrictions are fully documented by the = information model (rfc3460). Are you suggesting that we should re-state = their applicability to the LDAP Schema?</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 3) As application restrictions upon values are = not enforced</FONT> <BR><FONT SIZE=3D2>> by the directory, the specification should = state how</FONT> <BR><FONT SIZE=3D2>> applications are to behave if they find values = in the</FONT> <BR><FONT SIZE=3D2>> directory which, per the application = restrictions, are</FONT> <BR><FONT SIZE=3D2>> invalid. For instance, how are = applications to deal with</FONT> <BR><FONT SIZE=3D2>> negative pcelsPriority values?</FONT> </P> <P><FONT SIZE=3D2>The last of the opening remarks for Section 5. (Note = 5) indicates that:</FONT> <BR><FONT SIZE=3D2>" if a constraint is violated, then the</FONT> <BR><FONT SIZE=3D2> policy rule(s) /group(s) SHOULD be = treated as being disabled, meaning</FONT> <BR><FONT SIZE=3D2> that execution of the policy rule(s) = /group(s) SHOULD be stopped."</FONT> <BR><FONT SIZE=3D2>Do you find this insufficient?</FONT> </P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 4) I don't understand the meaning of = pcelsPriority</FONT> <BR><FONT SIZE=3D2>> DESC note that says: "Default value: = 0". Does this mean that</FONT> <BR><FONT SIZE=3D2>> if pcelsPriority is not present in the entry, = then the</FONT> <BR><FONT SIZE=3D2>> application is to assume a 0 = priority? Also, since</FONT> <BR><FONT SIZE=3D2>> pcelsPolicySetAssociation MUSTs pcelsPriority, = when would</FONT> <BR><FONT SIZE=3D2>> pcelsPriority need a default value?</FONT> </P> <P><FONT SIZE=3D2>Indeed, we have overlooked this detail. In the next = revision we will remove "Default value: 0" from the DESC if = the pcelsPriority attribute definition.</FONT></P> <P><FONT SIZE=3D2>> I suggest you remove</FONT> <BR><FONT SIZE=3D2>> these defaults from the DESC field and instead = detail how</FONT> <BR><FONT SIZE=3D2>> applications are to behave when an optional = (MAY) attribute</FONT> <BR><FONT SIZE=3D2>> is not present in the object.</FONT> </P> <P><FONT SIZE=3D2>All the default values defined in PCELS for LDAP = attributes, they are directly mapped from information model (rfc3460) = property defaults. I'm thinking of adding a general note on default = values for optional attributes to the opening remarks in Section 5. = Would that be acceptable?</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 5) I note that a number of attribute types are = described as</FONT> <BR><FONT SIZE=3D2>> holding "lists" while some are = described as "unordered sets".</FONT> <BR><FONT SIZE=3D2>> The term list implies an ordering of its = members. And, in</FONT> <BR><FONT SIZE=3D2>> LDAP, all sets are unordered. I suggest = you always use the</FONT> <BR><FONT SIZE=3D2>> term "set" or always use the term = "unordered set" when</FONT> <BR><FONT SIZE=3D2>> referring to values of a attribute type.</FONT> </P> <P><FONT SIZE=3D2>This was indeed poorly worded. The intention was to = refer to *sets* of values. (Unordered obviously.) We will fix this in = the next revision. However, PCELS defines several items with = "List" in the name. This is because of the names of the = corresponding information model items. I don't think that we can change = the names without creating confusion.</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 6) I note that a number of attributes of = syntaxes/matching</FONT> <BR><FONT SIZE=3D2>> rules which behave properly (ensure same value = (in different</FONT> <BR><FONT SIZE=3D2>> representations) is not stored twice, ensure = matching of</FONT> <BR><FONT SIZE=3D2>> different representations match) for the kinds = of</FONT> <BR><FONT SIZE=3D2>> application-restricted values placed in = them. For instance,</FONT> <BR><FONT SIZE=3D2>> it seems a bit odd to use case ignore directory = string</FONT> <BR><FONT SIZE=3D2>> matching for IPv6 addresses. </FONT> </P> <P><FONT SIZE=3D2>I am not sure I understand what this issue is. For = instance the attribute pcelsIPv6AddrList is a DirectoryString and it is = mapped from a property defined by rfc3460 in section 6.14.2. Among = other things, this property can be a hostname hence case insensitive. = Is there anything wrong with that?</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 7) The I-D should detail delegations it makes = under the OID</FONT> <BR><FONT SIZE=3D2>> to be assigned by IANA. That is, the x in = IANA-ASSIGNED-OID.2.x</FONT> <BR><FONT SIZE=3D2>> should be specified so that the RFC-Editor can = simply replace</FONT> <BR><FONT SIZE=3D2>> IANA-ASSIGNED-OID with the assigned OID = throughout the I-D</FONT> <BR><FONT SIZE=3D2>> to produce the RFC-to-be.</FONT> </P> <P><FONT SIZE=3D2>Since we might still see some minor changes to the = set of classes and attributes, the plan was to fill-in the numbers = after locking down the content but before advancing the document to the = next stage. </FONT></P> <P><FONT SIZE=3D2>And last but not least, thanks a lot for revising = this document</FONT> </P> <P><FONT SIZE=3D2>Thank you,</FONT> <BR><FONT SIZE=3D2>Mircea.</FONT> </P> <BR> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> -- Kurt</FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C3EF50.C27D92DC--