Re: if mapping

dsiinc! Fri, 19 February 1993 16:04 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa07854; 19 Feb 93 11:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07850; 19 Feb 93 11:04 EST
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa19829; 19 Feb 93 11:04 EST
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18451; Fri, 19 Feb 93 10:35:32 -0500
X-Resent-To: fddi-mib@CS.UTK.EDU ; Fri, 19 Feb 1993 10:35:31 EST
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18431; Fri, 19 Feb 93 10:35:28 -0500
Received: from (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23147; Fri, 19 Feb 93 10:35:18 -0500
Date: Fri, 19 Feb 93 10:35:18 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: dsiinc!
Message-Id: <9302191535.AA23147@relay1.UU.NET>
Received: from dsiinc.UUCP by with UUCP/RMAIL (queueing-rmail) id 103251.5364; Fri, 19 Feb 1993 10:32:51 EST
To: uunet!!
Subject: Re: if mapping
Content-Type: text
Content-Length: 1887

[Anil writes:]
>    I agree with your argument for removing numbering restrictions
>    on indices.

There is another reason to remove the 1-N restriction from the
resource indices.  In the previous draft, we attempted to align 
the SMT indices with the SNMP indices.  As Sal mentioned, there 
are no restrictions of 1-N for SMT, so this would not have 
accomplished the 1-to-1 mapping like we envisioned.  Additionally,
if the station had multiple SMT instances, the 1-to-1 mapping would
have been almost impossible.  

Removing the 1-N restriction allows representation of the following 

    SMT 1	MAC 1
    SMT 1	MAC 17
    SMT 2	MAC 1

>[Sal writes:]
>>   One last point - this about ghosts.  Given a ghost resource, in SNMP it
>> seems improper to be able to retreive some variables and skip others that
>> have "gone away" because of ghosthood.  It also appears to be improper to
>> assign "default" values to these shadow variables - although I think a good
>> case could be made for this type of operation.  The most "correct" method,
[Anil writes:]
>    <groan> looks like this issue's back to haunt us.. here's another
>    exorcism attempt..

I don't really care which way we decide to resolve this, as long 
as everyone agrees to it consistently.  However, I have always worked
with the assumption that "partially implemented" tables or making up 
fake values to complete tables were bad things.  If these things are 
common in SNMP, why did we take the time and effort to move the optional 
MAC counters to a separate table and also remove all the optional SMT
variables from the MIB? 

>    ps: nice to see some life on this list.. if we're not careful we'll
>    get this mib done yet :-)

Wouldn't that be nice?

Ron Mackey			Distributed Systems International, Inc.			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057