Subject: SCTP-MIB discussion

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Nov 2001 15:05:35 +0100

I raised several comments on the SCTP-MIB when reviewing it as part of
the IPv6 MIB design effort. Many of my comments are not IPv6 specific
and should have WG discussion. 

I am forwarding the message below to give you the context and I will
now move follow-up discussion to the SIGTRAN mailing list since this
WG is currently responsible for this document.

/js

------- Start of forwarded message -------
From: "Maria-Carmen Belinchon-Vergara (ECE)"
	 <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>
Cc: [email-masked], "'Shawn A. Routhier'" <[email-masked]>
Subject: RE: [ipv6mib] SCTP MIB
Date: Mon, 19 Nov 2001 12:47:38 +0100
Sender: [email-masked]
Precedence: bulk

Hi all, 

	First of all, thanks a lot for your comments, they have been very fruitful. On the other handl, the SCTP MIB is now out. You can move some of the comments to the sigtran mailing list if you prefer. In the meantime, my comments in line:

- -----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 12:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ipv6mib] SCTP MIB

>>>>> Maria-Carmen Belinchon-Vergara (ECE) writes:

Maria-Carmen> I intend to submit the SCTP MIB next week. If I don't
Maria-Carmen> receive any comment before Tuesday, the 13th, I'll
Maria-Carmen> submit the doc to the IETF list ;o)

I went through the MIB and wrote down several suggestions and
comments. Since most of the comments are not IPv4/IPv6 specific, they
should probably be sent do the SIGTRAN working group. The problem with
this is however that I reviewed a document which is not accessible as
an ID. So perhaps it is best to just post the ID and to move the
discussion on the SIGTRAN WG mailing list.

Anyway, here are my comments on <draft-ietf-sigtran-sctp-mib-05.txt>:

- - Section 1 says that this MIB is based on RFC 2452. In what sense is
  this true?
[MCarmen] Actually, the SCTP MIB is based on RFC2851-update and RFC2012-update, so maybe this comment should be removed in the SCTP MIB. BTW, could you please clarify me what is the aim of RFC2452?

- - I made this comment before: What is the purpose of the sctpScalars
  and sctpTables node? I can not recall having seen that in other IETF
  MIBs. Note also that sctpCompliance is actually registered below
  sctpCompliances and not sctpGroups.
[MCarmen] We thought it was clerarer for the readers, we didn't see any rule against this structure, Scalars and Tables in two different nodes. Also, you are right in the sctpCompliance, it is now fixed.

- - The text in the 2nd paragraph of section 3.1.1.1 reads a bit rough.
[MCarmen] I'll try to makeit clearer

- - Does deleteTCB really make sense? Is this widely implemented in TCP
  MIBs? Have WG folks expressed their interest to implement this? If
  there is no strong evidence, then I would prefer to remove it.
[MCarmen] SCTP people have no feeling (so far) against or pro deleteTCB. If it states in the TCP MIB, I don't see why it shoud be removed in the SCTP MIB, since you have the same "need" of removing the assoc/conn in both protocols.

- - Should scalars be re-arranged and put into several different groups?
[MCarmen] Right now, SCTP MIB has defined 1st the paramters and then the statisctics when talking about scalars. I think this split make very clear for implementors/readers the parameters and statistics and also, you ahve the letters "Stat" to clearly indicate that it is an statistic. I don't see what is wrong in it. 

  sctpMib
    - sctpParameter 
        - sctpRtoAlgorithm
        - sctpRtoMin 
        - sctpRtoMax
        - sctpRtoInitial
        - sctpMaxAssoc
        - sctpValCookieLife
        - sctpMaxInitRetr
    - sctpStats
        - sctpCurrEstab
        - sctpActiveEstabs
        - sctpPassiveEstabs
        - sctpAborteds
        - sctpShutdowns
	- sctpOutOfBlues
	- sctpChecksumErrors
	- sctpSentCtrlChunks
	- sctpSentOrderChunks
	- sctpSentUnorderChunks
	- sctpRecCtrlChunks
	- sctpRecOrderChunks
	- sctpRecUnorderChunks
	- sctpFragmentedUsrMessages
	- sctpReassembledUsrMessages
	- sctpSentSCTPPacks
	- sctpRecSCTPPacks

