Subject: RE: [Megaco] Auditing the active Contexts

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

Call it a difference of opinion, but I disagree.

For one thing, the RFC and Recommendation H.248 are published.
We can do some things in the IG, but not change the protocol.
It's pretty easy to add some explanation, pretty hard to
eliminate something.  Even if you "deprecate" it in the IG,
it's still in the protocol.

Besides, it gets you what you want, in a way that the 
parser can deal with, that is easy for the MG to generate.
Sure, the package is a more compact way to get the information,
but the way I suggest is appropriate is simple to do,
and has little consequences.  You usually only do this
operation when you have reason to suspect the MG is out
of sync with the MGC.

Brian

> -----Original Message-----
> From: Dan Linton [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 11:14 AM
> 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

---

From: Dan Linton <[email-masked]>
Date: Thu, 06 Sep 2001 10:51:18 -0400

Brian,

We can always agree to disagree. However, I would like to use that as
a last measure. So I'll take another crack at it.

First let's remove the idea of a new parameter on root. I agree that it is
too late for that. That is not the issue at all.

One thing I forgot to offer last time was that we have an implementation
for ALL/ROOT in our MG. It was my example Number 1 which violates
the ABNF. That's what prompted this whole discussion prior to which I was
planning to implement something like Number 3. As an implementor, I can
say that working with ALL/ROOT is not as trivial is it might seem.

The problem with both my example Number 3 and your proposal is that
they treat ROOT as a wildcarded TerminationID. Perhaps this is my
opinion, but ROOT is and should be treated as a fully specified
TerminationID. Therefore, handling it like a wildcarded TerminationID
is the wrong approach, and if it is wrong (i.e. a defect) it should be fixed
via the IG. Luckily, expanding ROOT as a wildcard also happens to be
unnecessary since ALL/ALL is possible.

Thanks,
Dan