<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 20px; font-family: Calibri, sans-serif; "><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; ">Dear NGU,</div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; "><br></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; ">Below is a dialog I had with Keith Scott, SIS Area director, on his question concerning the 5-year Review copy of the Prox-1 Data Link Layer blue book.</div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; ">Please read through this discussion and let me know if you have any comments concerning the proposed RID dispositions to those questions which I believe need to be turned into RIDs. Below is my summary of 5 RIDs for consideration. </div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; ">- Thanks Greg</div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; "><br></div><div><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">Item 1:</span> Note <span class="Apple-style-span" style="font-size: 16px; ">2 in Section 4.3.2.2. The mechanisms provided in this specification will not eliminate duplicate data associated with the transition between the end of one session and the beginning of the </span><span class="Apple-style-span" style="font-size: 16px; ">next. Elimination of this problem is left to the controlling data system. </span></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; "><span class="Apple-style-span" style="font-size: 16px; ">Recommended Change: </span><span class="Apple-style-span" style="font-size: 16px; ">The mechanisms provided in this specification will not eliminate <span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">the possibility of </span>duplicate data associated with the transition between the end of one session and the beginning of the </span><span class="Apple-style-span" style="font-size: 16px; ">next.</span></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; "><span class="Apple-style-span" style="font-size: 16px; "><br></span></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; "><span class="Apple-style-span" style="font-size: 16px; "><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">Item 2. </span> </span><span class="Apple-style-span" style="font-size: 16px; ">The section numbers around 4.2.5 -- 4.2.7 seem busted. Maybe they should be: </span></div><span class="Apple-style-span" style="font-size: 20px; "><p class="MsoNormal" style="color: rgb(0, 0, 0); margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; font-family: Calibri, sans-serif; "><br>4.2.5 MAC BUFFERS <br>4.2.5.1 SENT_TIME_BUFFER <br>4.2.5.1.1 The SENT_TIME_BUFFER shall store all of the egress clock times, associated frame sequence numbers, and QoS Indicator when time tag data is collected. <br>4.2.5.2 RECEIVE_TIME_BUFFER <br>4.2.5.2.2 The RECEIVE_TIME_BUFFER shall store all of the ingress clock times, associated frame sequence numbers and QoS Indicator when time tag data is collected. <br><br></span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; "><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><p class="MsoNormal" style="color: rgb(0, 0, 0); margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Tom to fix please.</span></p><p class="MsoNormal" style="color: rgb(0, 0, 0); margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; "><br></span></p><p class="MsoNormal" style="color: rgb(0, 0, 0); margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; "><br></span></p></span><span class="Apple-style-span" style="font-family: Calibri, sans-serif; "><span class="Apple-style-span" style="font-size: 16px; "><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">Item 3</span>. </span></span><span class="Apple-style-span" style="font-size: 16px; font-family: Calibri, sans-serif; ">6.2.2.1.1 <br>It is unclear from the below when or if the receiver is powered on in half-duplex mode: <br><br>"... <br>b) connecting-T: In the Physical Layer, the Connecting-Transmit state in full duplex <br>shall dictate that the ***receiver (sequentially in half duplex)*** and transmitter are <br>powered on and enabled to process received frames, and that the transmitter is <br>enabled for asynchronous channel operations. (***In half duplex, only the transmitter is <br>powered on.***) The Hail Activity shall be conducted while MODE is connecting-T. </span><div><font class="Apple-style-span" face="Calibri,sans-serif"><span class="Apple-style-span" style="font-size: 16px;"><br></span></font></div><div><font class="Apple-style-span" face="Calibri,sans-serif"><span class="Apple-style-span" style="font-size: 16px;"><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">b) connecting-T: In this state the Hail Activity/Sequence is conducted. Applicable to both Full-Duplex and Half-Duplex operations. The Receiver is powered on through out this state. The Transmitter is powered on and off potentially multiple times during this Activity.</span></span></font></div><div><font class="Apple-style-span" face="Calibri,sans-serif"><span class="Apple-style-span" style="font-size: 16px;"><br></span></font></div><div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; font-family: Calibri, sans-serif; "><br></span></p><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; font-family: Calibri, sans-serif; "><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">Item 4</span>: 6.2.3.7 REMOTE_SCID_BUFFER <br>Are the tests mentioned done on reception or transmission? It seems like this is trying to ensure that all frames are sent to the same destination spacecraft ID?</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">All tests are carried out upon reception. I need to reference 3.2.2.9 here which lists all of the tests by the receiving node– we will make this a RID. This buffer is just a receptical for the value of the Remote_<i>spacecraft</i>_ID i.e., partnered node MIB parameter. </span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">New Definition – </span><span class="apple-style-span"><span style="font-size: 13.5pt; font-family: Calibri, sans-serif; ">REMOTE_SCID_BUFFER </span></span><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">shall be used to hold the value of the <span class="apple-style-span">Remote_<i>spacecraft</i>_ID of the partnered node. See 3.2.2.9</span></span></span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; font-family: Calibri, sans-serif; "><br><br><span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">Item 5:</span> 6.2.3.9 RECEIVING_SCID_BUFFER <br>"...or it may be loaded with the spacecraft ID contained in the first valid received frame." -- First of WHAT (I think 'first valid received frame of a new connection where the sourceOrDest parameter of the frame is DESTINATION' [since if the first valid received frame has sourceOrDestination set to source then the value of the SCID will be the transmitter -- or is this not possible?])?</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Again, one has to interpret the S/D flag differently if one is the Sending node or the Receiving node. Yes it is the initial valid received frame of a session. However this refers to the optional test when S/D = SOURCE, since the test when S/D = DESTINATION is always made. See section 3.2.2.9 and section 6.2.4.2. We accept some of the rewording as a <span class="Apple-style-span" style="background-color: rgb(255, 248, 45);">RID – we will update with the wording "the initial valid received frame of a session" and in 6.2.4.2 as well.</span></span></p></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; "><br></div><div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px; ">End of Items.</div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 20px; font-family: Calibri, sans-serif; "><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br><span style="font-weight:bold">Date: </span> Wed, 29 Feb 2012 16:15:39 -0800<br><span style="font-weight:bold">To: </span> "Scott, Keith L." <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, "<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>" <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>><br><span style="font-weight:bold">Cc: </span> Thomas Gannett <<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>>, Gilles Moury <<a href="mailto:Gilles.Moury@cnes.fr">Gilles.Moury@cnes.fr</a>>, "Hooke, Adrian J (9000)" <<a href="mailto:adrian.j.hooke@jpl.nasa.gov">adrian.j.hooke@jpl.nasa.gov</a>>, "Greenberg, Edward (313B)" <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>>, "<a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>" <<a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>>, "<a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a>" <<a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a>><br><span style="font-weight:bold">Subject: </span> Re: CESG Poll for the three Proximity-1 books<br></div><div><br></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; "><div style="color: rgb(0, 0, 0); font-size: 20px; ">Keith,</div><div style="color: rgb(0, 0, 0); font-size: 20px; "><br></div><div style="color: rgb(0, 0, 0); font-size: 20px; "><span class="Apple-style-span" style="color: rgb(31, 73, 125); font-size: 15px; ">If that’s the case, we’re done (though I still think the note is misleading).</span></div><div style="color: rgb(0, 0, 0); font-size: 20px; "><span class="Apple-style-span" style="color: rgb(31, 73, 125); font-size: 15px; "><br></span></div><div>In sessions that are "stiched together" in order to send a complete data set, the sending application has to pick a point in the data set to resume transmitting from. Depending how the first session ended and what termination mechanism in Prox–1 was chosen, the "sender"(master) may not be aware that the last frame(s) within the window were accepted by the "receiving node"(slave) because the acknowledgement for them was generated, transmitted, but never received by the master (went out of view). So when the master starts transmitting again in session 2, it may start with what it believes the last frame acknowledged was, which could be one or more frames that the other side already acknowledged. So that's a simple example of how duplicates could be passed on without intervention by the controlling data system. Again it's not Prox-1's job to solve this.</div><div><br></div><div>I think we can relook at the wording of the note and see if we can come up with something more precise. There is the possiblity of duplicate data being passed under that condition.</div><div><br></div><div>Thanks,</div><div><br></div><div>Greg</div><div style="color: rgb(0, 0, 0); font-size: 20px; "><br></div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 20px; "><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "Scott, Keith L." <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><br><span style="font-weight:bold">Date: </span> Wed, 29 Feb 2012 06:43:56 -0800<br><span style="font-weight:bold">To: </span> "Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>, "<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>" <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>><br><span style="font-weight:bold">Cc: </span> Thomas Gannett <<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>>, Gilles Moury <<a href="mailto:Gilles.Moury@cnes.fr">Gilles.Moury@cnes.fr</a>>, "Hooke, Adrian J (9000)" <<a href="mailto:adrian.j.hooke@jpl.nasa.gov">adrian.j.hooke@jpl.nasa.gov</a>>, "Greenberg, Edward (313B)" <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>>, "<a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>" <<a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>>, "<a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a>" <<a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a>><br><span style="font-weight:bold">Subject: </span> RE: CESG Poll for the three Proximity-1 books<br></div><div><br></div><div 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"><meta name="Generator" content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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:12.0pt;
font-family:"Times New Roman","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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
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:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";}
span.EmailStyle20
{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;}
--></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]--><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Greg,<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">With respect to the following:
<o:p></o:p></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">How do we reconcile 2.2.3.2:
</span><span style="color: black; font-family: Calibri, sans-serif; "><br>
The Sequence Controlled service ensures that data are reliably transferred across the space link and delivered in order, without gaps, errors, or duplications within a single
<br>
communication session without COP-P resynchronization during the session (see 4.3.2).
<br></span><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">with Note 2 in section 4.3.2.2:</span><span style="color: black; font-family: Calibri, sans-serif; "><br>
2 The mechanisms provided in this specification will not eliminate duplicate data associated with the transition between the end of one session and the beginning of the
<br>
next. Elimination of this problem is left to the controlling data system. <br>
GPC: they do not in conflict as there is guarantee within a session but not across session. It may be this should be highlighted somehow in section 2 too.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Is what you’re saying with note 2 “if the sending *<b>application</b>* (prox-1
<b>user</b>) injects duplicate data across a session boundary (perhaps as a result of transmitting a bit of ‘rewind’ to brute-force cover the break between two sessions?) then prox-1 will delivery duplicate user data?” If that’s the case, I’d suggest rewording
the note to be clear – not much Prox-1 can/could be expected to do in this case. I’m getting this from your response below (my emphasis):<o:p></o:p></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">The bounds on duplicate data is not a function of Prox-1 but rather how much of a "rewind" the
<b><u>user</u></b> plans to do if they are stitching Prox-1 sessions together by brute force. We eliminated the possibility of frame counter ambiguity in Prox-1 by limiting the window size N to 127. This is due to the duality of interpreting sequence counts
whenever a rollover occurs using modulo arithmetic … in our case with counts greater than 127. Since the sequence counter is a mod 256 counter, there is no way for us to deal with unique sequence counter unless we limit N to 127.</span><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">If that’s the case, we’re done (though I still think the note is misleading).<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">If the prox-1 user provides a single, non-overlapping data object to prox-1 that is transferred across multiple sessions and if I *<b>CAN</b>* have duplicate
data delivered that is associated with the transition between sessions, that duplicate data has to show up during one of the sessions (probably the second in a causal universe). If there are no COP-P resynchronization events during either session, then I’ve
got duplicate data in a session with no resynchroniztion events?<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">I’m fine with the rest of your dispositions.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "> --keith<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">========<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Just a comment:<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">I believe the following formulations are equivalent, just that the second is clearer.
<b>Regardless, I’m fine with your wording if you prefer it</b>.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="color: black; font-family: Calibri, sans-serif; ">2.2.3.2
<br>
I think where it says: "...without gaps, errors, or duplications within a single communication session *</span><span style="color: red; font-family: Calibri, sans-serif; ">without COP-P resynchronization during the session</span><span style="color: black; font-family: Calibri, sans-serif; ">*..."?
<br><br>
might be better phrased as: <br>
"... without gaps, errors, or duplications within a single communication session *</span><span style="color: red; font-family: Calibri, sans-serif; ">when COP-P resynchronization is not required during the session (see 4.3.2).</span><span style="color: black; font-family: Calibri, sans-serif; ">*"
<br></span><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">[or maybe it should have been “in those cases where COP-P resynchronization is not required…”]</span><span style="color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><br><br><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> Kazz, Greg J (313B) [<a href="mailto:greg.j.kazz@jpl.nasa.gov">mailto:greg.j.kazz@jpl.nasa.gov</a>]
<br><b>Sent:</b> Tuesday, February 28, 2012 4:12 PM<br><b>To:</b> <a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>; Scott, Keith L.<br><b>Cc:</b> Thomas Gannett; Gilles Moury; Hooke, Adrian J (9000); Greenberg, Edward (313B); Kazz, Greg J (313B); <a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>; <a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a><br><b>Subject:</b> Re: CESG Poll for the three Proximity-1 books<o:p></o:p></span></p></div></div><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; ">G.P./Keith, et al<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span class="apple-style-span"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; ">My answers are in
</span></span><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">RED</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "> below. Thanks for the questions!<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; ">Greg<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;border-bottom-color:initial;border-left-color:initial;border-right-color:initial"><p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size: 11pt; color: black; font-family: Calibri, sans-serif; ">From:
</span></b><span style="font-size: 11pt; color: black; font-family: Calibri, sans-serif; ">"<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>" <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>><br><b>Date: </b>Tue, 28 Feb 2012 00:00:27 -0800<br><b>To: </b>"Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>, "<a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>" <<a href="mailto:Massimo.Bertinelli@esa.int">Massimo.Bertinelli@esa.int</a>>,
"<a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a>" <<a href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a>><br><b>Cc: </b>Thomas Gannett <<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>>, Gilles Moury <<a href="mailto:Gilles.Moury@cnes.fr">Gilles.Moury@cnes.fr</a>><br><b>Subject: </b>CESG Poll for the three Proximity-1 books<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">Dear All,</span></b><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; "> as far as I can see on the web, the CESG poll reported only votes stating "</span><span style="color: black; font-family: Calibri, sans-serif; ">APPROVE UNCONDITIONALLY</span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">"
and the 3 polls got quorum.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">So next step should be the CMC Poll to authorize to start Agency Review.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">Greg,</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; "> Keith Scott also voted "</span><span style="color: black; font-family: Calibri, sans-serif; ">APPROVE UNCONDITIONALLY</span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">"
but with the comments reported below.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">It is my understanding that they do not prevent starting the CMC Poll, but I would appreciate your fast reaction to know your opinion and which comments can be solved at once
and which one should be converted to RIDs (author SLP WG Chair on behalf of Keith I would propose) for discussion within Agency Review.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">I wish you all a nice day.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">Gian Paolo</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">PS I took the freedom of inserting one personal comment.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br></span><span style="font-size: 10pt; color: black; font-family: Arial, sans-serif; ">--------------------------------------------------------------------------------------------------------------------</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><br></span><span style="color: black; font-family: Calibri, sans-serif; ">Prox-1 Data Link Layer
<br><br><br>
2.2.3.2 <br>
How do we reconcile 2.2.3.2: <br>
The Sequence Controlled service ensures that data are reliably transferred across the space link and delivered in order, without gaps, errors, or duplications within a single
<br>
communication session without COP-P resynchronization during the session (see 4.3.2).
<br>
with Note 2 in section 4.3.2.2: <br>
2 The mechanisms provided in this specification will not eliminate duplicate data associated with the transition between the end of one session and the beginning of the
<br>
next. Elimination of this problem is left to the controlling data system. <br>
GPC: they do not in conflict as there is guarantee within a session but not across session. It may be this should be highlighted somehow in section 2 too.<br>
------ <br><br>
** Figure 2-1 at the top: <br>
"INPUT of USER DATA + Routing Info" -- is it really routing information? Maybe "USER DATA + Control Info"? If this referrs specifically to the Port ID then OK, I suppose the control of data output from the receiver is a form of routing.
<br><br>
This meshes with 2.1.6 'Addressing' where one could use 'The Port ID provides the means to *direct* user data internally...'
<br></span><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Yes, PORT ID is the output port to which the data is routed, so I would stick to this term.<br></span><span style="color: black; font-family: Calibri, sans-serif; ">------ <br><br>
2.2.3.2 <br>
I think where it says: "...without gaps, errors, or duplications wthin a single communication session *without COP-P resynchronization during the session*..."?
<br><br>
might be better phrased as: <br>
"... without gaps, errors, or duplications within a single communication session *when COP-P resynchronization is not required during the session (see 4.3.2).*"
<br><br>
AND it seems like there may be duplicates anyway if there are other sessions (as above)?
<br><br></span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Recall that Prox-1 was built for point to point links involving independent comm sessions. Every session is independent of the previous
or next one. </span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">For data continuity between sessions, Prox-1 always relies upon higher layer protocols, e.g., CFDP, LTP, DTN, etc… Prox-1 has an elegant
way of ending a session by both sides declaring they have no more data to send, but to date the missions use the physical exit strategy- node no longer in view - to terminate the session and keep the data flowing until the bitter end. Prox-1 guarentees no
gaps, duplicates or errors (based upon the CRC-32 undetected error rate and the link FER) within a single session. </span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">I don't like the rewording above because it states a negative requirement – something that cannot be validated. </span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><span style="color: black; font-family: Calibri, sans-serif; "><br>
---- <br><br>
"SDUs supplied by a sending user for transfer with the Sequence Controlled quality of service are inserted into transfer frames as required and transmitted on a Physical Channel (PC) in the order in which they are presented."
<br><br>
The frames may be initially transmitted in the order in which they are presented, but retransmissions will mess with this ordering, correct?
<br></span><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">The overall order of the frames is still preserved. Retransmission would force a go-back-N number of frames to be retransmitted and then forward progress should then reoccur.</span><span style="color: black; font-family: Calibri, sans-serif; "><br>
---- <br><br>
"4.2.6 The SENT_TIME_BUFFER shall store all of the egress clock times, associated frame sequence numbers, and QoS Indicator when time tag data is collected."
<br><br>
What does this mean? Does 'when time tag data is collected' apply to all of the data mentioned (1. egress times, 2. frame sequence number, 3. QoS indicators) or are the first two always stored and QoS indicators only included when time tag data is collected?
Does this mean '...andthe QoS indicator of when time tag...' (and if so, what exactly does that mean?)
<br><br>
4.2.6.1 <br>
Same issue as 4.2.6 <br></span><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Time tag data is the Raw snap shots of the clock when a Prox-1 frame ingresses or egresses a defined point on the spacecraft. All the other data (FSN, QoS indicator) is meta data associated
with each clock value. These buffers are identified on both the Send and Receive sides.</span><span style="color: black; font-family: Calibri, sans-serif; "><br>
----- <br><br>
The section numbers around 4.2.5 -- 4.2.7 seem busted. Maybe they should be: <br><br>
4.2.5 MAC BUFFERS <br>
4.2.5.1 SENT_TIME_BUFFER <br>
4.2.5.1.1 The SENT_TIME_BUFFER shall store all of the egress clock times, associated frame sequence numbers, and QoS Indicator when time tag data is collected.
<br>
4.2.5.2 RECEIVE_TIME_BUFFER <br>
4.2.5.2.2 The RECEIVE_TIME_BUFFER shall store all of the ingress clock times, associated frame sequence numbers and QoS Indicator when time tag data is collected.
<br><br></span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Tom to fix please.</span><span style="color: black; font-family: Calibri, sans-serif; "><br>
----- <br><br>
4.3.2.2 (and Reliable Data Transfer in general) <br>
Is the user informed of whether COP-P resynchronization has taken place during the course of a single communication session? If not, how does the receiver know if there may be duplicate data? Does detectingresynchronization require setting the MIB parameter
Resync_Local to 'false'? If the user is required to monitor the RESYNC variable (7.1.2) to detect resynchronization, is there any guarantee that the user will detect the change (that is, if the user reads 1/second, will they notice the resynch event?)
<br><br>
Note 1 in section 4.3.2.2 -- how is the delivery of duplicate data due to factors outside the scope of the Proximity-1 protocol? It seems that duplicate data may be delivered because the Proximity-1 protocol does not detect duplication across resynchronization
events, but I suspect a more robust COP-like protocol *could*. The point is, the duplicate data is a result of the Prox-1 reliability mechanisms not being robust across resynchronzation, not some sort of external factor.<br><br>
What are the 'bounds' on duplicate data reception associated with Note 2 in section 4.3.2.2? Are all data received with 256 frames of a communication session boundary suspect of duplication, e.g.?
</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><span style="color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Prox-1 notifies the "user" I.e., the vehicle controller on the Sending side when COP-P (Sending node) detects loss of synchronization (Synch_Timer
expires). Prox-1 gives the user two options regarding how to handle resynchronization. If the MIB parameter Resync-Local is set to "true", then Prox-1 COP-P Sending Node will force the other side to reset it's sequence counter. The receiving node is simply
data driven and responds to the sending node. If set to "false", it's up to the Sending Node vehicle controller on how to deal with the out of sync condition, which is then outside of the protocol. Some missions may simply not care if one overflight (of short
duration) didn't go as planned or they may invoke their own strategy. … The "user" doesn't monitor the RESYNC variable that is an internal variable within the COP-P to monitor when the resync condition terminates. </span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">The only way I am aware for the receiving node to get duplicate data is to stich together data from several prox-1 sessions where the
data controller allowed overlap but this was not a consequence of Prox-1. Even during a resync, the protocol can't accept duplicate frame numbers. The worst case is no forward progress if the Receiving Node's expected frame counter, V(R), exceeds the window
size, which could occur through SEU hit on that register. </span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">The bounds on duplicate data is not a function of Prox-1 but rather how much of a "rewind" the user plans to do if they are stiching
Prox-1 sessions together by brute force. We eliminated the possibility of frame counter ambiguity in Prox-1 by limiting the window size N to 127. This is due to the duality of interpreting sequence counts whenever a rollover occurs using modulo arithmetic
… in our case with counts greater than 127. Since the sequence counter is a mod 256 counter, there is no way for us to deal with unique sequence counter unless we limit N to 127.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><span style="color: black; font-family: Calibri, sans-serif; "><br>
--------------- <br><br>
6.2.2.1.1 <br>
It is unclear from the below when or if the receiver is powered on in half-duplex mode:
<br><br>
"... <br>
b) connecting-T: In the Physical Layer, the Connecting-Transmit state in full duplex
<br>
shall dictate that the ***receiver (sequentially in half duplex)*** and transmitter are
<br>
powered on and enabled to process received frames, and that the transmitteris <br>
enabled for asynchronous channel operations. (***In half duplex, only the transmitter is
<br>
powered on.***) The Hail Activity shall be conducted while MODE is connecting-T. <br><br></span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">I agree this text needs some clean up. What's important here is that the state of the transmitter changes in half-duplex depending
upon who controls the Prox-1 Token. The receiver can be on all the time. This is a RID to make this read clearly.</span><span style="font-size: 15pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><span style="color: black; font-family: Calibri, sans-serif; "><br>
6.2.3.7 REMOTE_SCID_BUFFER <br>
Are the tests mentioned done on reception or transmission? It seems like this is trying to ensure that all frames are sent to the same destination spacecraft ID?
</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">All tests are carried out upon reception. I need to reference 3.2.2.9 here which lists all of the tests by the receiving node– we
will make this a RID. This buffer is just a receptical for the value of the Remote_<i>spacecraft</i>_ID i.e., partnered node MIB parameter. </span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">New Definition – </span><span class="apple-style-span"><span style="font-size: 13.5pt; font-family: Calibri, sans-serif; ">REMOTE_SCID_BUFFER </span></span><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">shall
be used to hold the value of the <span class="apple-style-span">Remote_<i>spacecraft</i>_ID of the partnered node. See 3.2.2.9</span></span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><p class="MsoNormal" style="margin-left:.5in"><span style="color: black; font-family: Calibri, sans-serif; "><br><br>
6.2.3.9 RECEIVING_SCID_BUFFER <br>
"...or it may be loaded with the spacecraft ID contained in the first valid received frame." -- First of WHAT (I think 'first valid received frame of a new connection where the sourceOrDest parameter of the frame is DESTINATION' [since if the first valid received
frame has sourceOrDestination set to source then the value of the SCID will be the transmitter -- or is this not possible?])?
</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-size: 15pt; color: rgb(255, 35, 14); font-family: Calibri, sans-serif; ">Again, one has to interpret the S/D flag differently if one is the Sending node or the Receiving node. Yes it is the initial valid
received frame of a session. However this refers to the optional test when S/D = SOURCE, since the test when S/D = DESTINATION is always made. See section 3.2.2.9 and section 6.2.4.2. We accept some of the rewording as a RID – we will update with the wording
"the initial valid received frame of a session" and in 6.2.4.2 as well.</span><span style="font-size: 15pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><pre style="margin-left:.5in"><span style="color:black">This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.<o:p></o:p></span></pre><pre style="margin-left:.5in"><span style="color:black"><o:p> </o:p></span></pre><pre style="margin-left:.5in"><span style="color:black">Please consider the environment before printing this email.<o:p></o:p></span></pre></div></div></div></span></div></div></span></div></body></html>