<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Erik,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">See comments </span><span style="color:red"><JVP> embedded</JVP>
</span><span style="color:#1F497D">below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Barkley, Erik J (3970) [mailto:erik.j.barkley@jpl.nasa.gov]
<br>
<b>Sent:</b> Tuesday, June 09, 2015 9:55 PM<br>
<b>To:</b> John Pietras; CCSDS SMWG ML (smwg@mailman.ccsds.org); CCSDS_CSTSWG (css-csts@mailman.ccsds.org)<br>
<b>Subject:</b> RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The notion of being able to only subtract from the maximum set of transfer services in the configuration profile I think addresses my main concern. I think we should note that this perhaps means some relatively
minor lesser ability for dynamic configuration on the fly ("oh, but we really want that extra transfer service today”) but that is probably okay. How I read this then (and probably what was implied all along) is that the resource instance numbers are a configuration
profile build time activity only and cannot be dynamically added to at service package request time. Presumably, for the eventual SM spec, I assume that the FR Names will be called out for indicating the particular transfer instance is “on” or “off” (further
assuming that this shows up in the new version of Service Package Request). <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red"><JVP> I am assuming that we’ll use something similar to the instanceEnabled parameter for each transfer service instance, as described below </JVP><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">With regard to a diagram, below is a copy of a diagram we discussed at the service management meeting with regard to development of service agreement and service configuration profile books. I think this helps
in looking at the overall situation. For example, SLE will continue to have, presumably, it's "traditional" SIIs and not the "newfangled" CSTS identifiers. But service management will have to deal with both of these. Although these are not class diagrams,
there was in some of the other diagrams in the discussion indications of cardinality and it will help to understand that, for example, the typical cardinality as far as I know for the SLE FWD Space Pkt to TC SLP is 0..* -- granted that does not add much to
the SII discussion but it does help to know that the SIIs, based on the FR Name, need to allow for whatever cardinality is specified. </span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red"><JVP> It sounds like you’re referring to the diagram that you are talking about is the big Functional Resource diagram (fig. 4-1) and possibly the functional resource composition diagrams throughout section 6 of
the FR Tech Note. The Data Transfer Services FRs that correspond to the SLE and CSTS transfer services are color-coed as such, and the cardinality is shown. </JVP>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">And it will also be nice to see MD-CSTS in this picture – messy as that may be. If MD-CSTS is a functional resource to the same degree that TD-CSTS is, then this seems to argue that it will be called out in
the SM configuration profile, as well. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red"><JVP> The diagram below shows the Service Components involved in the production and provision of space communication and radiometric data services. MD-CSTS is not explicitly shown here because (a) it belongs to
the Service Management Functions Abstract Service Component and (b) since the MD-CSTS “touches” everything involved in the production and provision of space communication and radiometric data services, it would indeed be messy. But if you do want to see MD-CSTS
on a similar diagram, look at fig. 6-26 of the FR Tech Note. </JVP><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In any case, I think my main concerns re SII have been addressed for now.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><img width="600" height="471" id="Picture_x0020_13" src="cid:image001.png@01D0A774.CD6BE6B0"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> John Pietras [<a href="mailto:john.pietras@gst.com">mailto:john.pietras@gst.com</a>]
<br>
<b>Sent:</b> Monday, June 08, 2015 2:04 PM<br>
<b>To:</b> Barkley, Erik J (3970); CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>); CCSDS_CSTSWG (<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>)<br>
<b>Subject:</b> RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Erik,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I’m not sure what you are asking for n the way of a diagram. Do you just want to see a graphical representation of the contents of the exist CSTS SII vs. the proposed one? Somehow I’m guessing that it’s more
than that. If you can give me a little better idea of what “situation” you are referring to, I’ll give it a stab.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Meanwhile, I’ll try to respond to your questions and comments on point 2 (interleaved
</span><span style="color:red">in <JVP> red </JVP> </span><span style="color:#1F497D">below). Maybe the answers will be good enough to bypass the need for a diagram (or further clarify what the focus of the diagram should be).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Barkley, Erik J (3970) [<a href="mailto:erik.j.barkley@jpl.nasa.gov">mailto:erik.j.barkley@jpl.nasa.gov</a>]
<br>
<b>Sent:</b> Thursday, June 04, 2015 8:02 PM<br>
<b>To:</b> John Pietras; CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>); CCSDS_CSTSWG (<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>)<br>
<b>Subject:</b> RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Now that I’ve had a bit of time to digest this, some comments, questions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">1)</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span style="color:#1F497D">Pg 6, it will probably be helpful if a diagram could be produced that illustrates the situation. I hope that is not a significant undertaking.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">2)</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span style="color:#1F497D">Assuming that the FRIN being used in the SII is as I think it is (the diagram will help), it does raise some potential concerns<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="color:#1F497D">a.</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span style="color:#1F497D">If we assume that the next generation service package has the current B-1 capability (which I believe is the case per the current abstract service request engineering under way) to modify a configuration profile (technically
profile re-specification) for the duration of the service package, then do we assume that the addition of a CSTS instance as part of that modification for the service package will come with a “pre-validated” FRIN
</span><span style="font-family:Wingdings;color:#1F497D">à</span><span style="color:#1F497D"> SII ? Or am I missing something here? (“Turning off” as CSTS instance does not seem like a problem). Also, we would probably disallow modification of FRINs as part
of the service package configuration profile re-specification? <o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><JVP> Good question and observation. If you recall, in SCCS-SM B-1 we didn’t actually allow space communication service profiles to be re-specified in Service Packages to add (SLE)
transfer service instances in an unconstrained way. Rather, each space communication service profile is defined as having an existing set of transfer service mapping objects (TsMaps), where each TsMap is linked to a Transfer Service instance that is defined
in a different part of the Service Package. Each TsMap object has an instanceEnabled parameter that is used to include that TS instance in the Service Package. So the greatest possible population of TS instances available via a given space communication service
profile *<b>is</b>* predefined – the only option is to re-specify one or more of the TsMaps as being disabled (i.e., not used in this particular Service Package).
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">We can use an approach that is similar for Extensible SCCS-SM, although there are possibilities for variations that might be better and should be explored. For the sake of discussion,
the approach that is arguably closest to the B-1 approach is one in which there are a predefined pool of TS profiles (now CSTSes in addition to SLE TSes) that can be used to construct Service Packages. Each of those pre-defined TS profiles will be for a specific
service instance and will have a FRIN that cannot be changed. Each space communication service packages will contain mappings to the maximum set of TS instances that might possibly be used.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">This is my current thinking, and I think that it is feasible. If anyone can see flaws of has a better or more elegant approach, please don’t hesitate to speak up.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">Note that there is a slight difference between this Extensible approach and the B-1 approach. In B-1, we allowed for the possibility of multiple instances of the same TS profile to
exist. Multiple TsMap objects is a space communication service profile could point to the same TS profile, and in scheduling a Service Package with such a space communication service profile, Complex Management (CM) would dynamically assign a different transferServiceInstanceNumber
to each TS instance. If you think about it, that is exactly the situation that we had when we assumed that CM (now Provision Management (PM)) would dynamically assign the FRINs – Mission users of the service could only know what service instance they were
dealing with after reading the Service Package Result. Requiring the there be a profile for each possible TS instance removes that dynamic uncertainty at the cost of creating multiple TS profiles where possibly only one might have needed to be created, although
in reality I have come to question whether multiple instances of the same TS profile was all that useful a “feature” anyway.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"></JVP><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="color:#1F497D">b.</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span style="color:#1F497D">It seems that for this approach, for things like MD-CSTS or TD-CSTS instances would have to be part of the service configuration profile. I’m not sure we have agreement that this would be the case – I think we have asked
questions like “are things like MD-CSTS just assumed to be there or do they need to be explicitly defined in the service configuration profile”? I will agree that it does not seem like a likely use case to have two MD-CSTS (or TD-CSTS) instances running in
parallel, but I would not put it past an implementation to think of “interesting” deployment options. Again, perhaps I’m mission something here.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><JVP> I’m not sure that I agree about the unlikelihood of multiple instances of MD-CSTS or TD-CSTS in the same Service Package – for complex spacecraft with concurrent links in multiple
bands, there may be operators monitoring performance per band, and as far as TD-CSTS goes, I can easily see the spacecraft control center getting a subset of tracking data that helps them evaluate the progress of a maneuver in near-real time, whereas another
TD-CSTS user of the same Service Package might be a Flight Dynamics facility that’s collecting all sorts of measurements in order to maintain a highly accurate trajectory model.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">Be that as it may, for whatever reasons, I have been assuming that multiple MD-CSTS and TD-CSTS instances can exist in a Service Package (however, I do believe that only one Service
Control CSTS instance should exist per Service Package). However, the MD-CSTS and TD-CSTS cases relate to the sService Package in different ways. Let’s look at each case individually.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">The MD-CSTS inherently can touch all functional resources in a service package, although the user of the MD-CSTS has to select (using the list-of-parameters and list-of-events parameters
of the relevant START invocations) which parameters and event notification will actually be reported. The MD-CSTS has the great advantage that it names its parameters and events using the same functional resource-based naming that Service Management uses.
E.g., since the functional resource that corresponds to the X-band downlink is represented in the Service Package as [FR Type OID = {Return 401 Space Link Carrier Reception} : FRIN = 2 ] , when MD-CSTS reports the actual-receive-frequency for [FR Type OID
= {Return 401 Space Link Carrier Reception} : FRIN = 2 ] the MD-CSTS user already knows where its coming from.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">There may be multiple MD-CSTS profiles (again, one for each possible MD-CSTS instance), but they will “attach” to the service package at a different place than where the space communication
service profiles and what I’ll call space communication transfer services profiles attach.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="color:red">Now let’s look at the situation with TD-CSTS, which is a bit trickier. A TD-CSTS instance is also nominally capable of reporting all tracking data measurements generated out of a
service package, so it too attaches to the service package independent of individual space communication service profiles. But the relationship between what tracking-data-generating resources are contained in the configuration profiles and what gets reported
in the payload of the TD-CSTS TRANSFER-DATA messages is not as straightforward is it is with MD-CSTS, because the TD-CSTS carries TDM segments that of course contain no reference to functional resource instances. I am still far from coming up with a complete
solution, but as of now I’m assuming that the solution will involve something like the following:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:red">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:red">
</span><span style="color:red">Those functional resources that represent resources that generate tracking data will have managed parameters that identify the TDM keyword values that are to be used for those tracking data parameters and associated metadata keywords.
Admittedly, this mapping will be complicated, because of the way the TDMs separate their information between metadata and data sections.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:red">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:red">
</span><span style="color:red">The TD-CSTS profiles will have to have some way of specifying which tracking data measurements from which particular functional resource instances are going to be reported by the particular TD-CSTS instance. Unlike MD-CSTS, where
the user of the service instance selects what she wants reported dynamically after the service instance is bound, in TD-CSTS all such selections have been deferred to Service Management. I have to admit that that was done so that a TD-CSTS spec could be created
without having to develop a language for dynamically specifying what is to be delivered. Yeah – I kicked the can over the wall to Service Management.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red">So the bottom line is that I’m comfortable that we’ve got a good handle on MD-CSTS (although I may not have yet convinced you of that), but I admit that there’s still a lot of work integrating TD-CSTS into Service
Management. But even so, to get back to what I think was the scope of your original question, TD-CSTS will still be an entity of the Service Package as a whole and not “contained by” space communication service profiles.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red">Did that in any way answer any of your questions?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:red"></JVP><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><o:p> </o:p></span></p>
</div>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:13.5pt;font-family:"Times New Roman","serif";color:black;background:white">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Times New Roman","serif";color:black;background:white"><br>
<a href="https://filter.gst.com/canit/b.php?i=01OCpW0PU&m=b17aa4c4c4a1&c=s" target="canit_note">Spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01OCpW0PU&m=b17aa4c4c4a1&c=n" target="canit_note">Not spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01OCpW0PU&m=b17aa4c4c4a1&c=f" target="canit_note">Forget previous vote</a></span><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><o:p></o:p></span></p>
</div>
</div>
</body>
</html>