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

Wed Dec 21 07:10:26 EST 2011

Dear John,

Once more thank you for your effort.

I worked and cross checked the ASN.1 and found the same problem as you. I
also consider the following definition as incorrect:
NotificationTypes ::= CHOICE
{ eventName ParamEventOrListName
, eventValue VisibleString
, notificationTypeExtension Extended
}
(I simply forgot to replace CHOICE by SEQUENCE)

I replaced it by:
NotificationTypes ::= SEQUENCE
{ eventName ParamEventOrListName
, eventValue VisibleString
, notificationTypeExtension Extended
}
With that definition I have to admit that I force the specifier to define any
new event as an Object Identifier. This OID is completed with a VisibleString
and the Extended.
   The VisibleString allows the procedure/service to send any message in a
   text form;
   The extension allows the procedure/service to define any structure (This
   functionality will be required for the forward services).

=====
I looked at your alternative proposals:
NotificationTypes ::= CHOICE
{ notificationType ::= SEQUENCE
  {  eventName ParamEventOrListName
   , eventValue VisibleString
  }
, notificationTypeExtension Extended
}
This approach forces the procedure/service that needs additional parameter to
use the extension and does not allow the use of event name (including a
functional resource).
From my understanding that structure is not desirable.

The second alternative structures:
EventName ::= CHOICE
{ eventName ParamEventOrListName
, eventNameExtension Extended
}

EventValue ::= CHOICE
{ eventValue VisibleString
, eventValueExtension Extended
}
would again prevent the use of the agreed structured event name and from my
understanding is not desirable.

Please let me know if the replacement of CHOICE by SEQUENCE solves the issue.

I am not sure that I will have time before Christmas to work on the book
again and I will publish it with the above change. Additional changes will be
incorporated into the January 2012 version.
I will send a separate mail pointing to the uploaded file.

I wish you a merry Christmas with your family.

Best regards
Yves

  From:       "John Pietras" <john.pietras at gst.com>                                                                                

  To:         <Yves.Doat at esa.int>, <css-csts at mailman.ccsds.org>                                                                    

  Date:       20/12/2011 18:15                                                                                                     

  Subject:    RE: [Css-csts] CSTS - NOTIFY operation changes - Object     Identifiersupdates                                       

  Sent by:    css-csts-bounces at mailman.ccsds.org                                                                                   

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/
__________________________________________________

===============================================
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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

================================================================================================
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.
=================================================================================================