<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Folks,</div>
<div><br>
</div>
<div>From the recent CESG meeting I have the action to update the SCID (and MACAO) registry documents. One intent on my part, aside from creating agency, member, affiliate, point of contact, representative registries that could be re-used as needed, was also
to add unique OIDs for all of the objects that get registered, whether organizations, persons, facilities, or spacecraft. </div>
<div><br>
</div>
<div>A part of that is to propose that each requrest for a SCID registration would also assign an OID. The SCIDs must be "relinquished" when the S/C is no longer in operation. The OID would be permanently assigned. Furthermore, I am proposing that we can
assign an OID without assigning a SCID. This handles those situations you identifid and also would allow us to register things like CubeSats that do not use CCSDS space link protocols, but still may use CCSDS agency space comm assets.</div>
<div><br>
</div>
<div>Does this make sense to you guys?</div>
<div><br>
</div>
<div>See attached DRAFT edits to the SCID and MACAO docs that include these features and updates to the (largely existent) SANA registry definitions..</div>
<div><br>
</div>
<div>Regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, June 2, 2015 at 7:11 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>" <<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>><br>
<span style="font-weight:bold">Cc: </span>SMWG <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>>, Wolfgang Hell <<a href="mailto:Wolfgang_._Hell@t-online.de">Wolfgang_._Hell@t-online.de</a>><br>
<span style="font-weight:bold">Subject: </span>RE: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div 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">
<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.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{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;}
/* List Definitions */
@list l0
{mso-list-id:1799176574;
mso-list-type:hybrid;
mso-list-template-ids:2037007948 -1009344854 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Marcin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The problem with using the SANA SCID registry for the spacecraft names for the ‘user’ parameter of the Simple Schedule is not that some missions don’t want (or are too lazy) to register their missions there,
it is that the purpose of the SANA SCID registry is to assign CCSDS Spacecraft Identifiers (those relatively small integer values that appear in the CCSDS transfer frame headers). In order to get your spacecraft into the SANA SCID registry, your spacecraft
has to use CCSDS space link protocols in the first place. NASA, for one still supports a number of missions that don’t use CCSDS space link protocols (for a variety of reasons). Those missions couldn’t register their S/C in the SCID registry if they wanted
too (the “SCID space” is too small for CCSDS to allocate them to missions that don’t actually use them). But that still doesn’t mean that the networks supporting those missions can’t use CCSDS Service Management interfaces (e.g., the Simple Schedule).
<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 don’t think that your proposed solution solves the problem either. Even if some SC names were not registered with SANA, they would have to be “registered” in some way – e.g., in some form of a
service agreement (not necessarily one that conforms to the (eventual) CCSDS Service Agreement Info Entity). A SANA registry is just a convenient place to collect all of those names in a common place so that they can be used consistently and authoritatively
whenever a CCSDS standard service needs to use a spacecraft name. <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">However, I agree that creating a separate SC Name registry opens up the possibility of multiple registries with inconsistent contents (some registered in one but not the other, different spellings, etc.). I think
a better solution would be to alter the SANA CCSDS SCID registry into a SANA Spacecraft Name and SCID registry that allows for the registration of SC names and *<b>optionally</b>* CCSDS SCIDs. That would create a single authoritative source for all SC names,
and if some of those also happen to use/need CCSDS SCIDs those will be there too. Or a relational database approach could be applied to those registries that work of various subsets of related date (in this case, related by spacecraft name).<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">I haven’t yet read the email that Erik sent out about the new proposals for SANA registries – perhaps some of these issues will be addressed there.<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">Talk to you soon in the WebEx.<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>
<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: 10pt; font-family: Tahoma, sans-serif;">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;">
<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a> [<a href="mailto:Marcin.Gnat@dlr.de">mailto:Marcin.Gnat@dlr.de</a>]
<br>
<b>Sent:</b> Tuesday, June 02, 2015 9:38 AM<br>
<b>To:</b> John Pietras<br>
<b>Cc:</b> <a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>; <a href="mailto:Wolfgang_._Hell@t-online.de">
Wolfgang_._Hell@t-online.de</a>; <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a><br>
<b>Subject:</b> RE: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi 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">Especially in the latter case you shown, creating another registry does not necessarily help, because it still may happen that someone didn’t registered there (didn’t wanted, or being too lazy ;-)), exactly as
at S/C ID Registry the problem is. <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">My simple proposal would be eventually (if we are going to change anything) to rather go for another special keyword (like “NONREGISTERED” or “OTHER”) which should be followed by in such a case obligatory extension
attribute i.e.:<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">-user=”NONREGISTERED”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">–nonreguser=”Cool S/C Name which is not registered in SANA”<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 other cases than “NONREGISTERED” this attribute would be optional.<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">We can than cover Non-SANA Spacecraft and we do not generate extra registries. <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">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Marcin<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: 10pt; font-family: Tahoma, sans-serif;">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;"><a href="mailto:smwg-bounces@mailman.ccsds.org">smwg-bounces@mailman.ccsds.org</a> [<a href="mailto:smwg-bounces@mailman.ccsds.org">mailto:smwg-bounces@mailman.ccsds.org</a>]
<b>On Behalf Of </b>John Pietras<br>
<b>Sent:</b> Montag, 1. Juni 2015 20:02<br>
<b>To:</b> <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a><br>
<b>Cc:</b> CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>);
<a href="mailto:Wolfgang_._Hell@t-online.de">Wolfgang_._Hell@t-online.de</a><br>
<b>Subject:</b> [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Colin,<o:p></o:p></p>
<p class="MsoNormal">As currently defined in E2.3 of the Simple Schedule book, the content of the ‘user’ column CSS User Registry is confined to:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]-->UNALLOCATED<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]-->PROVIDER-CSSS, or<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]--> “any value contained in the SANA Spacecraft Identifiers Registry (<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html">http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>) column ‘Spacecraft Name’”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While Wolfgang and I were discussing the ‘spacecraftName’ component of the CSTS Service Instance Identifier (see the email that I sent out earlier today) this morning, Wolfgang made a point that upon further consideration raises an issue
for the Simple Schedule book. That point is that not all spacecraft that are supported by CCSDS member agencies have CCSDS-assigned SCIDs (he mentioned Russian spacecraft as an example).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wolfgang’s concern focused on tying the CSTS SII to the existing SANA SCID registry, but this also applies to the Simple Schedule, assuming that that we would promote the use of the Simple Schedule to report the schedules for spacecraft
that don’t have CCSDS SCIDs.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I think that we’re going to have to loosen up the specification of the allowable contents of the ‘user’ column of the CSS User Registry.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This issue has triggered several more thoughts. As currently constructed, the CSS User Registry must be constantly updated to copy the spacecraft names from the SANA SCID registry. Ignoring for the moment the issue of some desirable SC
names not appearing in the SANA SCID registry in the first place, wouldn’t it be simpler (that is, easier to maintain) to simply specify in the definition of the Simple Schedule ‘user’ parameter that it’s allowed values are<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]-->UNALLOCATED<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]-->PROVIDER-CSSS, or<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]--> “any value contained in the SANA Spacecraft Identifiers Registry (<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html">http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>) column ‘Spacecraft Name’”<o:p></o:p></p>
<p class="MsoNormal">without creating a separate registry?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Of course, we do have the possibility of needing to register names that don’t appear in the SANA SCID registry, so we do need the some sort of registry for those names. However, by including UNALLOCATED and PROVIDER-CSSS in the CSS User
Registry, this registry is constrained to be used *<b>only</b>* for the ‘user’ parameter of the Simple Schedule. If we have another Info Entity with a parameter populated by spacecraft names but not UNALLOCATED or PROVIDER-CSSS (perhaps Service Agreement,
for example), we’d have to create another registry that copies almost all of the contents except the Simple Schedule ‘user’ parameter-specific UNALLOCATED and PROVIDER-CSSS values. An alternative approach would be to define a CSS Spacecraft Name registry that
contains only that (spacecraft names), and defines the allowed values in the Simple schedule ‘user’ parameter as:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]-->UNALLOCATED<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]-->PROVIDER-CSSS, or<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">
</span></span><!--[endif]--> “any value contained in the SANA CSS Spacecraft Name Registry”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That is, distinguish the spacecraft Name registry (which will vary over time but could be used for multiple purposes) from the Simple Schedule ‘user’ parameter-specific values.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My apologies for raising these concerns in the 11<sup>th</sup> hour, but the need to support spacecraft that don’t use CCSDS SCIDs is an issue that does need to be addressed. The rest of the comments are observations on what might be better
ways to proceed but aren’t critical to the correctness or applicability of the Simple Schedule specification.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<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-color: white; background-position: initial initial; background-repeat: initial initial;">
<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-color: white; background-position: initial initial; background-repeat: initial initial;">NOTE: This message was trained as non-spam. If this
is wrong, please correct the training as soon as possible. <br>
<a href="https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=s" target="canit_note">Spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=n" target="canit_note">Not spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=f" target="canit_note">Forget previous vote</a></span><span style="font-size: 12pt; font-family: 'Times New Roman', serif;"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>