[Css-csts] Action Item #02-0511S: Annex E with simplified service state tables

Mon Sep 5 11:40:06 EDT 2011

Dear John,

please find our statements below your comments in red.

Best regards,
Martin

From: John Pietras [mailto:john.pietras at gst.com]
Sent: 30 August 2011 20:08
To: Martin Karch
Cc: css-csts at mailman.ccsds.org; Margherita.di.Giulio at esa.int; Yves.Doat at esa.int
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified service state tables

Martin,
Thanks for the excerpt from the FW specification. The paragraphs that apply to the 'not-authenticated PDU' issue are 3.2.4.5.1.1, 3.2.4.5.1.2, and 3.2.4.5.1.5 (Note - these numbers appear to be incorrect - I believe that they should be 3.2.4.6, 3.2.4.7, and 3.2.4.8). Based on these paragraphs, I still believe that it is appropriate to have the 'not-authenticated PD" case called out in the service state tables (E-1 and E-5) because it is true for the service:  the decision to remove it from the Association Control state table was because we (the WG) decided that it was unnecessary and inappropriate to assume that the Association Control procedure would "see" a PDU that failed authentication. However, I might suggest a more correctly descriptive name for the incoming event - 'PDU failed authentication' ('not authenticated PDU' could be incorrectly interpreted to refer to a PDU when the authentication level is 'none'). The reference for the 'not authenticated PDU' or 'PDU failed authentication' event should be to what is now paragraph 3.2.4.5.1.1, although as stated above I think the number should really be 3.2.4.6.

We agree that it is appropriate to have the 'not-authenticated PDU' in the service state tables (E-1 and E-5).

In addition, I realized while reading through the excerpt that you sent me that I should have included an 'invalid PDU' incoming event in state tables E-1 and E-5. In the December draft version of the FW, every procedure state table had an 'invalid PDU' event. In Berlin, we decided to remove the 'invalid PDU' events from the individual procedure state tables because we determined that individual procedures are not able to "see" some of the conditions by which a PDU would be invalid (e.g., if it has an invalid procedure type identifier, it will never be submitted to a procedure that could recognize it). Instead, we added a statement in section 3.2.3 to say that in the case of an invalid PDU the association would be aborted (3.2.3.8) and a NOTE that says that the invalid PDU case "is not addressed elsewhere in this Recommendation" [Note - should be "Recommended Standard"]. When I re-did Annex E earlier this summer, I forgot that we had removed 'invalid PDU' for the individual procedure state tables. It should be added the E-1 and E-5 because otherwise it would appear nowhere in any state table. The reference for the 'invalid PDU' event should be to paragraph 3.2.3.6.

We agree, for the reason you mentioned, to add 'invalid PDU' to E-1 and E-5.

Finally, in the December draft version of the FW, paragraph 3.2.3.6 included a bullet that stated that one of the reasons for considering a PDU to be invalid is that "it is invalid in the current state of the procedure". In discussing this in Berlin, we decided that this was not "invalid" in the sense that it would always cause a peer-abort, and this bullet was pulled out to become a new paragraph by itself (3.2.3.7) "A PDU shall be considered unexpected if it is invalid in the current state of the procedure" with the NOTE "The unexpected behavior is addressed in each procedure". In thinking about it more closely, this requirement is unnecessary. First, it primarily exists to coin a new term/condition "unexpected PDU", which is never used elsewhere in the specification. Second, and more important, it is unnecessary to state this in section 3 because each state table explicitly shows for each incoming PDU what happens in each of the states of the procedure without ever having to label the PDU expected or unexpected. So my recommendation is to delete 3.2.3.7 as unnecessary.

We agree removing 3.2.3.7.

Best regards,
John

From: Martin Karch [mailto:martin.karch at vega.de]<mailto:[mailto:martin.karch at vega.de]>
Sent: Tuesday, August 30, 2011 12:17 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>; 'Margherita.di.Giulio at esa.int'; Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified service state tables

Dear John,

please find attached, as desired,  section 3.2 of the Book. The section contains the updates made in the Berlin meeting so far.

I have only one comment to your comments, and this time it is in black (see below).

Best regards,
Martin

From: John Pietras [mailto:john.pietras at gst.com]<mailto:[mailto:john.pietras at gst.com]>
Sent: 29 August 2011 22:34
To: Martin Karch
Cc: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>; Margherita.di.Giulio at esa.int<mailto:Margherita.di.Giulio at esa.int>; Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified service state tables

Martin,
Please see my responses below, in red.

John

From: Martin Karch [mailto:martin.karch at vega.de]<mailto:[mailto:martin.karch at vega.de]>
Sent: Friday, August 26, 2011 8:35 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>; 'Margherita.di.Giulio at esa.int'; Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified service state tables

Dear John,

Please find attached a PDF file of Annex of the Book, which Yves prepared according to your input "SimplifiedStatefulAnnexE.zip" and  according to the following comments to 921x1r2[Draft 201012]-Annex_E-clean.pdf:

