[Css-csts] RE: Comments on CSTS Specification Framework Concept on CWE

Thu Aug 6 14:25:58 EDT 2009

Martin,

Please find my replies to your responses to my comments in the modified version of your table below. (If you choose to make further comments on this, we will need to come up with another synonym for response and reply).

As you correctly responded I several cases, the Concept Book merely reflects the wording found I the Framework (FW) so if any changes are to be made they should be made in both documents. To that end, I plan to re-state those comments in an email to Yves and the CSTSWG.

Best regards,

John

ID

Page

Response/JP Reply

Same in FW

JP1

1-1

OK

JP2

1-1

OK

JP3

1-2

The reference is to section 2 where the history is discussed. My understanding was that this is how sections must be referenced.

/JP – I looked at the CCSDS Pubs Manual, and I found the following:

4.3.6 TEXT REFERENCES

Numbered figures and tables must be referenced in text. Sections, subsections, annexes, and notes may need to be referenced. When referenced,

a) sections shall be referenced as ‘section {N}’, where N is the section number;

a) subsections shall be referenced by subsection number only, except when reference to a subsection begins a sentence, in which case ‘Subsection’ shall precede the number;

Apparently the Secretariat Editor also found a single-digit section reference possibly confusing.

JP4

1-2

This is copied from the FW. I concede that these sentences are not very clear, but I think this somehow reflects that SLE services are theoretically CSTSes but practically are not based on the framework. Suggestions for a clearer wording would be very much appreciated.

/JP – Yes, these are issues for the FW as well as the Concept. I’m am not sure myself which of the contradictory statements that are identified in JP-4 are correct, I’m having some problem myself suggesting better wording. Rather than addressing it in the context of the Concept Book, I’ll write up the issues as comments on the FW itself. Once we get them resolved for the FW, the Concept Book can follow.

X

JP5

1-2

X

JP6

1-3

I believe this is the same problem as addressed by JP4 and JP5. I have no problem adding a statement but I have problems to find brief and clear words. Can you suggest something?

/JP – As with the above comments, I’ll write up my issues and recommendations as comments on the FW, and however they are resolved there can be copied to this Concept book.

x

JP7

1-3

x

JP8

1-3

This is the official title of the Recommendation and I believe we cannot just change it in the references.

/JP – Perhaps my comment wasn’t clear: the reference did not have “Space Link Extension” included, and I added it because it is indeed part of the official title.

Also, I just noticed that the title for reference [9] is slightly incorrect: it should be just “Space Link Extension”, not “Space Link Extension Services”.

x

JP9

2-1

OK, I will change to "in 1991" (should I add AD? ;-)

JP10

2-1

OK

JP11

2-1

OK

JP12

2-1

