[Cesg-all] Result of CESG poll closing 2 February 2011

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2011-01-001 Approval to release CCSDS 
734.1-R-1, Licklider Transmission Protocol (LTP) for CCSDS (Red Book, 
Issue 1) for CCSDS Agency review
Results of CESG poll beginning 12 January 2011 and ending 27 January 2011:

                  Abstain:  0 (0%)
  Approve Unconditionally:  3 (50%) (Peccia, Taylor, Durst)
  Approve with Conditions:  3 (50%) (Shames, Barkley, Moury)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Peter Shames (Approve with Conditions):  The major comment is 
that this document does not have the normative content expected of a 
full protocol specification, instead it is essentially a profile of 
how to apply RFC 5326 within CCSDS.  Note that Chap 3 is titled 
"CCSDS Profile of RFC 5326.  Accordingly I recommend that it be 
published as a Magenta Book, Application Profile.

There are a number of other issues identified in the attached mark-up 
of the text.

This document also introduces "Yet Another MIB" (YAM), which, along 
with those required for CFDP, AMS, BP, BPSec, link layers, MAL, etc, 
etc create a naming, definition, and registry thicket.  At some point 
(real soon now) CCSDS needs to deal with this in a consistent way, 
using the SANA.

Note that there is a similar problem with "Network Management" in 
general within CCSDS.  This document mentions SNMP which is totally 
inappropriate within CCSDS space missions in the general case.  It is 
a SIS issue to identify when this work will be done.

      Erik Barkley (Approve with Conditions):  The books is not 
really a protocol definition as LTP is defined elsewhere -- RFC 5326 
-- but a best practices book on how to standardize usage of LTP in 
CCSDS -- should be reviewed (and indicated as) a Magenta Track document.

      Chris Taylor (Approve Unconditionally):  I have a few comments, 
all of which are not show stoppers for the release of the document 
but may come back as Agency Rids.


I find the following text at the start of section 2.1 confusing:
"The two requirements identified in reference [D3] for such a layer-N 
protocol are reliable delivery of layer-(N+1) PDUs and the ability to 
aggregate multiple layer (N+1) PDUs into a single layer-N PDU for the 
purposes of reliable delivery across the link.  The first of these is 
accomplished by the LTP protocol described here; the second defines a 
protocol to reliably delivery layer-(N+1) PDUs over a link." It seems to
indicate that LTP is meeting the first objective of reliable delivery 
but then states that the second objective is reliable delivery.


To meet the aggregation requirement a function needs to be provided 
in layer N+1 and the text identifies this as a work item. As far as I 
know, no work item exists as of yet and anyway not the sort of info 
we want in a blue book. May be it would be more appropriate to 
include the Aggregation function in the LTP spec.


Given that the encapsulation service has no means to limit data flow, 
the following sentence (3rd para of 2.1) opens up the question of 
whether the encapsulation service is suitable as and n-1 
service.  "LTP assumes that, where necessary, the layer N-1 service 
limits the rate at which LTP can inject data (0), ensuring that LTP 
does not adversely affect other layer-N protocols sharing the 
underlying service." Suggest we explicitly state that flow control is 
part of the local implementation.

If LTP is intended to provide a reliable service shouldn't the text 
be making a recommendation that all transmission should be red? 
Otherwise we may as well use a straight packet service. Suggest that 
we include a specific profile for a reliable service. (Unreliable 
features can still be included).

For the use of persistent file base storage, it would be extremely 
useful if we could tie in with the SOIS file and packet store services.

I would really prefer a self standing BB rather than referring to RFCs.

      Gilles Moury (Approve with Conditions):  This book is mainly an 
application profile for CCSDS links of the LTP protocol which is 
specified in an RFC. Being an application profile with many "should" 
and "may", it looks more like a magenta book (recommended practice) 
than a fully prescriptive blue book. Besides, one might consider 
integrating the LTP spec in the CCSDS book (if this does not violate 
copyright) so as to be isolated from further evolutions of the RFC 
and as to get a self-sufficient document. In that case, the document 
would clearly be a blue book.


Total Respondents:  6

All Areas responded to this question.



SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Generate CMC poll after 
conditions have been addressed

* * * * * * * * * * * * * * * * * * * * * * * *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 734x1r0_CESG_Approval-ps.pdf
Type: application/pdf
Size: 903637 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20110203/078fde77/734x1r0_CESG_Approval-ps-0001.pdf