<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1426224462;
mso-list-type:hybrid;
mso-list-template-ids:1030231882 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> John Pietras [mailto:john.pietras@gst.com] <br>
<b>Sent:</b> Monday, February 09, 2015 9:23 AM<br>
<b>To:</b> Barkley, Erik J (3970)<br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org)<br>
<b>Subject:</b> Response to CSSMWG Action Item 2015-0113-5<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Erik and CSSMWG colleagues –<o:p></o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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.<o:p></o:p></p>
<p class="MsoNormal">EB> perhaps something we end up saying specifically for the service agreement/configuration profile book.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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.<o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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.)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Well, that’s all I have. Talk to you tomorrow.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">John <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>