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

Thu Jul 23 14:10:55 EDT 2009

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

ID

Page

Response

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.

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.

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?

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.

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 <http://www.merriam-webster.com/dictionary/bespoke> ) – is that not a well-known term? Will change to "proprietary"

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.

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.

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.

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.)

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?

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."

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?

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".

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 …"

X (2.4.2)

JP28

7-11

OK

JP29

7-12

OK

JP-30

9-1

OK

________________________________

From: John Pietras [mailto:john.pietras at gst.com] 
Sent: 22 June 2009 20:23
To: Martin Götzelmann
Cc: css-csts at mailman.ccsds.org
Subject: Comments on CSTS Specification Framework Concept on CWE

Martin,

I’ve posted comments on the CSTS SFW Concept on the CWE, in the form of a markup of your G-0.12 document. The marked-up document (CSTS SFW Concepts G-0.12-jvp.doc) can be found at 

http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/CSTS%20SFW%20Concepts%20G-0.12-jvp.doc

or http://tinyurl.com/CSTS-SFW-Concept-JVPcmmts

The comments are mostly in the form of embedded Word comment markup, but I also took the liberty of correcting some minor typographical errors when I noticed them.

Best regards, 

John

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090723/2280181a/attachment.htm