[Sls-slp] FW: Proximity-1 Timing Services comments from Gian Paolo Calzolari

[Kazz, Greg J (313B)]

Dear SLS-SLP WG,

Below please find comments from Gian Paolo on Prox-1 Data Link Section 5 Timing Services. We will be reviewing the entire Prox-1 Data Link Layer book during our Berlin meeting including this section as well.
Please let me know if you have any responses to these comments below

Thanks and best regards,

Greg Kazz
Chairman SLS-SLP WG

From: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Tue, 3 May 2011 07:57:20 -0700
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: Marjorie de Lande Long <marjorie at delandelong.com<mailto:marjorie at delandelong.com>>
Subject: Proximity-1 Timing Services


Greg,
        As you know the current CCSDS 211.0-B-4 July 2006 Proximity-1 DLL Blue Book contains a Section 5 titled PROXIMITY-1 TIMING SERVICES containing two subsections: 5.1 COUPLED NON-COHERENT PROXIMITY TIMING SERVICE and 5.2 PROXIMITY TIME CORRELATION.
Comparing the blue book in force with your latest file “CCSDS_211.0-B-4_Apr20_2011_GJK.doc” there are no changes apart from a typo (course --> coarse).

I think this section deserves some clarification despite we are doing a good work with the clarifications that will go into the Proximity-1 C&S Book.
See the items below.

Regards

Gian Paolo

---------------------------
#1
I think that clause 5.1.1 is not really a normative clause (it says: Timing Services are required for Proximity operations in order to provide the following three capabilities........) but just an informative preamble. There is no "shall formulation" and no one of the 3 listed capabilities is "fully" specified in the document.
The same could be said for clause 5.1.2 (it says: All three of these capabilities require that MODEis active and.....) as I think that requirements on the MODE setting are elsewhere.
Recommendation: transform section 5.1 into a non normative section titled e.g. OVERVIEW.
---------------------------
#2
Following the suggestion #1 above, the current section 5.2.1 OVERVIEW could be embedded  into 5.1 as it continues the description.
---------------------------
#3
The first sentence of 5.2.1 OVERVIEW (i.e.: "The method requires that both the initiating and recipient transceiver shall have the capability of time tagging the trailing edge of the last bit of the Attached Synchronization Marker of every incoming and every outgoing Proximity frame.") should be modified removing "shall" (i.e. From " transceiver shall have" To " transceiver have".
In fact shall can only be in normative sections.
---------------------------
#4
Steps a) to c) in in 5.2.2 TIME TAG CAPTURE METHOD are fine with me.
Step d) is unverifiable and not fully specified in this document.
The "Proximity time correlation packet" is undefined in this document (despite it deserves also an acronym TCP).
The processing of "Proximity time correlation packet" is undefined in this document.
Recommendation: convert step d) into descriptive statements specifying that the further processing is not defined in this document.
---------------------------
#5
Remove from Annex E the acronym  TCP = Time Correlation Packet
It is never used.
It is likely to create confusion with e.g. TCP/IP if used.
---------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20110503/14515874/attachment.html>