RE: RE: PCELS position
"Pana, Mircea" <[email protected]> Tue, 23 Sep 2003 16:58:17 -0500
| 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_01C3821D.CB5C9290 Content-Type: text/plain; charset="iso-8859-1" John, IMO an LDAP attribute is not defined *for* a class. An LDAP attribute defined in the global context and then *used* by LDAP object classes. An attribute has a syntax and (basic) semantics of its own and these are carried over in any class that use the attribute. Then, in the context of a class an attribute may have additional semantics. The semantics associated by the class to an attribute are not necessarely shared with other classes that use the attribute. Such semantics belog to the class not the attribute. For example, a fictional attribute "ipv4Addresses" may be a list of ip addresses in the x.x.x.x notation. In a "mailServer" class this attribute may be used to store the ip addresses of this mail server. In an "ingressFilter" class however, the same attribute may be used to match source/dest ip addresses of ingress ip packets. Same attribute - different class semantics. So, it's like saying that a Hummer and a Boat have the same type of engine even though they use this engine in different ways (one connected to the weels, the other to the propeller). Regards, Mircea. -----Original Message----- From: John Strassner [mailto:[email protected]] Sent: Tuesday, September 23, 2003 3:12 PM To: 'Pana, Mircea'; John Strassner; 'Wijnen, Bert (Bert)'; 'David McTavish'; '[email protected]' Cc: 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Mircea, The pcimRuleEnabled attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled attribute is defined for the pcimPolicyRule. You claim that since the definition of pcimRuleEnabled is the same, there should be no problem. I disagree because: 1) the semantics of the two defining classes are different 2) the derivation of the two defining classes are different It's like saying that a Hummer and a Boat both have an engine, so why can't I use the Boat's engine in a Hummer? regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: [email protected] -----Original Message----- From: Pana, Mircea [mailto:[email protected]] Sent: Tuesday, September 23, 2003 1:00 PM To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish'; '[email protected]' Cc: 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position John, I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem. However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that. Mircea. -----Original Message----- From: John Strassner [mailto:[email protected]] Sent: Tuesday, September 23, 2003 1:03 PM To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; '[email protected]' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: [email protected] -----Original Message----- From: Pana, Mircea [mailto:[email protected]] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; '[email protected]' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [ mailto:[email protected] <mailto:[email protected]> ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; '[email protected]' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > Is PCIMe considered so complete, that it is beyond modification, if such > modification could preserve its intent while also adhering to the desires > of maintaining consistency with PCIM and PCLS? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C3821D.CB5C9290 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>RE: [Policy] RE: PCELS position</TITLE> <META content="MSHTML 6.00.2800.1226" name=GENERATOR> <STYLE>@font-face { font-family: Wingdings; } @font-face { font-family: Tahoma; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: blue; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman" } P.Numbered { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 0.8in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } LI.Numbered { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 0.8in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } DIV.Numbered { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 0.8in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } P.Bulletted { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } LI.Bulletted { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } DIV.Bulletted { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } P.numbered0 { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 0.8in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } LI.numbered0 { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 0.8in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } DIV.numbered0 { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 0.8in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } P.bulletted0 { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } LI.bulletted0 { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } DIV.bulletted0 { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: -0.25in; LINE-HEIGHT: 200%; FONT-FAMILY: "Times New Roman" } SPAN.emailstyle20 { COLOR: navy; FONT-FAMILY: Arial } SPAN.EmailStyle23 { COLOR: navy; FONT-FAMILY: Arial } DIV.Section1 { page: Section1 } OL { MARGIN-BOTTOM: 0in } UL { MARGIN-BOTTOM: 0in } </STYLE> </HEAD> <BODY lang=EN-US vLink=blue link=blue> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>John,</FONT></SPAN></DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>IMO an LDAP attribute is not defined *for* a class. An LDAP attribute defined in the global context and then *used* by LDAP object classes. </FONT></SPAN><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>An attribute has a syntax and (basic) semantics of its own and these are carried over in any class that use the attribute. Then, in the context of a class an attribute may have additional semantics. The semantics associated by the class to an attribute are not necessarely shared with other classes that use the attribute. Such semantics belog to the class not the attribute.</FONT></SPAN></DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>For example, a fictional attribute "ipv4Addresses" may be a list of ip addresses in the x.x.x.x notation. In a "mailServer" class this attribute may be used to store the ip addresses of this mail server. In an "ingressFilter" class however, the same attribute may be used to match source/dest ip addresses of ingress ip packets. Same attribute - different class semantics.</FONT></SPAN></DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>So, it's like saying that a Hummer and a Boat have the same type of engine even though they use this engine in different ways (one connected to the weels, the other to the propeller).</FONT></SPAN></DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>Regards,</FONT></SPAN></DIV> <DIV><SPAN class=197045120-23092003><FONT face=Arial color=#0000ff size=2>Mircea.</FONT></SPAN></DIV> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> John Strassner [mailto:[email protected]]<BR><B>Sent:</B> Tuesday, September 23, 2003 3:12 PM<BR><B>To:</B> 'Pana, Mircea'; John Strassner; 'Wijnen, Bert (Bert)'; 'David McTavish'; '[email protected]'<BR><B>Cc:</B> 'Joel M. Halpern'<BR><B>Subject:</B> RE: [Policy] RE: PCELS position<BR><BR></FONT></DIV> <DIV class=Section1> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Mircea,</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The pcimRuleEnabled attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled attribute is defined for the pcimPolicyRule. You claim that since the definition of pcimRuleEnabled is the same, there should be no problem.</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I disagree because:</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT> </P> <P class=MsoNormal style="MARGIN-LEFT: 24pt; TEXT-INDENT: -0.25in"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">1)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">the semantics of the two defining classes are different</SPAN></FONT></P> <P class=MsoNormal style="MARGIN-LEFT: 24pt; TEXT-INDENT: -0.25in"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">2)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">the derivation of the two defining classes are different</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It's like saying that a Hummer and a Boat both have an engine, so why can't I use the Boat's engine in a Hummer?</SPAN></FONT></P> <DIV> <P><FONT face="Times New Roman" color=navy size=3><SPAN style="FONT-SIZE: 12pt; COLOR: navy">regards,<BR>John </SPAN></FONT></P> <P><FONT face="Times New Roman" color=navy size=3><SPAN style="FONT-SIZE: 12pt; COLOR: navy">John C. Strassner <BR>Chief Strategy Officer <BR>Intelliden Inc. <BR>90 South Cascade Avenue <BR>Colorado Springs, CO 80906 USA <BR>phone: +1.719.785.0648 <BR> fax: +1.719.785.0644 <BR>email: [email protected] </SPAN></FONT></P></DIV> <DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> <P class=MsoNormal><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Pana, Mircea [mailto:[email protected]] <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, September 23, 2003 1:00 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> </SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">'</SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">John Strassner</SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">'</SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">; 'Wijnen, Bert (Bert)'; </SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">'David McTavish'</SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">; </SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">'[email protected]'</SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> </SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">'Joel M. Halpern'</SPAN></FONT><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [Policy] RE: PCELS position</SPAN></FONT></P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <DIV> <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">John,</SPAN></FONT></P></DIV> <DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P></DIV> <DIV> <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem.</SPAN></FONT></P></DIV> <DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P></DIV> <DIV> <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that.</SPAN></FONT></P></DIV> <DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P></DIV> <DIV> <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Mircea.</SPAN></FONT></P></DIV> <DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P></DIV> <DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P></DIV> <DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P></DIV> <BLOCKQUOTE style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> John Strassner [mailto:[email protected]]<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, September 23, 2003 1:03 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; '[email protected]'<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> John Strassner; 'Joel M. Halpern'<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [Policy] RE: PCELS position</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards.</SPAN></FONT></P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is <I><SPAN style="FONT-STYLE: italic">different</SPAN></I> than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID.</SPAN></FONT></P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. </SPAN></FONT></P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <DIV> <P><FONT face="Times New Roman" color=navy size=3><SPAN style="FONT-SIZE: 12pt; COLOR: navy">regards,<BR>John </SPAN></FONT></P> <P><FONT face="Times New Roman" color=navy size=3><SPAN style="FONT-SIZE: 12pt; COLOR: navy">John C. Strassner <BR>Chief Strategy Officer <BR>Intelliden Inc. <BR>90 South Cascade Avenue <BR>Colorado Springs, CO 80906 USA <BR>phone: +1.719.785.0648 <BR> fax: +1.719.785.0644 <BR>email: [email protected] </SPAN></FONT></P></DIV> <DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> <P class=MsoNormal><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Pana, Mircea [mailto:[email protected]] <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, September 22, 2003 8:21 AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; '[email protected]'<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> 'John Strassner'; 'Joel M. Halpern'<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [Policy] RE: PCELS position</SPAN></FONT></P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).</SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:</SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup</SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt"> </SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.</SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule</SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.</SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Thanks,</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Mircea.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">-----Original Message-----</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">From: Wijnen, Bert (Bert) [<A href="mailto:[email protected]">mailto:[email protected]</A>]</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Sent: Sunday, September 21, 2003 6:14 AM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">To: 'David McTavish'; 'Pana, Mircea'; '[email protected]'</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Cc: 'John Strassner'; 'Joel M. Halpern'</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Subject: RE: [Policy] RE: PCELS position</SPAN></FONT> </P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">W.r.t.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Is PCIMe considered so complete, that it is beyond modification, if such </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> modification could preserve its intent while also adhering to the desires </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> of maintaining consistency with PCIM and PCLS? </SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">find that we did some things in PCIMe that we should not have done, then, with WG consensus,</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">we can make incompatible changes to PCIMe and then recycle at Proposed Standard.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">That is part of the normal standars track process. That is, we get something to PS, then we start</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">find major issues, we may advance to DS.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Hope this helps.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Bert</SPAN></FONT> </P></DIV></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C3821D.CB5C9290--