Subject: Re: SCTP MIB

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

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

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

RFC 2452 was an attempt to make a TCP-MIB extension suitable for
IPv6. Many people now believe this went into the wrong direction.
This is why efforts are underway to revise the original TCP-MIB so
that it works with any version of IP.

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

sctpScalars does not add anything useful. You should either group
scalars so that those scalars which you typically access together have
a common root node, or you register them directly below your *Objects
branch. Note that I proposed a more useful grouping below.

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

The point is whether deleteTCB was ever implemented and whether
managers use it. I am still waiting for someone to report that (a)
they actually support deleteTCB in the TCP-MIB and (b) that they have
managers which use it.

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

My proposal goes back to the previous comment that I believe
sctpScalars itself is kind of useless. My proposal was to separate
scalars from parameters and thus giving the intermediate node(s) some
justification. (In fact, some code generators on the manager side will
now generate different API calls for paramters and statistics, which
is a good think.)

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

Case diagrams explain the relationship between counters. Most SNMP
books explain how they work. The point is that I want to understand
how the counters interrelate and I am not sure yet all this
information is in the description.

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

I am asking again: In which cases can you have an SCTP association
without knowing the port numbers?

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

I think it should be defined and I propose that it be the zero-length
string.

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

The data type already says that it is an InetAddress. Does SCTP run
over any other non-IP protocols? Note as well that
sctpAssocRemPrimaryAddress does not include "IP".

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

I see. I have no strong feeling for 36 or 64. (The fact that we have
to put in arbirary restrictions here is in fact a problem in the SMI.)

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

If you want to restrict the values, then you can do it formally in the
compliance statement by saying SYNTAX InetAddressType { .... }. This
way, you are still open for extensions. Note that the current
statements in the conformance section still allow for DNS names...

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

I have no problem to further restrict the type in the conformance as
long as the description says clearly under which conditions this
restriction in OK and under which conditions not.

Maria-Carmen> - The changes section says:

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

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

Yes, please revisit this decision since I believe it points into the
wrong direction. We have been doing Counter32/Counter64 combinations
for some time now for things that could wrap in less than an hour.
Diffserv now decided to only do 64 bit counters.

/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]