Comments from Simplified PROCESS-DATA Exercise John Pietras CSTSWG Berlin May, 2011

CSTSWG2 Purpose The response to Action Item # F and RID NASA-JVP-47 included a specific restructuring of the PROCESS-DATA operation and Data Processing procedure Although the proposed restructuring itself is being deferred pending further analysis, the exercise revealed some technical omissions and inconsistencies that should be addressed even if the PROCESS-DATA operation and Data Processing procedure are not restructured The following pages identify (in order of technical fact to suggested changes) –Technical corrections in the PROCESS-DATA operation, Data Processing procedure, and/or other operations and procedures –Apparently-incorrect type castings –Inconsistent approaches that should be made consistent –Ambiguities between content and format of Activities and detailed Behaviors –Proposed restructuring of operation specification for clarity

CSTSWG3 Technical Corrections (1 of 3) In the notification-type extension table (4-48) for the Notification procedure should be changed from a single row “event-names and event-value” to two rows, “event-name” and “event-value” to be consistent with the definition in the notification-type Extension paragraph ASN.1 diagnostic parameter extension sections should use “diagnostics” in the path, not “Diagnostics” –Throughout D2.5, the path to the diagnostics parameter is written as: (StandardReturnHeader):result:negative:Diagnostics: extensionDiagnostics –However, “Diagnostics” is the type, not the parameter. These statements should read (StandardReturnHeader):result:negative:diagnostics: extensionDiagnostics –This occurs throughout the ASN.1 and should be changed throughout ASN.1 for PROCESS-DATA negative return incorrectly characterized as a “sequence” composed of diagnostic extension syntax and extension parameter syntax –Should be rephrased as something like “negative data return both adds a parameter and adds diagnostic parameter values”

CSTSWG4 Technical Corrections (2 of 3) Section : “… the Service Provider shall begin processing as soon as possible” –“As soon as possible” is vague –Believe that actual condition is “as soon as both (a) the production process is or becomes operational and (b) no other data unit that was transferred earlier than this data unit is still awaiting start of processing” Section : “the sequence number shall be used as a reference to the data unit in any future reports sent by the Service Provider to the Service User” –This phrase is not normative for Transfer and Buffering of Data Units behavior It’s in the note that follows this requirement –It is normative for the Feedback behavior ( ) and should be included there Section : “The ‘active.locked’ state shall be a substate of the ‘active’ state” is a definition, not a behavior specification –Perhaps change to read “The Service Provider shall enter the ‘active.locked’ substate of the ‘active’ state if one of the following events occurs (see ‎ ):” if it important to establish this relationship

CSTSWG5 Technical Corrections (3 of 3) : states –“To recover from the ‘active.locked’ state, the Service User may issue a STOP invocation (see 3.8), and then (if and when the Service Provider’s Production Status is no longer ‘interrupted’ or ‘halted’) issue a START invocation; or issue an EXECUTE-DIRECTIVE for clearing the buffer and returning to ‘active.processing’ (see ).” – This is not normative behavior of the procedure. It should be turned into a Note The actual normative statements are made in 3.8 and : Adds an extension diagnostic “provider state is locked” –However, reason (3) for the PROCESS-DATA ‘unable to process’ diagnostic is because the Service Provider is locked –If the extension diagnostic is to supersede ‘unable to process’ due to reason 3, a Note should be included to that effect in : “NOTIFICATION invocation” should be “NOTIFY invocation”

CSTSWG6 Apparently-Incorrect Type Castings In the ASN.1, diagnostic parameter extensions (extensionDiagnostic) should be Embedded, not Extended, Type –The diagnostic should never have a possible null value, which the Extended type would allow but Embedded would not –This occurs throughout the ASN.1 and should be changed throughout In the ASN.1, notification-type parameter extensions (notificationExtension and notificationTypeExtension) should be Embedded, not Extended, Type –The notification-type should never have a possible null value, which the Extended type would allow but Embedded would not –This occurs throughout the ASN.1 and should be changed throughout

CSTSWG7 Inconsistent Approaches (1 of 2) The extension syntaxes should be identified for the operations as well as for the procedures –The CSTSWG had previously determined that it is useful to identify the corresponding extension syntaxes in the derived operations for the procedures. That approach should be extended to include the base operation themselves –This should apply to the syntax of the invocation, returns, and acknowledgements (as appropriate) of the operations and also to any diagnostic values that are added by the operations notification-type extension tables but no diagnostic extension tables –New notification-type extension tables have been added to the Buffered Data Delivery, Data Processing, and Notification procedure NOTIFY operation definitions –If it is deemed useful to have tables of notification-type extension values, shouldn’t there also be tables for the diagnostic parameter extension values?

