Subject: Re: V16 Review - Auditing contexts and their terminations

From: Chuong Nguyen <[email-masked]>
Date: Sat, 1 Apr 2000 14:09:07 -0600

With the proposed solution, does this make contextAudit a new command?
If yes, it should follow other commands request and response/reply
syntax.
That is the command is included in the transaction reply.
Transaction = 1 {Context = 3 {command ...}}
Reply = 1 {Context = 3 {command ..}}

See comments below.

Chuong

Nancy-M Greene wrote:

>
>
> Here are 2 issues with the ABNF that have come up on our review of
> section 7.2.5 AuditValue:
>
> 1) 7.2.5 Audit Value - auditing all matching terminations and their
> contexts
>
> Issue: The entry before the last in table we have
> "ContextID=ALL  , TerminationID= wildcard, Audit of all matching
> terminations and contexts to which they are associated."
>
> Comment: In the ABNF, the reply reads like this:
> AuditValue = contextID { t1,t2,...}
> We can't report all the contexts in this reply.
> The ABNF must be fixed to allow returning list of contexts
> rather than just one with a list of terminations.
>

Doesn't the text say something about repeating a command for each
matching wildcard found.
That is keep use AuditValue to do context and termination relationship
audit.

Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}

(Have to add a ContextAuditToken to auditItem in ABNF first)

Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
                   Context = 2 {AuditValue =
contextAudit{t3,t4}}.......}

or go with the Nancy's proposed solution but make contextAudit a new
command.

>
> 2) 7.2.5 Audit Value - return all context ids
>
> Issue: The last entry in the table is:
> ContextID=All, TerminationID=Root, list of all contextIDs,
>
> Comment: The ABNF does not allow a list of contextIDs
> returned on the audit. This has to be fixed to allow list of
> contexts.
>
> Also, we need to check whether the ASN.1 handles these 2 cases
> correctly.
>
> Proposal: A proposal for solving these 2 issues in the ABNF:
>
> Auditing a context does not belong to any particular command. So it
> should stay out of AuditRequest. We already have a contextAudit in the
>
> ABNF, so we should use it instead.
>
> Case 1: List of all contexts and all terminations:
> Request: Context = ALL {ContextAudit{Terminations}, othercommands
> ....}
> Reply: Context=All {Root { Cid1 { t1,t2,3....}, Cid2 { ....}}, other
> replies}
> ; Terminations will be a new token added to contextAuditProperties
> ; and we will need RootDescriptor (list of lists as above)
>

Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
                    Context = 2 {ContextAudit = {t3,t4},
                   Context = maxContext {ContextAudit = t4r4,t3434},
                  Context = 2 {other command reply...}, etc }

Assuming ContextAudit is classified as a new command.

