[Smwg] RE: Response to CSSMWG Action Item 2015-0113-5

[Barkley, Erik J (3970)]

John,

Thanks very much for the inputs. I have incorporated your inputs into the overall inter-recommendation tracking spreadsheet and the updated spreadsheet is attached.   Comments directly applicable to your analyses are embedded below.  In processing these comments it strikes me that a general approach that we may very well need to take is that the standard header may need to be tailored and/or have restrictions applied to it for the particular information entity being "carried". For example, with regard to event notifications and the version parameter, perhaps the rules end up saying that the version is set to "not applicable" or is always set to 1, or something like that.

Best regards,

-Erik

From: John Pietras [mailto:john.pietras at gst.com]
Sent: Monday, February 09, 2015 9:23 AM
To: Barkley, Erik J (3970)
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org)
Subject: Response to CSSMWG Action Item 2015-0113-5

Erik and CSSMWG colleagues -
I have a few comments on Erik's standard header vs. information entity analysis. In response to AI #2015-0113-5,  Review Erik's standard header vs information entities analysis spreadsheet and provide comments, here they are:

1.       Erik questioned the interpretation of 'originatingOrganization'  for the Service Agreement, and whether it should accommodate multiple parties. We could do that, but an alternative interpretation might be to treat it as "the organization that possesses the definitive version of the document." The SA is of course negotiated between the Provider CSSS and the Mission, but once that's done I think the Provider CSSS is the "keeper" of the ratified document. That concept is consistent with the way we treated the QSA in Blue-1: UM queries CM, not the other way around. Info Entity-specific data can identify the parties (Provider CSSS and Mission) that mutually entered into the agreement.
EB> perhaps something we end up saying specifically for the service agreement/configuration profile book.


2.       Regarding the Trajectory Prediction Segment info entity, we had discussed the possibility of negotiating with the NavWG to get all of the info that we need included in the NDM schemas, and as I recall David Berry is amenable to such a discussion because the affected Nav books are coming up for review. If we could achieve that we would automatically eliminate the multiple "(perhaps conflict with NDM)" comments in Erik's listing. We should consider a joint session CSSMWG/NavWG at next month's meeting to discuss possible convergence within the NDM and ODM books.
EB> perhaps. I will admit I'm somewhat leery about this as we now have a two ring circus of negotiation that may take quite a while to reach any kind of conclusion. We may want to do something like say that when the NDM book has the equivalent information in it, it supersedes whatever the service management header has in it. I think this needs further discussion.


3.       Regarding the Service Package Execution Event Notification Info Entity, I think the questions about version, startTime and endTime reflect the fundamentally different nature of this form the other Info Entities. By its nature, a notification is tied to the moment that it is generated. Another change in circumstances can result in another notification being issued, but I don't see that as being a different version of the same notification. I have said in the past that I think of this notification as an operation (message)  in the to-be-defined Service Package Service.  Rather than try to warp the notions of Info Entity version, startTime and endTime so that they can accommodate this entity, we might consider demoting it from stand-alone Info Entity status and bookmark it for coverage in the future automation book (along with things like service package request failures and service package replacements, cancellations, deletions, etc.)

EB> it may be that we still have a header attached to it in that it has "down scoping" restrictions applied to it.  I tend to agree with you that the notifications are in a different class than the "payload" data objects such as the service configuration profile. But it gets to be a bit muddy if you think that ultimately the service package request are not really a persistent data object, right? Having said that I think we also may want to consider as you have suggested, putting this in the automation book and not really in the service package/service request book.

Well, that's all I have. Talk to you tomorrow.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150213/b6e9a887/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d1-InterRecommdation Tracker-12022015.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 32313 bytes
Desc: d1-InterRecommdation Tracker-12022015.xlsx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150213/b6e9a887/attachment.xlsx>