Re: Proposal supporting RowStatus (was Re: RowStatus
case@cs.utk.edu Tue, 15 December 1992 15:57 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03673; 15 Dec 92 10:57 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03669; 15 Dec 92 10:57 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09742; 15 Dec 92 10:59 EST
Received: by thumper.bellcore.com (4.1/4.7) id <AA14591> for ietf-archive@nri.reston.va.us; Tue, 15 Dec 92 10:59:37 EST
Received: from seymour1.cs.utk.edu by thumper.bellcore.com (4.1/4.7) id <AA14583> for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 15 Dec 92 10:59:33 EST
Received: by seymour1.cs.utk.edu (5.61++/2.8t-SNMPres) id AA00209; Tue, 15 Dec 92 10:57:34 -0500
Date: Tue, 15 Dec 1992 10:57:34 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: case@cs.utk.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Message-Id: <9212151557.AA00209@seymour1.cs.utk.edu>
To: snmp2@thumper.bellcore.com
Subject: Re: Proposal supporting RowStatus (was Re: RowStatus
Cc: mlk%bir.UUCP@mathcs.emory.edu
Michael: It seems to me that your proposal is redundant. The reason it seems this way to me is that I believe that when a manager sees RowStatus in a table and in the IMPORTS clause, it can simply and unambiguously know how RowStatus works on that table. If it is called something it does not recognize and/or is imported from somewhere unknown, then the manager is not going to be able to handle it, just like it won't be able to handle a value in your proposed clause that it doesn't recognize. Therefore, what we have today and what you propose is equally strong in both cases -- those when the technique is recognized and when the technique is not recognized. As a result, it adds little or no additional value, so I can't see a benefit of considering it further. regards, jdc