RE: RE: PCELS position
John Strassner <[email protected]> Tue, 23 Sep 2003 11:51:01 -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_01C381FB.40AF98D0
Content-Type: text/plain
I'm saying:
1) that an information model should not be driven by the
concerns of a single data model, and
2) I do not believe that the word "reuse" applies when an
attribute is defined in one class, with one set of
semantics, and then is blopped into a new class with
completely different semantics. That is what I meant
by stealing an OID.
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: Robert Moore [mailto:[email protected]]
> Sent: Tuesday, September 23, 2003 11:40 AM
> To: David McTavish
> Cc: 'Wijnen, Bert (Bert)'; David McTavish; 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; '[email protected]'; [email protected]
> Subject: RE: [Policy] RE: PCELS position
>
>
>
>
>
> David,
>
> Yes, that's exactly what I was saying. What I don't understand is
> this: if
> LDAP attributes are globally unique, what's the problem with
> reusing them
> in multiple classes (with the same syntax and semantics, of
> course)? This
> was a desirable thing in CMIP, but John is suggesting that it's to
> be
> avoided in LDAP.
>
> Regards,
> Bob
>
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> [email protected]
>
>
>
>
> David McTavish
> <dmctavish@sandvi To: Robert
> Moore/Raleigh/IBM@IBMUS, John Strassner
> ne.com>
> <[email protected]>
> cc: "'Wijnen,
> Bert (Bert)'" <[email protected]>, David McTavish
> 09/23/2003 01:33
> <[email protected]>, "'Joel M. Halpern'"
> <[email protected]>, John Strassner
> PM
> <[email protected]>, "'Pana, Mircea'"
> <[email protected]>,
> "'[email protected]'"
> <[email protected]>, [email protected]
> Subject: RE:
> [Policy] RE: PCELS position
>
>
>
>
>
> Hi Bob,
> Unfortunately, in LDAP, attributes must be globally unique. So, if
> an
> attribute is defined as "foo" in one objectclass as a boolean, and
> as an
> integer in another class, this causes an incompatibility. In some
> cases
> (OpenLDAP), this prevents the server from even starting. It's not
> the most
> elegant implementation, but something you get used to when working
> on LDAP.
>
> Hope this is informational,
> d.
>
>
> -----Original Message-----
> From: Robert Moore [mailto:[email protected]]
> Sent: Tuesday, September 23, 2003 1:26 PM
> To: John Strassner
> Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern';
> John
> Strassner; 'Pana, Mircea'; '[email protected]'; [email protected]
> Subject: RE: [Policy] RE: PCELS position
>
>
>
>
>
>
> >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.
>
> John, I'll have to say that I'm missing the essence of your
> argument here.
> Formally (as you've acknowledged), LDAP falls into the same
> category as
> X.500 and CMIP: attributes are defined, and maintain their
> identity,
> independent of the classes in which they appear. (Digression for
> those who
> haven't worked in the DMTF: CIM works the opposite way -- an
> attribute's
> identity is tied to the class in which it is defined, so that it's
> possible
> to have two attributes with identical names defined in two
> different CIM
> classes. This is, of course, a potential source of confusion, so
> there
> were DMTF guidelines saying "Don't do this." But these provided an
> artificial overlay of global scope on attributes whose identity was
> inherently scoped by the classes that defined them.) I don't have
> specific
> experience with X.500 and LDAP, but I do know that in the CMIP case
> it was
> perfectly good practice (in fact, it was typical) to define
> attributes
> without regard to the classes that would include them. I'm don't
> see why
> X.500 and LDAP should be any different. But your use of the
> wording "...
> the original class baz that defined foo" suggests that you see some
> non-formal, but nevertheless significant sense in which LDAP
> attributes
> *are* defined relative to the (first?) class that contains them.
>
> Regards,
> Bob
>
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> [email protected]
>
>
>
>
>
> John Strassner
>
> <John.Strassner@inte To: "'Pana,
> Mircea'"
> <[email protected]>, "'Wijnen, Bert (Bert)'"
> lliden.com>
> <[email protected]>,
> "'David McTavish'" <[email protected]>, "'[email protected]'"
> Sent by:
> <[email protected]>
>
> [email protected] cc: John
> Strassner
> <[email protected]>, "'Joel M. Halpern'"
> g
> <[email protected]>
>
> Subject: RE:
> [Policy]
> RE:
> PCELS position
>
>
> 09/23/2003 01:03 PM
>
>
>
>
>
>
>
> 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]]
> 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_01C381FB.40AF98D0
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Policy] RE: PCELS position</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I'm saying:</FONT>
</P>
<P><FONT SIZE=3D2> 1) that an information model should not be =
driven by the </FONT>
<BR><FONT SIZE=3D2> concerns of a single data =
model, and</FONT>
<BR><FONT SIZE=3D2> 2) I do not believe that the word =
"reuse" applies when an</FONT>
<BR><FONT SIZE=3D2> attribute is defined in one =
class, with one set of </FONT>
<BR><FONT SIZE=3D2> semantics, and then is =
blopped into a new class with</FONT>
<BR><FONT SIZE=3D2> completely different =
semantics. That is what I meant</FONT>
<BR><FONT SIZE=3D2> by stealing an OID.</FONT>
</P>
<P><FONT SIZE=3D2>regards,</FONT>
<BR><FONT SIZE=3D2>John</FONT>
</P>
<P><FONT SIZE=3D2>John C. Strassner</FONT>
<BR><FONT SIZE=3D2>Chief Strategy Officer</FONT>
<BR><FONT SIZE=3D2>Intelliden Inc.</FONT>
<BR><FONT SIZE=3D2>90 South Cascade Avenue</FONT>
<BR><FONT SIZE=3D2>Colorado Springs, CO 80906 USA</FONT>
<BR><FONT SIZE=3D2>phone: +1.719.785.0648</FONT>
<BR><FONT SIZE=3D2> fax: =
+1.719.785.0644</FONT>
<BR><FONT SIZE=3D2>email: =
[email protected]</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Robert Moore [<A =
HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]</FONT>=
<BR><FONT SIZE=3D2>> Sent: Tuesday, September 23, 2003 11:40 =
AM</FONT>
<BR><FONT SIZE=3D2>> To: David McTavish</FONT>
<BR><FONT SIZE=3D2>> Cc: 'Wijnen, Bert (Bert)'; David McTavish; =
'Joel M. Halpern'; John</FONT>
<BR><FONT SIZE=3D2>> Strassner; 'Pana, Mircea'; '[email protected]'; =
[email protected]</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: [Policy] RE: PCELS position</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> David,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Yes, that's exactly what I was saying. =
What I don't understand is</FONT>
<BR><FONT SIZE=3D2>> this: if</FONT>
<BR><FONT SIZE=3D2>> LDAP attributes are globally unique, what's the =
problem with</FONT>
<BR><FONT SIZE=3D2>> reusing them</FONT>
<BR><FONT SIZE=3D2>> in multiple classes (with the same syntax and =
semantics, of</FONT>
<BR><FONT SIZE=3D2>> course)? This</FONT>
<BR><FONT SIZE=3D2>> was a desirable thing in CMIP, but John is =
suggesting that it's to</FONT>
<BR><FONT SIZE=3D2>> be</FONT>
<BR><FONT SIZE=3D2>> avoided in LDAP.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Regards,</FONT>
<BR><FONT SIZE=3D2>> Bob</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Bob Moore</FONT>
<BR><FONT SIZE=3D2>> WebSphere Advanced Design and Technology</FONT>
<BR><FONT SIZE=3D2>> WebSphere Platform System House</FONT>
<BR><FONT SIZE=3D2>> IBM Software Group</FONT>
<BR><FONT SIZE=3D2>> +1-919-254-4436</FONT>
<BR><FONT SIZE=3D2>> [email protected]</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; David McTavish</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; <dmctavish@sandvi =
To: Robert</FONT>
<BR><FONT SIZE=3D2>> Moore/Raleigh/IBM@IBMUS, John Strassner</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; ne.com></FONT>
<BR><FONT SIZE=3D2>> <[email protected]></FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
;  =
; cc: "'Wijnen,</FONT>
<BR><FONT SIZE=3D2>> Bert (Bert)'" <[email protected]>, =
David McTavish</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; 09/23/2003 01:33</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>, "'Joel M. =
Halpern'"</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>, John =
Strassner</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; PM</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>, =
"'Pana, Mircea'"</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>,</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
;  =
; "'[email protected]'"</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>, =
[email protected]</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
;  =
; Subject: RE:</FONT>
<BR><FONT SIZE=3D2>> [Policy] RE: PCELS position</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Hi Bob,</FONT>
<BR><FONT SIZE=3D2>> Unfortunately, in LDAP, attributes must be =
globally unique. So, if</FONT>
<BR><FONT SIZE=3D2>> an</FONT>
<BR><FONT SIZE=3D2>> attribute is defined as "foo" in one =
objectclass as a boolean, and</FONT>
<BR><FONT SIZE=3D2>> as an</FONT>
<BR><FONT SIZE=3D2>> integer in another class, this causes an =
incompatibility. In some</FONT>
<BR><FONT SIZE=3D2>> cases</FONT>
<BR><FONT SIZE=3D2>> (OpenLDAP), this prevents the server from even =
starting. It's not</FONT>
<BR><FONT SIZE=3D2>> the most</FONT>
<BR><FONT SIZE=3D2>> elegant implementation, but something you get =
used to when working</FONT>
<BR><FONT SIZE=3D2>> on LDAP.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Hope this is informational,</FONT>
<BR><FONT SIZE=3D2>> d.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Robert Moore [<A =
HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]</FONT>=
<BR><FONT SIZE=3D2>> Sent: Tuesday, September 23, 2003 1:26 =
PM</FONT>
<BR><FONT SIZE=3D2>> To: John Strassner</FONT>
<BR><FONT SIZE=3D2>> Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; =
'Joel M. Halpern';</FONT>
<BR><FONT SIZE=3D2>> John</FONT>
<BR><FONT SIZE=3D2>> Strassner; 'Pana, Mircea'; '[email protected]'; =
[email protected]</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: [Policy] RE: PCELS position</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> >Furthermore, the argument that you are =
"reusing" an attribute foo</FONT>
<BR><FONT SIZE=3D2>> in a new</FONT>
<BR><FONT SIZE=3D2>> class bar is completely specious, because the =
new class >bar is</FONT>
<BR><FONT SIZE=3D2>> different</FONT>
<BR><FONT SIZE=3D2>> than the original class baz that defined foo. =
The differences are</FONT>
<BR><FONT SIZE=3D2>> very</FONT>
<BR><FONT SIZE=3D2>> fundamental - different hierarchies, different =
>attributes, and</FONT>
<BR><FONT SIZE=3D2>> worse</FONT>
<BR><FONT SIZE=3D2>> (e.g., the definition of priority). This isn't =
reuse, this is</FONT>
<BR><FONT SIZE=3D2>> simply</FONT>
<BR><FONT SIZE=3D2>> stealing an OID.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> John, I'll have to say that I'm missing the =
essence of your</FONT>
<BR><FONT SIZE=3D2>> argument here.</FONT>
<BR><FONT SIZE=3D2>> Formally (as you've acknowledged), LDAP falls =
into the same</FONT>
<BR><FONT SIZE=3D2>> category as</FONT>
<BR><FONT SIZE=3D2>> X.500 and CMIP: attributes are defined, and =
maintain their</FONT>
<BR><FONT SIZE=3D2>> identity,</FONT>
<BR><FONT SIZE=3D2>> independent of the classes in which they =
appear. (Digression for</FONT>
<BR><FONT SIZE=3D2>> those who</FONT>
<BR><FONT SIZE=3D2>> haven't worked in the DMTF: CIM works the =
opposite way -- an</FONT>
<BR><FONT SIZE=3D2>> attribute's</FONT>
<BR><FONT SIZE=3D2>> identity is tied to the class in which it is =
defined, so that it's</FONT>
<BR><FONT SIZE=3D2>> possible</FONT>
<BR><FONT SIZE=3D2>> to have two attributes with identical names =
defined in two</FONT>
<BR><FONT SIZE=3D2>> different CIM</FONT>
<BR><FONT SIZE=3D2>> classes. This is, of course, a potential =
source of confusion, so</FONT>
<BR><FONT SIZE=3D2>> there</FONT>
<BR><FONT SIZE=3D2>> were DMTF guidelines saying "Don't do =
this." But these provided an</FONT>
<BR><FONT SIZE=3D2>> artificial overlay of global scope on =
attributes whose identity was</FONT>
<BR><FONT SIZE=3D2>> inherently scoped by the classes that defined =
them.) I don't have</FONT>
<BR><FONT SIZE=3D2>> specific</FONT>
<BR><FONT SIZE=3D2>> experience with X.500 and LDAP, but I do know =
that in the CMIP case</FONT>
<BR><FONT SIZE=3D2>> it was</FONT>
<BR><FONT SIZE=3D2>> perfectly good practice (in fact, it was =
typical) to define</FONT>
<BR><FONT SIZE=3D2>> attributes</FONT>
<BR><FONT SIZE=3D2>> without regard to the classes that would =
include them. I'm don't</FONT>
<BR><FONT SIZE=3D2>> see why</FONT>
<BR><FONT SIZE=3D2>> X.500 and LDAP should be any different. =
But your use of the</FONT>
<BR><FONT SIZE=3D2>> wording "...</FONT>
<BR><FONT SIZE=3D2>> the original class baz that defined foo" =
suggests that you see some</FONT>
<BR><FONT SIZE=3D2>> non-formal, but nevertheless significant sense =
in which LDAP</FONT>
<BR><FONT SIZE=3D2>> attributes</FONT>
<BR><FONT SIZE=3D2>> *are* defined relative to the (first?) class =
that contains them.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Regards,</FONT>
<BR><FONT SIZE=3D2>> Bob</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Bob Moore</FONT>
<BR><FONT SIZE=3D2>> WebSphere Advanced Design and Technology</FONT>
<BR><FONT SIZE=3D2>> WebSphere Platform System House</FONT>
<BR><FONT SIZE=3D2>> IBM Software Group</FONT>
<BR><FONT SIZE=3D2>> +1-919-254-4436</FONT>
<BR><FONT SIZE=3D2>> [email protected]</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; John Strassner</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; <John.Strassner@inte =
To: "'Pana,</FONT>
<BR><FONT SIZE=3D2>> Mircea'"</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>, "'Wijnen, Bert =
(Bert)'"</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; lliden.com></FONT>
<BR><FONT SIZE=3D2>> <[email protected]>,</FONT>
<BR><FONT SIZE=3D2>> "'David McTavish'" =
<[email protected]>, "'[email protected]'"</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; Sent by:</FONT>
<BR><FONT SIZE=3D2>> <[email protected]></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; [email protected] =
cc: John</FONT>
<BR><FONT SIZE=3D2>> Strassner</FONT>
<BR><FONT SIZE=3D2>> <[email protected]>, =
"'Joel M. Halpern'"</FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; g</FONT>
<BR><FONT SIZE=3D2>> <[email protected]></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
;  =
; Subject: RE:</FONT>
<BR><FONT SIZE=3D2>> [Policy]</FONT>
<BR><FONT SIZE=3D2>> RE:</FONT>
<BR><FONT SIZE=3D2>> PCELS position</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; 09/23/2003 01:03 PM</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Again, you are trying to determine the validity =
of an information</FONT>
<BR><FONT SIZE=3D2>> model</FONT>
<BR><FONT SIZE=3D2>> based on the concerns of one specific data =
model. This is</FONT>
<BR><FONT SIZE=3D2>> backwards.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Furthermore, the argument that you are =
"reusing" an attribute foo</FONT>
<BR><FONT SIZE=3D2>> in a new</FONT>
<BR><FONT SIZE=3D2>> class bar is completely specious, because the =
new class bar is</FONT>
<BR><FONT SIZE=3D2>> different</FONT>
<BR><FONT SIZE=3D2>> than the original class baz that defined foo. =
The differences are</FONT>
<BR><FONT SIZE=3D2>> very</FONT>
<BR><FONT SIZE=3D2>> fundamental - different hierarchies, different =
attributes, and</FONT>
<BR><FONT SIZE=3D2>> worse (e.g.,</FONT>
<BR><FONT SIZE=3D2>> the definition of priority). This isn't reuse, =
this is simply</FONT>
<BR><FONT SIZE=3D2>> stealing an</FONT>
<BR><FONT SIZE=3D2>> OID.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> So, how about defining a NEW set of classes and =
attributes? And if</FONT>
<BR><FONT SIZE=3D2>> you</FONT>
<BR><FONT SIZE=3D2>> prefixes the new classes and attributes, this =
would also get around</FONT>
<BR><FONT SIZE=3D2>> the</FONT>
<BR><FONT SIZE=3D2>> schema problem that I stated earlier.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> regards,</FONT>
<BR><FONT SIZE=3D2>> John</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> John C. Strassner</FONT>
<BR><FONT SIZE=3D2>> Chief Strategy Officer</FONT>
<BR><FONT SIZE=3D2>> Intelliden Inc.</FONT>
<BR><FONT SIZE=3D2>> 90 South Cascade Avenue</FONT>
<BR><FONT SIZE=3D2>> Colorado Springs, CO 80906 =
USA</FONT>
<BR><FONT SIZE=3D2>> phone: +1.719.785.0648</FONT>
<BR><FONT SIZE=3D2>> fax: =
+1.719.785.0644</FONT>
<BR><FONT SIZE=3D2>> email: =
[email protected]</FONT>
<BR><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Pana, Mircea [<A =
HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]</FONT>=
<BR><FONT SIZE=3D2>> Sent: Monday, September 22, 2003 8:21 AM</FONT>
<BR><FONT SIZE=3D2>> To: 'Wijnen, Bert (Bert)'; 'David McTavish'; =
Pana, Mircea;</FONT>
<BR><FONT SIZE=3D2>> '[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>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Maybe there is no need for such drastic =
measures. Maybe it is only</FONT>
<BR><FONT SIZE=3D2>> a matter</FONT>
<BR><FONT SIZE=3D2>> of interpretation of the PCIMe recommendations. =
After all PCIMe is</FONT>
<BR><FONT SIZE=3D2>> quite</FONT>
<BR><FONT SIZE=3D2>> lenient wrt. that is and what is not used in =
submodels (see PCIMe</FONT>
<BR><FONT SIZE=3D2>> section</FONT>
<BR><FONT SIZE=3D2>> 5.10.).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Some of the structural changes proposed by =
PCIMe make it difficult</FONT>
<BR><FONT SIZE=3D2>> for</FONT>
<BR><FONT SIZE=3D2>> PCELS to be interoperable with PCLS. These are =
as follows:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 1. PCIMe defines a new abstract class, =
PolicySet, and makes it a</FONT>
<BR><FONT SIZE=3D2>> superclass</FONT>
<BR><FONT SIZE=3D2>> of the already defined PolicyRule and =
PolicyGroup</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> 2. In PCIMe the PolicyRule.Priority property =
has been deprecated in</FONT>
<BR><FONT SIZE=3D2>> favor</FONT>
<BR><FONT SIZE=3D2>> of a new relative priority mechanism.</FONT>
<BR><FONT SIZE=3D2>> 3. PolicyRepository is deprecated in favor of =
the new</FONT>
<BR><FONT SIZE=3D2>> ReusablePolicyContainer.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> PCELS could be interoperable with PCLS if it =
was to interpret these</FONT>
<BR><FONT SIZE=3D2>> PCIMe</FONT>
<BR><FONT SIZE=3D2>> changes as follows:</FONT>
<BR><FONT SIZE=3D2>> A. there is no need to have an explicit LDAP =
mapping of the</FONT>
<BR><FONT SIZE=3D2>> abstract</FONT>
<BR><FONT SIZE=3D2>> PolicySet. (see also B.)</FONT>
<BR><FONT SIZE=3D2>> B. there is no need to have an explicit LDAP =
mapping of the</FONT>
<BR><FONT SIZE=3D2>> modified</FONT>
<BR><FONT SIZE=3D2>> PolicyGroup. Implementations can use (the =
equivalent of) a</FONT>
<BR><FONT SIZE=3D2>> PolicyRule with</FONT>
<BR><FONT SIZE=3D2>> no Actions or Conditions for PolicyGroup =
objects.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> C. implementations SHOULD (as opposed to MUST) =
use the relative</FONT>
<BR><FONT SIZE=3D2>> priority</FONT>
<BR><FONT SIZE=3D2>> mechanism instead of the absolute priority =
attribute of PolicyRule</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> D. PolicyRepository SHOULD not be used directly =
but it is</FONT>
<BR><FONT SIZE=3D2>> acceptable for</FONT>
<BR><FONT SIZE=3D2>> instances of this class to occur through =
inheritance.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> So, the question is whether the statements A. =
through D. violate</FONT>
<BR><FONT SIZE=3D2>> PCIMe or</FONT>
<BR><FONT SIZE=3D2>> not. Opinions?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><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>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> W.r.t.</FONT>
<BR><FONT SIZE=3D2>> > Is PCIMe considered so complete, =
that it is beyond modification,</FONT>
<BR><FONT SIZE=3D2>> if such</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > modification could preserve its =
intent while also adhering to</FONT>
<BR><FONT SIZE=3D2>> the</FONT>
<BR><FONT SIZE=3D2>> desires</FONT>
<BR><FONT SIZE=3D2>> > of maintaining consistency with PCIM and =
PCLS?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> PCIMe is at Proposed Standard. If, for example =
because of this</FONT>
<BR><FONT SIZE=3D2>> effort to</FONT>
<BR><FONT SIZE=3D2>> 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,</FONT>
<BR><FONT SIZE=3D2>> then,</FONT>
<BR><FONT SIZE=3D2>> with WG consensus,</FONT>
<BR><FONT SIZE=3D2>> we can make incompatible changes to PCIMe and =
then recycle at</FONT>
<BR><FONT SIZE=3D2>> Proposed</FONT>
<BR><FONT SIZE=3D2>> Standard.</FONT>
<BR><FONT SIZE=3D2>> That is part of the normal standars track =
process. That is, we get</FONT>
<BR><FONT SIZE=3D2>> something to PS, then we start</FONT>
<BR><FONT SIZE=3D2>> using/implementing (the "using" part =
is reusing PCIMe definitions</FONT>
<BR><FONT SIZE=3D2>> in otehr</FONT>
<BR><FONT SIZE=3D2>> CIM docs (like the</FONT>
<BR><FONT SIZE=3D2>> other docs we did in Policy, and like the IPsec =
work, the</FONT>
<BR><FONT SIZE=3D2>> "implementing" is</FONT>
<BR><FONT SIZE=3D2>> sort of mapping onto for</FONT>
<BR><FONT SIZE=3D2>> example LDAP I think)... and if we find major =
issues, then we fix</FONT>
<BR><FONT SIZE=3D2>> and</FONT>
<BR><FONT SIZE=3D2>> recycle at PS. If we do not</FONT>
<BR><FONT SIZE=3D2>> find major issues, we may advance to DS.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Hope this helps.</FONT>
<BR><FONT SIZE=3D2>> Bert</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C381FB.40AF98D0--