[Css-csts] Parameter Names and Published Identifiers
- Notification procedure
Sylvain Gully
Sylvain.Gully at dlr.de
Wed Dec 7 05:35:06 EST 2011
Hello Yves,
I agree with the changes to the NOTIFICATION procedure, and the need of
rewording the NOTIFY operation.
I have but a little question (to you or John). In the case of a name
event list having a functional ressource defined, should the event names
contained in that name event list have the possibility to have a
different functional ressource (also different from the one of their
name event list). I try to explain that in the following example:
- The name event list "MyList" has a defined functional ressource
"/S-Band/DownlinkCarrier" (I mean the corresponding OID)
- Is it possible for a name event contained in that list to have another
functional ressource: e.g. name event "TrackingAlert" with functional
ressource "/S-Band/DownlinkCarrier/TrackingReceiver" ?
regards,
Sylvain
Yves.Doat at esa.int schrieb:
> 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
>
--
Deutsches Zentrum für Luft- und Raumfahrt e.V.
Raumflugbetrieb und Astronautentraining
Kommunikation und Bodenstationen
Oberpfaffenhofen
82234 Weßling
Tel. +49 (8153) 28-2142
Fax +49 (8153) 28-1456
e-mail Sylvain.Gully at dlr.de
More information about the Css-csts
mailing list