[Css-csts] Parameter Names and Published Identifiers -
Notification procedure
John Pietras
john.pietras at gst.com
Wed Dec 7 15:41:28 EST 2011
Yves,
Here are my comments on the proposed updates to the Notification procedure:
1. In reading the first 2 sentences of the second paragraph under the Concept section, I realized that I still did not get it quite right in the Information Query and Cyclic Report sections, and since the revised Notification section follows that same style it has the same problem. The short explanation of the problem is that I used the name of the operation parameter in the first sentence, and then the second sentence appears to define that parameter (but it doesn’t, exactly). I think (hope) that replacing the first two sentences of the respective Concept sections with the following single sentences fixes the problem:
Information Query: “The set of queriable parameters for a CSTS are identified by the parameter names of individual queriable parameters and/or parameter list names of lists of queriable parameters for that service.”
Cyclic Report: “The set of reportable parameters for a CSTS are identified by the parameter names of individual reportable parameters and/or parameter list names of lists of reportable parameters for that service .”
Notification: “The set of notifiable events for a CSTS are identified by the event names of individual notifiable events and/or event list names of lists of notifiable events for that service.”
2. The second to last sentence in the second paragraph under the Notification Concept section should read “The default list has no identifier, and it is automatically subscribed when no event names or list name are explicitly specified.” (instead of “… when no event names or list identifiers are explicitly specified.”)
3. Section 4.10.4.1.2.2.4 used to read “A derived service may define additional individual notifiable events. For each additional individual notifiable parameter, a string-valued published identifier, and the type and range of the event value (see 4.10.4.2.2.2) shall be defined.”
It now reads “A derived service may define additional individual notifiable events. For each additional individual notifiable parameter, an event name, and possible associated extension shall be defined.”
a. I agree with the change of “string-valued published identifier” to “event name”.
b. I think that “the type and range of the event value” should not have been deleted. Since the event value is part of every event notification, if new events are added by a service then the event value associated with that new event must be defined.
c. I’m not sure what “possible associated extension” refers to. If it the fact that every set of extension parameters can be further extended, we agreed that this is inherent in all extension parameters (unless explicitly prohibited by the service specification) and should not be called out in individual cases.
4. In the Common Types ASN.1 module, the ListOfNamesDiagnosticsExt now defines the unknownNames choices as
SEQUENCE OF
{ text AdditionalText
, name ParamEventOrListName
}
Before Boulder, this unklnownNames choice was defined as (doing a direct type substitution for the UnknownNames type)
SEQUENCE
{ text AdditionalText
, name SEQUENCE OF VisibleString
}
In other words, before Boulder, there was one text (AdditionalText) for the whole list of unknownNames. Now there is one text (AdditionalText) for *each* name in the list. I don’t have a problem with the new approach, but I just want to point out that it is different from what it was before in case there was a reason to have the text component refer to the list as a whole. The same comments apply the the CyclicReportStartDiagnosticsExt type in the Cyclic report PDUs ASN.1 module.
5. In the NotifyInvocation type in the Common Operations PDUs ASN.1 module, the notificationType parameter of type NotifiicationType, which is defined in the Common Types ASN.1 module as an extensible choice of productionConfigured/Interrupted/Halted/Operational, each of which is of type Extended. The Notification PDUs ASN.1 module appears to be attempting to define event-name (i.e., dual obkject identifier) forms of these standard notifications as extensions, so that there will in effect be two choices for representing each standard event notification; e.g., productionConfigured of type Extended (in the base NOTIFY operation) and nProductionConfigured for the Notification procedure. There should only be one possible choice for each, derived from their base types as defined for the NOTIFY operation. Although it is somewhat ugly, the Notification PDUs ASN.1 module should define extensions for each of the standard NotificationTypes, e.g., something like
NotificationNotifyNotificationTypeProductionConfiguredExt ::= SEQUENCE
{ functionalResource CHOICE
{ resourceIdNotApplicable [1] NULL
}
, nProductionConfigured OBJECT IDENTIFIER ::= {nevents 1}
}
NotificationNotifyNotificationTypeProductionInterruptedExt ::= SEQUENCE
{ functionalResource CHOICE
{ resourceIdNotApplicable [1] NULL
}
, nProductionInterrupted OBJECT IDENTIFIER ::= {nevents 2}
}
.
.
.
FunctionalResourceQualifier ::= CHOICE
{ resourceIdApplicable [0] PublishedIdentifier
, resourceIdNotApplicable [1] NULL
}
(I don’t know if the above is legal ASN.1 for restricting the value of functionalResource to the resourceIdNotApplicable choice, but I hope that it gets the idea across).
Best regards,
John
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Monday, December 05, 2011 2:32 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Parameter Names and Published Identifiers - Notification procedure
Dear John, dear all,
You are right, the possibility to include Functional Resource for the Notification procedure is certainly a better approach.
I updated the text of the Notification procedure to be in line with the other changes including the Functional Resource and the event Id. I also updated the ASN.1 to include the Functional Resource and use the same structure as for the others (ParameterOrListName changed to ParamEventOrListName).
I attach the new Notification procedure with associated ASN.1
The following two points need to be noted:
1. The definition of the notification was such that it would have been possible to use the procedure without extension (i.e. using a visible string allowing private definition). This possibility is not there anymore and I removed the note at the end of section 4.10.4.2.2.2. A service using that procedure has to define the Functional Resources and associated Events
2. I think that with this new definition, we should review the definition of the NOTIFY operation where the selection of events is a simple choice and does not consider Functional resource. Please let me now if you agree and I will rework it.
If you find too many problems and prefer to get the Word file or discuss on the telephone please let me know.
In case the rest of the WG would like to get a summary please let me know and we could organise a 1 hour teleconference.
Best regards
Yves
From:
"John Pietras" <john.pietras at gst.com>
To:
<Yves.Doat at esa.int>
Date:
01/12/2011 16:28
Subject:
RE: [Css-csts] Parameter Names and Published Identifiers - Notification procedure
________________________________
Yves,
I started to respond to the Notification section, and my first reaction was to start changing the “identifiers” to “names”, but I then saw that your intention appears to be that the events are still “identified” by single published identifiers (rather than the pair of identifiers).
I think that events will also be qualified, at least in some cases, so I think that the “names” approach, comparable to the Cyclic Report, is appropriate. For example, if we have a “loss of carrier lock” event, it will have to be qualified (i.e., which carrier?). However, I don’t want to write a long list of recommended changes unless there is agreement on this.
If you agree to the naming of events via a pair of identifiers, I can try to put together a list of proposed changes along those lines.
Best regards,
John
From: John Pietras
Sent: Thursday, December 01, 2011 8:30 AM
To: 'Yves.Doat at esa.int'
Subject: RE: [Css-csts] Parameter Names and Published Identifiers
Yves,
I am on travel, so I apologize for not responding sooner. I realized when I received your message that I neglected to update the Notification procedure last week. I don’t have time this morning to send you comments on the Notification section, but here are my comments on the other sections. I will try to get comments to you on the Notification section by tomorrow.
Best regards,
John
INFORMATION QUERY
- In section 4.4.2.2, in the first sentence of the second paragraph, I suggest italicizing the whole phrase “list of parameters” since that maps to the list-of-parameters parameter of the GET operation.
- Behavior: I did not look at this the last time, because I was concentrating on the name/identifier issues. But looking at it this time, I noticed that the only behavior now listed (since the Activities section has been deleted) is Terminating. That implies that the only behavior that this procedure has is to terminate. The previous version referred to the behavior of the GET operation.
CYCLIC REPORT
- In section 4.7.2.2, in the first sentence of the second paragraph, I suggest italicizing the whole phrase “list of parameters” since that maps to the list-of-parameters parameter of the GET operation.
ASN.1 Common Types
- In the QualifiedParameter type, the first component of the sequence should be “parameterName” instead of “parameterIdentifier” to be consistent with our name/identifier terminology.
- In the ListOfNamesDiagnosticsExt type, I think that the ‘names’ component of unknownNames should be SEQUENCE OF ParameterOrListName.
ASN.1 CYCLIC REPORT PDUs
- In the CyclicReportStartDiagnosticsExt type, I think that the ‘names’ component of unknownNames should be SEQUENCE OF ParameterOrListName.
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int <mailto:Yves.Doat at esa.int> ]
Sent: Monday, November 28, 2011 2:43 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Parameter Names and Published Identifiers
Dear John, dear all
John, thank you very much for your comments. I integrated them in the book.
* GET operation:
- 3 rephrased requirements
- The operation makes use of the new definitions functional resource and parameter identifiers.
*
* Cyclic Report procedure:
- concept updated and naming harmonised.
- ASN.1: 1 definition changed.
- The procedure makes use of the new definitions functional resource and parameter identifiers.
*
* Information Query procedure:
- concept updated and naming harmonised.
- The procedure makes use of the GET operation (no change)
*
* Notification procedure (most impacted procedure):
- The procedure has been updated to make use of the new definitions functional resource and parameter identifiers.
- The event definition was based on string and has been changed to Published Identifiers (Object Identifier based).
- START operation updated.
- NOTIFY operation updated.
- ASN.1 updated (quite some changes)
NOTE: The NOTIFY operation does not identify events using Published Identifiers. The events are selected among a CHOICE in the ASN.1. Let me know if you consider we should harmonise the NOTIFY operation .
You will find attached for each procedure and the GET operation the new text and ASN.1 extracted from the book. Each document is not too long and self-contained. In order to meet the agreed planning, I would appreciate if you could review rapidly each of the pdf file and let me have your comments.
Best regards
Yves
================
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/20111207/9b6be502/attachment.html
More information about the Css-csts
mailing list