Subject: Re: MEGACOHGCP10: Clarifications + Editorial corrections/comments

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Sep 1999 10:25:25 -0400

> 1. Topology Descriptor: The position of topology descriptor
> is not clear in the
> document - is it a parameter to a command or is it a context
> property (which is
> not a part of a message) ? In section 7.1.16, it has been
> mentioned that the
> Topology descriptor can be a part of Add or Modify command
> message, but the ABNF
> specification puts it at the level of command list, in fact
> the way ABNF defines
> a topology descriptor can be specified without specifying the
> command message.
Topology is a Context Parameter.  That puts it at the same "level" as a
command in an action, which is what the syntax does.  Yes, you can, and
should be able to change topology of a context without a command.  A command
affects a Termination, a Context parameter affects the entire context.

> 2. Since the Subtract command always returns Statistics in
> the response message,
> the StatisticsDescriptor should be marked as mandatory in the
> response to
> Subtract command (sec 7.2.3).
Probably true, although if you had an error, you wouldn't
get statistics.  I'll probably fix this.

> 3. What is the need of sending StatisticsDescriptor and
> ObservedEventsDescriptor
> in AuditCapabilities Response message ? These descriptors
> describe activity
> rather than a capability.
Statistics would return the list of statistics being kept (not the values).
We haven't defined what observedEvents returns.  One possibility is that it
would return the list of events possible.

Probably need some text.

> 4. What does the profile parameter in ServiceChange
> Descriptor represent ? How
> is to be used by MG / MGC ?
Profiles can define things like what options are implemented, what kinds of
packages are supported, etc.
A profile is defined in some other document.  It has a name and a version.
A knowledgeable MGC could look at profile
and quickly decide if it could serve an MG contacting it.
Profile is not, strictly speaking, required.  There are ways to figure out
what the MG implements without profile.

>
> Editorial corrections/comments:
Thanks for pointing these out.  I will take care of them
in the next revision.
>
> 1. The text in section 6.2.4 says that the table lists *all*
> of the possible
> descriptors, but the table is not complete. The missing
> descriptors being -
> Topology, TerminalState, Stream, Local Control, Local, Remote.
>
> 2. Package Descriptor is missing from the list of descriptors
> that can be sent
> in RequestedInfo Descriptor (sec 7.1.12)
>
> 3. There is no description for 'Packages', 'Observed Events'
> and 'Extension'
> descriptor.
>
> 4. In the package definition (section 12) description, bullet 3 and 4.
> PropertyID to be replaced by ParameterId.
>
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:[email-masked]
> Web    :  http://www.ficon-tech.com
>

---

From: Harpreet Singh Anand <[email-masked]>
Date: Thu, 16 Sep 1999 10:43:34 +0530

> would return the list of events possible.

PackageDescriptor contains the packages supported by the termination and thus
implictly contains information on the statistics being supported by the
termination. Therefore, there is no need of having StatisticsDescriptor.

Similarly ObservedEvents is also not needed as the information regarding the
list of possible events is getting covered in two descriptors - package
descriptors - implicitly gives the list of all possible events that can be
observed and the EventsDescriptor contains the list of events that are actually
being observed for the termination.

> what the MG implements without profile.

Is there a standard of way of defining profiles (say something similar to that
for packages), so that all MGs define their profiles in a consistent manner ? If
not, then the usefulness of the profile would be limited because then the MGC
would not know how to interpret the profile info and would use the audit to know
about MG capability.

Regards,
Harpreet