<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 14 (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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.5pt;
        font-family:Consolas;}
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.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:Consolas;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@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:1456021033;
        mso-list-type:hybrid;
        mso-list-template-ids:-38738642 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">Mr. Pecchioli,<o:p></o:p></p>
<p class="MsoNormal">Hello, I’m John Pietras. I’m the book editor for the CSTS Monitored Data Service Red Book. Thank you for reviewing the book.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">One of your RIDs, titled “Generation time for GET”, stated:<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none">“I suggest to add the generationTime parameter also for the GET Return PDU (similarly to the TRANSFER-DATA PDU). This is useful for the receiving side to know when the parameter value has been sampled.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The CSTS Working Group discussed this RID and decided that we need a bit more information about your intentions for the recommended changes before we could decide on how to proceed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here is a little bit more background information that will hopefully help us come to a mutual understanding.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">In the RID, you use the TRANSFER-DATA as an example of an invocation carrying a generationTime. However, there is a difference between the generation time of a TRANSFER-DATA
 invocation and a GET return, in that (in some cases, anyway) a TRANSFER-DATA invocation may be stored in a Recording Buffer, and so the generation time is disjoint from the actual delivery time. In contrast, the GET return is always sent in immediate response
 to the GET invocation, so the generation time of the parameters can be assumed to be the time of receipt, minus some time for transmission through the underlying communications network. Furthermore, since the GET returns are all delivered in-sequence by the
 underlying TCP connection, there is no question as to the sequencing of the returns.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Therefore, adding a generationTime parameter to the GET return would be needed only if the generation time that can be estimated from the receipt time (i.e., normally
 within a second or two) is insufficiently accurate for an Agency’s (or Mission’s) purposes. Is there is a requirement to know the generation time with greater accuracy than within 2 seconds of the receipt time of the return?  <o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The CSTS WG  is considering extending the GET return set of parameters to include a single generationTime parameter that applies to all values carried in the return .
 Note that this would be the generation time of the GET return itself; it would provide no indication of the actual freshness of each of the parameters being reported. The assumption is that all values being reported are current values.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal">If we were to add a generationTime parameter to the GET return, it would have to be with the understanding that all values being returned in the GET return are current as of the time that the GET return is generated and sent. That is, it
 would not be possible (without major reworking of not only the MD-CSTS but the CSTS Framework as a whole) to have measurements taken at various times sitting and waiting to be retrieved via the GET operation. If a measurements is “stale” by any appreciable
 amount of time, it negates the usefulness of having the generationTime in the GET return.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, to summarize:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">      
</span></span><![endif]>To your understanding, is it sufficient to know that the time of a measurement to within 2 seconds of its true generation time? If so, then no change to the MD service would be required.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">      
</span></span><![endif]>If it is not sufficient, we could put a single generationTime parameter in the GET return. This generationTime would apply to all values in the return, which implies that all values contained in the return are sampled essentially instantaneously
 at generationTime. Would that suit the purposes for which you envision the generationTime parameter?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you in advance for your help in refining and resolving this RID.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John Pietras<o:p></o:p></p>
<p class="MsoNormal">Principal Engineer<o:p></o:p></p>
<p class="MsoNormal">GST, Inc.<o:p></o:p></p>
<p class="MsoNormal">7855 Walker Drive, Suite 200<o:p></o:p></p>
<p class="MsoNormal">Greenbelt, MD 20770<o:p></o:p></p>
<p class="MsoNormal">240-542-1155<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>