>
> Case 2: All terminations and a specific context
> Request: Context=Cid {ContextAudit{Terminations}, othercommands ...}
> Reply: Context=Cid { Terminations { t1,2,t3, ...}, other replies}
> ; same as above but with TerminationsDescriptor this time (list of
> ; terminations
>

Reply:  Context=Cid {ContextAudit = {t1, t2, ...}}

>
> Case 3: All contexts, no terminations
> Request: Context=Cid or ALL {ContextAudit{Root}, othercommands ...}
> Reply: Context=Cid or ALL { Contexts { cid1,cid2,cid3, ...}, other
> replies}
> ; RootToken, ContextsToken and ContextsDescriptor.
>

Reply:  Context = cid1, Context= cid2, .....

The transaction might get too large but it seems to follow other
commands convention for
a transaction reply.

>
> This way we avoid falling into explaining AuditValue or
> AuditCapability
> for context audit and at the same time, auditing context at the
> context
> level. Also, remove contextTerminationsAudit from auditReply.
>
> Comments?
>
> Nancy
> Abdallah
>
>
> -------------------------------------------------------------------------
>
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 4 Apr 2000 08:18:44 -0400

Chuong,

See comments below.

Abdallah

> Reply = 1 {Context = 3 {command ..}}

Context audit is a special command-property operation which needs
special handling just as other contextAuditProperties. Auditing
terminations and contexts were split at the context and the
command-descriptor levels, my proposal would make it happen at
one place which is the context. This is the way it should have been
done in the first place.

You approach adds another level of parsing when you consider
contextAudit and you wont know whether you are parsing a list
or a list of lists till you advance. I try to stay away from those
and simplify parsing to one look ahead symbol as much as I could.

Also, I rather not populate the reply transaction with all audit
contexts.
My approach is much easier to read and follow. You know what the
audit is about, whether terminations, contexts or root; no need for
deep parsing to figure it out. Also it is similar to contextProperties
and contextAuditProperties.

<snip>

> or go with the Nancy's proposed solution but make contextAudit a new

It is property type of command similar to topology. It is fine the way
it
is, IMO.

> Assuming ContextAudit is classified as a new command.

It does not look good and a bit confusing having more contexts in the
reply than the request.

> The transaction might get too large but it seems to follow other

Let us try to simplify not complicate things.

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 4 Apr 2000 08:43:42 -0500

Abdallah
Thanks for the reply.

It doesn't really matter to me what the approach is as long as it is
clearly documented somewhere
and agreed/understood by Megaco implementors.

Your approach about not repeating context seems contrary to previous
discussion on how to
handle wildcard command.

Transaction = 1 {Context = * {AuditValue = *{Audit{Media}}}}

What is the expected Reply?  The following or something else
Reply = 1 {Context = 1 {AuditValue = t1, t2 {Audit{...}}},
                   Context = 2 {AuditValue = t3,t4 {Audit{...}}},
                   ... , Context = n {...}}

Thanks
Chuong

Abdallah Rayhan wrote:

>> That is keep use AuditValue to do context and termination
>> relationship audit.
>>
>> > Reply: Context=All {Root { Cid1 { t1,t2,3....}, Cid2 { ....}},
>> > other replies}

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 4 Apr 2000 17:01:08 -0400

Chuong,

I think you are confusing context auditing with terminations
which is why we have this proposal; we want to separate these
two concepts. Termination auditing occurs at the
termination level with Audit descriptor while context
audit either reports contexts and/or terminations, and
not auditing the terminations at the same time. The latter
is possible, however, it is performed at the command
level not the context .

Let me try to explain the cases we have and how that
translates in terms of transactions and replies.

Case 1: List of all contexts and all terminations:
Request:
Transaction = tid { Context = * {ContextAudit{Terminations}}}
Reply:
Reply = tid { Context=* {Root { Cid1 { t1,t2,t3....}, Cid2 { ....}}}}

Notice that we dont have to repeat "context=cid". If there are other
contexts in the reply, they each have unique ids.

Case 2: All terminations in a specific context
Request:
Transaction=tid { Context=Cid {ContextAudit{Terminations}}}
Reply:
Reply = tid { Context=Cid { Terminations { t1,2,t3, ...}}}

Again, if the request has other commands for the context cid,
the reply commands would come after ContextAudit{Terminations{ ....}}.
This includes AuditValue which could have a wildcard.

Case 3: All contexts, no terminations
Request:
Transaction = tid { Context=* {ContextAudit{Root}}}
Reply:
Reply =tid { Context= * { Contexts { cid1,cid2,cid3, ...}}}

Case 4: Perform case 1 in addition to terminationaudit
This case should be discouraged, IMO, my 2 cents,
because of the  size of the reply. Instead, the MGC
should use AuditValue with a specific  terminationId
instead of with a wildcard.
Request:
Transaction = tid { Context = * {ContextAudit{Terminations},
                                                   AuditValue = * { ....
} }}
Reply:
Reply = tid { Context=* {Root { Cid1 { t1,t2,3....}, Cid2 { ....}}},
                   Context = 1 { AuditValue = tid11 { ....}, AuditValue
= tid12 { .....} },
                   Context = 2 { AuditValue = tid21 { ....}, AuditValue
= tid22 { .....} },
                   .......}

One thing to remember when you audit the context you dont need to audit
the termination using the same command. I believe separating the
two is important.

Abdallah