Re: SMI clarification

ANDREASSON <ANDREASSON@taec.mrgate.valmts.vbo.mts.dec.com> Tue, 16 July 1996 11:05 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09204; 16 Jul 96 7:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09200; 16 Jul 96 7:05 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa05632; 16 Jul 96 7:05 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa18017; 16 Jul 96 6:20 EDT
Received: from server21.digital.fr by neptune.TIS.COM id aa18003; 16 Jul 96 6:08 EDT
Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by server21.digital.fr (8.7.5/8.7) with ESMTP id MAA19851 for <snmpv2@neptune.tis.com>; Tue, 16 Jul 1996 12:15:23 +0200 (MET DST)
Received: from valmts.vbe.dec.com (valmts.vbe.dec.com [16.36.176.78]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id MAA20784 for <snmpv2@neptune.tis.com>; Tue, 16 Jul 1996 12:17:11 +0200 (MET DST)
Received: from mts.dec.com by valmts.vbe.dec.com (PMDF V5.0-7 #16475) id <01I752113Z80004BVM@valmts.vbe.dec.com> for snmpv2@neptune.tis.com; Tue, 16 Jul 1996 12:12:04 +0100 (CET)
Received: with PMDF-MR; Tue, 16 Jul 1996 09:21:13 +0000 (GMT)
MR-Received: by mta VALMTS; Relayed; Tue, 16 Jul 1996 10:11:23 +0000
Alternate-recipient: prohibited
Disclose-recipients: prohibited
Date: Tue, 16 Jul 1996 09:21:13 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: ANDREASSON <ANDREASSON@taec.mrgate.valmts.vbo.mts.dec.com>
Subject: Re: SMI clarification
To: snmpv2@neptune.tis.com
Message-id: <G0002F8EE16JUL199611211482*@MHS>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
UA-content-id: Re: SMI clarification
X400-MTS-identifier: [;G0002F8EE16JUL199611211482]
Hop-count: 1
X-Orig-Sender: snmpv2-approval@neptune.tis.com
Precedence: bulk

This topic reminds me of the riddles column in some magazines -
I am writing this on the beach ;-)


Olivier Miakinen wrote:
>
> I'm interested in having the answer to your question, and I think
> that people who responded didn't see THE point. Then I cut extra-stuff,
> in order for the `INDEX { t1AltIndex, t1AltIndex }' to appear alone.
>

I think we got 'THE point' - if there was just one variable in the
INDEX clause, there wouldn't be any 'point'.

...

Olivier Miakinen wrote later:
>I suppose that both values are different, because it wouldn't be
>necessary to specify the attribute twice if it was always the same value.
>I mean, you can have an instance of t2Sum that is: t2Sum.7.15, where
>7 is one t1AltIndex value, and 15 is another t1AltIndex value.
>

Yes. Another way to look at the problem is to consider it as a special
case of having one table row be a function of several rows in other
table(s). In the generic case, for example t2Sum.7.15 might be
a different or the same instance as t2Sum.15.7 - (this is implementation
dependent, of course).


>As an other example, if the INDEX clause was:
>   INDEX { t2Sum, t2Sum }
>then I would say this would be impossible, for the following reason:
>If you get t2RowStatus.7.15, you can't know if corresponding t2Sum
>is 7 or 15.

Not really, I would say also the "INDEX { t2Sum, t2Sum }" is both
syntactically and semantically correct. It just implies that the agent
would treat requests for t2RowStatus.x.x as valid, whereas
t2RowStatus.x.y (x!=y) would generate an error. (However, I can hardly
think of a situation where this construction may be of any use...)

Semantically, it's just required of the INDEX clause to provide for a
way to unambiguously identify a row:

(From RFC 1902:)
"
   The instance identification information in an INDEX clause must
   specify object(s) such that value(s) of those object(s) will
   unambiguously distinguish a conceptual row.
   ...
"

...I'll move on to the chess problems column :-)


Sigge Andreasson