[Css-csts] Issues regarding the new Notification procedure

[John Pietras]

Members of the CSTSWG --
In Heppenheim, the decision was made to create a Notification procedure
that could have the events to be notified specified in the START
operation for that procedure. The Monitored Data service would use a
separate instance of the Notification procedure instead of having the
NOTIFY operation embedded in the Monitor Cyclic Report Procedure. In
attempting to develop the definition of the Notification procedure, some
issues have arisen. I believe that I missed some of the discussion on
this topic, so I may not understand all of the CSTSWG's intentions and
motivations for creating this procedure. Let me try to explain these
issues.

1. In the SLE transfer services, some form of NOTIFY operation has
always been mandatory. Is creating a separate Notification operation
procedure intended to make notifications now optional for CSTSs, or does
every service still have to have a NOTIFY capability?

2. If every CSTS will still be required to have a NOTIFY capability (to
report on production status at a minimum, for example), will that NOTIFY
always have to be implemented via the NOTIFICATION operation, or can a
NOTIFY operation still be used to extend another procedure? [NOTE - if
every CSTS is expected to have some form of NOTIFY capability, that
needs to be added to the Guidelines.]

3. If every NOTIFY has to be implemented via the new Notification
operation, then CSTSs that use the NOTIFY only to report the occurrence
of the standard (non-extension) events will have more operational
overhead than the existing SLE services - that is, the requirement to
START and STOP the Notification procedure is more than is required today
for SLE services, in which the NOTIFY is automatically enabled as soon
as the service is bound. 

4. If the NOTIFY operation can still be implemented in a CSTS by
extending another procedure by adding a NOTIFY to it, should it be
possible to have both a NOTIFY-extended procedure and a Notification
procedure in the same CSTS? In such an instance, the NOTIFY in the
extended operation and the NOTIFY in the Notification procedure would
both report the standard baseline events, but only the Notification
procedure NOTIFY would report the events identified in the Notification
START operation. 

4A. A CSTS could be defined such that the NOTIFY in an extended
procedure could report on more than the standard baseline events, but
those events would have to be identified either as part of the service
definition or as part of the Service Management configuration of that
CSTS. This mode would allow a NOTIFY to be statically configured for the
duration of the service instance.

4B. A single CSTS instance could have multiple instances of the
Notification procedure. Each instance of the Notification procedure
would report the common baseline events, as well as that procedure's
unique events, as identified in the START operation for that procedure
instance. Is there any reason why we would want such a capability? Is
there any reason why we would want to forbid such a capability?

5. Whether the NOTIFY is enabled via a dedicated Notification procedure
or as an extension to another procedure, it will still differ from the
SLE approach to notifications in that for CSTSs notifications are not
automatically enabled upon binding, but must wait for the procedure that
includes the NOTIFY to start. My first thought was that a similar
capability could be provided for a CSTS if the Association procedure for
that CSTS were to be extended with the NOTIFY, but we explicitly forbid
the Association procedure to be extended with additional operations. 

I am asking the members of the CSTSWG for opinions on these issues. If
there is already a consensus, then my understanding it will help can in
defining the Notification procedure. Please feel free to respond by
email, and perhaps we can discuss these issues a bit at next week's
CSTSWG telecon.

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970