Re: fddi mib update text

[dsiinc![e-mail]]

>    In response to the chair's call for text to update the FDDI MIB,
>    here is a coalesced list of updates as per the resolution of all
>    issues since the last draft, both at the Nov IETF meeting and on this
>    mailing list.  Thanks to Larry Stefani for reviewing this in detail.
>    Updates are marked with "***" in the left margin.  

Thanks for providing an exhaustive list.  Except for the comments
below, I agree with all the proposed changes.

>          -- FddiResourceId ::= INTEGER (0..65535)
>          -- This data type is used to refer to an instance of a  MAC,
>***       -- PORT, or PATH Resource ID.  Indexing begins
>          -- at 1.  Zero is used to indicate the absence of a resource.

(PICKING NITS) Why not just specify the range as (1..65535) and remove 
the last two sentences?  No SNMP object will ever return a zero resource
index.  Zero was included in SMT to indicate a "wild-card" request (SMT's 
own warped version of get-next).  Besides, as we discussed earlier, there 
is nothing in SMT that requires resource indexing to begin at 1.

>          snmpFddiSMTIndex OBJECT-TYPE
>***                   "A unique value for each SMT, which is the same
>***                   as the corresponding resource ID in SMT.  The

There is no resource ID in SMT for SMT itself.  This sentence should 
be removed.  This change is okay for the rest of the indices, but not 
this one.

>[Page 18]
>          snmpFddiSMTConnectionPolicy OBJECT-TYPE
>                      The value is a sum.  This value initially takes
>***                   the value 32768, then for each of the connection
>                      policies currently enforced on the node, 2 raised
>                      to a power is added to the sum.  The powers are
>                      according to the following table:

This is not worded correctly (it is also incorrect in the SMT document).  
If I read it as written, I'd have to add 32768 for rejectM-M in addition 
to the initial value of 32768, which is incorrect.  I think it would be 
better if we removed the line about the initial value so it looks like
any other "sum" description.  The default 32768 is covered by the 
previous paragraph that indicates "... Bit 15, (rejectM-M), is always 
set and cannot be cleared."

>[Page 20]
>[should the syntax be changed to TimeStamp instead? --agr]
>          snmpFddiSMTTraceMaxExpiration OBJECT-TYPE

Yes.

>[Page 38]
>          snmpFddiMACHardwarePresent OBJECT-TYPE
>***           SYNTAX  INTEGER { notPresent(1), present (2) }

Can I recommend that we change the type of this variable (and also
PORTHardwarePresent) from this form to 

>              SYNTAX  INTEGER { true(1), false(2) }

These variables are booleans.  In SMT, 
		notPresent(0) = false(0),
		Present(1) = true(1)

These were just meant as aliases for true and false.  The code that 
checks and sets these variables is the boolean code.

However, in SNMP, we've changed this mapping to:
		notPresent(1) != false(2) 
		Present(2) != true(1)

which is likely to confuse people who expect all the booleans
to be the same.  We can get rid of one unnecessary conversion
routine if we change this syntax as indicated.

>[Page 43]
>***       snmpFddiMACNotCopiedThreshold OBJECT-TYPE
>***           ACCESS  read-only

This should be read-write.

>[Page 46]
>          snmpFddiPATHTVXLowerBound OBJECT-TYPE
>              DESCRIPTION
>                      "Specifies the minimum time value (maximum twos-
>                      complement numeric value) of fddiMACTvxValue that

Of course, without "(maximum twos-complement...)" stuff.

>***       snmpFddiPATHConfigResourceIndex OBJECT-TYPE
>***                   "The value of the SMT resource index used to refer to
>***                   the instance of this resource."
>***           ::= { snmpFddiPATHConfigEntry 5 }

I don't believe this wording is descriptive enough.  This wording is
identical to the definition of the SMT PATH index, which may lead people 
to believe they are exactly the same object.  Can I suggest the
following replacement text?

>***                   "The value of the resource index used to refer to
>***                   this MAC or PORT resource."

>[Page 59]
>          snmpFddiPORTHardwarePresent OBJECT-TYPE
>***           SYNTAX  INTEGER { notPresent(1), present (2) }

See my note on MACHardwarePresent.

>[Page *]
>*** Didn't we decide to remove all chipset stuff? (this is a question)

I believe we agreed to remove all of it.

One question:  Since we added and removed so many variables, can I 
assume that all the variables will be renumbered starting with 1 or
will there be gaps in the numbering scheme?  Anil's and Larry's 
changes indicate gaps, but we've always renumbered to keep indexing
dense.

For your information:  Two weeks ago, the ANSI X3T9.5 completed the 
letter ballot period and approved the final SMT document.  SMT is over... 
done... complete... end of story.  There were no technical changes made 
to the 7.2 draft, but there were several editorial changes.  Since 
changes were made, the committee had to roll the SMT version number.  
The final SMT standard will be published as SMT 7.3.  There were no
changes that affected the MIB.  We should probably roll our references
to refer to this new document.

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