Subject: Re: What does AuditCapability of Packages mean? - Update

From: "Derks, Frank" <[email-masked]>
Date: Wed, 6 Oct 1999 13:49:35 +0200

Hi Brian,

since you are already working on the new version, I will pass my findings in
the V10 version of the MEGACP document (draft-ietf-megaco-protocol-04.txt),
until now, on.

- Add "DS0" and "DS1" to the abbreviations section. These are used in 7.1.1

- The second paragraph in 6 ("Connection model") states that "a Termination
sources and/or sinks" one or more media streams". This contradicts 6.2,
which states "a Termination is a logical entity on a MG that sources and/or
sinks" media and/or _control_ streams".

- The second and third paragraphs of 6.2 ("Terminations") and the fourth
paragraph of 6.2.4 ("Termination Properties and Descriptors") lead me to
believe that, until a termination is added to a context, it does not "exist"
and can therefore not be "operated on" until it is added to a context. Is
this the intention? The text is not too explicit about this.

- Section 6.2.4 is titled "Termination Properties and Descriptors". It is,
however, not clear about _what_ such a property is and, from this section,
it would even seem that a property and a descriptor are roughly equivalent.
Probably, the intention is that a property is described by its descriptor.
Words to this effect would make this clearer.

-The sixth paragraph of 6.2.4 would seem to indicate an action that is
entirely "local" to the MG. Is this the case? If so, words to that affect,
would make things clearer.

- The paragraph right after the Descriptor table in 6.2.4, implies (at least
in my reading) that a Termination is "part of" the Media: "within the Media
descriptor there is the Termination State descriptor....". If the
"Termination State descriptor" is alway only associated with the media, then
I can understand its presence in the "Media Descriptor", but it still seems
a bit illogical.

- The first paragraph of section 6.2.5, second sentence, says "A package
(MG)...". Is the intention here that the referred to package is the "MG"
package?

- Sections 7 and 7.2. None of the commands have a ContextID as a parameter.
How does one add a Termination to a specific context?

- Section 7, 4th item in the command list and section 7.2.4. It is not
defined what "atomic" means. Some clarifying text would be in place.

- In sections 7.1.1 and 7.1.2, the wordings "command responder" and "command
initiator" are used. Is this wording because of the fact that all but one
case (the Notify command) the initiator is the MGC?

- The second paragraph in section 7.1.2 starts with "Properties may..". The
three numbered items below that sentence, however,  talk about parameters.
It would seem that again the word "property" is used quite loosely and in
this case its relation to "parameter" is not very clear.

- Sections 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.8, 7.1.9, 7.1.10, 7.1.11, 7.1.13,
7.1.14, 7.1.15 and 7.1.16, don't really specify what the Descriptor looks
like. Is this intentional or is this work that still has to be done? The
specifications in the sections that do have it, seem to be incomplete.

- The second paragraph in section 7.1.8 list "delete" as one of the allowed
values for the mode parameter. This is rather a strange "mode".

- In section 7.1.10 it is stated that the RequestIdentifier is used to
correlate the request with reported events. Why would I want to correlate
the Request, rather than the Termination, with such events?

- The table in section 7.1.10 only has "Action" as a suffix in
"NotifyAction". This is not consistent with the other two actions.

- In the fourth paragraph of section 7.1.10, "Embedded" is spelled with an
uppercase "E". This may lead people to believe that there are both and
"Embedded Signals Descriptor" and a "Signals Descriptor", this is probably
not the intention.

- In section 7.1.11, three types of signals are specified (on/off, timeout,
brief), it would seem that these are not the signals themselves, but the
behaviour of the signals. I.e. properties of signals. What is the intention?

- In section 7.2.1, the first paragraph after the "function prototype", it
is stated that "The TerminationID specifies the termination to be added to
the Context.". I do not see a Context parameter.

- Section 12.1, item 3. I think it would be useful to also state that a
description of the events and their parameters is required.

- Section 12.2. Most of the parameters have a (descriptive?) field called
"Direction". The purpose of this field is not clear and its values are not
explained either. I think that it would be best to bring an example in line
with 12.1: include what is stated there and don't add anything that isn't
there.

- Section 12.2, "3.1.3 Detected Tone List". It is not clear to me what the
intention of the "X" is and I don't see any need for the separator character
"/".

- Section 12.2, "3.2.1 Stream ID". I think the description should say: "Id
of the audio stream on which silence was detected".

- Section 12.2, "3.2.2 Duration". I think the description should say
something along the lines of: "The number of seconds to wait before this
event is reported".

- Section 12.2, "4.1.2 Tone List". It is not clear to me what the intention
of the "X" is and I don't see any need for the separator character "/"

- Section 12.2, "4.1.3 Signal Type". I know this is a matter of taste but
instead of "TO", I would prefer "FOR".

- Section 12.2, "3.2.2 Duration". The unit of the duration is not present

Unfortunately I have not had the time to read through the remainder of the
document, but I will try to do so and let you know what I come up with.

Regards,

Frank

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: 05 October 1999 21:08
To: [email-masked]
Subject: What does AuditCapability of Packages mean?

Megacogans:

I am working on V11, which we expect out at the end of this week.  Very few
substantive changes will be made, most of the changes will be editorial.  I
was asked to clarify what was returned from AuditValue and AuditCapability.
I propose the following wording:

For AuditValue -

The appropriate descriptors, with the current values for
the Termination, are returned from AuditValue.  ObservedEvents returns a
list of events in the EventBuffer
PackagesDescriptor returns a list of packages realized by
the Termination.  DigitMapDescriptor returns the name or
value of the current DigitMap for the Termination.
Statistics returns the current values of all statistics
being kept on the Termination.

For AuditCapability --

The EventsDescriptor returns the list of possible events on
the Termination.  The SignalsDescriptor returns the list of
possible signals which could be applied to the Termination.
StatisticsDescriptor returns the names of the statistics
being kept on the termination.  ObservedEventsDescriptor
returns the names of active events on the termination.
DigitMap and Packages are not legal in AuditCapability.

If someone can think of anything useful auditCapability of DigitMap or
Packages, speak up!

Brian