RE: PCELS draft
[email protected] Sun, 15 Feb 2004 18:51:37 -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_01C3F427.0808936C Content-Type: text/plain; charset="iso-8859-1" Kurt, Agreed. The next revision of PCELS will include changes to address all the issues that you have identified. Thank you for taking the time to explain these issues in detail. Mircea. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:[email protected]] > Sent: Tuesday, February 10, 2004 6:57 PM > To: [email protected] > Cc: [email protected] > Subject: RE: PCELS draft > > > My point with 1) is that the I-D seems to be overly reliant on > formal language (RFC2252) description of the LDAP semantics. > That is, for an attribute type such as 'pcelsIsMirrored', > you should, in addition to providing the formal language > description, you should describe the LDAP semantics. For > instance: > The 'pcelsIsMirrored' attribute type is of syntax > BOOLEAN [X.680] and has an equality matching rule > of booleanMatch [ref]. Attributes of this type can > only have a single value. > > That is, you should include supporting prose. > > My point with 2) is that, it appears to me, that you were relying > on comments within the formal language description to detail > an implementation requirement. I suggest you replace all DESC > comments with something descriptive of the element (as oppose > to describing a restriction upon the element). > For instance, for pcelsIPHdrVersion, > DESC 'HdrIpVersion property' > With 3), I think your suggested (in your second follow-up) is > better than the current text. > > With 4), note that 'pcelsPriority' is only one of many attribute > types which are described as having defaults. The issue (and > resolution) is applicable to each. I think a general statement, > combined with removing any mention of defaults in DESC fields > (or replacing the field as suggested in 2), likely can adequately > resolve this issue. > > With 5), I think you may also need to consider (if you haven't > so already) whether the set/list is represented in a single value > of the attribute or in multiple, if the latter, how implementations > are to compose/decompose the PCIM_EXT value from/to its LDAP > representation. > > With 6, I am particular concerned that LDAP's matching semantics > may not be compatible with the application needs. For instance, > pcelsIntegerList could contain multiple values each containing > different representations of the same integer (because these 3 > and 03 are different directory strings). Also, I'm concerned > that the LDAP ordering matching rule may not meet the applications > needs (as the ordering will be applied to their representations, > not their abstract value). As I am PCIM ignorant, I leave it > you and others to determine if the application needs are met > or not. However, you might want to make a general note to > deployers of this that they cannot rely on LDAP syntaxes and > rules being consistent with PCIM syntaxes and rules. > > With 7, okay. > > > > At 01:07 PM 2/9/2004, [email protected] wrote: > >Kurt, > > > >> -----Original Message----- > >> From: Kurt D. Zeilenga > [<mailto:[email protected]>mailto:[email protected]] > >[...] > >> > >> 1) I noticed a number of RFC 2252 schema definitions > >> (e.g., pcelsIsMirrored) not accompanied by prose which detailed > >> the schema element. While an RFC 2252 schema definition should > >> be provided for each schema element, providing such should not > >> be viewed by itself to provide a complete technical > >> specification of the schema element. The prose needs to detail > >> all aspects of the schema element, such as application syntax > >> and semantics, not covered in the RFC 2252 schema definition. > >> It is also good to echo aspects of the RFC 2252 schema definition > >> in the prose. > > > >In the opening remarks for Section 5. we indicate that: > >" The semantics for the policy information classes that are to be > > mapped directly from the information model to an LDAP > representation > > are detailed in [PCIM_EXT]. Consequently, this document > presents only > > a brief reference to those semantics." > >In your opinion, is this not sufficient? Are you suggesting > that the we should duplicate some of the text from rfc3460? > > > >> > >> 2) I noticed a number of places where the only description > >> of an application restriction upon the element (e.g., > >> pcelsIPHdrVersion) was in a comment field (e.g., DESC) in the > >> formal language (RFC2252) description of the element. These > >> restrictions should be stated in prose. > > > >The restrictions are fully documented by the information > model (rfc3460). Are you suggesting that we should re-state > their applicability to the LDAP Schema? > > > >> > >> 3) As application restrictions upon values are not enforced > >> by the directory, the specification should state how > >> applications are to behave if they find values in the > >> directory which, per the application restrictions, are > >> invalid. For instance, how are applications to deal with > >> negative pcelsPriority values? > > > >The last of the opening remarks for Section 5. (Note 5) > indicates that: > >" if a constraint is violated, then the > > policy rule(s) /group(s) SHOULD be treated as being > disabled, meaning > > that execution of the policy rule(s) /group(s) SHOULD be > stopped." > >Do you find this insufficient? > > > >> > >> 4) I don't understand the meaning of pcelsPriority > >> DESC note that says: "Default value: 0". Does this mean that > >> if pcelsPriority is not present in the entry, then the > >> application is to assume a 0 priority? Also, since > >> pcelsPolicySetAssociation MUSTs pcelsPriority, when would > >> pcelsPriority need a default value? > > > >Indeed, we have overlooked this detail. In the next revision > we will remove "Default value: 0" from the DESC if the > pcelsPriority attribute definition. > > > >> I suggest you remove > >> these defaults from the DESC field and instead detail how > >> applications are to behave when an optional (MAY) attribute > >> is not present in the object. > > > >All the default values defined in PCELS for LDAP attributes, > they are directly mapped from information model (rfc3460) > property defaults. I'm thinking of adding a general note on > default values for optional attributes to the opening remarks > in Section 5. Would that be acceptable? > > > >> > >> 5) I note that a number of attribute types are described as > >> holding "lists" while some are described as "unordered sets". > >> The term list implies an ordering of its members. And, in > >> LDAP, all sets are unordered. I suggest you always use the > >> term "set" or always use the term "unordered set" when > >> referring to values of a attribute type. > > > >This was indeed poorly worded. The intention was to refer to > *sets* of values. (Unordered obviously.) We will fix this in > the next revision. However, PCELS defines several items with > "List" in the name. This is because of the names of the > corresponding information model items. I don't think that we > can change the names without creating confusion. > > > >> > >> 6) I note that a number of attributes of syntaxes/matching > >> rules which behave properly (ensure same value (in different > >> representations) is not stored twice, ensure matching of > >> different representations match) for the kinds of > >> application-restricted values placed in them. For instance, > >> it seems a bit odd to use case ignore directory string > >> matching for IPv6 addresses. > > > >I am not sure I understand what this issue is. For instance > the attribute pcelsIPv6AddrList is a DirectoryString and it > is mapped from a property defined by rfc3460 in section > 6.14.2. Among other things, this property can be a hostname > hence case insensitive. Is there anything wrong with that? > > > >> > >> 7) The I-D should detail delegations it makes under the OID > >> to be assigned by IANA. That is, the x in IANA-ASSIGNED-OID.2.x > >> should be specified so that the RFC-Editor can simply replace > >> IANA-ASSIGNED-OID with the assigned OID throughout the I-D > >> to produce the RFC-to-be. > > > >Since we might still see some minor changes to the set of > classes and attributes, the plan was to fill-in the numbers > after locking down the content but before advancing the > document to the next stage. > > > >And last but not least, thanks a lot for revising this document > > > >Thank you, > >Mircea. > > > >> > >> -- Kurt > >> > ------_=_NextPart_001_01C3F427.0808936C 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.2657.73"> <TITLE>RE: PCELS draft</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Kurt,</FONT> </P> <P><FONT SIZE=3D2>Agreed. The next revision of PCELS will include = changes to address all the issues that you have identified. Thank you = for taking the time to explain these issues in detail.</FONT></P> <P><FONT SIZE=3D2>Mircea.</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Kurt D. Zeilenga [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]</FONT> <BR><FONT SIZE=3D2>> Sent: Tuesday, February 10, 2004 6:57 PM</FONT> <BR><FONT SIZE=3D2>> To: [email protected]</FONT> <BR><FONT SIZE=3D2>> Cc: [email protected]</FONT> <BR><FONT SIZE=3D2>> Subject: RE: PCELS draft</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> My point with 1) is that the I-D seems to be = overly reliant on</FONT> <BR><FONT SIZE=3D2>> formal language (RFC2252) description of the = LDAP semantics.</FONT> <BR><FONT SIZE=3D2>> That is, for an attribute type such as = 'pcelsIsMirrored',</FONT> <BR><FONT SIZE=3D2>> you should, in addition to providing the formal = language</FONT> <BR><FONT SIZE=3D2>> description, you should describe the LDAP = semantics. For</FONT> <BR><FONT SIZE=3D2>> instance:</FONT> <BR><FONT SIZE=3D2>> = The 'pcelsIsMirrored' attribute type is of syntax</FONT> <BR><FONT SIZE=3D2>> = BOOLEAN [X.680] and has an equality matching rule</FONT> <BR><FONT SIZE=3D2>> = of booleanMatch [ref]. Attributes of this type can</FONT> <BR><FONT SIZE=3D2>> = only have a single value.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> That is, you should include supporting = prose.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> My point with 2) is that, it appears to me, = that you were relying</FONT> <BR><FONT SIZE=3D2>> on comments within the formal language = description to detail</FONT> <BR><FONT SIZE=3D2>> an implementation requirement. I suggest = you replace all DESC</FONT> <BR><FONT SIZE=3D2>> comments with something descriptive of the = element (as oppose</FONT> <BR><FONT SIZE=3D2>> to describing a restriction upon the = element).</FONT> <BR><FONT SIZE=3D2>> For instance, for pcelsIPHdrVersion,</FONT> <BR><FONT SIZE=3D2>> = DESC 'HdrIpVersion property'</FONT> <BR><FONT SIZE=3D2>> With 3), I think your suggested (in your second = follow-up) is</FONT> <BR><FONT SIZE=3D2>> better than the current text.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> With 4), note that 'pcelsPriority' is only one = of many attribute</FONT> <BR><FONT SIZE=3D2>> types which are described as having = defaults. The issue (and</FONT> <BR><FONT SIZE=3D2>> resolution) is applicable to each. = I think a general statement,</FONT> <BR><FONT SIZE=3D2>> combined with removing any mention of defaults = in DESC fields</FONT> <BR><FONT SIZE=3D2>> (or replacing the field as suggested in 2), = likely can adequately</FONT> <BR><FONT SIZE=3D2>> resolve this issue.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> With 5), I think you may also need to consider = (if you haven't</FONT> <BR><FONT SIZE=3D2>> so already) whether the set/list is represented = in a single value</FONT> <BR><FONT SIZE=3D2>> of the attribute or in multiple, if the latter, = how implementations</FONT> <BR><FONT SIZE=3D2>> are to compose/decompose the PCIM_EXT value = from/to its LDAP</FONT> <BR><FONT SIZE=3D2>> representation.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> With 6, I am particular concerned that LDAP's = matching semantics</FONT> <BR><FONT SIZE=3D2>> may not be compatible with the application = needs. For instance,</FONT> <BR><FONT SIZE=3D2>> pcelsIntegerList could contain multiple values = each containing</FONT> <BR><FONT SIZE=3D2>> different representations of the same integer = (because these 3</FONT> <BR><FONT SIZE=3D2>> and 03 are different directory strings). = Also, I'm concerned</FONT> <BR><FONT SIZE=3D2>> that the LDAP ordering matching rule may not = meet the applications</FONT> <BR><FONT SIZE=3D2>> needs (as the ordering will be applied to their = representations,</FONT> <BR><FONT SIZE=3D2>> not their abstract value). As I am PCIM = ignorant, I leave it</FONT> <BR><FONT SIZE=3D2>> you and others to determine if the application = needs are met</FONT> <BR><FONT SIZE=3D2>> or not. However, you might want to make a = general note to</FONT> <BR><FONT SIZE=3D2>> deployers of this that they cannot rely on LDAP = syntaxes and</FONT> <BR><FONT SIZE=3D2>> rules being consistent with PCIM syntaxes and = rules.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> With 7, okay.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> At 01:07 PM 2/9/2004, [email protected] = wrote:</FONT> <BR><FONT SIZE=3D2>> >Kurt, </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> -----Original Message----- </FONT> <BR><FONT SIZE=3D2>> >> From: Kurt D. Zeilenga </FONT> <BR><FONT SIZE=3D2>> [<<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>><A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>] </FONT> <BR><FONT SIZE=3D2>> >[...] </FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 1) I noticed a number of RFC 2252 = schema definitions </FONT> <BR><FONT SIZE=3D2>> >> (e.g., pcelsIsMirrored) not = accompanied by prose which detailed </FONT> <BR><FONT SIZE=3D2>> >> the schema element. While an RFC = 2252 schema definition should </FONT> <BR><FONT SIZE=3D2>> >> be provided for each schema element, = providing such should not </FONT> <BR><FONT SIZE=3D2>> >> be viewed by itself to provide a = complete technical </FONT> <BR><FONT SIZE=3D2>> >> specification of the schema = element. The prose needs to detail </FONT> <BR><FONT SIZE=3D2>> >> all aspects of the schema element, = such as application syntax </FONT> <BR><FONT SIZE=3D2>> >> and semantics, not covered in the RFC = 2252 schema definition. </FONT> <BR><FONT SIZE=3D2>> >> It is also good to echo aspects of the = RFC 2252 schema definition </FONT> <BR><FONT SIZE=3D2>> >> in the prose. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >In the opening remarks for Section 5. we = indicate that: </FONT> <BR><FONT SIZE=3D2>> >" The semantics for the = policy information classes that are to be </FONT> <BR><FONT SIZE=3D2>> > mapped directly from the = information model to an LDAP </FONT> <BR><FONT SIZE=3D2>> representation </FONT> <BR><FONT SIZE=3D2>> > are detailed in [PCIM_EXT]. = Consequently, this document </FONT> <BR><FONT SIZE=3D2>> presents only </FONT> <BR><FONT SIZE=3D2>> > a brief reference to those = semantics." </FONT> <BR><FONT SIZE=3D2>> >In your opinion, is this not sufficient? = Are you suggesting </FONT> <BR><FONT SIZE=3D2>> that the we should duplicate some of the text = from rfc3460? </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 2) I noticed a number of places where = the only description </FONT> <BR><FONT SIZE=3D2>> >> of an application restriction upon the = element (e.g., </FONT> <BR><FONT SIZE=3D2>> >> pcelsIPHdrVersion) was in a comment = field (e.g., DESC) in the </FONT> <BR><FONT SIZE=3D2>> >> formal language (RFC2252) description = of the element. These </FONT> <BR><FONT SIZE=3D2>> >> restrictions should be stated in = prose. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >The restrictions are fully documented by = the information </FONT> <BR><FONT SIZE=3D2>> model (rfc3460). Are you suggesting that we = should re-state </FONT> <BR><FONT SIZE=3D2>> their applicability to the LDAP Schema?</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 3) As application restrictions upon = values are not enforced </FONT> <BR><FONT SIZE=3D2>> >> by the directory, the specification = should state how </FONT> <BR><FONT SIZE=3D2>> >> applications are to behave if they = find values in the </FONT> <BR><FONT SIZE=3D2>> >> directory which, per the application = restrictions, are </FONT> <BR><FONT SIZE=3D2>> >> invalid. For instance, how are = applications to deal with </FONT> <BR><FONT SIZE=3D2>> >> negative pcelsPriority values? </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >The last of the opening remarks for Section = 5. (Note 5) </FONT> <BR><FONT SIZE=3D2>> indicates that: </FONT> <BR><FONT SIZE=3D2>> >" if a constraint is violated, then = the </FONT> <BR><FONT SIZE=3D2>> > policy rule(s) /group(s) = SHOULD be treated as being </FONT> <BR><FONT SIZE=3D2>> disabled, meaning </FONT> <BR><FONT SIZE=3D2>> > that execution of the policy = rule(s) /group(s) SHOULD be </FONT> <BR><FONT SIZE=3D2>> stopped." </FONT> <BR><FONT SIZE=3D2>> >Do you find this insufficient? </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 4) I don't understand the meaning of = pcelsPriority </FONT> <BR><FONT SIZE=3D2>> >> DESC note that says: "Default = value: 0". Does this mean that </FONT> <BR><FONT SIZE=3D2>> >> if pcelsPriority is not present in the = entry, then the </FONT> <BR><FONT SIZE=3D2>> >> application is to assume a 0 = priority? Also, since </FONT> <BR><FONT SIZE=3D2>> >> pcelsPolicySetAssociation MUSTs = pcelsPriority, when would </FONT> <BR><FONT SIZE=3D2>> >> pcelsPriority need a default value? = </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >Indeed, we have overlooked this detail. In = the next revision </FONT> <BR><FONT SIZE=3D2>> we will remove "Default value: 0" = from the DESC if the </FONT> <BR><FONT SIZE=3D2>> pcelsPriority attribute definition.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> I suggest you remove </FONT> <BR><FONT SIZE=3D2>> >> these defaults from the DESC field and = instead detail how </FONT> <BR><FONT SIZE=3D2>> >> applications are to behave when an = optional (MAY) attribute </FONT> <BR><FONT SIZE=3D2>> >> is not present in the object. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >All the default values defined in PCELS for = LDAP attributes, </FONT> <BR><FONT SIZE=3D2>> they are directly mapped from information model = (rfc3460) </FONT> <BR><FONT SIZE=3D2>> property defaults. I'm thinking of adding a = general note on </FONT> <BR><FONT SIZE=3D2>> default values for optional attributes to the = opening remarks </FONT> <BR><FONT SIZE=3D2>> in Section 5. Would that be acceptable?</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 5) I note that a number of attribute = types are described as </FONT> <BR><FONT SIZE=3D2>> >> holding "lists" while some = are described as "unordered sets". </FONT> <BR><FONT SIZE=3D2>> >> The term list implies an ordering of = its members. And, in </FONT> <BR><FONT SIZE=3D2>> >> LDAP, all sets are unordered. I = suggest you always use the </FONT> <BR><FONT SIZE=3D2>> >> term "set" or always use the = term "unordered set" when </FONT> <BR><FONT SIZE=3D2>> >> referring to values of a attribute = type. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >This was indeed poorly worded. The = intention was to refer to </FONT> <BR><FONT SIZE=3D2>> *sets* of values. (Unordered obviously.) We = will fix this in </FONT> <BR><FONT SIZE=3D2>> the next revision. However, PCELS defines = several items with </FONT> <BR><FONT SIZE=3D2>> "List" in the name. This is because = of the names of the </FONT> <BR><FONT SIZE=3D2>> corresponding information model items. I don't = think that we </FONT> <BR><FONT SIZE=3D2>> can change the names without creating = confusion.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 6) I note that a number of attributes = of syntaxes/matching </FONT> <BR><FONT SIZE=3D2>> >> rules which behave properly (ensure = same value (in different </FONT> <BR><FONT SIZE=3D2>> >> representations) is not stored twice, = ensure matching of </FONT> <BR><FONT SIZE=3D2>> >> different representations match) for = the kinds of </FONT> <BR><FONT SIZE=3D2>> >> application-restricted values placed = in them. For instance, </FONT> <BR><FONT SIZE=3D2>> >> it seems a bit odd to use case ignore = directory string </FONT> <BR><FONT SIZE=3D2>> >> matching for IPv6 addresses. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >I am not sure I understand what this issue = is. For instance </FONT> <BR><FONT SIZE=3D2>> the attribute pcelsIPv6AddrList is a = DirectoryString and it </FONT> <BR><FONT SIZE=3D2>> is mapped from a property defined by rfc3460 in = section </FONT> <BR><FONT SIZE=3D2>> 6.14.2. Among other things, this property can = be a hostname </FONT> <BR><FONT SIZE=3D2>> hence case insensitive. Is there anything wrong = with that?</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> 7) The I-D should detail delegations = it makes under the OID </FONT> <BR><FONT SIZE=3D2>> >> to be assigned by IANA. That is, = the x in IANA-ASSIGNED-OID.2.x </FONT> <BR><FONT SIZE=3D2>> >> should be specified so that the = RFC-Editor can simply replace </FONT> <BR><FONT SIZE=3D2>> >> IANA-ASSIGNED-OID with the assigned = OID throughout the I-D </FONT> <BR><FONT SIZE=3D2>> >> to produce the RFC-to-be. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >Since we might still see some minor changes = to the set of </FONT> <BR><FONT SIZE=3D2>> classes and attributes, the plan was to fill-in = the numbers </FONT> <BR><FONT SIZE=3D2>> after locking down the content but before = advancing the </FONT> <BR><FONT SIZE=3D2>> document to the next stage. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >And last but not least, thanks a lot for = revising this document </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >Thank you, </FONT> <BR><FONT SIZE=3D2>> >Mircea. </FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> >> -- Kurt </FONT> <BR><FONT SIZE=3D2>> >> </FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C3F427.0808936C--