Subject: Re: Error values in the AgentX Notify PDU

From: Matt White <[email-masked]>
Date: Mon, 28 Sep 1998 18:00:27 -0400

--On Monday, September 28, 1998, 3:08 PM -0400 Bob Natale
<[email-masked]> wrote:
> I think you mean the "Close and Notify PDUs" there...?  And, yes,
> that was the consensus of the meeting attendees.  However, this
> will yet be put before the full list for any desired discussion
> or refinement.

Yes, that is what I meant.

> Hmmm.  I *think* the master agent would probably deliver a
> "noError" response to the subagent when it (the master)
> determined that the sub's Notify PDU was "correct" iaw some
> local definition of that term and the master had the resources
> and connectivity to process and transmit the corresponding
> SNMP notification message--I do not think the downstream
> receipt of the notification by the target will be communicated
> back to the sub, one way or the other.

This behaviour is somewhat less useful than waiting until an ack has been
received to send a Response PDU.  Remember that the wording of the RFC2257
states that what the master does with the Notify is implementation specific
and may include: SNMP Traps, SNMP Informs, syslog, paging, mailing a xmas
card to your grandmother or dropping the packet on the floor.

Some of these actions provide a way of determining whether the notification
was received by recipient.  This is useful information to the subagent --
there is actually an application here that requires it.  What I am
suggesting is that there be an error type of 'notDelivered' or some such
thing that the master can reply to Notify PDUs with.

We don't require its use since we don't say much about what to do with
AgentX Notify PDUs.  That way, if a master wants to inform the subagent
that it was not able to deliver the notification, there is a simple way of
doing so.  This has the inherent restriction that the master must time out
the notification that it sends before the AgentX Notify times out, but I
would not think this too counter-intuitive.

-Matt

----------
Matt White
Network Systems Designer
Canegie Mellon Computing Services

---

From: Mike Daniele <[email-masked]>
Date: Tue, 29 Sep 98 13:49:07 -0400

Matt,

>thing that the master can reply to Notify PDUs with.

How would you foresee this working when a master is configured
to send notifications to several targets, and some accept delivery 
and some don't?

Thanks,
Mike

---

From: Matt White <[email-masked]>
Date: Tue, 29 Sep 1998 14:37:44 -0400

Hmmm...my apologies.  I didn't really answer your question, did I?

The answer is: it depends.  The master agent designer could do one of
several things:
*  reply noError if the notification was ACKed by any of its recipients
*  reply notDelivered if the notification was NAKed by any of its recipients
*  maintain groups of recipients that are 'important' and apply one of the
above to that group.

There's going to be some fuzziness about this since the subagent has no
concept of where its notifications are going.

-Matt

----------
Matt White
Network Systems Designer

--On Tuesday, September 29, 1998, 1:49 PM -0400 Mike Daniele
<[email-masked]> wrote:

> Matt,
> 
>> Some of these actions provide a way of determining whether the
>> notification was received by recipient.  This is useful information to
>> the subagent -- there is actually an application here that requires it.
>> What I am suggesting is that there be an error type of 'notDelivered' or
>> some such thing that the master can reply to Notify PDUs with.
>

---

From: Matt White <[email-masked]>
Date: Tue, 29 Sep 1998 14:30:09 -0400

The purpose of the notDelivered error is to inform the subagent that the
subagent was not heard and should seek alternate forms of communication or
attempt to deal with the situation on its own.

In the case of one or more ACKs and one or more NAKs, master behaviour is
implementation specific because there is no way for us to know the right
thing to do now at the writing of this document.  In reality, a master
agent should allow this to be a user-configurable option, so that a given
site can choose an appropriate behaviour for their application.

-Matt