Re: Modification of Row Objects

Gary Ellis <garye@hpspdla.spd.hp.com> Mon, 16 December 1991 19:41 UTC

Received: from mtigate.mti.com by NRI.NRI.Reston.VA.US id aa00515; 16 Dec 91 14:41 EST
Received: by mtigate.mti.com id AA17931 (5.65+/IDA-1.3.5); Mon, 16 Dec 91 10:22:53 -0800
Received: from relay.hp.com by mtigate.mti.com with SMTP id AA17920 (5.65+/IDA-1.3.5); Mon, 16 Dec 91 10:22:19 -0800
Received: from hpspd.spd.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA12054; Mon, 16 Dec 91 10:22:09 -0800
Received: from hpspdla.spd.hp.com by hpspd.spd.hp.com with SMTP (15.11/15.5+IOS 3.12) id AA27271; Mon, 16 Dec 91 10:22:47 pst
Received: by hpspdla.spd.hp.com (16.6/15.5+IOS 3.12) id AA09731; Mon, 16 Dec 91 10:20:52 -0800
From: Gary Ellis <garye@hpspdla.spd.hp.com>
Message-Id: <9112161820.AA09731@hpspdla.spd.hp.com>
Subject: Re: Modification of Row Objects
To: RMONMIB mailing list <rmonmib@lexcel.com>
Date: Mon, 16 Dec 1991 10:20:50 -0800
X-Mailer: ELM [version 2.3 PL11]

Robin Iddon writes:
> 
> In a previous message Gary suggests a manager modifies the EntryStatus object
> for a row from valid to underCreation.  This would allow the manager to modify
> some of the other row objects and then have them take effect by re-validating
> the EntryStatus object.
> 
> Whilst I sympathize with this approach I don't see that RFC1271 allows this.
> Certainly the comment under the EntryStatus definition neither allows nor
> disallows this.  The text of RFC1271 does not imply this is the way to do it,
> however:
> 
> [From RFC1271]
> 5.  Control of Remote Network Monitoring Devices
> 
>    ...
> 
>    Because the parameters in the control table often describe resulting
>    data in the data table, many of the parameters can be modified only
>    when the control entry is invalid.  Thus, the method for modifying
>    these parameters is to invalidate the control entry, causing its
>    deletion and the deletion of any associated data entries, and then
>    create a new control entry with the proper parameters.  Deleting the
>    control entry also gives a convenient method for reclaiming the
>    resources used by the associated data.
>

Sigh....this is what happens when there are so many new revisions of the
same document.  I'm not sure when the above paragraph appeared in the text.
Perhaps it was when when IESG/IAB compatible text was being added immediately
prior to submission as an RFC.  In any event, I rememember clearly discussions
in which it was agreed that the underCreation state could be entered at
any time from the valid state.  The intent of the working group was to allow 
a manager to modify values in a row without deleting that row.  There *was*
discussion about how it was likely that in the case of an error during 
row creation, the manager would delete the row and recreate it, but
that is different from modifications to a valid row.

Although the text as written gives a strongly worded suggestion, it is 
*not* true that RFC1271 does not allow a state transition from valid to
underCreation, and interoperability is *not* compromised by an agent that
allows this.  At this point though, its probably water under the bridge,
since the document has been published, and managers will be implemented
using the above text as their guide.


---------------------------------------------------------
Gary Ellis                       (garye@hpspd.spd.hp.com)
Hewlett-Packard Company -- Intelligent Networks Operation