RE: RE: PCELS position
David McTavish <[email protected]> Tue, 23 Sep 2003 13:56:27 -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_01C381FC.02D4AD60
Content-Type: text/plain;
charset="iso-8859-1"
John,
I'm not suggesting fundamental changes to 3460, but rather minor
modifications that relax some of the stringent requirements that were
introduced. My intention is NOT to remove the new functionality added, but
rather, acknowledge the stress points of PCIMe that make it incompatible
with PCIM. My primary concern is that PCIMe has inadvertantly created a new
standard, by implying compatibility with PCIM but not achieving it. My
impression that PCIMe is supposed to be compatible was manifested by the
title of the RFC, "PCIM Extensions", which in nature would imply using PCIM
as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are
not compatible, and that this issue is NOT on an implementation level, but
rather in the underlying core of the design. Going forward, if such
incompatibility is allowed to manifest, there will only be a divide in the
use of either standard; thereby making implementations incompatible on many
fronts between PCIM and PCIMe, regardless of implementation detail. In my
opinion, this jeopardizes the effort invested into either effort if they are
not capable of interaction. By not acknowledging the short-comings of the
incompatibilities between PCIM and PCIMe now, I believe we are doing a
disservice to the community and any existing adopters.
The core key issues that limit compatibility between PCIM and PCIMe are as
follows:
- existence of priority within rules and groups needs to be optional
instead of mandatory, and allow for implied defaults
- deprecation of classes {PolicyGroupInPolicyGroup,
PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment
- renaming of data model component Repository to ReusablePolicyContainer
provides no conceivable benefit, and creates incompatibility
You'll note that I have no problems with the structure of PolicySet, as it
appears that this is an implementation issue (perhaps resolvable via
Mircea's "inferred" implementation idea). So, please, review the above
points, and I think you will see that these are design issues, not
implementation details, and this in fact, does create an incompatibility
with PCIM.
If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that
the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND,
the Abstract in RFC 3460 is modified to state up front the incompatibilities
between PCIMe and PCIM.
Regards,
d.
-----Original Message-----
From: John Strassner [mailto:[email protected]]
Sent: Tuesday, September 23, 2003 12:43 PM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea';
'[email protected]'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position
Importance: High
I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION
MODEL, because of DATA MODEL concerns. That is exactly backwards, because it
ensures that the information model cannot be mapped to other types of data
models.
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: Wijnen, Bert (Bert) [mailto:[email protected]]
Sent: Sunday, September 21, 2003 4: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_01C381FC.02D4AD60
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>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: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; 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"
}
SPAN.EmailStyle19 {
COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
page: Section1
}
OL {
MARGIN-BOTTOM: 0in
}
UL {
MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2>John,</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New" size=2>I'm not
suggesting fundamental changes to 3460, but rather minor modifications that
relax some of the stringent requirements that were introduced. My
intention is NOT to remove the new functionality added, but rather, acknowledge
the stress points of PCIMe that make it incompatible with PCIM. My
primary concern is that PCIMe has inadvertantly created a new standard, by
implying compatibility with PCIM but not achieving it. My impression that
PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM
Extensions", which in nature would imply using PCIM as a
ground-work. Through my analysis, it is evident that PCIM and PCIMe are not
compatible, and that this </FONT></SPAN><SPAN class=788564616-23092003><FONT
face="Courier New" size=2>issue is NOT on an implementation level, but rather in
the underlying core of the design. Going forward, if s</FONT></SPAN><SPAN
class=788564616-23092003><FONT face="Courier New" size=2>uch incompatibility is
allowed to manifest, there will only be a divide in the use of either standard;
thereby making implementations incompatible on many fronts between PCIM and
PCIMe, regardless of implementation detail. In my opinion, this jeopardizes
the effort invested into either effort if they are not capable of
interaction. By not acknowledging the short-comings of the
incompatibilities between PCIM and PCIMe now, I believe we are doing a
disservice to the community and any existing adopters.</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=788564616-23092003></SPAN><SPAN class=788564616-23092003><FONT
face="Courier New" size=2>The core key issues that limit compatibility between
PCIM and PCIMe are as follows:</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New" size=2> -
existence of priority within rules and groups needs to be optional instead of
mandatory, and allow for implied defaults</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New" size=2>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New" size=2> -
deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup}
instead of extending from PolicySetContainment</FONT></SPAN></DIV> -
renaming of data model component Repository to ReusablePolicyContainer provides
no conceivable benefit, and creates incompatibility</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New" size=2>You'll note
that I have no problems with the structure of PolicySet, as it appears that this
is an implementation issue (perhaps resolvable via Mircea's "inferred"
implementation idea). </FONT></SPAN><SPAN class=788564616-23092003><FONT
face="Courier New" size=2>So, please, review the above points, and I think you
will see that these are design issues, not implementation details, and this in
fact, does create an incompatibility with PCIM. </FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New" size=2>If
compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the
name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the
Abstract in RFC 3460 is modified to state up front the incompatibilities between
PCIMe and PCIM.</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2>d.</FONT></SPAN></DIV>
<DIV><SPAN class=788564616-23092003><FONT face="Courier New"
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=788564616-23092003><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> John Strassner
[mailto:[email protected]]<BR><B>Sent:</B> Tuesday, September 23,
2003 12:43 PM<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><B>Importance:</B> High<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">I fundamentally
disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of
DATA MODEL concerns. That is exactly backwards, because it ensures that the
information model cannot be mapped to other types of data
models.</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>
<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> Wijnen,
Bert (Bert) [mailto:[email protected]] <BR><B><SPAN
style="FONT-WEIGHT: bold">Sent:</SPAN></B> Sunday, September 21, 2003 4:14
AM<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">'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">'Pana,
Mircea'</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">'</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">;
</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">W.r.t.</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">>
</SPAN></FONT><FONT face="Courier New" size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Is PCIMe considered so
complete, that it is beyond modification, if such</SPAN></FONT><FONT
face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> </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">>
</SPAN></FONT><FONT face="Courier New" size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">modification could
preserve its intent while also adhering to the desires</SPAN></FONT><FONT
face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> </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">></SPAN></FONT><FONT
face="Courier New" size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> of maintaining
consistency with PCIM and PCLS?</SPAN></FONT><FONT face=Arial color=blue
size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> </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">PCIMe is at Proposed
Standard. If, for example because of this effort to try and MAP it onto
LDAP, we</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">find that we did some
things in PCIMe that we should not have done, then, with WG
consensus,</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">we can make
incompatible changes to PCIMe and then recycle at Proposed
Standard.</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">That is part of the
normal standars track process. That is, we get something to PS, then we
start</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">using/implementing
(the "using" part is reusing PCIMe definitions in otehr CIM docs (like
the</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">other docs we did in
Policy, and like the IPsec work, the "implementing" is sort of mapping onto
for </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">example LDAP I
think)... and if we find major issues, then we fix and recycle at PS. If we do
not</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">find major issues, we
may advance to DS.</SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Courier New" size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"></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">Hope this
helps.</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">Bert</SPAN></FONT></P></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C381FC.02D4AD60--