[Smwg] Service Package draft uploaded

Wed Jun 6 20:54:09 UTC 2018

Wes,
My first comment is that I think that this document could really benefit from explaining the *concepts* behind all of these bits and how they are all supposed to fit together. For example, there's a very brief introduction to the concepts of terse and verbose modes (hereinafter referred to as compact and detailed, respectively), but there should be (in my opinion) a more-detailed description of each mode and a tie-in with which of the various classes are present in each mode (and why). As it is, I am very much confused by the class diagram in figure 3-1. Section 2 would be a good place for such exposition.

My more-specific comments are related to configuration profile information:

1.       In figure 3-1, the OIDParameter class has a cardinality of "0..1*" in its relationship with the OfflineServiceDetails. It should probably be "0..*".

2.       As Erik alluded to in his comments, I am proposing that we move away from using OIDs to identify FR instances and parameters of those FR instances in Service Management info entities, using instead the CCSDS-standard text classifiers that correspond to those OIDs. I'm also recommending not calling it OIDParameter but RespecificationParameter. Those changes would also apply here.

3.       From figure 3-1, it appears that both compact and detailed modes can contain OIDParameter(RespecifiedParameter) elements, but that's not true. We need OIDParameter(RespecifiedParameter) only in compact mode. In detailed mode, the respecified parameters are contained in the embedded configuration profiles.

4.       I'm not sure of the purpose of the providerPortId parameter of the ServiceDetails class. It is supposed to represent the as-scheduled transfer service instances, but I don't see how that will work without also identifying the transfer service instances that they correspond to. It's like saying that a company phone directory is just the set of phone numbers but not the names of the people that have those numbers. And I'm not sure that they need to be called put separately in any case. The way that I'm proposing that the Service Agreement/Configuration Profiles work (based somewhat on how at least some networks schedule SLE services today) is as follows:

a.       Every possible transfer service instance is declared in the Service Agreement;

b.       For every site (e.g., ground station) at which a given transfer service instance might be scheduled, the site-local specifics (including the port ID used to connect to it at that site) are documented in the SA. So we end up with a table: when TS instance A is scheduled at site B, port C is used to bind to that service instance (it's actually a bit more elaborate: a set of ports can be specified for any one site).
Since both UM and Provision Management (PM) share the Service Agreement, knowing which site is supporting the Service Package is tantamount to knowing the responder port. Presumably the Site ID can be derived from the apertureId, which is included in the Service Package Result for online services. However, that there is no Site ID associated with offline services - how does the Service Package Result indicate *where* an offline service is being performed?
Note - The discussion so far applies to online and offline services that are "scheduled" using the SMURF Service Package Request. In the SA/CP Tech Note I've also introduced the notion of "permanent" offline services that are recorded in the  SA but not subsequently "requested" - their presence in the SA as permanent services constitutes all the requesting that's needed. For permanent offline services, I've stated that they are defined on a site-by-site basis.

Note, too,  that similar concepts apply to data stores.

5.       Wes, you asked why the frequencyBand is exposed separately even though it is also contained within the configuration profiles themselves. My recollection is that it has something to do with allowing an apples-to-apples parity with the Simple Schedule Format when the SP Result is in compact mode (same with the ServiceType being exposed).
Obviously my comments are more like proposed discussion items than specific recommendations, but I hope they are useful.  Talk to you next week.

Best regards,
John

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]
Sent: Monday, March 26, 2018 11:17 AM
To: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: [Smwg] Service Package draft uploaded

Hello, I've uploaded a draft copy of the Service Package book to CWE.  It is based on the earlier draft JP had worked on, plus the XML schema document Marcin provided to me.

I have several comments embedded noting some differences between the document and the XML schema that I found.

Is it correct to assume that the XML schema that has been used in prototyping activity is more mature than the earlier draft and should take precedence (so we update the document to match the XSD file)?  If that is the case, there are only a small number of errors/issues that I found in the XSD file, that we can discuss.

One easy question I have is in the class OnlineServiceDetails, which has a field that I don't understand the purpose/usefulness of:
frequencyBand

Mandatory parameter.

Used to specify the frequency band that will be used by the service. If the frequency band is not relevant the value N/A (not applicable) shall be used.

*         C-Band

*         Ka-Band

*         Ku-Band

*         L-Band

*         S-Band

*         V-Band

*         X-Band

*         Optical

*         N/A

Enum

n/a

I believe that since the structure already contains an onlineConfigurationProfileXRef, that the frequencyBand value would be looked up via that anyways, and does not need to be included in the OnlineServiceDetails.  If someone else knows more than me and can either correct me, or confirm that this could be deleted, that would be helpful.

The draft document itself is at:
https://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS-SM%2FCWE%20Private%20-%20Beta%2FBook%20Production%2FBlue%2FService%20Package%20Data%20Formats%2FWhite%20Book%2FDrafts&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View=%7BD853EDDB-F007-4BF6-8C31-BA03A9D0F4A4%7D&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180606/c4abce65/attachment.html>