<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; font-family: Calibri, sans-serif; font-size: 14px;">
<div style="color: rgb(0, 0, 0);">Thanks for the clarifications Marc. That helps a lot.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">One question for you is whether what we have in the “TM & TC frequencies” slots are actually frequencies, as in 2380 Ghz, or if they are frequency bands, as in “S Band”. I think that we may get enough relief from just using
the frequency bands (see attached table) that this in itself may be adequate, but I do recognize that there may be issues even at that level.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">As you pointed out:</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div>
<blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;">
<div><font color="#0000ff">that the reliability of that data is unknown for </font>
</div>
<div><font color="#0000ff">various reasons, such as: data was not entered properly by the operator,
</font></div>
<div><font color="#0000ff">data was not provided by the requestor, frequencies were changed from
</font></div>
<div><font color="#0000ff">the time of the registration request to the time of the launch and the
</font></div>
<div><font color="#0000ff">requestor never sent the information back to the registry operator</font></div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
</blockquote>
</div>
<div style="color: rgb(0, 0, 0);">Do you have any faith that if we were to attempt to apply the “separation by frequency bands” approach that we would have success at the 95% plus level, or would we be more at the 75% or 50% level?</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">As for “clear procedures”, yes, we do understand absolutely the need for this, for you as SANA Operaotr and for the user / requestor community.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">Thanks, Peter</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">On 7/30/15, 8:54 AM, "Marc Blanchet" <<a href="mailto:info@sanaregistry.org">info@sanaregistry.org</a>> wrote:</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="color: rgb(0, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px;">
<div>- clarifications below enclosed in <SANA> </SANA>.</div>
<div><br>
</div>
<div>Marc.</div>
<div><br>
</div>
<div>On 29 Jul 2015, at 17:22, Shames, Peter M (312B) wrote:</div>
<div><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>Dear Jean-Marc,</div>
<div><br>
</div>
<div>I agree completely that this is not a settled issue by any means, and </div>
<div>I am glad that you and Osvaldo are engaged more actively in the </div>
<div>discussion. As I noted, this has been discussed for some time, but </div>
<div>this is the first effort to try and come to terms with it and to </div>
<div>actually identify a workable solution. I believe that open dialogue </div>
<div>is essential, since this ultimately affects all agencies (and other </div>
<div>organizations) who use CCSDS standards.</div>
<div><br>
</div>
<div>Once we identify an agreed path forward we must then, as quickly as we </div>
<div>can, get all of the involved elements (registries, documents, </div>
<div>procedures), revised so that everyone knows what to expect. In the </div>
<div>meantime I think we are in a transitional state where we really must </div>
<div>retain as much of the limited “SCID namespace” as we can in order </div>
<div>to not find ourselves at an abruopt halt when we run out of available </div>
<div>numbers.</div>
<div><br>
</div>
<div>Other comments are in-line, below.</div>
<div><br>
</div>
<div>Very best regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>From: Jean-Marc Soula </div>
<div><<a href="mailto:Jean-Marc.Soula@cnes.fr">Jean-Marc.Soula@cnes.fr</a><<a href="mailto:Jean-Marc.Soula@cnes.fr>">mailto:Jean-Marc.Soula@cnes.fr></a>></div>
<div>Date: Wednesday, July 29, 2015 at 10:49 AM</div>
<div>To: Peter Shames </div>
<div><<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a><<a href="mailto:peter.m.shames@jpl.nasa.gov>">mailto:peter.m.shames@jpl.nasa.gov></a>>,
</div>
<div>"<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de></a>"
</div>
<div><<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de></a>></div>
<div>Cc: CCSDS Engineering Steering Group - CESG Exec </div>
<div><<a href="mailto:cesg@mailman.ccsds.org">cesg@mailman.ccsds.org</a><<a href="mailto:cesg@mailman.ccsds.org>">mailto:cesg@mailman.ccsds.org></a>>, "SANA
</div>
<div>Steering Group (SSG)" </div>
<div><<a href="mailto:ssg@mailman.ccsds.org">ssg@mailman.ccsds.org</a><<a href="mailto:ssg@mailman.ccsds.org>">mailto:ssg@mailman.ccsds.org></a>></div>
<div>Subject: RE: AW: [SANA #5270] AW: SCID assignments</div>
<div><br>
</div>
<div>Bonjour à tous,</div>
<div><br>
</div>
<div>I share the Oswaldo’s concern on which explanations or which </div>
<div>solutions may be offered by CCSDS to the projects requesting multiple </div>
<div>SCId and being rejected for those assets pertaining to the simulator / </div>
<div>tester … category.</div>
<div>I understand the rules have changed (and I do not object the arguments </div>
<div>for that) but the procedures were not yet revised (the abstracted blue </div>
<div>text below clearly shows that simulators / testers were valid assets </div>
<div>to obtain a SCId) … nor alternate solutions are offered (which we </div>
<div>should discuss further now).</div>
<div><br>
</div>
<div><br>
</div>
<div>You are correct in that the current, published, SCID document does not </div>
<div>discriminate against simulators nor testers. And yet we have this </div>
<div>problem that we must resolve in some way that does not halt the </div>
<div>ability of new spacecraft to be flown, by as many different users as </div>
<div>can be accommodated. In the immediate term the only way that I can </div>
<div>see to handle this is to only give out new (or re-cycled) SCIDs to the </div>
<div>real spacecraft. Your support for a set of registries sorted by </div>
<div>frequency, and inclusion of a "Frequency = none” category may be a </div>
<div>rapid way forward.</div>
<div><br>
</div>
<div>I think we can, through discussion, arrive at an agreed recommendation </div>
<div>to agencies re how to deal with the similator / tester issue. I hope </div>
<div>that this is the start of an active discussion where we try and arrive </div>
<div>at that agreement, because so far the discussion jhas ben of the </div>
<div>nature “We have a problem ….. What do we do?"</div>
<div><br>
</div>
<div>In CNES we also have several projects for which simulators have been </div>
<div>assigned a SCId, different from the one assigned to the SC.</div>
<div>Some more may come soon with similar requirements…</div>
<div><br>
</div>
<div><br>
</div>
<div>I hope that is sufficient motivation to have you and your staff, among </div>
<div>others from different agencies, get engaged in the discussion.</div>
<div><br>
</div>
<div>CCSDS should offer a workaround way to answer these requests and not </div>
<div>just reject the request because of the lack of Ids.</div>
<div><br>
</div>
<div>I agree we need a work-around. And I think we need to find one </div>
<div>quickly and document it.</div>
<div><br>
</div>
<div>Meanwhile, if we do not modulate requests for multiple SCIDs what is </div>
<div>to stop anyone from requesting several SCIDs for one spacecraft and </div>
<div>using up what little resource we have left?</div>
<div><br>
</div>
<div>Out of your list of activities below, Peter, I see Number 3 as quite </div>
<div>promising in terms of solving our SCId capacity issue, but I am not </div>
<div>100% sure if Number 4 could be another solution or not.</div>
<div><br>
</div>
<div>In more details:</div>
<div><br>
</div>
<div>Number 3: if SANA may allocate the same SCId to several missions, </div>
<div>based on the frequency discrimination, the issue of the testers / </div>
<div>simulators may be solved as they fall in the category “no </div>
<div>radiation” (meaning “no frequency”). Frequencies are already </div>
<div>part of the SCId request form and the information is already available </div>
<div>for a majority of missions (I hope).</div>
<div><br>
</div>
<div>You are correct, but we seem to have a bit of an issue. While the </div>
<div>transmitting frequencies (TM & TC) are on the form </div>
<div>(<a href="http://sanaregistry.org/cgi/spacecraftid">http://sanaregistry.org/cgi/spacecraftid</a>) they do not appear in the
</div>
<div>available database in SANA </div>
<div>(<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html">http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>). We will
</div>
<div>have to check with the SANA operator to see if this information is, in </div>
<div>fact, in the database but is just hidden in what is displayed.</div>
</blockquote>
<div><br>
</div>
<div><SANA>Currently, as discussed a while ago when we took over the </div>
<div>spacecraftid registry, frequencies are kept internally in the database </div>
<div>but are not exposed.</div>
<div><br>
</div>
<div>However, one has to understand that, as we did a giant cleanup of the </div>
<div>registry, it is clear that the reliability of that data is unknown for </div>
<div>various reasons, such as: data was not entered properly by the operator, </div>
<div>data was not provided by the requestor, frequencies were changed from </div>
<div>the time of the registration request to the time of the launch and the </div>
<div>requestor never sent the information back to the registry operator, </div>
<div>etc… Therefore, as we have seen for some IDs that were allocated </div>
<div>simultaneously to multiple missions, it took a long time to get the </div>
<div>space agencies involved to find the real frequencies used for those </div>
<div>missions. Therefore, the use of the frequency data for concurrent use of </div>
<div>spacecraft ids are a challenge. Moreover, we also heard that </div>
<div>spacecraftids are also used within information systems to uniquely </div>
<div>identify the spacecraft, and that id does not include the frequencies. </div>
<div>Therefore, the collision may also happen in information systems.</div>
<div><br>
</div>
<div>One also has to remember that we have been accepting requests and </div>
<div>provided assignments of spacecraft ids that were requested to be hidden </div>
<div>publicly (for various reasons such as military). Therefore, the public </div>
<div>version of the registry is not a full view of the database.</div>
<div></SANA></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>We will also have to accommodate spacecraft that use more than one </div>
<div>frequency, as in S / X or X / Ka. I do not know that the database in </div>
<div>its current form accommpodates that.</div>
</blockquote>
<div><br>
</div>
<div><SANA>we can certainly make it happen</SANA></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><br>
</div>
<div>As you suggest, perhaps we can, for a while, adopt that “no </div>
<div>frequency” approach and still manage the simulator / tester </div>
<div>assignments within SANA. I think that is an interesting approach to </div>
<div>discuss.</div>
<div><br>
</div>
<div>Number 4: I saw a lot of emails on registries but could not spend </div>
<div>enough time with them to be sure of the meaning of “Object Id </div>
<div>(OId)” and how it may be used in practice to differentiate the </div>
<div>assets of a same satellite project and the assets of multiple projects </div>
<div>between them. It could be, assuming some verifications, that the OID </div>
<div>is another way to allow SANA to allocate several times the same SCId </div>
<div>to several missions, based on the OID discrimination this time.</div>
<div><br>
</div>
<div><br>
</div>
<div>The concept of the OID is an ISO construct that the Cross Support </div>
<div>Services area first started to use. It is a tree structured name </div>
<div>space where “CCSDS” (ISO OID = 1.3.112.4) forms the base of the </div>
<div>tree and we then get to determine which classes of objects we will </div>
<div>assign unique numbers to. A proposal for how to manage that namespace </div>
<div>is in the draft Registry Policy document and there is an information </div>
<div>model for it as well. Both are attached here. What has been proposed </div>
<div>is that there is a branch of the OID tree for spacecraft, and that </div>
<div>every spacecraft, simulator, or tester would have a unique SCID </div>
<div>assigned. That Spacecraft OID, as proposed, is just a number, of the </div>
<div>form 1.3.112.4.7.nnn. This OID is assigned when any registeration </div>
<div>request is made and it remains associated with that spacecraft </div>
<div>forever. In that way it can be used to unambiguously tag the </div>
<div>spacecraft data and allows the SCIDs to just be used on the </div>
<div>transmitted spacelink.</div>
<div><br>
</div>
<div>The rest of the Spacecraft information will be stored in the </div>
<div>Spacecraft database, as it is now, along with the SCID (during the </div>
<div>valid period) and the OID (which is permanent). The model of the </div>
<div>spacecraft database is also attached for reference. Most of these </div>
<div>fields are in the current database, but any shown in red are newly </div>
<div>added. It does occur to me now that we will probably need to add both </div>
<div>transmitting and receiving frequencies, and to add the ability to have </div>
<div>a spacecraft with multiple frequency bands.</div>
<div><br>
</div>
<div>So if we adopt some such approach I agree that we can re-allocate the </div>
<div>same SCID, using the Version Number (protocol type) and Frequency(s). </div>
<div>On the ground we can use just the OID as a unique identifier since it </div>
<div>is permanent. But unless there is a way to adopt the OID on the </div>
<div>spacelink I do not think that gives us any discrimination in radiated </div>
<div>space communication.</div>
<div><br>
</div>
<div>Those two options should be explored quickly, and I believe this is </div>
<div>the idea in the messages below, to confirm that the activity Number 2 </div>
<div>may be cancelled and there is enough room then to continue the </div>
<div>allocation to simulators / testers.</div>
<div>Does it make sense ?</div>
<div><br>
</div>
<div><br>
</div>
<div>Based on this discussion, and if others agree with the use of </div>
<div>frequency band (including = none) , then I think that we could </div>
<div>continue to use the SANA to regsiter simulators and testers, as long </div>
<div>as we can use that distinction as well. For that matter, since these </div>
<div>simulators and testers will each belong to some single organization </div>
<div>that “owns” that asset you could even imagine a “Frequency = </div>
<div>None” namespace on a per agency / organization basis. There is no </div>
<div>fear then of collisions in communications and the OID can be used for </div>
<div>unambiguous identification of datasets. It is a little more </div>
<div>complicated than what we now do, but it is quite “future proof” </div>
<div>and avoids any risk of ambiguity.</div>
<div><br>
</div>
<div>In any case, one criteria to decide is how long it may take to put a </div>
<div>solution in place.</div>
<div>If too long, then we have a risk of overflow on the SCIds in the </div>
<div>meantime ; if doable in a reasonable time span, it would be a pity to </div>
<div>have rejected some requests for SCIds and have a solution for them a </div>
<div>few months later…</div>
<div><br>
</div>
<div>I agree, but contingent on getting rapid agreement on having a </div>
<div>“Frequency = none” SCID registry immediately set up, either on a </div>
<div>global basis or on an agency / organization basis. Does that sound </div>
<div>agreeable to you (and others)?</div>
<div><br>
</div>
<div>I think, for practicality, that we also need to reach agreement on a </div>
<div>set of SCID registries separated by frequency band (including None) so </div>
<div>that we can immediately re-gain some SCID breathing room/</div>
<div><br>
</div>
<div>Does that sound workable as well?</div>
</blockquote>
<div><br>
</div>
<div><SANA>From the point of view of SANA, it would be good for our </div>
<div>operations point of view that we had clear and written and </div>
<div>agreed/approved recommendations on the way forward. Written so we can </div>
<div>refer the requestors to the document that describes the (new) policy. It </div>
<div>does not need to be a full blown book, but some document that shows the </div>
<div>new policy that we are using as our base assignment policy.</SANA></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><br>
</div>
<div><br>
</div>
<div>So my recommendation would be to work on activities 3 or 4, with the </div>
<div>objective not to apply number 2.</div>
<div>Of course activities number 1 and 5 should continue, with less </div>
<div>pressure on number1 if a solution is found … and no pressure on </div>
<div>number 5 which anyway is a long term and maybe not a global solution.</div>
<div><br>
</div>
<div>For further discussions I believe…</div>
<div><br>
</div>
<div><br>
</div>
<div>Yes. Indeed.</div>
<div><br>
</div>
<div>Best regards</div>
<div><br>
</div>
<div>Jean-Marc Soula</div>
<div>CNES - DCT/OP/C-STA</div>
<div>Advisor, GN Operations</div>
<div>18 Avenue Edouard Belin</div>
<div>31401 Toulouse Cedex 9 - France</div>
<div>Tel.: +33 (0)5 61 2 74647</div>
<div>Fax.: +33 (0)5 61 2 73135</div>
<div>Email: <a href="mailto:Jean-Marc.Soula@cnes.fr">Jean-Marc.Soula@cnes.fr</a><<a href="mailto:Jean-Marc.Soula@cnes.fr">mailto:Jean-Marc.Soula@cnes.fr</a>></div>
<div><br>
</div>
<div>Best regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>De : </div>
<div><a href="mailto:ssg-bounces@mailman.ccsds.org">ssg-bounces@mailman.ccsds.org</a><<a href="mailto:ssg-bounces@mailman.ccsds.org">mailto:ssg-bounces@mailman.ccsds.org</a>>
</div>
<div>[<a href="mailto:ssg-bounces@mailman.ccsds.org">mailto:ssg-bounces@mailman.ccsds.org</a>] De la part de Shames, Peter M
</div>
<div>(312B)</div>
<div>Envoyé : mercredi 29 juillet 2015 18:18</div>
<div>À : <a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de">mailto:osvaldo.peinado@dlr.de</a>></div>
<div>Cc : CCSDS Engineering Steering Group - CESG Exec; SANA Steering Group </div>
<div>(SSG)</div>
<div>Objet : [SSG] Re: AW: [SANA #5270] AW: SCID assignments</div>
<div>Importance : Haute</div>
<div><br>
</div>
<div>Dear Osvaldo,</div>
<div><br>
</div>
<div>As I think you are aware, the CCSDS is in danger of running out of </div>
<div>available spacecraft ID (SCID) numbers. You could say that we are now </div>
<div>being hurt by our own success because there are so many spacecraft </div>
<div>using CCSDS data link and related standards that we no longer can </div>
<div>assign a SCID for the spacecraft, the simulator, and other possible </div>
<div>“flight-less birds”.</div>
<div><br>
</div>
<div>In the current SCID document, CCSDS 320.0-B-6C1, we have this </div>
<div>statement (emphasis added):</div>
<div><br>
</div>
<div>Section 2.1 Purpose of the CCSDS SCID</div>
<div><br>
</div>
<div>Because the SCID field is only eight or ten bits long, the SCID is not </div>
<div>intended to provide unique identification for all times.</div>
<div>It is inevitable that the SCIDs will have to be reused; however, at </div>
<div>any one time, the number of vehicles under simulation,</div>
<div>test, or active operational control is not anticipated to exceed the </div>
<div>available numbering domains.</div>
<div><br>
</div>
<div>Clearly this is no longer the case and the SSG, SLS and CESG have been </div>
<div>discussing this for at least the last three meetings. There are </div>
<div>several loosely coordinated activities which are now in process that </div>
<div>relate to this:</div>
<div><br>
</div>
<div>1) We have requested the Agency Representatives to relinquish all </div>
<div>assigned SCIDs for spacecraft that are no longer operational. This </div>
<div>has been somewhat successful, but we need to do it again.</div>
<div>2) We are in the process of revising the SCID assignment procedures to </div>
<div>no longer allow assignment of multiple SCID for a spacecraft </div>
<div>(simulators, testers, etc)</div>
<div>3) We are considering the use of frequency separation as well as the </div>
<div>current Version Number (VN) separation that is now in use. This could </div>
<div>relatively easily increase the number assignment space.</div>
<div>4) Under the new registry approach that is now in discussion we will </div>
<div>be assigning unique, permanent, object identifiers (OID) to all </div>
<div>spacecraft, similators, flightless birds, etc. These will persist </div>
<div>through time.</div>
<div>5) We are working on a new protocol, USLP, with a larger SCID number </div>
<div>space.</div>
<div><br>
</div>
<div>We have not yet discussed in any depth what recommendation we can make </div>
<div>to organizations who wish to have a separate, unique, SCID that they </div>
<div>can use internally to distinguish the spacecraft from any other </div>
<div>simulators or test gigs. Clearly this is a concern, but it is may be </div>
<div>treated as an internal issue that can be managed locally. It does not </div>
<div>have the same potential for cross agency impact because any such </div>
<div>signals will not be broadcast.</div>
<div><br>
</div>
<div>If you (or anyone else on this thread) has any other ideas or wishes </div>
<div>to contribute to the discussion please do so. I think that this is an </div>
<div>important enough issue for us to work quickly (as quickly as CCSDS can </div>
<div>move) to come up with a resolution.</div>
<div><br>
</div>
<div>Best regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>On 7/29/15, 7:43 AM, </div>
<div>"<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de></a>"
</div>
<div><<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de></a>> wrote:</div>
<div><br>
</div>
<div>Dear Audric,</div>
<div>I know about the problem of SCIDs becoming rare.</div>
<div>You can process the satellite one, and discard the SIM one, BUT ....I </div>
<div>need to have for the project anyways and official answer from SANA.</div>
<div>It should be possible to inform the users about the situation and in </div>
<div>case of rejecting a request indicate a reference to a document and to </div>
<div>propose a solution, like "use the same ID as the Spacecraft or </div>
<div>something that you like, because your system is a closed one", as </div>
<div>example , can you do that?</div>
<div>I have another question:</div>
<div>I need to submit a request for another Satellite and it looks like the </div>
<div>link to do the request from the SANA page simply disappear, it is only </div>
<div>an E-mail.</div>
<div>It is that correct?</div>
<div>Thanks and best Regards</div>
<div>O. Peinado</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-----Ursprüngliche Nachricht-----</div>
<div>Von: SANA [<a href="mailto:info@sanaregistry.org">mailto:info@sanaregistry.org</a>]</div>
<div>Gesendet: Mittwoch, 29. Juli 2015 16:07</div>
<div>An: Peinado, Osvaldo Luis</div>
<div>Betreff: Re: [SANA #5270] AW: SCID assignments</div>
<div><br>
</div>
<div>Dear Mr. Peinado,</div>
<div><br>
</div>
<div>We were waiting for the SSG answer before getting back to you and see </div>
<div>if</div>
<div>you had any constraint on the two SCIDs being assigned at the same </div>
<div>time</div>
<div>or not.</div>
<div><br>
</div>
<div>If you tell us that we can go and process the non-sim request, we will</div>
<div>happily do that.</div>
<div><br>
</div>
<div>Thank you.</div>
<div><br>
</div>
<div>--</div>
<div>Best regards,</div>
<div>Audric Schiltknecht</div>
<div>Space Assigned Numbers Authority</div>
<div><br>
</div>
<div>Le 2015-07-29 09:47, </div>
<div><a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de">mailto:osvaldo.peinado@dlr.de</a>> a écrit :</div>
<div>Dear Audrich</div>
<div>Thank you for your answer.</div>
<div>I´m aware about the discussion about the SIM SCID and that till now </div>
<div>is nothing written down to deal with it, but what happened with the </div>
<div>SCID for the satellite?</div>
<div>I sent two separate request.</div>
<div>I do not see it also in the list of registry updates, why?</div>
<div>Best Regards</div>
<div>Osvaldo</div>
<div>-----------------------------------</div>
<div>Dr. Osvaldo Peinado</div>
<div>Ground Operations Manager</div>
<div>German Space Operations Center (GSOC)</div>
<div>Tel: +49 8153 28 3010</div>
<div>Fax: +49 8153 28 1456</div>
<div>Mobile: +491729410099</div>
<div>German Aerospace Center (DLR)</div>
<div>Oberpfaffenhofen</div>
<div>82234 Wessling</div>
<div>Germany</div>
<div>-----Ursprüngliche Nachricht-----</div>
<div>Von: Space Assigned Numbers Authority [<a href="mailto:info@sanaregistry.org">mailto:info@sanaregistry.org</a>]</div>
<div>Gesendet: Dienstag, 28. Juli 2015 22:35</div>
<div>An: Peinado, Osvaldo Luis</div>
<div>Cc: Space Assigned Numbers Authority</div>
<div>Betreff: SCID assignments</div>
<div>Dear Mr. Peinado,</div>
<div>SANA are currently discussing some issues regarding your recent SCID</div>
<div>requests with the SSG (Sana Steering Group).</div>
<div>When all is sorted out, we will inform you of the result.</div>
<div>Thank you for your understanding.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>[CCSDS OID Tree flat 10Jul15 v6.pdf]</div>
<div><br>
</div>
<div>[Spacecraft ID, name, & characteristics v1.pdf]</div>
<div><br>
</div>
<div>[CCSDS SCID Registry relationships v3.pdf]</div>
<div>_______________________________________________</div>
<div>SSG mailing list</div>
<div><a href="mailto:SSG@mailman.ccsds.org">SSG@mailman.ccsds.org</a></div>
<div><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg</a></div>
</blockquote>
<div><br>
</div>
</blockquote>
</body>
</html>