Subject: [Tsvwg] Review comments for SCTP MIB

From: [email-masked]
Date: Fri, 23 Aug 2002 18:50:23 -0400

Earlier this year I was asked to review the SCTP MIB
for MIB related issues.  The following are my comments
from that review.  I believe the authors may have
incorporated these comments in their working draft but I don't
think that draft has been posted to the drafts directory.

I also had some minor editorial issues that I've passed to the authors.
As I don't think the WG needs to see it I've left it out of this message.

I've attempted to subscribe to this mailing list but haven't gotten
a confirmation back so any comments on these that you would like
me to respond to should cc me for the near term.

regards,
Shawn A. Routhier

**

Comments on the MIB itself

>1) The mib-2 identifier needs to be imported from SNMPv2-SMI.  This
>   is probably the only change that must be made.
>
>2) sctpAssocID - This object is an index but also has text indicating
>   that it can be zero ("Value zero is reserved to indicate no association").
>   It is unclear to me if this text is trying to say that if there aren't
>   any associations then there will be a single entry in the table with
>   a 0 index or if it is trying to say that there may be entries where
>   the association hasn't been formed or has been removed that this object
>   is then set to zero.  If the text means the second then there is a
>   problem as there can be only one entry with this object set to zero
>   as it is used as an index.
>
>3) Can an Association be in the sctpAssocTable before it is fully formed?
>   In particular can sctpAssoc{Local Rem}Port be zero if the association
>   isn't completely formed yet?
>
>4) The access clause for sctpAssoc{In Out}Streams is read-only and the
>   description also mentions that it must be read only ("This parameter
>   has to be read-only by the manager.")  If there is a protocol requirement
>   I think describing why it must be read-only would be useful but I don't
>   think the current line is useful.
>
>5) The text for sctpAssoc{Local Rem}AddressType mentions the use of
>    unknown (0) when the associated address (sctpAssoc{Local Rem}Address)
>    is empty or unkown however the addresses are never allowed to be
>    empty as they have a syntax with size (1..36).  Also note that the
>    text for the address objects also seems to allow for a zero length
>    value.  Either the text or the syntax should be corrected.
>
>6) The text for sctpLookupRemPortEntry refers to a "local" port in
>    the description - I imagine that should be "remote" port.
>
>7) What should happen with the sctpLookupRemHostNameEntry if the
>   sctpAssocRemHostName doesn't yet exist?
>

**

Comments on the rest of the document

>section 3.1.3.1
>
>In the first paragraph you specify that the implmenter is allowed to choose
>the value used for the index.  You should mention any other constraints on
>their choice - for example any minimum time period between reuse of indices.
>You also may want to add a second clause to make sure the implementer chooses
>a unique value.  You do already have this information but it tends to be
>a good idea to make it very clear to the implementers.  For example you
>might have "It can be the tag value, the TCB creation time, or any other
>value the implementers decide, however it must be unique within the table."
>
>section 3.1.3.2
>
>The use of optional tables in MIBs is somewhat of a odd issue.  While
>it is nice to avoid adding the overhead of these tables to systems that
>don't need them if they are optional no management station can actually
>expect to use them.  I'd like to understand how you think they might be
>used - for example when an entity would implement and populate them and
>when a management station would decide to try and use them.  (Note: at
>this point I am not suggesting you change anything, I'm just trying to
>understand your model of the world.)
>
>You should also be clear what happens in a lookup table if the field 
>used for indexing that table is not yet valid in the main table.  You
>might need to add some text in both this section and in the MIB text.
>
>Will the timestamp in the reverse lookup tables be different than the
>timestamp in the association table?
>
>section 3.2
>
>In the second paragraph you seem to be saying that scoped address won't
>be used, however in the MIB that seems to be a valid option.  Also some
>of the inetAddress descriptions in the MIB seem to allow for the use of
>DNS names (I think I mentioned this in my previous email.)
>

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg