Re: if mapping

dsiinc!rem@uunet.uu.net Fri, 19 February 1993 16:04 UTC

Received: from ietf.nri.reston.va.us 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 uunet.uu.net (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!rem@uunet.uu.net
Message-Id: <9302191535.AA23147@relay1.UU.NET>
Received: from dsiinc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 103251.5364; Fri, 19 Feb 1993 10:32:51 EST
To: uunet!cs.utk.edu!fddi-mib@uunet.uu.net
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 
configurations:

    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.
rem@dsiinc.com			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057