[Css-csts] RE: Annotated EF-CLTU Book
John Pietras
john.pietras at gst.com
Mon Nov 8 14:24:54 EST 2010
Wolfgang,
Thanks for the quick reply. I believe that the problem can be fixed (to the same degree that it is satisified in the F-CLTU Blue Book) by changing 3.6.2.5.1 to read as follows:
"The cltu-identification parameter shall contain a monotonically increasing sequence number that shall be set for the first CLTU-TRANSFER-DATA invocation after a successful CLTU-START invocation to the value of the first-cltu-identification parameter of that CLTU-START invocation."
I won't distribute an updated draft until after you've had a chance to look at the other changes.
Best regards,
John
-----Original Message-----
From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
Sent: Monday, November 08, 2010 12:03 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: Annotated EF-CLTU Book
John,
So far I did not have the chance to look through all your responses, but as
you need a quick response to the two issues you address, let me respond to
them here.
In terms of a fix to paragraph 3.6.2.6.3, I like the first fix that you are
offering better, as you mention the relevant parameter (production-status).
As to respect the typographic conventions, production status should be in
fixed width font and hyphenated (use the Identifier style).
Regarding the second issue, I feel that there is an important difference
between the original CLTU book and the enhanced specification, as the F-CLTU
specification as in the paragraph that defines the cltu-identification
parameter (3.6.2.5.1), it clearly states that this parameter contains a
sequence number. In EF-CLTU, the term sequence number is used only later
further down in the text (in 3.6.2.5.4). I think the easiest way to cure this
issue is modifying the text in 3.6.2.5.1 of EF-CLTU such that the term
sequence number is introduced in that section as is done in F-CLTU.
Having inspected F-CLTU again, I think we are clean as we introduce the term
sequence number where the relevant parameters are defined. In that respect I
withdraw my comment. As explained above, for EF-CLTU I think it would be
better to to align it in that regard with F-CLTU.
Best regards,
Wolfgang
From: "John Pietras" <john.pietras at gst.com>
To: <Wolfgang.Hell at esa.int>
Cc: <css-csts at mailman.ccsds.org>
Date: 08/11/2010 16:14
Subject: RE: Annotated EF-CLTU Book
Wolfgang,
I've uploaded the updated EF-CLTU draft Orange book to the CWE at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Orange%20Books/EnhancedFCLTU-912_1-O-101_6.doc
or http://tinyurl.com/EFCLTU-O-101-6
Thank you for the many good comments and typo fixes. In the updated draft,
I've first accepted all of the changes from the previous version (101.5) for
which you had no comment, so that only your porposed changes (and the
responses to them) are highlighted in the current version. The pure typo
fixes that you suggested have also been included without markup. Some of your
comments that provide some leeway in the response - these comments (and my
responses) I've left marked-up so that they can be more-easily located. Some
of your comments caused me to find more typos or errors, and these I've also
left marked up.
Finally, your comments addressed two items that were "inherited" directly
from the F-CLTU Blue Books. One of these is easily handled, but the second
requires a bit of consideration. I hope that we can come to a quick
resolution so that the imminent implementation of the EFCLTU service for the
ISS can proceed.
The first issue was paragraph 3.6.2.6.3:
"If the earliest-radiation-time parameter is unspecified, the provider shall
begin processing immediately after any delay associated with the previous
SLE-CLTU has timed out, as long as the production process is running (i.e.,
not ‘halted’ or ‘interrupted’)."
on which you commented
"Radiation is neither possible when the production-status is ‘configured’.
Why not simply state: as long as the production-status is ‘operational’. The
production process is not a parameter and therefore cannot assume values such
as ‘halted’. This may well be also a RID against F-CLTU."
This phrasing is indeed taken from the F-CLTU Blue Book.
In the update, I changed the sentence to read: "If the
earliest-radiation-time parameter is unspecified, the provider shall begin
processing immediately after any delay associated with the previous SLE-CLTU
has timed out, as long as production status is ‘operational’."
and I also offer another variation in a comment: "If the
earliest-radiation-time parameter is unspecified, the provider shall begin
processing immediately after any delay associated with the previous SLE-CLTU
has timed out, as long as the production process is in the ‘operational’
state."
If either of these strikes you as better than the other, please let me know.
As far as the F-CLTU book is concerned, I think that this can be treated as a
typo, which Tom G. can fix without RID.
The other, and potentially more troublesome, error inherited from the F-CLTU
Blue Books is the multiple occurrences of the requirements to report the
sequence numbers of CLTUs in asynchronous notifications and status reports.
E.g., for 3.7.2.5 (b):
"otherwise, the cltu-last-processed parameter shall specify the sequence
number of the SLE-CLTU that the provider most recently processed or attempted
to process, whether the contents of the SLE-CLTU were successfully radiated
or an exception occurred. If the data parameter of a CLTU-TRANSFER-DATA
invocation contains multiple SL-PDUs, this parameter shall identify the
sequence number of the SLE-CLTU of which any contained SL-PDU has been
processed or attempted to be processed."
On which you commented:
" Should one not refer to the specific parameter cltu-identification rather
than talking globally of a sequence number? This comment applies throughout
this part of the document. This may also be a problem in F-CLTU. I have not
checked."
The "sequence number" terminology is present in section 2 as well as the
synchronous notification and status reports sections of the F-CLTU Blue Books
(and therefore the EFCLTU Orange Book). Note also that the CLTU-THROW-EVENT
operation also uses the "sequence number" terminology in refernce to the
event-invocation-identification.
It would seem that this has not been a problem for the F-CLTU Blue Books (it
goes back to at least Blue 1). I'm not opposed to removing the ambiguity in
the EFCLTU Orange Book, but I am concerned that to do so might decouple (or
appear to decouple) the two books in areas where they are intended to be the
same. As I mentioned at the London meeting, there is an imminent
implementation of the Orange Book for ISS, and so I would very much like to
resolve this issue (however we do it) as soon as possible.
If we actually change the normative phrasing of the affected sections in the
Orange Book, it will have the appearance of changing the requirement (even
though it is only a clarification). One possible way around this would be to
follow the various normative statements with clarifying notes to the effect
of "The sequence number is the value of the cltu-identification parameter" or
"The sequence number is the value of the event-invocation-identification
parameter", as appropriate.
Alternatively, we could assume that since these uses of "sequence number"
have been (apparently) correctly interpreted over the various implementations
of the various versions of the F-CLTU Blue Books, we can assume that the
current wording is sufficient for the Orange Book. Given that the Orange Book
is an intermediate document that will be superseded by a "proper" CSTS
specification and therefor only a limited number of implementatons will be
made, this may be justification to let it stay as-is.
I am anxiously awaiting your reply.
Best regards,
John
From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
Sent: Friday, October 29, 2010 3:43 AM
To: John Pietras
Subject: Annotated EF-CLTU Book
John,
As agreed, please find attached the above mentioned book with my edits and
comments.
Best regards,
Wolfgang
More information about the Css-csts
mailing list