Subject: RE: [Megaco] Auditing the active Contexts

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Sep 2001 07:27:41 -0400

The correct response, I think is:
     Context = 1 {AuditValue = Line/1} 
      Context = 2 {AuditValue = Line/2} 
The particular termination doesn't matter (it's only needed to get the
syntax correct),
and most importantly, you only get one.
 
I rather like the parameter idea.  We can do that with a package, but I
think we need to
keep the ALL/ROOT for backwards compatibility.
 
Brian

-----Original Message-----
From: Dan Linton [mailto:[email-masked]]
Sent: Wednesday, September 05, 2001 6:13 AM
To: megaco
Subject: Re: [Megaco] Auditing the active Contexts

List, 

Any comments on this? 

Thanks, 
Dan 

Dan Linton wrote: 

Hello, 

Section 7.2.5 in the RFC contains a table of ContextID/TerminationID's 
that are allowed with the AuditValue command. Every entry in that table 
makes sense except one: ALL/ROOT (i.e. ContextID = *, 
TerminationID = ROOT). 

I'm evaluating this under the fundamental assumption that commands operate 
on terminations in a context and that ROOT should be treated as if it is in
the 
NULL context (which can also be found in the table mentioned above). So 
NULL/ROOT yields properties on the gateway and ALL/ALL yields a list 
of contexts and the terminations within the context. Why do we even need 
ALL/ROOT? If it is simply to get a list of active contexts (ALL/ALL
effectively 
does that plus more), then I would like to propose a simpler solution. That 
is, disallow ALL/ROOT. Instead, define an ActiveContexts property in the 
Base Root package as a list of ContextIDs. Examples are: 

1)  root/ActiveContexts = {} 

2)  root/ActiveContexts = {1, 2, 8} 

Of course, this would be a readonly property. The ROOT properties are 
returned when the MGC audits NULL/ROOT. If the MGC requires more 
information than that about the active contexts, it should use ALL/ALL. 

--------- 

Shifting gears back to ALL/ROOT. Not only is it a special case that
convolutes 
the implementation, I don't think it works. I cannot come up with an
appropriate 
reply even taking Section 11.1 of the Implementor's Guide into
consideration. 
Each of the examples given here has an issue (documented below). 

1) Action Request: 
      Context = * {AuditValue = ROOT {Audit{}}} 
   Action Replies: 
      Context = 1 {}, 
      Context = 2 {} 

2) Action Request: 
      Context = * {AuditValue = ROOT {Audit{}}} 
   Action Replies: 
      Context = 1 {AuditValue = ROOT}, 
      Context = 2 {AuditValue = ROOT} 

3) Action Request: 
      Context = * {AuditValue = ROOT {Audit{}}} 
   Action Replies: 
      Context = 1 {AuditValue = Line/1, 
                   AuditValue = RTP/1}, 
      Context = 2 {AuditValue = Line/2, 
                   AuditValue = RTP/2} 

In Number 1, the replies violate the current ABNF (missing the Command
Reply). 
Number 2 repeats the same information inside of each Action Reply. However,
the 
larger issue with Number 2 is that ROOT is not in either of the contexts
listed. The 
replies for Number 3 are exactly the same as if ALL/ALL had been used in the

request. 

As it currently stands, I don't think there is a valid way to Reply. So we
at least need 
to fix that. I like adding a property to root as outlined above. However, I
would 
settle for simply disallowing ALL/ROOT (use ALL/ALL instead). 

Thanks, 
Dan

---

From: Dan Linton <[email-masked]>
Date: Wed, 05 Sep 2001 11:13:43 -0400

Brian,

See comments inline.

"Rosen, Brian" wrote:

> The correct response, I think is:     Context = 1 {AuditValue = Line/1}
>       Context = 2 {AuditValue = Line/2}The particular termination doesn't matter (it's only needed
> to get the syntax correct),and most importantly, you only get one.

Why only one? It's almost like we are 'replacing' ROOT versus 'expanding' it as we
would do if we had received * instead of ROOT. Perhaps more important than that
is how does an implementor know to do this versus something else? And if we need
a note in the IG, I would rather have it say that ALL/ROOT should not be used.

> I rather like the parameter idea.  We can do that with a package, but I think we need tokeep the
> ALL/ROOT for backwards compatibility.

Don't we potentially already have a backwards compatibility issue for those that have
implemented it differently than what you've shown above? We should probably ask if
anyone has implemented ALL/ROOT and if so, what does their reply look like.

Thanks,
Dan

>     > on terminations in a context and that ROOT should be treated as if it is in the
>     > ALL/ROOT? If it is simply to get a list of active contexts (ALL/ALL effectively
>     > Shifting gears back to ALL/ROOT. Not only is it a special case that convolutes
>     > the implementation, I don't think it works. I cannot come up with an appropriate
>     > reply even taking Section 11.1 of the Implementor's Guide into consideration.
>     > In Number 1, the replies violate the current ABNF (missing the Command Reply).
>     > Number 2 repeats the same information inside of each Action Reply. However, the
>     > larger issue with Number 2 is that ROOT is not in either of the contexts listed. The
>     > As it currently stands, I don't think there is a valid way to Reply. So we at least
>     > need
>     > to fix that. I like adding a property to root as outlined above. However, I would

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco