[Css-csts] Revised Forward Procedures for integration into the Framework

Fri May 3 04:50:35 EDT 2013

Dear Wolfgang,

Here are my comments - prepared of course in ignorance of the discussions on the Bordeaux meeting.

Simple DPP V12

(1)    Comment WH1:  I do not understand why all queued PD operations have to be checked if the provider verifies that the counter in a received PD operation is greater than the previous one. The only case where this can happen is when the number of PD stored is larger than the range divided by the increment (assuming that the same increment is always used). If the concern really is that a user application would use huge increments provoking ambiguity then OK, let's go for an increment by 1 and state the assumption that range is sufficiently large to ensure uniqueness as this is done by CLTU.

(2)    The paragraph following Comment WH 1 says "The ascending order of the data-sequence-counter values shall only be verified when the PROCESS-DATA invocation is to be inserted into the Input Queue. No such check shall be performed when the invocation is extracted from the queue for processing"

I do not understand why this is stressed  - it should be clear from section 2.1.3 that the check is applied when the data are added to the queue. In any case, why should it be forbidden to repeat the check when extracting the PD invocation from the queue - that would be silly because it would give the same result but it would not do any harm.

(3)    2.1.3.2.4 states "A value shall be considered greater if the increment with respect to the one received with the previous operation is less than the range of the data-sequence-counter parameter."

I do not understand why this is needed. How can the increment be larger than the range? I am assuming that the range is the range of the type definition - or is that wrong?

Buffered DPP V12

(4)    1.1.4.2.2.3 states: "The size of the Input Queue for incoming PROCESS-DATA operations shall be defined by the service using this procedure, possibly delegating the definition to service management or by a derived procedure."

This is an inherited feature - why is this re-stated? Have you revised the rules for handling inherited specifications in Bordeaux ?

Sequence Controlled DP procedure V12

(5)    Comment WH1: I am not aware of the rule that we should not specify what the user does and I do not really understand why we should not do this where a certain behaviour is expected. Here are a few examples from the framework:
3.4.1.1 The Service User shall invoke the BIND operation to establish an association with a Service Provider.
4.3.3.1.2.1   Except as provided in 4.3.3.1.2.3, the Service User shall not invoke any further operations for this service instance until the return from the Service Provider is received.
4.5.3.1.1 The Service User shall initiate the transfer of data using the START operation including the selection criteria.

The identified specifications have been adopted from the CLTU book (see 3.6.2.5) with the difference that the CLTU book says "shall be set" instead for "the Service User shall set" - this can of course be done, but I do not really see the difference.

I concur that the 1.1.4.2.1 duplicates 1.1.4.2.3 and 1.1.4.2.2 duplicates 1.1.4.2.4 but I would rather remove the paragraphs on validation and just add the corresponding diagnostic values, as this is done in the CLTU book.

(6)    Comment WH3: The Simple DPP explicitly states that at most one data unit can be processed at any time and in my understanding this statement applies to all derived procedures unless it is explicitly modified. This specification was added to the simple DPP after an intensive discussion in Boulder as far as I remember.

(7)    Comment WH4:  This has been adopted from CLTU 3.6.2.7.5. I believe to remember that this has been discussed several times in the context of the SLE services, but the conclusion seems to be that the specification should be retained.

(8)    Comment WH5: I do not really see the problem. In all cases in which the procedure enters the locked state, the Service User has received a notification indicating the incident. Therefore there should be no confusion if the diagnostic code just says "service instance locked"

Kind Regards, Martin

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Wolfgang.Hell at esa.int
Sent: 27 April 2013 15:32
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Revised Forward Procedures for integration into the Framework

Dear CSTS WG Members,

As agreed with Margherita during the Bordeaux meeting, I have assigned highest priority to the consolidation of the three Forward Procedures so that these can be integrated into the Framework asap. I have uploaded the results of this activity to

 (Embedded image moved to file: pic01814.gif)

 The CCSDS Collaborative Work Environment (CWE) > Cross Support Services Area

(CSS) > Documents > CSS-CSTS > CWE Private > Working Materials > DPP Working

 Papers

The vast majority of the issues raised before and aty the Bordeaux meeting have been taken care of. A few minor points are addressed by means of comments in the documents. Given that the next scheduled meeting is not before June, I would appreciate if you could provide feedback via email so that I can close this activity and provide Yves with stable input to the Framework.

Best regards,

Wolfgang

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130503/d922eedf/attachment.html