[Css-csts] Parameter Names and Published Identifiers
- Notification procedure
Yves.Doat at esa.int
Yves.Doat at esa.int
Mon Dec 12 03:06:40 EST 2011
Dear John,
Thank you for your comments.
Here are my answers
I agree with you and I updated the text of the 3 procedures.
I rephrased the sentence.
You are right and I updated the requirement.
You are right and I did not point to that change.
Before Boulder, the definition allowed to have one text (sor of summary
text) for a list of events.
With the new definition one can have a text for each reported event. With
the new definition we loose this "sort of" summary text.
I also do not have a problem with that. If someone has a problem, please
let me know.
As stated in my previous email, The NOTIFY operation offers a CHOICE for
selecting an event, while the Notification procedure offers the
combination of F.R. and event identifier. The 2 definition are not
compatible and I propose to rework the NOTIFY operation such as it uses a
similar structure as proposed in the Notification procedure. When working
on the NOTIFY procedure, I will consider if your proposal is valid.
Best regards
Yves
From:
"John Pietras" <john.pietras at gst.com>
To:
<Yves.Doat at esa.int>
Cc:
css-csts at mailman.ccsds.org
Date:
07/12/2011 21:41
Subject:
RE: [Css-csts] Parameter Names and Published Identifiers - Notification
procedure
Sent by:
css-csts-bounces at mailman.ccsds.org
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]
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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20111212/77c9bba6/attachment.html
More information about the Css-csts
mailing list