Subject: Re: Preconditions

From: Peter Blatherwick <[email-masked]>
Date: Mon, 24 Jan 2000 10:05:25 -0600

My 0.02...

First, we must avoid application dependencies in the protocol itself.
Therefore setting pre-conditions as part of the base protocol, especially if
they are aimed at particular events or signals, is not a good idea IMHO.  I
think anything along these lines should be solved in package definitions
since they are at least concerned with application level information
exchange.  I don't think anyone is asking for anything other than careful
package definition, but thought I should say this anyway.

However, I do see the "invisible state transition problem" as potentially
serious in at least some cases.  I think the best way to solve this in
general is to define, in the affected packages, the detection event as
"detects transition to or already in the requested state".  This would
detect the edge OR if the state already exists.  (I'm pretty sure this is
old ground, but darned if I can find the old thread right now.)

-- Peter

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: 23 Jan, 2000 18:57
> To:   [email-masked]
> Subject:      Re: Preconditions
>
> Let's be careful.  I believe all of these items are defined
> in packages.  I don't think there is anything like this in
> the base package.  In general, we have talked about defining
> events such as hook state as "edge detect", rather than state
> detect.  Would it solve the problem to make such events, in
> the packages, explicitly defined as change-of-state detected.
> Something like "detects the transition...".
>
> Brian
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:[email-masked]]
> > Sent: Saturday, January 22, 2000 3:22 PM
> > To: Rosen, Brian
> > Cc: [email-masked]
> > Subject: Preconditions
> >
> >
> >
> >
> >
> > Rosen, Brian writes:
> >  > Frankly, I don't think it matters a whole heck of a lot
> > what happens in
> >  > cases
> >  > like this, unless there is some possibility that the MG
> > and the MGC will not
> >  > sync quickly.
> >
> >    That's a very big "unless".
> >
> >  > They do in this case -- the user hangs up, and then the state
> >  > is consistent, the next time he goes off hook, the right
> > thing happens.  If
> >  > anyone
> >  > can define a case that doesn't converge like this, please
> > speak now,
> >
> >    A device control protocol like MEGACO is utterly
> >    at the mercy of a shared view of the device's
> >    state. If the MG and MGC are out of sync and the
> >    MG has no way to convey that within the protocol,
> >    the protocol is broken. Period. Relagating such things
> >    to audits is even more broken, because MGC's in the
> >    real world have about zero incentive to do what
> >    amounts to device state polling -- which does
> >    not scale for high fanout devices like residential gateways.
> >
> >  > I recommend we say "thanks for sharing"
> >
> >    This is a base functionality of MGCP -- the
> >    only protocol which has any track record
> >    thus far. Is this more Anything But MGCP
> >    hubris again?
> >
> >    I would say that the onus is on the naysayers
> >    to actually prove there does not exist any
> >    unrecoverable and non self-healing state
> >    mismatches. It is completely unreasonable for
> >    those who would like to have a more robust
> >    protocol to prove a negative.
> >
> >               Mike
> >