Mircea's suggestions
David McTavish <[email protected]> Mon, 22 Sep 2003 14:24:49 -0400
| 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_01C38136.CEC12F50
Content-Type: text/plain;
charset="iso-8859-1"
Some good suggestions here Mircea, but I believe that they will also
inevitably require modifications to the underlying PCIMe document.
Hopefully, we can pursue these options to find some common ground.
A.B. From first glance, I'm not sure about A or B, but if this could be
implemented through "inferrence", then I'm all for it. However, reviewing
PCIMe, it seems that the document intends to dictate the underlying
implementation strategy via the class inheritence diagram. If the
relationship between Rules/Groups and PolicySets can be abstracted out in
PCELS, then I believe this would remove the necessity to deprecate pcimRule
and pcimGroup objects. However, I am not sure if this was the intent of the
document, and will leave for others to discuss, as obviously, I'm somewhat
biased. :)
C. My opinion, from PCIMe is that C violates in its current form. In
particular, I'd be concerned with the following quotations from PCIMe:
Section 3.2.3:
"Drawing from both QPIM and ICPM, the Priority property has been
deprecated in PolicyRule, and placed instead on the aggregation
PolicySetComponent. ... With the removal of the Priority property from
PolicyRule, a new modeling dependency is introduced."
I believe if this was rephrased such that the last sentence permitted the
existence of the Priority property within the PolicyRule object instead of
calling for its outright removal, then the proposal would preserve room for
backwards compatibility.
Section 5.5
"PolicySetComponent.Priority MUST have a unique value when compared with
others defined for the same aggregating PolicySet"
This means that Priority MUST have a unique value for all rules/groups,
which means existing PCIM implementations would be non-compliant. In order
for this to be backwards compatible, it needs to be relaxed to allow for a
default of zero (or non-existence), and process accordingly. I believe that
PCIMe needs to be reworked in this capacity to have more leniency.
D. I'm not quite sure which direction you were inferring for the
inheritence... are you inferring that a ReusableContainer object would
extend from the current Repository object class? This could be a more
practical approach, but I still get the feeling that we are just patching an
object to change the name, and the existing problem is maintained because
the object dependency must be fully qualified within LDAP. (ie: a
ReusableContainer object in ldap would have the following objectclasses
defined {top, pcimPolicy, pcimRepository, pcimReusableContainer,
pcimReusableContainerInstance}).
Regards,
d.
-----Original Message-----
From: Pana, Mircea [mailto:[email protected]]
Sent: Monday, September 22, 2003 10: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_01C38136.CEC12F50
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></HEAD>
<BODY>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>Some good
suggestions here Mircea, but I believe that they will also inevitably require
modifications to the underlying PCIMe document. Hopefully, we can pursue these
options to find some common ground.</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>A.B. From
first glance, I'm not sure about A or B, but if this could be implemented
through "inferrence", then I'm all for it. However, reviewing PCIMe, it seems
that the document intends to dictate the underlying implementation strategy
via the class inheritence diagram. If the relationship between Rules/Groups
and PolicySets can be abstracted out in PCELS, then I believe this would remove
the necessity to deprecate pcimRule and pcimGroup objects. However, I am not
sure if this was the intent of the document, and will leave for others to
discuss, as obviously, I'm somewhat biased. :)</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>C.
</FONT></SPAN><SPAN class=839100415-22092003><FONT face="Courier New" size=2>My
opinion, from PCIMe is that C violates in its current form. In particular, I'd
be concerned with the following quotations from PCIMe:</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>Section
3.2.3:</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>"Drawing
from both QPIM and ICPM, the Priority property has been<BR>
deprecated in PolicyRule, and placed instead on the aggregation<BR>
PolicySetComponent. ... With the removal of the Priority
property from<BR> PolicyRule, a new modeling dependency is
introduced."</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>I believe if
this was rephrased such that the last sentence permitted the existence of the
Priority property within the PolicyRule object instead of calling for its
outright removal, then the proposal would preserve room for backwards
compatibility.</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>Section
5.5</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New"
size=2>"PolicySetComponent.Priority MUST have a unique value when compared with
others defined for the same aggregating PolicySet"</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>This means
that Priority MUST have a unique value for all rules/groups, which means
existing PCIM implementations would be non-compliant. In order for this to be
backwards compatible, it needs to be relaxed to allow for a default of zero (or
non-existence), and process accordingly. I believe that PCIMe needs to be
reworked in this capacity to have more leniency.</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New" size=2>D. I'm not
quite sure which direction you were inferring for the inheritence... are you
inferring that a ReusableContainer object would extend from the current
Repository object class? This could be a more practical approach, but I
still get the feeling that we are just patching an object to change the name,
and the existing problem is maintained because the object dependency must be
fully qualified within LDAP. (ie: a ReusableContainer object in ldap would have
the following objectclasses defined {top, pcimPolicy, pcimRepository,
pcimReusableContainer, pcimReusableContainerInstance}).</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003></SPAN><SPAN class=839100415-22092003><FONT
face="Courier New" size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New"
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003><FONT face="Courier New"
size=2>d.</FONT></SPAN></DIV>
<DIV><SPAN class=839100415-22092003></SPAN><SPAN
class=839100415-22092003></SPAN><SPAN class=839100415-22092003></SPAN><SPAN
class=839100415-22092003></SPAN><SPAN class=839100415-22092003><FONT
face="Courier New" size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Pana, Mircea
[mailto:[email protected]]<BR><B>Sent:</B> Monday, September 22, 2003 10:21
AM<BR><B>To:</B> 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea;
'[email protected]'<BR><B>Cc:</B> 'John Strassner'; 'Joel M.
Halpern'<BR><B>Subject:</B> RE: [Policy] RE: PCELS
position<BR><BR></FONT></DIV>
<P><FONT size=2>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=2>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=2>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=2>2. In PCIMe the PolicyRule.Priority property has been
deprecated in favor of a new relative priority mechanism.</FONT> <BR><FONT
size=2>3. PolicyRepository is deprecated in favor of the new
ReusablePolicyContainer.</FONT> <BR><FONT size=2> </FONT> <BR><FONT
size=2>PCELS could be interoperable with PCLS if it was to interpret these
PCIMe changes as follows:</FONT> <BR><FONT size=2>A. there is no need to have
an explicit LDAP mapping of the abstract PolicySet. (see also B.)</FONT>
<BR><FONT size=2>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=2>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=2>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=2>So, the question is whether the statements A. through D.
violate PCIMe or not. Opinions?</FONT> </P>
<P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Mircea.</FONT> <BR><FONT
size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Wijnen, Bert
(Bert) [<A
href="mailto:[email protected]">mailto:[email protected]</A>]</FONT>
<BR><FONT size=2>Sent: Sunday, September 21, 2003 6:14 AM</FONT> <BR><FONT
size=2>To: 'David McTavish'; 'Pana, Mircea'; '[email protected]'</FONT>
<BR><FONT size=2>Cc: 'John Strassner'; 'Joel M. Halpern'</FONT> <BR><FONT
size=2>Subject: RE: [Policy] RE: PCELS position</FONT> </P><BR>
<P><FONT size=2>W.r.t.</FONT> <BR><FONT size=2>> Is PCIMe considered
so complete, that it is beyond modification, if such </FONT><BR><FONT
size=2>> modification could preserve its intent while also adhering
to the desires </FONT><BR><FONT size=2>> of maintaining consistency with
PCIM and PCLS? </FONT></P>
<P><FONT size=2>PCIMe is at Proposed Standard. If, for example because of this
effort to try and MAP it onto LDAP, we</FONT> <BR><FONT size=2>find that we
did some things in PCIMe that we should not have done, then, with WG
consensus,</FONT> <BR><FONT size=2>we can make incompatible changes to PCIMe
and then recycle at Proposed Standard.</FONT> <BR><FONT size=2>That is part of
the normal standars track process. That is, we get something to PS, then we
start</FONT> <BR><FONT size=2>using/implementing (the "using" part is reusing
PCIMe definitions in otehr CIM docs (like the</FONT> <BR><FONT size=2>other
docs we did in Policy, and like the IPsec work, the "implementing" is sort of
mapping onto for </FONT><BR><FONT size=2>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=2>find major issues, we may advance to DS.</FONT> </P>
<P><FONT size=2>Hope this helps.</FONT> <BR><FONT size=2>Bert</FONT>
</P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C38136.CEC12F50--