Re: Other party issues (was Re: Fwd: Contexts?

Keith McCloghrie <kzm@hls.com> Tue, 18 May 1993 05:56 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21427; 18 May 93 1:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21423; 18 May 93 1:56 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa29374; 18 May 93 1:56 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA15120> for JOHNSO17@NIEHS.NIH.GOV; Tue, 18 May 93 01:26:44 EDT
Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id <AA15110> for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 18 May 93 01:26:33 EDT
Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA20390; Mon, 17 May 93 22:30:21 PDT
Received: by nms.hls.com (4.1/SMI-4.1) id AA09006; Mon, 17 May 93 22:25:31 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith McCloghrie <kzm@hls.com>
Message-Id: <9305180525.AA09006@nms.hls.com>
Subject: Re: Other party issues (was Re: Fwd: Contexts?
To: mlk%bir.UUCP@mathcs.emory.edu
Date: Mon, 17 May 1993 22:25:30 -0700
Cc: snmp2@thumper.bellcore.com
In-Reply-To: <0D15DDF1.1re2dq@bir.bir.com>; from "Michael L. Kornegay" at May 17, 93 9:46 pm
Organization: Hughes LAN Systems
X-Mailer: ELM [version 2.2 PL0]

> I also believe the following issue may become more important and may
> need to be considered when SNMPv2 is evaluated at the next step of 
> the process, this is particularly important in a multiple manager
> environment:
> 
> mlk>  o Since consistancy is important, we probably should have included some
> mlk>   form of party modification notification in the Party MIB so changes by
> mlk>   other managers could be detected, and updates of managers' local copies
> mlk>   could be performed.  Such indication might have included a TimeStamp of
> mlk>   last sysUpTime when party mib was modified, and possibly generate a 
> mlk>   Party MIB changed trap.

Could be.  This is the kind of suggestion for which I hope
implementation experience will tell us how useful it is.  As people
implement and figure out how they are going to use the information,
perhaps they could bear this suggestion in mind, and report back to the
list on how and when they would use such a partyMibLastChange object
and/or trap.

[Correspondingly, if you implementors were to find that some of the 
objects we already have are not useful to you, please report on that 
also, so we can decide if they should be deprecated.]

Thanks,
Keith.