Subject: v16 comments: Event Handling

From: Harpreet Singh Anand <[email-masked]>
Date: Mon, 27 Mar 2000 11:07:20 -0600

Hello all,

The description for event handling in Sec 7.1.9 needs to be clarified
for the following states:

(a) Consider the state when Event Bfr Control (EBC) is LockStep and Mg
is collecting events according to EventBuffer Descriptor (EBD). If in
this state MG receives a command which sets EBC to Off (and the command
does not contain any new ED), then what should MG do? Should the MG
    - flush event buffer queue and start collecting events according to
the last ED that was set. OR
    - Flush event buffer and keep on collecting events according to EBD.

(b) Consider the state when Event Bfr Control (EBC) is LockStep and Mg
is collecting events according to EventBuffer Descriptor (EBD). If in
this state MG receives a command which sets a new EBD, then what should
MG do? Should the MG

    - flush the event bfr queue and start collecting events according to
the new EBD OR
    - keep the events in the bfr q. which correspond to the EBD and
remove other events and start collecting events according to the new EBD
OR
    - does not flush the event q and start collecting events according
to the new EBD

(c) Consider the state when Event Bfr Control (EBC) is LockStep and Mg
is collecting events according to Event Descriptor (ED). Also consider
that at this time EBD is not specified. If in this state MG receives an
event which matches an event in the ED. The MG would send the Notify
command request. If EBD would have been specified then the MG would have
started collecting events according to the EBD. But if the EBD is not
specified, then what should MG do ? Should the MG

    - Remain in the same state and keep on collecting according to the
current ED ? OR
    - Stop collecting events as EBD is not available.

Regards,
Harpreet

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 27 Mar 2000 16:56:56 -0800

At the risk of oversimplifying here, I think this boils down to which of
these parameters are mandatory and which are optional. It would be *really*
nice if we could get a table or something containing all the parameters and
indicating for each if it's mandatory or optional.

-- Flemming

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839

---

From: James Hua <[email-masked]>
Date: Tue, 28 Mar 2000 11:15:02 -0600

How can I unsubscrible this mailing list?

Thanks

---

From: Harpreet Singh Anand <[email-masked]>
Date: Tue, 28 Mar 2000 13:17:47 -0500

Hello,

> indicating for each if it's mandatory or optional.

Actually each of the case given below can be avoided if certain triggers are
defined as invalid in some state. It would be good if these clarifications are
added either in the draft itself or in the implementor's guide.

Regards,
Harpreet

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 28 Mar 2000 15:16:52 -0800

> added either in the draft itself or in the implementor's guide.

My point is that we should *not* try to do that. Rather than all of us trying to
figure out and agree which combinations of parameters make sense and design that
into the protocol, you design a general solution that has a clear and well-defined
behavior in all cases. If there are combinations you don't find useful, your MGC
will simply not use those.

-- Flemming