[CMC] Re: [Cesg-all] Results of CMC Polls Closing 6 May 2016

Tue May 10 16:06:32 UTC 2016

Dear Jean-Marc,

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.

I think that there are two questions that may require further discussion:

  1.  In CCSDS 313.1-Y-1, SANA Registry Management Policy, sections 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?
  2.  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?

Once we agree on these proposed changes I will update any figures and send it off to the Secretariat for publication.

Best regards, Peter

From: <cesg-all-bounces at mailman.ccsds.org<mailto:cesg-all-bounces at mailman.ccsds.org>> on behalf of Tom Gannett <thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>>
Date: Saturday, May 7, 2016 at 4:06 PM
To: CMC <CMC at mailman.ccsds.org<mailto:CMC at mailman.ccsds.org>>
Cc: CCSDS Engineering Steering Group - CESG All <cesg-all at mailman.ccsds.org<mailto:cesg-all at mailman.ccsds.org>>
Subject: [Cesg-all] Results of CMC Polls Closing 6 May 2016

CMC E-Poll Identifier: CMC-P-2016-04-010
Authorization to publish CCSDS 313.0-Y-2, Space
Assigned Numbers Authority (SANA)—Role,
Responsibilities, Policies, and Procedures Yellow Book, Issue 2)

Results of CMC poll beginning 13 April 2016 and ending 6 May 2016:

                 Adopt:  9 (90%) (CNSA, CSA, DLR,
ESA, FSA, INPE, JAXA, NASA, UKSA)
   Adopt Provisionally:  1 (10%) (CNES)
                Reject:  0 (0%)
  Reject with Comments:  0 (0%)

CNES: - Is Reference [2] in section 1.7
appropriate as it is never called in the document ?

Actually the SANA Consideraitons section on Page B-1 sould reference the CCSDS Publications Manual [2].  This has been added to the text.

- Section 2 (bottom of page 2-1), puts
prerequisites on the agency review, with a
candidate registry, and to the publication, with
an approved registry. Three questions:
* as this is new, should it be documented in the
the CCSDS Org & Processes document ?

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.

* as this may delay the overall production cycle
of standards, are there commitments from the SANA
operator on the maximum time required to
establish a Candidate / Approved registry ?

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.

* Could approval of the registry be part of the
same poll as the prublication of the related
standard (to avoid consecutive polls) ?
If so, processes should also be updated.

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.

- In section 3.18 what is meant with the words
"concurrence of the CMC" for "formation (b)" or
"termination (h) of an expert group? As CMC
manages the allocation of resources should the
word "concurrence" be replaced with the word "approval" ?

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.

Results are based on responses from 10 out of 11 members (90.91%).

No response was received from the following Agencies:

ASI

Secretariat Interpretation of Results:  Adopted Provisionally
Resulting CMC Resolution:               CMC-R-2016-05-001
Inferred Secretariat Action:            Address Provisions; Publish Document

* * * * * * * * * * * * * * * * * * * *

CMC E-Poll Identifier: CMC-P-2016-04-011
Authorization to publish CCSDS 313.1-Y-1, CCSDS
SANA Registry Management Policy (Yellow Book, Issue 1)

Results of CMC poll beginning 13 April 2016 and ending 6 May 2016:

                 Adopt:  9 (90%) (CNSA, CSA, DLR,
ESA, FSA, INPE, JAXA, NASA, UKSA)
   Adopt Provisionally:  1 (10%) (CNES)
                Reject:  0 (0%)
  Reject with Comments:  0 (0%)

CNES: Questions to be clarified:
- §1.2 and §1.3.1 What is actually binding onto
the Agencies in providing or not enterprise or
service provider information ? The use of "shall"
in this document is found abusive in many places
as the demanded information is not strictly
related to a CCSDS need (e.g.: organization or
protocol). The Agencies should be free to expose
whatever they feel usefull or to keep in
confidence information not strictly CCSDS related
("should" better suits this case).

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:

“Agencies and other service providers are free to constrain the requested information they provide, but at the cost of a loss of functionality.”

- §3.3.1.3.13 Why is a service provider or user
role identified here while this definition
overlaps with the roles of P-O Members or Associates?

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.

Would you prefer a separate sub-section just for Roles definitions?

- § 3.3.2.1 Is it anticipated that GSCIds will
never more be assigned to Simulators or the like
? If so, is it mentioned somewhere in the document (not found)?

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.

- Annex B §B1 The term "sponsors" is not clear
and the FigB1 may be confusing as Observers are
not sponsored by the Members ... or some text should be added.

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.

- Annex B Table B3. "Transmit frequency" to be
replaced by "Frequency band" and modify type,
range and notes accordingly... and clarify how
the case of a satellite having several
frequencies, several GSCId, etc... will be handled.

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.

- Annex B (B4 and B5): there are duplicates
between "site and aperture registries" and "IOAG
RF COMMUNICATION assets": how will this be
controlled if there are different PoC ?

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.

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: "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."

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.

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.

Results are based on responses from 10 out of 11 members (90.91%).

No response was received from the following Agencies:

ASI

Secretariat Interpretation of Results:  Adopted Provisionally
Resulting CMC Resolution:               CMC-R-2016-05-002
Inferred Secretariat Action:            Address Provisions; Publish Document

* * * * * * * * * * * * * * * * * * * *

CMC E-Poll Identifier: CMC-P-2016-04-012
Authorization to publish CCSDS 313.2-Y-1,
Procedures for SANA Registry Specification (Yellow Book, Issue 1)

Results of CMC poll beginning 13 April 2016 and ending 6 May 2016:

                 Adopt:  9 (90%) (CNSA, CSA, DLR,
ESA, FSA, INPE, JAXA, NASA, UKSA)
   Adopt Provisionally:  1 (10%) (CNES)
                Reject:  0 (0%)
  Reject with Comments:  0 (0%)

CNES: In section 2.3, clarify if a prototype
registry in e) is same as a Candidate registry in
i). Candidate and Approved are available on the
SANA site while prototype is unclear.

Agree.  The word “prototype” is to be replaced by “Candidate”.

Results are based on responses from 10 out of 11 members (90.91%).

No response was received from the following Agencies:

ASI

Secretariat Interpretation of Results:  Adopted Provisionally
Resulting CMC Resolution:               CMC-R-2016-05-003
Inferred Secretariat Action:            Address Provisions; Publish Document

* * * * * * * * * * * * * * * * * * * *

_______________________________________________
CESG-all mailing list
CESG-all at mailman.ccsds.org<mailto:CESG-all at mailman.ccsds.org>
http://mailman.ccsds.org/mailman/listinfo/cesg-all

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20160510/14c811fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x2y1_CMC_Approval-SEA.pdf
Type: application/pdf
Size: 249853 bytes
Desc: 313x2y1_CMC_Approval-SEA.pdf
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20160510/14c811fd/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x1y1_CMC_Approval-SEA.pdf
Type: application/pdf
Size: 1054999 bytes
Desc: 313x1y1_CMC_Approval-SEA.pdf
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20160510/14c811fd/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x0y2_CMC_Approval-SEA.pdf
Type: application/pdf
Size: 369224 bytes
Desc: 313x0y2_CMC_Approval-SEA.pdf
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20160510/14c811fd/attachment-0002.pdf>