Subject: [Fwd: [Megaco] Auditing the active Contexts]

From: Dan Linton <[email-masked]>
Date: Fri, 07 Sep 2001 06:22:59 -0400

This is a resend. I sent this out yesterday but it never made it to the list.
Hopefully, this won't end up being the second copy.

Subject: Re: [Megaco] Auditing the active Contexts
From: Dan Linton <[email-masked]>
To: Nurit Shenhar <[email-masked]>
Cc: "'Megaco_IETF (E-mail)" <[email-masked]>
Date: Thu, 06 Sep 2001 10:44:43 -0400

Nurit,

Thanks for the input. This solution has the draw back you have mentioned.
ROOT isn't in the specified contexts. The MGC will have to be smart enough
to deal with an Action Reply for a specific context where the Command Reply
contains a termination not found in that context. Of course, the MG requires
special code to produce said reply. On the positive side, this approach has an
advantage over my example Number 3 as well as Brian's proposed solution.
That is, it treats ROOT like a fully specified termination. This is good since
ROOT happens to be a fully specified termination. Number 3 and Brian's
proposal treat ROOT as if it were a wildcarded TerminationID which I think
is wrong.

One more comment below.

Thanks,
Dan

Nurit Shenhar wrote:

> Hi Dan
>
> Our implementation of the all/root is:
>
> MEGACO/1 [10.2.229.18]:2944
> P=4{
> C=1{
> AV=ROOT},
> C=2{
> AV=ROOT}}
>
> I know that ROOT is considered to be in the NULL context, but it also
> represents the whole gateway. And besides, when somebody sends this command,
> he shouldn't care what the termination is. He should only check the context
> number.
>

I think if the MGC comes to the point of sending this, it will also be
interested in which terminations are in which contexts. So it will use
ALL/ALL instead.

>
> Nurit
>
> -----Original Message-----
> From: Dan Linton [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 5:14 PM
> To: Rosen, Brian
> Cc: megaco
> Subject: Re: [Megaco] Auditing the active Contexts
>
> 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
>
> > 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
> >
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco
>
>