- - It might be helpful to draw a Case diagram to explain how the
  various counters are related to each other.
Why is TCP not including this? Could you give me a pointer of this?

- - The description of sctpMaxAssoc talks about the special value -1
  which conflicts with the type Unsigned32.
[MCarmen] Right. Fixed.

- - Change sctpStatSentSCTPPacks to sctpPktsOut and sctpStatRecSCTPPacks
  sctpPktsIn?
[MCarmen]OK, I'll change "Sent" and "Received" by "Out" and "In". But I don't see why I should remove "Stat" from the name when it makes it clearer for readers that they are statistics.

- - Change sctpStatFragmentedUsrMessages to sctpFragMsgs and
  sctpStatReassembledUsrMessages to sctpStatReasmMsgs?
[MCarmen] Same comment as above

- - Change sctpAssocLocalSCTPPort to sctpAssocLocalPort and
  sctpAssocRemSCTPPort to sctpAssocRemPort?
[MCarmen] OK

- - Change sctpAssocId to exclude the value 0. This allows other MIBs to
  reference associations and to use the value 0 to indicate no
  association. You may even want to consider to introduce TC for
  SctpAssocIndex and ScptAssocIndexOrZero.
[MCarmen] I could limit the range of SctpAssocId [1..] or just leave Unsigned32 and clarify with a comment the reserved value 0. I think the 1st option is better.

- - The notion of a NULL value in sctpAssocRemHostName is unclear. Do
  you mean a zero-length string? If yes, please use the phrase
  zero-length string rather than NULL value.
[MCarmen] OK, Fixed. it was zer-length string.

- - Is it possible to have an unknown sctpAssocLocalSCTPPort values? If
  not, you may want to refine the range to InetPortNumber (1..65535).
[MCarmen] I took the fact from RFC2851 "The value zero is object-specific and must be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter."

- - Is it possible to have an unknwon sctpAssocRemSCTPPort value? If
  not, you may want to refine the range to InetPortNumber (1..65535).
[MCarmen] Same comment as above

- - The descriptions of sctpAssocRemPrimaryAddressType and
  sctpAssocRemPrimaryAddress say that the values are filled in after
  INIT or INIT ACK chunks have been received. So what is the value
  before these chunks have been received?
[MCarmen] Should it be specified? I think it is implementation dependent, it can be all zeros, or all 255, or whatever, the important thing is that the content is valid only after these chunks (init time) are received.

- - See above for my comments whether deleteTCB is really needed in
  sctpAssocState. (Usually, people delete the application which holds
  the association rather than the association itself.)
