Re: if mapping

[dsiinc![e-mail]]

[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.
[e-mail]			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057