<font size=2 face="sans-serif">Greg,</font>
<br><font size=2 face="sans-serif">        please
note that the following comments were not implemented</font>
<div><font size=4 face="Cambria"><b>NOTES in hide requirements.</b>
Is misleading (in fact some values are not protocol Id’s defined at </font><a href=http://sanaregistry.org/r/protocol_id/protocol_id.html><font size=4 color=blue face="Times New Roman"><u>http://sanaregistry.org/r/protocol_id/protocol_id.html</u></font></a><font size=4 face="Times New Roman">
) and the first 3 notes are actually normative clauses</font><font size=4 face="Cambria">.
  </font><font size=4 color=red face="Cambria">Agreed.</font>
<br><font size=2 face="sans-serif">Please convert/include the 3 notes to.into
normative clause(s).</font>
<br><font size=2 face="sans-serif">Note 4 should actually become part of
the clause from Note 3 to poiint to the (new) SANA registry.</font>
<br><font size=2 face="sans-serif">Moreover in telecon #2 "</font><font size=3 face="sans-serif">Greg
Kazz and Ed Greenberg took the action to document how the Sending and Receiving
side procedures (4.2 and 4.3) are affected if a fixed vs. a variable length
transfer frame is used.</font><font size=2 face="sans-serif">" and
it would be nice if you could report about this at telecon #3. I think
the list is going to be rather short....</font>
<br><font size=2 face="sans-serif">Lat but not least, in the attached file
you find a few remarks about the updated chapter 5 on Managed Parameters.</font>
<br><font size=2 face="sans-serif">It could be good discussing this at
telecon #3 together with the remarks for "Not imported parameters"
I sent within the file named USLP.ManagedParameterSources20160203.pdf</font>
<br><font size=2 face="sans-serif">Regards</font>
<br><font size=2 face="sans-serif">Gian Paolo</font>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Kazz, Greg J
(312B)" <greg.j.kazz@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"SLS-SLP Mailing
List" <sls-slp@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">12/02/2016 20:48</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[Sls-slp] Material
to discuss during 3rd USLP Telecon</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">sls-slp-bounces@mailman.ccsds.org</font>
<hr noshade>
<br><font size=4 face="Calibri">Dear SLP WG,</font>
<br><font size=4 face="Calibri">I will soon create a doodle poll for the
3rd USLP White Book telecon.</font>
<br><font size=4 face="Calibri">The focus will be on Section 2 of the post
telecon 2 white book as well as a trial balloon pitch for an additional
type of Insert Zone service, called On-demand insert.</font>
<br><font size=4 face="Calibri">You can find the latest version of the
USLP white book post telecon 2 on the CWE under:</font>
<br><a href=http://tinyurl.com/jf9j6u3><font size=4 color=blue face="Calibri"><u>http://tinyurl.com/jf9j6u3</u></font></a><font size=4 face="Calibri">
<br><font size=4 face="Calibri">It contains the date feb 9 and post telecon
2 in the word file name.</font>
<br><font size=4 face="Calibri">Topic 1 (Section 2 review) is spearheaded
by Gian Paolo whose comments you will find in the CWE under:</font>
<br><font size=2 face="sans-serif"> </font><a href=http://tinyurl.com/jf9j6u3><font size=2 color=blue face="sans-serif"><u>http://tinyurl.com/jf9j6u3</u></font></a><font size=3 face="Calibri">
<br><font size=3 face="Calibri">At least two key questions need to be discussed
by SLP WG concerning the review of Section 2. They are:</font>
<br><font size=2 face="sans-serif">1) Shall USLP retain the TC Coding capability
that a protocol data unit transferred can contain several frames?</font><font size=3 face="Calibri">
</font><font size=2 face="sans-serif"><br>
The fact that TC coding allows it does not exclude a possible limitation
on the USLP side (e.g. SLE FSP explicitly forbids the option of including
several TC frames in a CLTU).</font><font size=3 face="Calibri"> </font><font size=2 face="sans-serif"><br>
We shall remember that several frames in a CLTU does decrease performance.</font><font size=3 face="Calibri">
</font><font size=2 face="sans-serif"><br>
2) Shall any reference to Proximity-1 coding be removed from the USLP Blue
Book as long as there is no agreed adaptation for that blue book?</font><font size=3 face="Calibri">
<br><font size=4 face="Calibri">Note: NASA has submitted an agenda item
to the C&S WG chairman to describe changes to the </font><font size=3 face="Calibri">CCSDS
211.2-B-2 (Prox-1 C&S Blue Book) including CWE project details  to
allow USLP transfer frames over the Proximity link.</font>
<br><font size=4 face="Calibri">Topic 2 (On-demand Insert Service) is spearheaded
by Ed Greenberg. The post telecon 2 white book contains trial sections
describing and standardizing the two types of Insert Service. The concept
is below:</font>
<br><font size=4 face="Calibri">The concept of the two types of Insert
Service follows:</font>
<p><font size=4 face="Calibri">USLP provides two complementary types of
Insert Service: a) Isochronous and b) On-demand. Only one Insert Service
type is allowed on a Physical Channel at any given time.</font>
<p><font size=4 face="Calibri">The Isochronous Insert Service provides
transfer of private, fixed-length, octet-aligned service data units across
a space link in a mode which efficiently utilizes the space link transmission
resources at relatively low data rates.  The service is unidirectional,
periodic, and sequence-preserving.  The service does not guarantee
completeness, but may signal gaps in the sequence of service data units
delivered to a receiving user.</font>
<p><font size=4 face="Calibri">For a given service instance, only one user,
identified with the Physical Channel Name of the Physical Channel, can
use this service on a Physical Channel. Service data units from different
users are not multiplexed together within one Physical Channel. The presence
of the Insert Zone is signaled by Managed Parameters.</font>
<p><font size=4 face="Calibri">The On-demand Insert Service provides the
optional transfer of private, variable length, octet-aligned service data
units across a space link in an episodic manner. The service is unidirectional,
asynchronous, and non-sequence preserving. The Insert Zone length may vary
between 1 and 255 octets and is specified in the first octet of the Insert
Zone. The presence of the on-demand Insert Zone is signaled by the On-demand
IZ flag in the TF header.</font>
<p><font size=4 face="Calibri">Multiple users may use this on-demand Insert
Service on a Master Channel, identified with the VCID of the frame which
contains the On-demand IZ flag set to ‘1’.</font>
<br><font size=4 face="Calibri">Best regards,</font>
<br><font size=4 face="Calibri">Greg </font>
<br><font size=4 face="Calibri">Chairman SLS-SLP WG </font>
<br><tt><font size=2>_______________________________________________<br>
Sls-slp mailing list<br>
</font></tt><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><font size=2>http://mailman.ccsds.org/mailman/listinfo/sls-slp</font></tt></a><tt><font size=2><br>
<br></div><PRE>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.

Please consider the environment before printing this email.