Subject: Re: Statistics

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Sep 1999 14:51:27 -0400

This is a neat lead-in for a topic I promised to raise.  Some people would
like to see a non-SNMP provisioning protocol, presumably lighter in weight
than SNMP, for provisioning small MGs.  This is not in our charter.  The
question is whether we would want to ask the IESG to extend our charter to
include such an item when the basic work is done.  Alternatively, would our
advice to the interested parties be that they should ask for a BOF on the
topic of a light-weight provisioning protocol?

That aside, whether information is transmitted by Megaco/H.248 or by SNMP,
it has to come from somewhere.  "Provisioning is evil" doesn't get around
that fact.  Hence Michael is making a very valid point when he suggests we
consider the limits to the device control protocol.  I would suggest that
those limits should relate to whether the MGC software will be making
decisions on the configuration settings based on current conditions
(real-time control), or whether instead the configuration settings concerned
are static.

> -----Original Message-----
> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Wednesday, September 08, 1999 12:19 PM
> To:   [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
>  > >  > > > >
>  > >  > > > >
>  > >  > > >
>  > >  >
>  > >
>  >