-          In Table E-2 there is the event 'abort-causing event xxx', but this one is not available in the state table E-1. In Table E-1 position 2 there is 'abortable event xxx'. Perhaps this one needs to be exchanged with 'abort-causing event xxx'.
Agreed. I had actually hand-marked that inconsistency to be fixed in my hardcopy, but I obviously didn't do it.

-          In Table E-1 position 1: we feel that in the cell for State 2 there is a {cleanup} missing. If a BIND invocation is received in the state 'bound' there might be some returns pending, and/or some parameter values might have changed already. Therefore we feel that also in this case a {cleanup} is needed after the PeerAbort.
Agreed.

-          Table E-2: The event 'not-authenticated PDU' was removed from the Access Control Procedure State Tables (in Berlin).  A reference to 'invalid PDU' should also not be made because we agreed to remove 'invalid PDU' from all the state tables. Therefor we think we do not need the entry in table E-2, and then also not in E-1.
I remember that we agreed to remove this incoming event from the Access Control procedure state table, and someone came up with some clever words that specified the handling of authentication failures without reference to the Access Control (or any other) procedure. However, since annex E deals with  the state tables for the services themselves, it might still be appropriate to identify non-authentication of a PDU as a service-level incoming event. Could you please send me the text for section 3.2 (updated to include the new wording that was agreed in Berlin) so that I can see if I agree that it's okay to delete this incoming event from the service state tables? Thanks.

-           Table E-5: The same problem as describe above with the 'abortable event xxx'/'abort-causing event xxx' exists in Tables E-5 and E-6.
Agreed.

-          Table E-5: Also here we feel that the 'not authenticated PDU' is not needed here.
See response above.

-          The Predicate Description Table and Compound Definitions Table are missing on page E-6.
In E3.8, I stated that tables E-2 (Event Description References), E-3 (Predicate Description Table) and E-4 (Compound Definitions Table) were also applicable to the stateful state machine case, in order to not repeat the tables. Actually, I made a slight mistake - I should have only referenced tables E-3 and E-4, since E-6 replaces E-4 for the Event Description References. In any case, I can see how this cross reference is perhaps too subtle, and just explicitly repeating the Predicate Description and Compound Definitions tables may be easier for the reader. However, if the new tables E-7 and E-8 are kept, then paragraph E3.8 should be changed to read "Each CSTS that has a stateful prime procedure instance shall conform to the state table for a CSTS with stateful prime procedure instance defined in table E-5, supported by information in tables E-6 through E-8."

               >> One intention for the comment was indeed that it is more convenient for the reader to actually see the tables (even if there is only one entry), rather than to read where he could look-up another table. Therefore I agree with your described approach to keep the tables E-7 and E-8 and adapt the description in E3.8 accordingly.

Best regards,
Martin

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org]<mailto:[mailto:css-csts-bounces at mailman.ccsds.org]> On Behalf Of John Pietras
Sent: 01 June 2011 20:47
To: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>
Subject: [Css-csts] Action Item #02-0511S: Annex E with simplified service state tables

CSTSWG colleagues ---
At the Berlin meeting, I was assigned action item #02-0511S: "JP to provide the revised version of Annex E, describing the approach for flagging the active state of started and acknowledged Prime Procedure to the Association Control Procedure."
 Actually, this action item is slightly misstated. In response to action item #06-1010F, I had devised an approach that eliminated the need to distinguish between state machines of CSTSes with stateful prime procedure instances that are stateful because they employ START and STOP operations vs. being stateful because they use a three-phased (acknowledged) operation.  The technical note describing that approach explained the changes needed in the state tables for the Association Control procedure and the stateful procedures in the CSTSFW. The technical note also identified the changes in the state tables of Annex E (Service State Tables) but did not identify all changes in Annex E (that is, the changes in the text of Annex E). Action item 02-0511S was to provide the complete update to Annex E.

The resulting update to Annex E has been uploaded to the CCSDS CSTSWG CWE Red-1 Framework Review May.2011 folder at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/Red-1%20Framework%20Review%20May.2011/SimplifiedStatefulAnnexE.zip

The zip file contains two documents. The Word document "921x1r2[Draft 201012]-stateful-110601.doc" is a marked-up version of the December 2010 Red book with Annex E updated. The PDF file "921x1r2[Draft 201012]-Annex_E-clean.pdf" is a final printing of Annex E with all changes accepted.

I believe that the revised Annex E is complete, with one exception: the state tables for the stateless and stateful services use the incoming event 'not authenticated PDU', the reference for which is given as section 3.2.3.6. I believe that the definition of this event and the composition of 3.2.3.6 may have been altered based on our discussions of valid/invalid PDUs and how and when they are detected. The final agreed-to rewording of those sections need to be examined and the reference of the 'not authenticated PDU' incoming events adjusted accordingly. In any case, the reference to that event needs to be made more complete - currently it just displays "a)".

Best regards,
John

================

GST IT DEPARMENT

================

WARNING

Please, dont open pdf files from unknown source.

Adobe confirms PDF zero-day attacks. Disable JavaScript now.

http://blogs.zdnet.com/security/?pQ19&tag=.e589
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110905/c67f3511/attachment-0001.htm