<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Microsoft Word - 313x1y1_CMC_Approval.doc</title>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-family: Calibri, sans-serif;">
<div style="font-size: 14px;">
<div>
<div>Dear Jean-Marc,</div>
<div><br>
</div>
<div>In order to resolve the issues you raised in these three CMC polls I propose the following set of changes. The proposed resolution responses are in-line below and the specific revisions to text are inserted in the marked-up review versions that were sent
to the CMC. Please indicate if you agree with these changes.</div>
</div>
</div>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">I think that there are two questions that may require further discussion:</div>
<ol>
<li>In CCSDS 313.1-Y-1, SANA Registry Management Policy, sections <span style="font-size: 14px;">3.3.1.3.10 thru 3.3.1.3.15 define all of the requriements for roles. This is treated as a part of the Contacts Registry, but these are really definitions for Roles.
And there are both Contact and Organization Roles, and these may be extended over time as new types are required. Were you suggesting that this sub-section on Roles have its own section numbering?</span></li><li>There is a method defined to synch the IOAG RF Asset and CCSDS Service Site & Aperture registries. Since the databases are both managed by the SANA their design could share certain common tables between the two databases, which would deal with synchronization.
At some point in the future the two organization could consider merging these two into one, but we thought it best to side-step that for now. Do you agree?</li></ol>
<div style="font-size: 14px;">Once we agree on these proposed changes I will update any figures and send it off to the Secretariat for publication.</div>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">Best regards, Peter</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;">
<div style="font-family:Calibri; font-size:12pt; 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><<a href="mailto:cesg-all-bounces@mailman.ccsds.org">cesg-all-bounces@mailman.ccsds.org</a>> on behalf of Tom Gannett <<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>><br>
<span style="font-weight:bold">Date: </span>Saturday, May 7, 2016 at 4:06 PM<br>
<span style="font-weight:bold">To: </span>CMC <<a href="mailto:CMC@mailman.ccsds.org">CMC@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Cc: </span>CCSDS Engineering Steering Group - CESG All <<a href="mailto:cesg-all@mailman.ccsds.org">cesg-all@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Subject: </span>[Cesg-all] Results of CMC Polls Closing 6 May 2016<br>
</div>
<div><br>
</div>
<span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>CMC E-Poll Identifier: CMC-P-2016-04-010 </div>
<div>Authorization to publish CCSDS 313.0-Y-2, Space </div>
<div>Assigned Numbers Authority (SANA)—Role, </div>
<div>Responsibilities, Policies, and Procedures Yellow Book, Issue 2)</div>
<div><br>
</div>
<div>Results of CMC poll beginning 13 April 2016 and ending 6 May 2016:</div>
<div><br>
</div>
<div> Adopt: 9 (90%) (CNSA, CSA, DLR, </div>
<div>ESA, FSA, INPE, JAXA, NASA, UKSA)</div>
<div> Adopt Provisionally: 1 (10%) (CNES)</div>
<div> Reject: 0 (0%)</div>
<div> Reject with Comments: 0 (0%)</div>
<div><br>
</div>
<div>CNES: - Is Reference [2] in section 1.7 </div>
<div>appropriate as it is never called in the document ?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">Actually the SANA Consideraitons section on Page B-1 sould reference the CCSDS Publications Manual [2]. This has been added to the text.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- Section 2 (bottom of page 2-1), puts </div>
<div>prerequisites on the agency review, with a </div>
<div>candidate registry, and to the publication, with </div>
<div>an approved registry. Three questions:</div>
<div>* as this is new, should it be documented in the </div>
<div>the CCSDS Org & Processes document ?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The CCSDS Org & Proc has a section on SANA (2.3.1.4.7) that describes the general features and then says “for guidance see the SANA Procedures.”. I do not think we need to add more materials to the Org & Proc.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>* as this may delay the overall production cycle </div>
<div>of standards, are there commitments from the SANA </div>
<div>operator on the maximum time required to </div>
<div>establish a Candidate / Approved registry ?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The SANA Operator has shown itself to be very responsive. There is not a posted time to respond, but in practice it has been a matter of a few days. Given the usual cadence of CCSDS progress this should be adequate … I am certain
that the delays will remain elsewhere.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>* Could approval of the registry be part of the </div>
<div>same poll as the prublication of the related </div>
<div>standard (to avoid consecutive polls) ?</div>
<div>If so, processes should also be updated.</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The approval of the registry is a matter that is essentially handled by the WG itself. As long as the WG includes something like a registry information and process design in the draft RB, as required in the revisions to Sec 3.10,
the review of this aspect will already be an integral part of the document review.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- In section 3.18 what is meant with the words </div>
<div>"concurrence of the CMC" for "formation (b)" or </div>
<div>"termination (h) of an expert group? As CMC </div>
<div>manages the allocation of resources should the </div>
<div>word "concurrence" be replaced with the word "approval" ?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">Agreed. Replace the terms “concur” with “approve” in those two clauses. The level of resouce commitment is intended to be modest, but it does need to be provided.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>Results are based on responses from 10 out of 11 members (90.91%).</div>
<div><br>
</div>
<div>No response was received from the following Agencies:</div>
<div><br>
</div>
<div>ASI</div>
<div><br>
</div>
<div>Secretariat Interpretation of Results: Adopted Provisionally</div>
<div>Resulting CMC Resolution: CMC-R-2016-05-001</div>
<div>Inferred Secretariat Action: Address Provisions; Publish Document</div>
<div><br>
</div>
<div>* * * * * * * * * * * * * * * * * * * *</div>
<div><br>
</div>
<div>CMC E-Poll Identifier: CMC-P-2016-04-011 </div>
<div>Authorization to publish CCSDS 313.1-Y-1, CCSDS </div>
<div>SANA Registry Management Policy (Yellow Book, Issue 1)</div>
<div><br>
</div>
<div>Results of CMC poll beginning 13 April 2016 and ending 6 May 2016:</div>
<div><br>
</div>
<div> Adopt: 9 (90%) (CNSA, CSA, DLR, </div>
<div>ESA, FSA, INPE, JAXA, NASA, UKSA)</div>
<div> Adopt Provisionally: 1 (10%) (CNES)</div>
<div> Reject: 0 (0%)</div>
<div> Reject with Comments: 0 (0%)</div>
<div><br>
</div>
<div>CNES: Questions to be clarified:</div>
<div>- §1.2 and §1.3.1 What is actually binding onto </div>
<div>the Agencies in providing or not enterprise or </div>
<div>service provider information ? The use of "shall" </div>
<div>in this document is found abusive in many places </div>
<div>as the demanded information is not strictly </div>
<div>related to a CCSDS need (e.g.: organization or </div>
<div>protocol). The Agencies should be free to expose </div>
<div>whatever they feel usefull or to keep in </div>
<div>confidence information not strictly CCSDS related </div>
<div>("should" better suits this case).</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">I think we would prefer to keep the requirement stated as it is. However, I do agree that agencies and service providers may feel otherwise, I I propose to add the following as a last sentence in pp1 of Sec 1.2:</div>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">“Agencies and other service providers are free to constrain the requested information they provide, but at the cost of a loss of functionality.”</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- §3.3.1.3.13 Why is a service provider or user </div>
<div>role identified here while this definition </div>
<div>overlaps with the roles of P-O Members or Associates?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">This set of clauses, 3.3.1.3.10 thru 3.3.1.3.15 defines all of the requirements for roles, their definition, and management. It could be a separate sub-section on its own, but we chose to group these together here.</div>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">Would you prefer a separate sub-section just for Roles definitions?</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- § 3.3.2.1 Is it anticipated that GSCIds will </div>
<div>never more be assigned to Simulators or the like </div>
<div>? If so, is it mentioned somewhere in the document (not found)?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The rules for SCID assignment are fully specified in ref [8} which is referred to here. These requirements are intended to focus on the registry and it’s relationship to other registries. There is some overlap, with [8], but
I would prefer to keep that to a minimum.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- Annex B §B1 The term "sponsors" is not clear </div>
<div>and the FigB1 may be confusing as Observers are </div>
<div>not sponsored by the Members ... or some text should be added.</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The definitions in Sec 1.4.2 and elsewhere define the relationships among agencies and the associates (observers or affiliates) that they may sponsor. According to the CCSDS rules (a02x1y4c2, sec 4.1.1) Observers are typically
sponsored by the member agencies for their country, but it is possible for an observers, with no member agency for their country, to be sponsored by the Secretariat. The CMC has to approve all requests. We did not want to re-write all of the rules here,
just to indicate in one compact form the information model and relationships.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- Annex B Table B3. "Transmit frequency" to be </div>
<div>replaced by "Frequency band" and modify type, </div>
<div>range and notes accordingly... and clarify how </div>
<div>the case of a satellite having several </div>
<div>frequencies, several GSCId, etc... will be handled.</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">Agreed. This field in Table B-3 and Figure B-4 have been updated to reflect the presence of multiple frequency bands. The CCSDS 320x0b6, SCID assignment, is where all of those other detailsabout SCID assignment are defined and
it is best not to repeat all of that here.</div>
<div style="font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>- Annex B (B4 and B5): there are duplicates </div>
<div>between "site and aperture registries" and "IOAG </div>
<div>RF COMMUNICATION assets": how will this be </div>
<div>controlled if there are different PoC ?</div>
</div>
</div>
</blockquote>
</span></span>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The IOAG created their RF Asset registry (fig B-7), using the SANA services. It contains limited information about sites, which are not explicitly identified, and mostly contains aperture sizes, location & elevation (where provided),
G/T, EIRP, and frequncy band coverage. This is very useful and it is informaiton that the CCSDS needs for CSS purposes. That said, it is also often incomplete and does not provide any informaiton about services. We have asked, and thae IOAG has agreed,
to add some fields to explicitly name the site, provide standard names for all the assets, and provide an ISO OID for all the assets.</div>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">The CCSDS Service Site and Aperture registry is intended to provide information for planning and providing cross support services. It is designed to provide information on each site, any services it offers, and any apertures it
hosts. Each site may have services (or not) and may have apertures (or not). And sites may be at fixed locations on the Earth’s surface, on the surface of other planetary bodies, or be in space (relay spacecraft). Some of the required information should
be in the RF Asset registry and the ISO OIDs that have been assigned will allow this informaiton to be kept synchronized, or even to be shared if that is found to be a useful thing to do. As is noted in the last pp above figure B-6: "<span style="font-family: TimesNewRomanPSMT; font-size: 12pt;">This
registry will point to IOAG RF Asset registry entries, and to Spacecraft Registry entries as needed, using the unique assigned OIDs to provide unambiguous cross-references."</span></div>
<div style="font-size: 14px;"><br>
</div>
<div>Both of these are Enterprise databases, so the assumption is that it is the agencies (or other owners of service providing assets) who actually are responsible for providing the informaiton and keeping it up to date. The SANA Operator will perform “sanity”
checks to ensure consistency among the databases, and will signal inconsistencies where they are identified. But ultimately it will be up to the agencies to provide the accurate data. To the extent that these registries (or cached local copies of them) are
used by CSS services (CSSM, SLE, CSTS) for planning and scheduling it should be advantageous for the service providers to keep their informaiton up to date.</div>
<div><br>
</div>
<div>The other option, of course, is to merge all of this information into one, single, database. We did not want to push the IOAG to do this, but it is certainly possible to consider it once these SANA databases are up and operational. </div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>Results are based on responses from 10 out of 11 members (90.91%).</div>
<div><br>
</div>
<div>No response was received from the following Agencies:</div>
<div><br>
</div>
<div>ASI</div>
<div><br>
</div>
<div>Secretariat Interpretation of Results: Adopted Provisionally</div>
<div>Resulting CMC Resolution: CMC-R-2016-05-002</div>
<div>Inferred Secretariat Action: Address Provisions; Publish Document</div>
<div><br>
</div>
<div>* * * * * * * * * * * * * * * * * * * *</div>
<div><br>
</div>
<div>CMC E-Poll Identifier: CMC-P-2016-04-012 </div>
<div>Authorization to publish CCSDS 313.2-Y-1, </div>
<div>Procedures for SANA Registry Specification (Yellow Book, Issue 1)</div>
<div><br>
</div>
<div>Results of CMC poll beginning 13 April 2016 and ending 6 May 2016:</div>
<div><br>
</div>
<div> Adopt: 9 (90%) (CNSA, CSA, DLR, </div>
<div>ESA, FSA, INPE, JAXA, NASA, UKSA)</div>
<div> Adopt Provisionally: 1 (10%) (CNES)</div>
<div> Reject: 0 (0%)</div>
<div> Reject with Comments: 0 (0%)</div>
<div><br>
</div>
<div>CNES: In section 2.3, clarify if a prototype </div>
<div>registry in e) is same as a Candidate registry in </div>
<div>i). Candidate and Approved are available on the </div>
<div>SANA site while prototype is unclear.</div>
</div>
</div>
</blockquote>
</span></span>
<div><br>
</div>
<div>Agree. The word “prototype” is to be replaced by “Candidate”.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-size: 14px;"><span style="mso-bookmark:_MailOriginalBody">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>Results are based on responses from 10 out of 11 members (90.91%).</div>
<div><br>
</div>
<div>No response was received from the following Agencies:</div>
<div><br>
</div>
<div>ASI</div>
<div><br>
</div>
<div>Secretariat Interpretation of Results: Adopted Provisionally</div>
<div>Resulting CMC Resolution: CMC-R-2016-05-003</div>
<div>Inferred Secretariat Action: Address Provisions; Publish Document</div>
<div><br>
</div>
<div>* * * * * * * * * * * * * * * * * * * *</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>_______________________________________________</div>
<div>CESG-all mailing list</div>
<div><a href="mailto:CESG-all@mailman.ccsds.org">CESG-all@mailman.ccsds.org</a></div>
<div><a href="http://mailman.ccsds.org/mailman/listinfo/cesg-all">http://mailman.ccsds.org/mailman/listinfo/cesg-all</a></div>
<div><br>
</div>
</div>
</div>
</blockquote>
</span></span>
</body>
</html>