[MCarmen] HHmmm, I don't agree with this, you can have M3UA (let's say in a SGw-signaling GW) on top of SCTP serving to different applications (as SCCP, ...), with several associations towards different remote M3UA peers (let's say in MGws - Media GW). You may want to remove only one association to a M3UA peer (in the remote MGw), due to a change in the the configuration or whatever, but you shouldn't be forced to tear down the whole application.

- - I propose to add a column to the sctpAssocTable which gives a
  pointer to the primary system level process which holds the
  association endpoint, e.g.
[MCarmen] OK.

  sctpAssocPrimaryProcess OBJECT-TYPE
      SYNTAX	 Unsigned32
      MAX-ACCESS read-only
      STATUS	 current
      DESCRIPTION
          "The number identifies the system level process which
	   holds primary responsibility of the SCTP association.
	   Wherever possible, this should be the system's native
	   unique identification number. The special value 0 can
	   be used to indicate that no primary process is known.

	   Note that the value of this object can be used as a
	   pointer into the swRunTable of the HOST-RESOURCES-MIB
	   (if the value is smaller than 2147483647) or into the
	   sysApplElmtRunTable of the SYSAPPL-MIB."
      ::= { sctpAssocEntry 16 }

- - Change sctpAssocLocalAddressIPType to sctpAssocLocalAddressType
  and sctpAssocLocalAddressIP to sctpAssocLocalAddress?
[MCarmen] "IP" are only 2 letters and let clear the address type. It also appears in this way in the RFC2851update. don't you think it is better? 

- - What is the motivation for the upper size limit 64 of
  sctpAssocLocalAddressIP and sctpAssocRemAddressIP?
[MCarmen] There is no real motivation. I asked in the London meeting why you limited the size to 36 and you told me you had to choose one value and you chose 36. I chose 64, but maybe for alignment I should write down 36 as well.

- - Change sctpAssocRemAddressIPType to sctpAssocRemAddressType and
  sctpAssocRemAddressIP to sctpAssocRemAddress?
[MCarmen] Same comment as above with "IP"

- - You list in several places a subset of the enumerations of the
  InetAddressType TC in the DESCRIPTION clauses. Does this imply that
  values not listed there are illegal? If you want this (not sure this
  is really a good idea), then you should formally specify the subset
  in the SYNTAX clause.
[MCarmen] The real issue is that we don't want to support DNS names here, so we list all the valid values, and the rest are considered not valid. I can change the comment to the one you have included in the TCP MIB: "...Only IPv4 and IPv6 addresses are expected.", but IMHO, specifying the values that are considered valid is clearer.

- - Contains sctpLookupLocalPortStartTime and sctpLookupRemPortStartTime
  really "the time this row was created" or the start time of the SCTP
  association (sctpAssocStartTime)? If the later is true, than you do
  not really define new objects for the time stamps.

- - If you follow the new registration scheme, then you may want to rename
  some conformance groups (sctpGeneralVariablesGroup -> sctpParamterGroup,
  sctpStateStatGroup + sctpOtherStatGroup -> sctpStatisticsGroup).

- - Change sctpAssocTablesVariablesGroup to sctpAssocTableGroup?

- - What is the motivation for having a sctpAssocStatGroup?

- - I have difficulties to understand the compliance statement. There
  are two mandatory groups and several conditional mandatory groups
  where the DESCRIPTION does not describe under which condition they
  are mandatory. Looks to me like some of them should be mandatory to
  begin with.

- - I have problems with the way the sctpAssocRemPrimaryAddressType,
  sctpAssocLocalAddressIPType, sctpAssocRemAddressIPType restriction
  in the conformance statement is written down. I would like to see a
  clearer statement that address with zone indices are required if an
  implementation can connected multiple zones. I think it should not
  be allowed that some SCTP connections are not visible because of
  similar addresses in multiple zones.
[MCarmen] OK, I'll add the statement, though maybe it sould be better not to limit the address type in the conformance, what do you think?

- - The security considerations section talks about read-create but I
  think there are no read-create objects left. Rather than copying
  just the boilerplate, it would be nice to list which objects are
  especially sensitive.
[MCarmen] Yes, I think you are right, maybe it is better.

- - The changes section says:

    o All counters to Counter32 to be backward compatible, not to waste
    memory. Operators needing more than 32 bits will do it by
    augmentations.

  I believe this is the wrong decision. Some of your counters are
  going to roll over pretty fast and thus they are useless. And
  bandwidth is increasing - so better be prepared for the future. The
  DiffServ MIB switched completely to 64 bit counters. Design for the
  future not for the past. I believe you should have 64 counters. You
  may want to have 32 bit counters in addition if SNMPv1 only
  implementations have to be supported - this is the WGs choice.
[MCarmen] Righ, this is a WG choice. I talked to Shawn in the London meeting and he told me that it should be my decision (or the group decision) based on the rules for choosing Counter32 or Counter64 and the need to be backward compatible. I choosed Counter32 after talking to the chairman, in order to be backward compatible, but maybe it should be questioned in the mailing list.

/js

thanks a lot again,
MCarmen
------- End of forwarded message -------

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Muehlenpfordtstr. 23, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <http://www.ibr.cs.tu-bs.de/~schoenw/>

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