Subject: Re: Statistics

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 09:05:03 -0400

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.

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
>  > > > >
>  > > > >
>  > > >
>  >
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 8 Sep 1999 09:18:50 -0700

> 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