Comments by Bob Durst and my responses
Overall: Approve upon successful resolution of the following comments.
Sec 2.2.1, Para 2. Despite the caveat in the Foreword that "Space Link" did not necessarily equal OSI Link Layer, it is jarring to me as a reader to see the protocols of the Network, Transport, and Application layers of the OSI model referred to as "Space Link protocols." This reminds me of the similar misuse of the term "waveform" in US DOD documents to refer to the full protocol stack that operates in a wireless environment. I think that it would be more precise to refer to these as "protocols for use over space links" rather than "space link protocols" to avoid this confusion with data link layer protocols. It's just a suggestion, but as I said, it's jarring to the reader.
Figure 2-1 (and many other places): The document, through the figure, incorrectly shows the relationship between FTP and SCPS-FP. SCPS-FP is a set of options that extend the functionality of FTP. SCPS-FP does not exist separately from FTP, and should not be shown as a separate box. This also holds in Figure 2-2, Figure 4-4, and throughout the document. This may be adequately resolved by relabeling one of the boxes (either the "FTP" box or "SCPS-FP" box) to "FTP/SCPS-FP" and deleting the other box.
Figure 2-1 (and many other places): A similar problem exists in the relationship between SCPS-TP and TCP and UDP. SCPS-TP defines optional extensions to TCP, and incorporates by reference UDP. The three boxes, "SCPS-TP," "TCP," and "UDP" should be reduced to two boxes, one labeled "TCP/SCPS-TP" and the other labeled "UDP." Also in Figure 2-2, and elsewhere in the document.
Figure 2-1: I believe that IPSec is a valid protocol for use over space links, and should be shown as a peer to SCPS-SP. CCSDS didn't define it, but there are several protocols on here (e.g., IPv4 and IPv6) that CCSDS didn't define.
Section 2.2.4: "Space link protocols of the Network Layer" see first comment, above.
Section 2.2.5: "Space link protocols of the Transport Layer" see first comment, above.
Section 2.2.6: "Space link protocols of the Application Layer" see first comment, above.
Sec 3.4, Para 2: "It is based on TCP and UDP of the Internet and is intended to be used on top of SCPS-NP, IP Version 4 or IP Version 6." Reword to "It defines extensions to TCP and incorporates UDP by reference. It may be used on top of SCPS-NP, IP Version 4 or IP Version 6."
Sec 3.5, Para 3: "It is based on FTP of the Internet and is intended to be used on top of SCPS TP or TCP." Reword to "It defines optional extensions to FTP of the Internet and is intended to be used on top of TCP (with or without the SCPS-TP extensions)."
Sec 3.5, Para 5: "Applications protocols used in the Internet, such as FTP (reference [25]), can also be used on top of SCPS-TP, TCP and UDP over space links." There are two problems with this statement, first is the SCPS-TP versus TCP issue, and the second is that the example (FTP) *cannot* be used over UDP. Suggest the following rewording: "Applications protocols used in the Internet can be used over TCP (with or without the SCPS-TP extensions) or UDP. Typically, an application is written to use the reliable stream-oriented service of TCP *or* the unreliable datagram service of UDP, but not both. Some exceptions to this exist, however, in which applications are written to operate over either service."
Figure 4-4: SCPS-FP and FTP -> "FTP/SCPS-FP", SCPS-TP, TCP -> "TCP/SCPS-TP"
Figure 4-5: Same comment as Figure 4-4.
Figure 4-6: Same comment as Figure 4-4. In particular, FTP -> "FTP/SCPS-FP," or else the figure implies that SCPS-FP CANNOT be used over IPv4 (which is incorrect).
Figure 4-7: TCP/SCPS-TP.
Figure 4-8: TCP/SCPS-TP.
Figure 4-9: TCP/SCPS-TP.
TY: All agreed.
Comments by Majorie de Lande Long and my responses
> Comments on 130.0-G-1.3, "Overview of Space Link Protocols", July 2005
> a) Reference [37] has various SLE books with dates shown as December 2004
> which should be November 2004.
TY: Agreed.
> b) 2nd paragraph on page 3-2 says "The Proximity-1 Space Link Protocol
> uses
> either fixed-length or variable-length Transfer Frames." but I believe
> Proximity-1 now only has variable-length frames.
TY: Agreed.
> c) Table 3-3, in the column for TC, "Pseudo-nose" should be
> "Pseudo-noise"
TY: Agreed.
> d) The Green Book contains a lot of material about layers, but at no
> point
> does it discuss the possibility of inserting extra layers for security or
> encryption; perhaps a paragraph could be added to section 2 to mention
> this?
TY: Agreed. I will introduce the security Green Book that is being edited by the Security WG of CCSDS.
Comments by ESA and my responses
A number of modifications/improvements should be brought to this document prior to publishing. Here are a few example issues identified:
1- General
The definition of Service should be independent of the protocol used at the level below (see ISO/IEC 10731 Sect 5.1.2). It is not the case in this book.
TY: Since this book is a Green Book, it does not define Services. If there is a problem with the definition of Services, the book that defines the Services should be modified.
2- Figure 2-1
The title Space Link Protocols should be replaced with Protocol Reference Model for Space Communications Systems
TY: Agreed.
3- Section 3.2.2
The title ‘Adressing of Data Link Protocols’ is confusing. According to ISO/IEC 7498-3 OSI-Basic Reference Model: Naming & Addressing, section 6.2.2.1, an address identifies a set of N-SAP (Service Address Point). In this chapter, there is confusion between addressing and multiplexing. Note also that in above ISO document, note 1 of section 7.2 states that “there is no relationship between the SAP entity correspondences … and multiplexing”.
TY: Agreed. The title should read 'Identifiers used by Space Data Link Protocols.'
4 - Table 3-1
Under the ‘address’ column are listed items which are not addresses: TFVN, SCID, PCID, VCID
TY: Agreed. 'Address' and 'Addressing capability' should read 'Identifiers.'
5 – Table 3-4
The concept of ‘Path Address’ is not defined.
TY: Since this book is a Green Book, it does not provide full definitions of technical terms (it is a task of a Blue Book). However, a brief explanation on 'Path Address' is given in the paragraph above table 3-4.
Given the importance of producing a clean unambiguous document and the complexity of the issue, it is proposed to call for external specialists (industry?) to assist or on an exceptional basis organise an agency review of the document.
TY: I agree with this idea completely.