CSTSWG8 Inconsistent Approaches (2 of 2) Multiple returns do not address lack of extension parameters –Common START negative return –Common STOP negative return –Common EXECUTE-DIRECTIVE negative return and negative acknowledgement –Common GET negative return –Cyclic Report START negative return –Throw Event EXECUTE-DIRECTIVE negative return and negative acknowledgement –Data Processing PROCESS-DATA negative return –Notification START negative return Multiple negative returns do not address lack of diagnostic extension parameters –Throw Event EXECUTE-DIRECTIVE negative acknowledgement –Data Processing START negative return –Data Processing STOP negative return –Notification STOP negative return

CSTSWG9 Ambiguities between Content and Format of Activities and Detailed Behaviors (1 of 2) What is (or should be) the difference between the intent of the Activities subsection and the following subsections of the Behavior section? –Multiple cases where the Starting behavior is a simple reference to the “The Service User shall invoke the START operation …” statement of the Activities subsection –Propose that the Activities sections be used to describe which party (User or Provider) invokes each operation of the procedure, and use the Starting, Transferring Data, etc., subsections to define the behavior of the procedure The Activities sections of the Behavior for the procedures do not always address all operations –Propose that the Activities section touch on each operation, and in particular which party (User or Provider) invokes the operation –Propose that the Activities paragraphs address all major “purposes” of the operation at some abstract level For example, in the case of the Data Processing procedure, the User invokes the START operation to prepare the Provider to receive data units, but it also tells the Provider the sequence number to expect in the first PROCESS-DATA invocation

CSTSWG10 Ambiguities between Content and Format of Activities and Detailed Behaviors (2 of 2) The Starting sections of the Behavior for the procedures often simply just reference the START operation paragraph of the Activities section –There is usually more behavior that must be specified for the START operation than is summarized in the single START paragraph of the Activities section. E.g., typically, the START causes the procedure to transition to the ‘active’ (or in the case of the Data Processing procedure, ‘active.processing’) state, and this should be specified under the Starting section. Similarly, the performance of any operation that results in a state transition should be explicitly stated, but this is not always the case. E.g., for the Data Processing procedure, the transition to the ‘inactive’ state needs to be defined as part of the Stopping behavior

CSTSWG11 Proposed Restructuring of Operation Specifications for Clarity (1 of 3) The appearance of the diagnostic parameter section in the middle of the extension parameters is potentially confusion –The general form of the INVOCATION, RETURN AND PARAMETERS sections for confirmed operations is to first provide the table of operation parameters (which always starts with Standard Operation Header (confirmed) (SOH)), followed by sections for the SOH, then diagnostic, then each of the extension parameters listed in the table, all at the same numbering level –The problem with this order is that, contrary to the impression given by the way that it is presented, the diagnostic parameter is not an extension parameter of the operation –Propose that the invocation and return (and acknowledgement, if applicable) parameters be defined first in an “Operation Parameter Definitions” section, followed by a “diagnostic Parameter Extension” section at the same level –See example for PROCESS-DATA operation in “simplified” package. Many General sections for the derived operations of procedures merely state that the Service User “uses” the operations and references their base definitions in section 3 –This is misleading because the whole purpose of the derived operation section is that the operation is somehow derived and is not used as defined in section 3 –Propose rewording to the effect that “the procedure extends and/or refines the XXX operation as defined in 3.YYY by adding parameters to the invocation, adding diagnostic parameters, etc. E.g., “This procedure extends the START operation defined in ‎3.7.2 through the addition of a parameter to the invocation.“

CSTSWG12 Proposed Restructuring of Operation Specifications for Clarity (2 of 3) In deriving operations for procedures, the mixing of additional parameters with additional diagnostic and notification-type values is confusing. Proposed restructuring (see simplified Data Processing procedure for example): –After the General section, the “Invocation [and Return [and Acknowledgement]] Extension Parameters” section This is a slight rewording of the current “Invocation [, Return [, Acknowledgement]] and Parameters” section title, in recognition that it doesn’t name all of the parameters of the operation but only the extension (i.e., additional ones) It’s also consistent with the title of the parameters tables that are include in these sections For each syntax that’s defined for the additional parameters for the invocation, positive return, negative return, positive acknowledgement, and/or negative acknowledgement for the operation, a separate subsection/paragraph is included under the Invocation […] Extension Parameters section The definitions of the extension parameters are included under the Invocation […] Extension Parameters section –If additional values are defined for the diagnostic parameter (for confirmed operations), a section “diagnostic Parameter Extension” is included at the same level as the Invocation […] Extension Parameters section This section has a “diagnostic parameter extension values syntax” subsection and a “diagnostic parameter extension values definition”

CSTSWG13 Proposed Restructuring of Operation Specifications for Clarity (3 of 3) Proposed restructuring (concluded) –For derived NOTIFY operations, if additional values are defined for the notification-type parameter, a section “notification-type Parameter Extension” is included at the same level as the Invocation […] Extension Parameters section This section has a “notification-type parameter extension syntax” subsection and a “notification-type parameter extension definition” subsection –If any previously-defined parameter is refined by the procedure, a section “xxx Parameter Refinement” is included at the same level as the Invocation […] Extension Parameters section Note that this section only needs to define the refinement, since no additional syntax is formally defined