[Css-csts] Updated MD-CSTS on CWE

[John Pietras]

CSTSWG colleagues ---
I have uploaded 3 files to the CWE>Cross Support Services Area (CSS)<http://cwe.ccsds.org/css> > Documents<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx> > CSS-CSTS<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS> > CWE Private<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private> > Future Services using Toolkit<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private%2FFuture%20Services%20using%20Toolkit> > MonitoredDataCSTS folder
(http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private%2FFuture%20Services%20using%20Toolkit%2FMonitoredDataCSTS&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View={8045374D-F8E0-4356-83CA-993252A38FE8}<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private%2FFuture%20Services%20using%20Toolkit%2FMonitoredDataCSTS&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View=%7b8045374D-F8E0-4356-83CA-993252A38FE8%7d>)


-          MonitoredDataCSTS_W-0.12. This is the marked-up version that contains all changes since the previous (2010) version. I've uploaded in case anyone wants to see specific changes, but in general don't bother reading this unless you like the color red.

-          MonitoredDataCSTS_W-0.12-clean. This is the version with all changes accepted. It still contains a handful of comments and questions in comment boxes, which can be seen when the document is viewed in Review : Final Showing Markup mode.

-          MonitoredDataCSTS_W-0_12-ASN1. The ASN.1 Object Identifiers module in a text file.

There have been numerous changes to the MD-CSTS specification, including:

-          Updates of the Functional Resource, monitored parameter, and notifiable event terminology throughout the book, to match the current Published Identifier-based naming approach;

-          Removal of normative references to Guidelines and direct insertion of normative material equivalent to the formerly-referenced Guidelines material;

-          Addition of specification for the setting of each configuration parameter for which such specification is deferred in the CSTS SFW to the service specification. These configuration parameters are specified in the MD-CSTS to be managed parameters;

-          Addition of 6 monitored parameters and 4 notifiable events. The monitored parameters are the values of the managed parameters, and the events are the four standard production status-related  events (configured, halted, etc.). These parameters and events are strawman proposals for the consideration of the WG members;

-          Addition of the root OIDs for the MD-CSTS Provider FR Type, paramtersId, eventsId, and parameter identifiers to Annex A;

-          Moving of the Production specification to a normative Annex; and

-          Changing the Service Management specification from a normative reference (in section 1) to an informative reference (in the informative references annex).

I believe that this draft is consistent with the latest version of the CSTSSFW and is therefore suitable for use as the basis for the next round of prototyping.

However, there are a few questions and open items for larger discussion that will have to be resolved.

1.       Where will the specification of the data dictionary contents be documented? This is not just the specification of the object identifiers, but the types, ranges, units, etc. Should it be in the MD-CSTS Recommended Standard (in which case the scope would be limited to monitored parameters and events) , the CSTS SFW (which would broaden the scope to also include directives), or a separate "area wide" book  that would also include service management parameters associated with each FR type? The Cross Support Service Management WG (CSSMWG) will be facing a similar problem of associating management data with Functional Resource Types, so a combined book (or set of books) might be a good way to proceed. This activity might also involve development of guidelines (a Magenta Book?) for specifying all data associated with a Functional Resource Type.

2.       At one time, the plan was to include the whole monitored data dictionary as in informational annex of the MD-CSTS, with the normative version being the SAN registry. Is that still the plan? The data dictionary is large. Would a subset be sufficient, e.g., enough to cover all of the references and examples in the MD-CSTS? If the plan is to register the complete set of OIDs before or at the same time as the MD-CSTS Red Book, this would seem to be sufficient.

3.       The draft MD-CSTS book currently states that the number of instances of the Cyclic Report and Notification procedures are the same for all instances of the MD service operated within the context of the same Service Agreement. Is there any reason for such a group-level restriction? Should it be just set by Service Management, which could allow it to be set on a MD service instance basis?

4.       For now, the monitored parameters for the MD service are limited to the values of the managed parameters, which makes them mostly suitable for the Information Query but not so much for the Cyclic Report. I tried to think of data unit counts that might be of interest for periodic reporting, but I don't know what is useful and/or would make sense. Total numbers of valid/unavailable/undefined/error parameter values reported since the beginning of the service instance provision period? Total numbers since the last START of the procedure? Would the numbers be summed across all instance of the Cyclic Report procedure, or reported for each instance (and if so, how would this be represented using qualified parameters)?

5.       It is not obvious what the production status (configured, operational, etc.) means in the context of the MD-CSTS service. I have made an attempt at definitions in 5.3 but I'd like to hear other opinions.

Best regards,
John



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130221/1e260073/attachment.htm