RE: RE: PCELS position
"Pana, Mircea" <[email protected]> Mon, 22 Sep 2003 09:20:48 -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_01C38114.B848BE90 Content-Type: text/plain; charset="iso-8859-1" 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]] 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_01C38114.B848BE90 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.2654.45"> <TITLE>RE: [Policy] RE: PCELS position</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>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.).</FONT></P> <P><FONT SIZE=3D2>Some of the structural changes proposed by PCIMe make = it difficult for PCELS to be interoperable with PCLS. These are as = follows:</FONT></P> <P><FONT SIZE=3D2>1. PCIMe defines a new abstract class, PolicySet, and = makes it a superclass of the already defined PolicyRule and = PolicyGroup</FONT></P> <P><FONT SIZE=3D2>2. In PCIMe the PolicyRule.Priority property has been = deprecated in favor of a new relative priority mechanism.</FONT> <BR><FONT SIZE=3D2>3. PolicyRepository is deprecated in favor of the = new ReusablePolicyContainer.</FONT> <BR><FONT SIZE=3D2> </FONT> <BR><FONT SIZE=3D2>PCELS could be interoperable with PCLS if it was to = interpret these PCIMe changes as follows:</FONT> <BR><FONT SIZE=3D2>A. there is no need to have an explicit LDAP mapping = of the abstract PolicySet. (see also B.)</FONT> <BR><FONT SIZE=3D2>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.</FONT></P> <P><FONT SIZE=3D2>C. implementations SHOULD (as opposed to MUST) use = the relative priority mechanism instead of the absolute priority = attribute of PolicyRule</FONT></P> <P><FONT SIZE=3D2>D. PolicyRepository SHOULD not be used directly but = it is acceptable for instances of this class to occur through = inheritance.</FONT></P> <P><FONT SIZE=3D2>So, the question is whether the statements A. through = D. violate PCIMe or not. Opinions?</FONT> </P> <P><FONT SIZE=3D2>Thanks,</FONT> <BR><FONT SIZE=3D2>Mircea.</FONT> <BR><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: Wijnen, Bert (Bert) [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]</FONT>= <BR><FONT SIZE=3D2>Sent: Sunday, September 21, 2003 6:14 AM</FONT> <BR><FONT SIZE=3D2>To: 'David McTavish'; 'Pana, Mircea'; = '[email protected]'</FONT> <BR><FONT SIZE=3D2>Cc: 'John Strassner'; 'Joel M. Halpern'</FONT> <BR><FONT SIZE=3D2>Subject: RE: [Policy] RE: PCELS position</FONT> </P> <BR> <P><FONT SIZE=3D2>W.r.t.</FONT> <BR><FONT SIZE=3D2>> Is PCIMe considered so complete, that it = is beyond modification, if such </FONT> <BR><FONT SIZE=3D2>> modification could preserve its intent = while also adhering to the desires </FONT> <BR><FONT SIZE=3D2>> of maintaining consistency with PCIM and PCLS? = </FONT> </P> <P><FONT SIZE=3D2>PCIMe is at Proposed Standard. If, for example = because of this effort to try and MAP it onto LDAP, we</FONT> <BR><FONT SIZE=3D2>find that we did some things in PCIMe that we should = not have done, then, with WG consensus,</FONT> <BR><FONT SIZE=3D2>we can make incompatible changes to PCIMe and then = recycle at Proposed Standard.</FONT> <BR><FONT SIZE=3D2>That is part of the normal standars track process. = That is, we get something to PS, then we start</FONT> <BR><FONT SIZE=3D2>using/implementing (the "using" part is = reusing PCIMe definitions in otehr CIM docs (like the</FONT> <BR><FONT SIZE=3D2>other docs we did in Policy, and like the IPsec = work, the "implementing" is sort of mapping onto for </FONT> <BR><FONT SIZE=3D2>example LDAP I think)... and if we find major = issues, then we fix and recycle at PS. If we do not</FONT> <BR><FONT SIZE=3D2>find major issues, we may advance to DS.</FONT> </P> <P><FONT SIZE=3D2>Hope this helps.</FONT> <BR><FONT SIZE=3D2>Bert</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C38114.B848BE90--