[Css-csts] RE: Annotated EF-CLTU Book

[John Pietras]

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/Enha
ncedFCLTU-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

________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20101108/e1bad4ce/attachment-0001.html