[Css-csts] CSTS - NOTIFY operation changes - Object Identifiersupdates

[John Pietras]

Yves,

I haven't reviewed the complete set of updates, but I think that there
is a flaw in the updated NOTIFY specification that may propagate through
the other sections.

 

Previously, the NOTIFY operation had the notification-type parameter,
which was defined (for the base operation) as a choice of
productionConfigured, productionInterrupted, productionHalted,
productionOperational, or notificationExtended, all of which were
defined as of type Extended. The Notification procedure extended the
notificationExtended choice with two parameters, event-name and
event-value, where both were defined as of type VisibleString.

 

In the update, you intended to bring the Notification procedure extended
definition into the base NOTIFY operation (which resulted in no
extension in the Notification procedure). However, in doing so, the
event-value has been lost in the text specification. Yet event-value is
in the ASN.1, but it is listed as a choice:

NotificationTypes ::= CHOICE

{ eventName ParamEventOrListName

, eventValue VisibleString

, notificationTypeExtension Extended

}

 

The intent was that (at least in the Notification procedures) eventName
and eventValue be both present, not one or the other. The above ASN.1
also allows the possibility to define notification types that have names
that are not structured suing OIDs. 

 

I've been trying to think of some ways to correct this, but there are
questions that I don't know the answers to:

1)      Do we want to make the event -value parameter a part of the base
NOTIFY operation?

2)      Do we want to require that event-names always be structures as
OIDs?

3)      Do we want to allow the extended values of notification type
replace on the name syntax, or the name/value constructions?

 

For example, the following allows the base notification type to consist
of an event-name and event-value pair, but allows procedures to derive
completely different constructions of notification-type.

 

NotificationTypes ::= CHOICE

{ notificationType ::= SEQUENCE

  {  eventName ParamEventOrListName

   , eventValue VisibleString

  }

, notificationTypeExtension Extended

}

 

For example, the following allows the base notification type to consist
of an event-name and event-value pair, but allows procedures to derive
completely different constructions of notification-type. The parameter
of the NOTIFY operation would be notification-type, defined as having
two components, event-name and event-value. But by extending the
notificationTypeExtension choice, a derived procedure could replace both
the event-name and event-value parameters with a new set of parameters.

 

NotificationTypes ::= CHOICE

{ notificationType ::= SEQUENCE

  {  eventName ParamEventOrListName

   , eventValue VisibleString

  }

, notificationTypeExtension Extended

}

 

Another possibility would be to let the base NOTIFY operation have
explicit event-name and event-value parameters, each of which could be
replaced by extension. This would, for example, allow a vector-valued
event value to be used in a derived procedure.

 

EventName ::= CHOICE

{ eventName ParamEventOrListName

, eventNameExtension Extended

}

 

EventValue ::= CHOICE

{ eventValue VisibleString

, eventValueExtension Extended

}

 

Without knowing what the ultimate intent is, I can't make a specific
recommendation.

 

Best regards,

John

 

From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of
Yves.Doat at esa.int
Sent: Monday, December 19, 2011 2:40 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] CSTS - NOTIFY operation changes - Object
Identifiersupdates

 

Dear all, 

A agreed I performed the following changes in the Framework: 

*	NOTIFY operation: The notification-type definition has been
changed from a choice of events to the structure agreed in the
Notification procedure: event-name and event-value. The event-name is
constructed with a functional resource and an event identifier.
	See attached file: "NOTIFY Operation.pdf" 
*	 
*	As a consequence of the NOTIFY operation changes the Buferred
Data Delivery procedure has been changed as follows:
	- The NOTIFY operation  is not extended anymore but refined to
allow the addition of procedure events
	See attached file: "Buffered Data Delivery with new NOTIFY.pdf" 
*	 
*	As a consequence of the NOTIFY operation changes the
Notification procedure has been changed as follows:
	- The NOTIFY operation is used as is without any extension and
refinement
	See attached file: "Notification procedure with new NOTIFY.pdf" 
*	 
*	The Object Identifiers definition (Annex C) has been updated as
follows: 

	*	A new Framework OID branch has been added for the
Framework events. That branch includes the 4 NOTIFY operation events.
(See Annex C and Annex J, Figure J-2) 
	*	A new CSTS branch has been added for the Functional
Resources OID and for the Parameters OID definitions See Annex J, Figure
J-1). 
		The Functional Resources OID has been further expanded
with 1 OID per Agency. This is done in order to reflect our Boulder
discussion where each Agency will have its own functional resources (We
agreed not to embark on standardisation of functional resources and let
each Agency defines its own). (See Annex C and Annex J, Figure J-4)
		The parameters OID bracnh has been added to cover the
parameters definition that are currently under discussion for the
monitoring service (See Annex J, Figure J-4).

See attached file: "Annexes C and J- Object identifiers.pdf" 



I will now check the ASN.1 syntax and upload the new version of the book
to the CWE before the end of the week. 

Please let me have 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/ <http://www.esa.int/> 
__________________________________________________

 
===============================================
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/?p=5119&tag=nl.e589
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20111220/314d3c16/attachment.htm