Subject: Re: Statistics

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 16:21:37 -0400

We have had this argument before (where is the boundary
between management and protocol).  I think that in
this case it depends on the programming of the MGC.
If the MGC is programmed to expect statistics in every
subtract, then it sets the variable on.  If it is
programmed to ask, then it sets them off.  If it is
programmed so that some management action IN THE MGC
determines whether it gets them every time or only under
some less common situations, then it sets them appropriately based on its
management action.  In no
case would provisioning the MG be appropriate.

Generally, I have NO problem defining packages that
provide this kind of control.  I like the idea of
provisioning the MGC, which then programs the MG.  While
we COULD arrange to get similar results via LDAP or SNMP,
I think it's much simpler to just define the packages
and let the MGC set up the MG appropriately.

Where the settings depend on the thing the gateway is
plugged in to (like the characteristics of the network
interface or the line interface), that should be
MG provisioning (or more likely LDAP accessed database)

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 12:19 PM
> To: Brian Rosen
> Cc: 'Michael Thomas'; [email-masked]
> Subject: RE: Statistics
>
>
> Brian Rosen writes:
>  > No, this is a MGC issue - it's the MGC that knows
>  > what it wants it's MGs to do. It's not an operator issue;
>  > the operator doesn't decide this directly.
>  >
>  > Provisioning is evil; it's hard to get right, today
>  > it's almost all manual, and with MGs, there are a lot of
> them.  Anything
>  > that can be dynamically set by the MGC should be.
>
>    You'll certainly get no argument from me on the
>    preceding paragraph. All I'm asking is whether
>    it makes sense to load up MEGACO with a lot of
>    state variables. Traditionally, that has been
>    the domain of SNMP (push), and LDAP (pull).
>
>    What I'm not sure that I agree with is whether
>    it belongs in MEGACO. Do we, for example,
>    load up the terminations with things like
>    various "fine tuning" variables like, oh say,
>    music-on-hold thresholds for VAD? Gain control
>    varaiables? Should there be corresponding
>    root variables which are moved into
>    terminations at, say, ServiceChange time?
>
>    That's why I say that this is possibly a
>    slippery slope. We need some sort of rule as
>    to which bucket these things belong in since I
>    don't think that the overall intent of MEGACO
>    is to handle every possible knob that the MGC
>    *might* want to turn.
>
>               Mike
>  >
>  > Brian
>  >
>  > > -----Original Message-----
>  > > From: Michael Thomas [mailto:[email-masked]]
>  > > Sent: Tuesday, September 07, 1999 8:33 PM
>  > > To: [email-masked]
>  > > Subject: Re: Statistics
>  > >
>  > >
>  > > Rex Coldren writes:
>  > >  > Brian,
>  > >  > I like the following:
>  > >  >
>  > >  > There is a property of root which turns on or off automatic
>  > >  > generation of statistics from subtract (would we really want
>  > >  > to automatically do this on a move?).  If this property is not
>  > >  > set then RequestedInfo is used to ask for statistics.
>  > >
>  > >    Hmm. The entire concept of root variables sure
>  > >    sounds like a slippery slope to provisioning if
>  > >    you ask me. At some point it's probably better
>  > >    to handle such things outside of MEGACO,
>  > >    probably in a MIB.
>  > >
>  > >                Mike
>  > >  >
>  > >  > Brian Rosen wrote:
>  > >  >
>  > >  > > Does anyone object to this?
>  > >  > >         RequestedInfo is allowed in Add/Subtract/Move/Modify
>  > >  > >         If it occurs, the requested descriptor is
>  > >  > >                 returned with the command as with AuditValue
>  > >  > >
>  > >  > > As an aside.  AuditValue can now be considered a No-Op
>  > >  > > which permits RequestedInfo.  If we need a no-op for other
>  > >  > > reasons, this can be it.
>  > >  > >
>  > >  > > Can I hear opinions on whether:
>  > >  > >         Subtract does NOT automatically return statistics,
>  > >  > >                 RequestedInfo is used to ask for them
>  > >  > > or, my personal favorite
>  > >  > >         There is a property of root which turns on or off
>  > >  > >                 the automatic generation of statistics from
>  > >  > >                 subtract and another for move
>  > >  > >
>  > >  > > Brian
>  > >  > >
>  > >  > > > -----Original Message-----
>  > >  > > > From: Nancy-M Greene [mailto:[email-masked]]
>  > >  > > > Sent: Tuesday, September 07, 1999 11:31 AM
>  > >  > > > To: [email-masked]; 'Brian Rosen'
>  > >  > > > Subject: RE: Statistics
>  > >  > > >
>  > >  > > >
>  > >  > > > Brian, you are right, RequestedInfo can be used in the
>  > > same way I was
>  > >  > > > thinking of using a flag. So, on further thought, it would
>  > >  > > > make sense to
>  > >  > > > allow RequestedInfo in Subtract, and perhaps also in Add,
>  > >  > > > Move, and Modify.
>  > >  > > >
>  > >  > > > Nancy
>  > >  > > >
> --------------------------------------------------------------
>  > >  > > > ------------
>  > >  > > > Nancy M. Greene
>  > >  > > > Internet & Service Provider Networks, Nortel Networks
>  > >  > > > T:514-271-7221 (internal:ESN853-1077)
>  > > E:[email-masked]
>  > >  > > >
>  > >  > > > > ----------
>  > >  > > > > From:       Brian Rosen[SMTP:[email-masked]]
>  > >  > > > > Sent:       Friday, September 03, 1999 10:20 AM
>  > >  > > > > To:         [email-masked]
>  > >  > > > > Subject:    Re: Statistics
>  > >  > > > >
>  > >  > > > > I do think we are into feature-creep here, and I do
>  > >  > > > > want to stop it.
>  > >  > > > >
>  > >  > > > > I don't agree that having RequestedInfo legal in other
>  > >  > > > commands makes
>  > >  > > > > implementation more complicated.  Commands need
> to be able
>  > >  > > > to return all
>  > >  > > > > sorts of descriptors if there was an underspecified
>  > >  > > > parameter included.
>  > >  > > > > Processing the requestedInfo descriptor has to
> be there for
>  > >  > > > AuditValue
>  > >  > > > > anyway.  I suspect it is close to zero work to make it
>  > >  > > > > happen; probably much more work to test it than to
>  > > implement it.
>  > >  > > > >
>  > >  > > > > What kind of "flag" were you thinking?  If it's in the
>  > >  > > > command, then the
>  > >  > > > > only flag that makes sense is "RequestedInfo".
> If it's my
>  > >  > > > > property-of-root,
>  > >  > > > > then
>  > >  > > > > I'll agree it's a good idea, but why wouldn't you have
>  > >  > > > > the same thing for Move?
>  > >  > > > >
>  > >  > > > > Brian
>  > >  > > > >
>  > >  > > > >
>  > >  > > >
>  > >  >
>  > >
>  >
>