RE: RE: PCELS position
"Pana, Mircea" <[email protected]> Tue, 23 Sep 2003 17:51:02 -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_01C38225.2A14E880 Content-Type: text/plain; charset="iso-8859-1" David, Regards, Mircea. > -----Original Message----- > From: David McTavish [mailto:[email protected]] > Sent: Tuesday, September 23, 2003 1:33 PM > To: 'Robert Moore'; 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 > > > Hi Bob, > Unfortunately, in LDAP, attributes must be globally unique. I don't think this is unfortunate ;-) > 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 This should be prevented from happening but it is a matter of server implementation. To be compliant with LDAP one must stick to the syntax globally defined for the attribute. > 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. You make it sound so painful ;-) > > 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_01C38225.2A14E880 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>David,</FONT> </P> <P><FONT SIZE=3D2>Regards,</FONT> <BR><FONT SIZE=3D2>Mircea.</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: David McTavish [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>= ]</FONT> <BR><FONT SIZE=3D2>> Sent: Tuesday, September 23, 2003 1:33 = PM</FONT> <BR><FONT SIZE=3D2>> To: 'Robert Moore'; John Strassner</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>> Hi Bob,</FONT> <BR><FONT SIZE=3D2>> Unfortunately, in LDAP, attributes must be = globally unique.</FONT> <BR><FONT SIZE=3D2>I don't think this is unfortunate ;-)</FONT> </P> <P><FONT SIZE=3D2>> So, if an</FONT> <BR><FONT SIZE=3D2>> attribute is defined as "foo" in one = objectclass as a </FONT> <BR><FONT SIZE=3D2>> boolean, and as an</FONT> <BR><FONT SIZE=3D2>> integer in another class, this causes an = incompatibility. In</FONT> <BR><FONT SIZE=3D2>This should be prevented from happening but it is a = matter of server implementation. To be compliant with LDAP one must = stick to the syntax globally defined for the attribute.</FONT></P> <P><FONT SIZE=3D2> </FONT> <BR><FONT SIZE=3D2>> some cases</FONT> <BR><FONT SIZE=3D2>> (OpenLDAP), this prevents the server from even = starting. It's </FONT> <BR><FONT SIZE=3D2>> not the most</FONT> <BR><FONT SIZE=3D2>> elegant implementation, but something you get = used to when </FONT> <BR><FONT SIZE=3D2>> working on LDAP.</FONT> <BR><FONT SIZE=3D2>You make it sound so painful ;-)</FONT> </P> <P><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'; 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 </FONT> <BR><FONT SIZE=3D2>> attribute foo in a new</FONT> <BR><FONT SIZE=3D2>> class bar is completely specious, because the = new class >bar </FONT> <BR><FONT SIZE=3D2>> is different</FONT> <BR><FONT SIZE=3D2>> than the original class baz that defined foo. = The differences are very</FONT> <BR><FONT SIZE=3D2>> fundamental - different hierarchies, different = >attributes, and worse</FONT> <BR><FONT SIZE=3D2>> (e.g., the definition of priority). This isn't = reuse, this is 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 identity,</FONT> <BR><FONT SIZE=3D2>> independent of the classes in which they = appear. (Digression </FONT> <BR><FONT SIZE=3D2>> for 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 </FONT> <BR><FONT SIZE=3D2>> it's 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 </FONT> <BR><FONT SIZE=3D2>> confusion, so 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 </FONT> <BR><FONT SIZE=3D2>> have specific</FONT> <BR><FONT SIZE=3D2>> experience with X.500 and LDAP, but I do know = that in the </FONT> <BR><FONT SIZE=3D2>> CMIP case it was</FONT> <BR><FONT SIZE=3D2>> perfectly good practice (in fact, it was = typical) to define attributes</FONT> <BR><FONT SIZE=3D2>> without regard to the classes that would = include them. I'm </FONT> <BR><FONT SIZE=3D2>> don't 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: </FONT> <BR><FONT SIZE=3D2>> "'Pana, Mircea'"</FONT> <BR><FONT SIZE=3D2>> <[email protected]>, "'Wijnen, Bert = (Bert)'"  = ; </FONT> <BR><FONT = SIZE=3D2>>  = ;  = ; = lliden.com> &nbs= p; </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: &nb= sp; = <[email protected]></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT = SIZE=3D2>>  = ;  = ; [email protected] = cc: </FONT> <BR><FONT SIZE=3D2>> John Strassner</FONT> <BR><FONT SIZE=3D2>> <[email protected]>, = "'Joel M. = Halpern'" &nbs= p; </FONT> <BR><FONT = SIZE=3D2>>  = ;  = ; = g  = ;  = ; </FONT> <BR><FONT SIZE=3D2>> <[email protected]></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT = SIZE=3D2>>  = ;  = ;  = ;  = ; Subject: </FONT> <BR><FONT SIZE=3D2>> RE: [Policy] RE:</FONT> <BR><FONT SIZE=3D2>> PCELS = position &nbs= p; &nbs= p; &nbs= p; = </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 </FONT> <BR><FONT SIZE=3D2>> information model</FONT> <BR><FONT SIZE=3D2>> based on the concerns of one specific data = model. This is backwards.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Furthermore, the argument that you are = "reusing" an attribute </FONT> <BR><FONT SIZE=3D2>> foo in a new</FONT> <BR><FONT SIZE=3D2>> class bar is completely specious, because the = new class bar </FONT> <BR><FONT SIZE=3D2>> is different</FONT> <BR><FONT SIZE=3D2>> than the original class baz that defined foo. = The differences are very</FONT> <BR><FONT SIZE=3D2>> fundamental - different hierarchies, different = attributes, </FONT> <BR><FONT SIZE=3D2>> and 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 you</FONT> <BR><FONT SIZE=3D2>> prefixes the new classes and attributes, this = would also get </FONT> <BR><FONT SIZE=3D2>> around 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 </FONT> <BR><FONT SIZE=3D2>> only a matter</FONT> <BR><FONT SIZE=3D2>> of interpretation of the PCIMe recommendations. = After all </FONT> <BR><FONT SIZE=3D2>> PCIMe is quite</FONT> <BR><FONT SIZE=3D2>> lenient wrt. that is and what is not used in = submodels (see </FONT> <BR><FONT SIZE=3D2>> PCIMe 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 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 </FONT> <BR><FONT SIZE=3D2>> it a 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 </FONT> <BR><FONT SIZE=3D2>> deprecated in 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 </FONT> <BR><FONT SIZE=3D2>> these 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 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 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 </FONT> <BR><FONT SIZE=3D2>> relative 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. </FONT> <BR><FONT SIZE=3D2>> violate 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 </FONT> <BR><FONT SIZE=3D2>> modification, if such</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> > modification could preserve its = intent while also adhering to 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 </FONT> <BR><FONT SIZE=3D2>> this 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 </FONT> <BR><FONT SIZE=3D2>> done, 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 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 </FONT> <BR><FONT SIZE=3D2>> definitions 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 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_01C38225.2A14E880--