The Merriam-Webster dictionary says that "bespoke" means "custom made" (see http://www.merriam-webster.com/dictionary/bespoke) – is that not a well-known term? Will change to "proprietary"

/JP – It’s not a term that I had ever heard before, and the several people that I asked in my office had not heard of it either. I looked it up in my low-tech printed dictionary, where the definition includes the notation Brit, which leads me to believe that it is a British term (and as you know, any Brit will tell you that Americans do not speak English). At least for us provincial Americans, “proprietary” is a better word.

JP13

3-1

OK

JP14

3-3

I am not sure whether this would really be a good place to make a general policy statement about SLE Service Specifications, because SLE services are mentioned here only as an example. My feeling is that such a statement, if we want to add it, would belong in section one (possibly replacing the ones you did not like – see JP4/5) or maybe section – e.g. end of section 2.2. However, in the past nobody wanted to make a clear statement and that is why we ended up with the vague phrase that converting SLE services to CSTSes based on the FW is "possible but not mandated"… Do all Agencies concur with the statement as phrased. If so, it should probably also go the FW Book.

/JP – In re-reading the section, I agree that this is not the best place to make such a statement: the comment was triggered by the discussion of CSTS equivalents of existing SLE services. I think that putting something into section 2.2 would work. I don’t think that it makes much sense to put it into the Introduction section, which is supposed to establish the purpose, scope, and context of the document itself, not the services on which it reports. 

With respect to the FW itself, I don’t think that any policy statement should be made there now about the replacing SLE services with CSTSes. Such a statement is, however, appropriate to the Concept book.

Maybe relevant

JP15

3-3

I think we should avoid expanding the references to cover each and every term used in the document – if somebody is interested he can check the referenced ISP1 book. Would we need to add a reference for ASN.1 as well? We do not have references for TCP and IP, for instance. Please let me know if you feel this is important and then I will add the reference.

/JP – There is a reference to ASN.1 in the following paragraph, and it’s listed as reference [7], and it was this reference that caused me to wonder why a BER reference wasn’t included. However, I agree with your logic that since it’s used in the context of discussing ISP-1, which does have a reference, it isn’t needed. 

JP16

4-1

OK

JP17

4-1

OK

JP18

4-3

OK – replaced "assumes" by "defines"

X (2.3)

JP19

5-1

You are right, there are no operation excluding extensions in the FW. I nevertheless think we should stick to this as the rules apply also for derivation of new operation in service specifications and there might be a need for this. The normative statements are of course in the guidelines but my understanding is that the Concepts cover the FW and the guidelines.

/JP – My concern is that the sentence currently implies that the FW explicitly states otherwise for some operations. What is mostly hidden in this statement is that new services can be built using operations and procedures adopted or derived from other services, and that those source services may place restrictions on further extension.

X (2.5.2)

JP20

6-1

OK, will add this NOTE. I tried to avoid notes to make the document better readable and therefore suggest adding this as normal text.

X

JP21

6-1

I see your point but I think the concepts book is not the right place to discuss this as it must follow the terminology in the FW. Changing this now might have a significant ripple through effect though. 

(I personally feel that the concept of blocking / non-blocking is not very helpful and the desired behaviour can be easily expressed by the state tables and therefore I would drop it completely.)

/JP – I agree that unless it’s changed in the FW it shouldn’t be changed here. But I do believe that it is a source of confusion and should be fixed in the FW and here.

X

JP22

6-5

The question is: what does it mean to "start a procedure"? For concrete services this is easier: RAF: start transfer of telemetry, CLTU: be prepared to accept CLTUs from the user. What is the correct abstraction for a generic START operation?

/JP – I agree that in the abstract start and stop are vague, but personally don’t think that saying “start an activity that is associated with the procedure” is any less vague than “start the procedure” or “start performing the procedure”. However, that’s just my perception, and I made the comments simply as suggestions to simplify the sentences. It’s not crucial in any case.

X (3.7.1)

JP23

6-5

JP24

6-5

I understand your concerns, bit I do need some short term to say something remains unspecified and it is important that the reader understands that this is handled via data typing. I will change the sentence as follows: "The data parameter itself is of the special type Extended, which is used to indicate that the data is undefined and the specification must be provided by a derived operation."

/JP – My original concern was that introducing the reference to the specific Extended type was too detailed for a concept book. But I somehow missed that Extended is actually introduced and explained in the example in section 6.1. So I withdraw my original comment but I like your rewording anyway. .

JP25

6-7

OK, I will just remove the last sentence of the paragraph. 

Can you remind me of the reason this was specified like this – if an invoker receives a negative ack, how can he know whether the performer will send a return or not? Is it also legal to send a positive return following a negative ack?

/JP – A negative ack corresponds to the termination of the operation, so (a) the invoker knows not to expect a return and (b) it’s not legal to send a positive return (or negative return) following a negative ack.

It’s my understanding that the reason for specifying it this way is that it’s supposed to replace the SLE approach for handling non-immediate or distributed processes (e.g., for the THROW-EVENT). In that approach, the return from the operation itself essentially confirms (acknowledges) that the invocation was valid and that the requested process was initiated. Final disposition of that operation was left to be reported via a NOTIFY operation. The idea is that a negative ack means that the invocation failed to meet the criteria to even begin the operation; thus no report on the final disposition (i.e. return) is needed or expected.

This behavior is not specified under the definition of the Standard Operation Header or the EXECUTE-DIRECTIVE operation (the only FW operation that is acknowledged), but it is reflected in the state table for the Throw Event procedure in the FW and generically in the state table for CSTS with Acknowledged Prime Procedure in the Guidelines. 

JP26

7-1

I feel that going into all the subtle differences between "started" procedures and "acknowledged" procedures at the level of the concepts will confuse more than help. However, to avoid conflicts with the FW, I will change the last sentence before the figure as follows: "A simplified state transition diagram for stateful procedures using START and STOP operations is shown in figure 7‑1 below." I would prefer not to change the captions – after all the text does say it is "simplified".

/JP – OK.

JP27

7-2

Of course you are right, but the issue addressed here is that you must distinguish procedure types and procedure instances. Do you really think a reader may derive that a service with only an association control procedure would make sense – strictly speaking, I do not think there is anything in the FW that would prevent this. 

I suggest changing the text as follows: " A CSTS will typically use more than one procedure in addition to the Association Control procedure and may require more than one procedure of the same type to be active at the same time …"

/JP – OK.

X (2.4.2)

JP28

7-11

OK

JP29

7-12

OK

JP-30

9-1

OK

________________________________

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de] 
Sent: Thursday, July 23, 2009 2:11 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; Yves.Doat at esa.int
Subject: RE: Comments on CSTS Specification Framework Concept on CWE

Dear John,

Below please find my responses to the comments you raised indicating in the last column which ones apply also to the CSTS Framework Specification as agreed on the teleconference. Sorry for the long delay!

I will wait with Draft 13 of the Green Book until I get further feed-back from you and Yves - of course comments from other members will be very welcome as well.

I have also up-loaded this list to the CWE, Folder CSTS Framework and Concept, File 
Response to Comments on Concepts G-0.12.doc

Kind Regards, Martin

___________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090806/c1bb98e5/attachment-0001.htm