[Css-csts] A few more comments on the Framework

John Pietras john.pietras at gst.com
Mon Aug 17 11:55:31 EDT 2009


Yves,

Here are a more comments on the CSTSFW:

 

1.	Section 3.9.2 heading should be just INVOCATION AND PARAMETERS for TRANSFER-DATA.
2.	Section 3.11.2 heading should be just INVOCATION AND PARAMETERS for NOTIFY.
3.	In D1.12, “nextension” should be “extension”.
4.	In D2.5, “startDiagnosticnExt” should be “startDiagnosticsExt” in the assignment of the OID for startDiagnosticsExt.
	NOTE – for the other operation extensions, the names are of the form “…DiagnosticExt”, that is, there is no “s” between “Diagnostic” and “Ext”. Perhaps the same should apply to the START operation.
5.	In section 4.5.3.1.1, the sentence should read “Table 4‑9 shows the [use of the ?] extension parameters of the START operation defined by this procedure.” (see below for comment on “use of the”.
6.	Inconsistent title for sections that specify extensions of notification-type. The variations are “Extension notification-types values”, “Extension notification-type”, and “Notification-type extension”. What should it be?
7.	The various specifications of extension parameters for operations use the phrasing “Table XXX shows the use of the extension parameters of the YYY operation defined by this procedure.” I think “use of the” was okay when we had the extension-parameters as an explicit parameter in the tables, but since we’ve decided that the extension mechanism is an artifact of ASN.1, I think these sentences should be of the form “Table XXX shows the extension parameters of the YYY operation defined by this procedure.”
8.	In the ASN.1, dpStartInvocExt, dpProcessDataNegReturnExt, dpNotifyInvocNotifTypeExt, dpNotifyInvocExt, and dpExecDirInvocDirectiveIdExt, all have the same OID: 
	{dpExtProcedureParam 1}.
9.	The names of some of the extension object types are very similar to the names of their associated object identifiers (e.g., StartDiagnosticsExt for the object type name, startDiagnosticsExt for the associated OID name), whereas others have greater differences (e.g., ExecDirectiveINegReturnDiagnosticsExt for the object type name, vs. teExecDirDiagnosticsExt for the associated OID name). These name pairs are recognizable by humans as referring to the same thing, especially because the OID appears right after the object specification in the ASN.1. However, it might be much more difficult to make the connection if they weren’t listed one after the other. Is there any reason not to use the same name for both, differing only in the first letter (upper case for object type name, lower case for OID name)?
10.	The NotificationTypes type concludes with the notificationExtension. Some of the notification-type extension objects also conclude with notificationExtension, but some conclude with extensionNotification. These should all be notificationExtension, or perhaps even notificationTypeExtension. 

 

Best regards,

John

 

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

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


More information about the Css-csts mailing list