Re: Set same var, implementation specific behavior?
"Steven L. Waldbusser" <sw0l+@andrew.cmu.edu> Wed, 04 November 1992 08:43 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00505;
4 Nov 92 3:43 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00501;
4 Nov 92 3:43 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01449;
4 Nov 92 3:44 EST
Received: by thumper.bellcore.com (4.1/4.7)
id <AA22105> for ietf-archive@nri.reston.va.us; Wed, 4 Nov 92 03:44:00 EST
Received: from andrew.cmu.edu by thumper.bellcore.com (4.1/4.7)
id <AA22099> for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2;
Wed, 4 Nov 92 03:43:58 EST
Received: by andrew.cmu.edu (5.54/3.15) id <AA21562@X> for
snmp2@thumper.bellcore.com; Wed, 4 Nov 92 03:43:55 EST
Received: via switchmail; Wed, 4 Nov 1992 03:43:54 -0500 (EST)
Received: from zeus.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.UexsoeO00WAr80Uts2>;
Wed, 4 Nov 1992 03:43:23 -0500 (EST)
Received: from zeus.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr5/sw0l/.Outgoing/QF.8exsocW00WAr4mxJ4v>;
Wed, 4 Nov 1992 03:43:20 -0500 (EST)
Received: from
Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.zeus.andrew.cmu.edu.sun4c.411
via MS.5.6.zeus.andrew.cmu.edu.sun4c_411;
Wed, 4 Nov 1992 03:43:20 -0500 (EST)
Message-Id: <UexsocG00WAr8mxIsm@andrew.cmu.edu>
Date: Wed, 4 Nov 1992 03:43:20 -0500 (EST)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Steven L. Waldbusser" <sw0l+@andrew.cmu.edu>
To: snmp2@thumper.bellcore.com, mlk%bir.UUCP@mathcs.emory.edu
Subject: Re: Set same var, implementation specific behavior?
In-Reply-To: <0D15DDF1.hpc96h@bir.bir.com>
References: <0D15DDF1.hpc96h@bir.bir.com>
Excerpts from mail: 3-Nov-92 Set same var, implementatio.. Michael L. Kornegay@math (262) > Paragraph 3 of page 26 of Prot Ops for SMP indicates if PDU contains multiple > var binds for same var, actual assignment is implementation-specific. > Do not allow implementation-specific things!!! It is impossible to reconcile this with "as if simultaneously". Paragraph 3 should read to MS implementors as: "This behavior will be implementation-specific, potentially non-deterministic. Thus I should never depend on such a packet (unless I am trying to seed a random number generator :-)" In the end, the right things happen, without adding rules that might burden the agent by enforcing deterministic behavior. I draw comfort from the analog that IP networks may deliver packets in an implementation-specific order, yet TCP/IP still works. Steve
- Re: Set same var, implementation specific behavio… Steven L. Waldbusser