Subject: Comments on SCTP MIB Draft 03

From: Mike Perler <[email-masked]>
Date: Wed, 21 Mar 2001 16:17:09 -0500

Here are some comments about the SCTP MIB draft in
draft-ietf-sigtran-sctp-mib-03.txt from February 20, 2001. I apologize if
any of these have already been mentioned, but I am new to this list.

Section 3 - Structure of the MIB
The MIB structure shows sctpCompliance under sctpGroups. However,
sctpCompliance is defined under sctpCompliances in the MIB. Also,
sctpCompliance is probably a lower-level than is needed to be shown here for
the overall MIB structure; sctpCompliances is probably enough.

Section 3.1.2.1 - Association Table
This section states "It is NOT possible to create rows in any table
(sctpAssocTable, sctpAssocLocalAddressTable, sctpRemAddressTable)." First,
the last table should be referred to as sctpAssocRemAddressTable. Also,
there are MIB attributes in sctpAssocTable and sctpAssocRemAddress that have
a MAX-ACCESS of read-create, which implies that SNMP can be used to create
rows. This inconsistency needs to be fixed.

If SNMP can be used to create and/or modify entries in this table, then some
rules should be defined to detail what should happen if there is a conflict
between user settings and SCTP control message information. For example, if
the user modifies the value of sctpAssocRemPrimaryAddress for an ESTABLISHED
association, should the primary path be modified?

Finally, this section states "[Setting sctpAssocState to deleteTCB] is the
only way to delete rows in any of the mentioned tables." According to the
state diagram in RFC 2960, delete TCB should cause an association to
transition to the CLOSED state. So why would this cause the row in the
association table to be deleted? Shouldn't this keep the row and change the
sctpAssocState to closed?

Section 4 - Definitions
sctpCurrEstab - If this indicates the current number of SCTP associations
that are in certain states, then it should be a Gauge32, not a Counter32. As
defined in section 7.1.6 of RFC 2578, counters cannot be decremented; they
must increment until reaching their maximum and then reset to zero.

sctpInverseAssocTable - Is there a reason that this is defined in the MIB
before sctpAssocTable? I think that from a readability point-of-view, it
would be nicer to have it after.

sctpInverseAssocEntry - Although the RFCs do not disallow the INDEX as
defined here, some MIB compilers complain when a table uses attributes for
its INDEX from another table that are not INDEX attributes in that other
table. Therefore, it might be better to redefine the inverse association
table row as follows:
	sctpInverseAssocEntry OBJECT-TYPE
		SYNTAX SctpInverseAssocEntry
		MAX-ACCESS not-accessible
		STATUS current
		DESCRIPTION
			"Each row corresponds to exactly one entry in
sctpAssocTable,
			 which is the entry in sctpAssocTable whose value of
sctpAssocId
			 is the same as sctpInverseAssocId."
		INDEX { sctpInverseAssocRemSCTPPort,
			  sctpInverseAssocLocalSCTPPort,
			  sctpInverseAssocRemPrimaryAddressType,
			  sctpInverseAssocRemPrimaryAddress,
			  sctpInverseAssocRemHostName,
			  sctpInverseAssocId }
		::= { sctpInverseAssocTable 1 }

From the mailing list archives, it seems that the reason for adding this
inverse association table is to allow an SNMP manager to easily find
associations based on certain criteria, such as remote port or remote IP
address. The inverse association table as defined, however, only provides
lookup using the remote port. Also, since only the association ID is
required to uniquely identify an association, the other information in the
INDEX is redundant and makes the agent implementation of the inverse
association table more complicated.

It might make more sense to provide a few different lookup tables based on
different criteria. For example, some or all of the following could be
defined:
 1) sctpAssocLookupLocalPortTable - all associations defined on the
specified local port, indexed by local port and association ID.
 2) sctpAssocLookupRemAddressTable - all associations to the specified
remote IP address, indexed by remote address type, remote address, and
association ID.
 3) sctpAssocLookupRemPortTable - all associations defined on the specified
remote port, indexed by remote port and association ID (or, if necessary, by
remote port, remote address type, remote address, and association ID).
 4) sctpAssocLookupRemHostTable - all associations to the specified remote
host, indexed by remote host name and association ID.

These tables could all be defined in different optional groups in the
conformance section, so that agents can choose which ones they will support,
if any.

sctpInverseAssocStartTime - If the change specified above for
sctpInverseAssocEntry is made (adding the index attributes to the inverse
table instead of referring to the association table), then it might make
more sense to remove this attribute and make the sctpInverseAssocId
attribute read-only (which is legal in SMIv2 for index objects of tables
that would otherwise be empty). I think that this would emphasize that the
main intent of the inverse table is to identify the association(s) for a
remote port, and that the details of the association can be found in
sctpAssocTable.

sctpAssocRemHostName - According to a message from the mailing list archive
from September 2000, this attribute was suppose to be changed to read-only
access. However, it is currently specified as read-create. The URL for the
message in the archive is
http://www17.nortelnetworks.com/scripts/wa.exe?A2=ind0009&L=SIGTRAN&D=0&F=P&
P=21076&F=

sctpAssocRemPrimaryAddressType - The DESCRIPTION for
sctpAssocRemPrimaryAddress states that it will be filled in after an INIT or
INIT ACK message. The same statement should be added for this object.

Finally, it might be useful to add a TEXTUAL-CONVENTION for association IDs.
This could be helpful to vendors that implement private MIBs that refer to
SCTP associations. Whether a TEXTUAL-CONVENTION is defined or not, though,
the association IDs should be restricted to the range Unsigned32
(1..4294967295), to prevent zero from being used.

Section 4.1.2 - Compliance Statements
For OBJECT sctpAssocRemPrimaryAddressType, the SYNTAX states that only
ipv4(1) and ipv6(2) are required. However, the DESCRIPTION for
sctpAssocRemPrimaryAddressType indicates that unknown(0) is supported, and
is required if sctpAssocRemPrimaryAddress is a zero length string.
Therefore, unknown(0) should be included in this SYNTAX.

The OBJECT statements for the sctpAssocLocalAddressIPType,
sctpAssocLocalAddressIP, sctpAssocRemAddressIPType, and
sctpAssocRemAddressIP objects should be removed. According to section 5.4.3
of RFC 2580, any MIB objects referenced in an OBJECT clause must be present
in one of the conformance groups in the MANDATORY-GROUP clause or one of the
GROUP clauses for the compliance. Since these four objects are
not-accessible, they cannot be specified in any conformance groups (as noted
in section 3.1 of RFC 2580) and therefore cannot be included in the
compliance specification.

Michael Perler
Member Technical Staff
S-Link Corporation

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]