[Css-csts] RE: Some problems with the NOTIFY operation
Yves.Doat at esa.int
Yves.Doat at esa.int
Sat Sep 8 08:03:15 EDT 2012
Dear John,
I carefully read your mail and I agree with your comments. Here are my
answers with the changes in the book:
Problem 1: Note in 3.10.2.2.3.3
We agreed that the Functional Resource is always required.
The note in 3.10.2.2.3.3 is a left over from a previous approach where I
proposed to have have the Framework events carried without being associated
to any Functional Resource. From our latest discussions and decisions, this
statement is not valid. I will remove the note.
Problem 2: Event-value definition to authorise the 'null' value
Note: I changed your proposal stating that unless otherwise specified, the
event-value shall be 'null'
The requirements are rephrased as follows
3.10.2.2.3.2 This operation shall define the following published events
(event-name):
‘production configured’ — configuration of the production process has been
completed. Unless otherwise specified by the procedure using that
operation, the associated event-value shall contain a null value.
‘production interrupted’ — the production process has stopped because of a
condition that may be temporary. Unless otherwise specified by the
procedure using that operation, the associated event-value shall contain a
null value.
‘production halted’ — the production process has been stopped by
management action. Unless otherwise specified by the procedure using that
operation, the associated event-value shall contain a null value.
‘production operational’ — the production process is ready to process data
and production-status has changed to ‘operational’. Unless otherwise
specified by the procedure using that operation, the associated
event-value shall contain a null value.
4.5.4.2.2.2.1 The value of the notification-type shall be one of the
following:
the types specified by the common NOTIFY operation in 3.10.2.2.3.2; the
notifications specified in the common NOTIFY are discardable;
‘data discarded due to excessive backlog’ (event-name) — some data was
discarded by the Service Provider, either because of timeliness
considerations (real-time mode) or because of recorded buffer overflow
(complete mode);
unless otherwise specified by the service using that procedure, the
associated event-value shall contain a null value;
this notification is discardable;
end of data’ (event-name) — the Service Provider has no more data to send:
the conditions triggering the ‘end of data’ insertion shall be defined
by the derived procedure;
unless otherwise specified by the procedure using that operation, the
associated event-value shall contain a null value;
this notification is non-discardable.
The ASN.1 is adapted as follows:
-- The definition of the Notification types follows the definition in
-- 3.10.2.2.3 and are defined by the Object Identifers
-- productionConfigured, productionInterrupted, productionHalted and
-- productionOperational (see C7).
NotificationTypes ::= SEQUENCE
{ eventName ParamOrEventName
, eventValue CHOICE
{ text [0] VisibleString
, empty [1] NULL
}
, notificationTypeExtension Extended
}
Problem 3: Functional Resource Identifier to be used with the Framework
events
The events defined by the Framework shall be transferred with the Functional
Resource Identifier of the service triggering the events.
We have two places with Framework events: the NOTIFY operation and the BDD
procedure.
In order to cover the cases I added the following 2 requirements:
3.10.2.2.3.4 The events defined by the NOTIFY operation shall be
transferred with the Functional Resource Identifier of the service triggering
the events.
4.5.4.2.2.2.2 The events defined by the Buffered Data Delivery procedure
shall be transferred with the Functional Resource Identifier of the service
triggering the events.
Problem 4: Section 4.8.4.1.2.2.10 attached Note
We agreed that the Functional Resource is always required.
The note is a left over from a previous approach where I proposed to have
have the Framework events carried without being associated to any Functional
Resource. From our latest discussions and decisions, this statement is not
valid. I will remove the note.
I updated the Framework document with the above answers.
Please let me know if the changes answer your comments.
Best regards
Yves
__________________________________________________
Head of the Ground Facilities Infrastructure Section (HSO-ONI)
in the Ground Facilities Operations Division
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288 Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________
From: "John Pietras" <john.pietras at gst.com>
To: <Yves.Doat at esa.int>
Date: 04/09/2012 15:51
Subject: RE: Some problems with the NOTIFY operation
Yves,
In re-reading my notes in preparation for today’s telecon, I realized that
there is a typo in the “problem” bullet #2. Instead of “I suggest that
event-type be made optional”, is should have read “I suggest that event-value
be made optional”. I hope that you were able to determine from the context
that this was a typo and that it did not cause too much confusion.
Talk to you in an few minutes.
Best regards,
John
From: John Pietras
Sent: Friday, August 24, 2012 5:18 PM
To: Yves.Doat at esa.int
Subject: Some problems with the NOTIFY operation
Yves,
I think I’ve come across some problems with the NOTIFY operation as defined
in the July draft of the CSTS SF.
In section 3.10.2.2.3.1, notification-type is defined in as having the
components event-name and event-value.
Section 3.10.2.2.3.2 identifies the four standard events and equates them to
the event-name component of notification-type.
Section 3.10.2.2.3.3 identifies the appropriate published events in C7, and
the NOTE states that unless otherwise specified by the procedure, the
Functional Resource of those events is not applicable.
In section 4.5.4.2.2.2, the Buffered Data Delivery procedure refines the
notification-type by adding two new “values”. There is no mention as to
whether Functional Resource IDs are applicable.
Section 4.8.4.1.2.2.3 (Notification procedure) states that the list-of-events
can contain one of the standard production statuses from C7.
Section 4.8.4.1.2.2.10 states “The event identifiers shall be defined using a
Published Identifier”. This is followed by a NOTE “In case the value of the
Functional Resource is not required, the structure allows to use a ‘null’ in
place of a Published Identifier.”
The applicable ASN.1 is as follows:
(from C7)
-- Events Identifiers
-- NOTIFY Operation events:
productionConfigured OBJECT IDENTIFIER ::= { frameworkEventsId 1 }
productionInterrupted OBJECT IDENTIFIER ::= { frameworkEventsId 2 }
productionHalted OBJECT IDENTIFIER ::= { frameworkEventsId 3 }
productionOperational OBJECT IDENTIFIER ::= { frameworkEventsId 4 }
-- Buffered Data Delivery Procedure events:
dataDiscardedExcessBacklog OBJECT IDENTIFIER ::= { frameworkEventsId 5 }
endOfData OBJECT IDENTIFIER ::= { frameworkEventsId 6 }
(from D3.5, Common Operations PDUs)
NotifyInvocation ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, eventTime Time
, notificationType NotificationTypes
, extensionParameter Extended
}
(from D3.3, Common Types)
-- The definition of the Notification types follows the definition in
-- 3.10.2.2.3 and are defined by the Object Identifers
-- productionConfigured, productionInterrupted, productionHalted and
-- productionOperational (see C7).
NotificationTypes ::= SEQUENCE
{ eventName ParamOrEventName
, eventValue VisibleString
, notificationTypeExtension Extended
}
-- The ParamOrEventName structure is used to identify:
-- 1. The name of a paramter
-- 2. The name of an event
ParamOrEventName ::= SEQUENCE
{ functionalResourceId FunctionalResourceIdentifier
, paramOrEventId PublishedIdentifier
}
Here are the problems as I see them:
1. Although the NOTE in 3.10.2.2.3.3 states that the Functional
Resource is not applicable, the ParamOrEventName type definition makes
no provision for not including the functionalResourceId. The NOTE in
section 4.8.4.1.2.2.10 state that ‘null’ can be used but (a) it is only
a NOTE and therefore informative, not normative, and (b) the
ParamOrEventName type definition doesn’t support this in any case. The
‘null’ option needs to be made explicit in the ParamOrEventName type
definition.
2. The production status change events specified in 3.10.2.2.3.2
and additional BDD events specified in 4.5.4.2.2.2 don’t have any
event-values associated with them, but the specification does not
identify what should go into event-value in this case and neither
3.10.2.2.3.1 nor the NotificationTypes type definition make any
allowance for event-value being optional. I suggest that event-type be
made optional (i.e., allowed to take on a ‘null’ value) and the
definition of each of the parameter status change events in section
3.10.2.2.3.2 and of each of the additional BDD events explicitly state
that they do not have an event-value.
3. The added BDD events clearly don’t have any Functional
Resource components, but that is not mentioned in 4.5.4.2.2.2.
4. Section 4.8.4.1.2.2.10 states “The event identifiers shall be
defined using a Published Identifier”. This is followed by a NOTE “In
case the value of the Functional Resource is not required, the
structure allows to use a ‘null’ in place of a Published Identifier.”
However, as used in the ASN.1, “event identifier” refers to the OID of
the event type itself (e.g., ‘production configured’), so the
“Published Identifier” must refer to that OID. However, the following
NOTE confuses the issue by saying that the Published Identifier can be
replace by a ‘null’. In the context of 4.8.4.1.2.2.10, that sounds like
the event (type) Published Identifier can be nulled out, when in fact
what’s meant is that the Functional resource Type Published Identifier
can be nulled out.
I have already informed Margherita that, unfortunately, the SMWG has also had
to scheduled its next telecon on 5 September, starting at 1630 CEDT. So I
will only be able to participate in the CSTSWG telecon until 1630. However,
if you would like to talk more about any of the comments that I’ve sent in
the past few weeks, I would be available to talk before the current CSTSWG
telecon start time (1600), starting as early as 1400 that day. Perhaps we
could even set up to CSTSWG telecon to start earlier and focus on my comments
before transitioning to the larger agenda at 1600. Let me know if this is a
good idea.
Best regards,
John
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the Css-csts
mailing list