Subject: RE: [Tsvwg] AD review of: draft-ietf-sigtran-sctp-mib-07.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 2 Sep 2002 17:07:15 +0200

inline

> -----Original Message-----
> From: Maria-Carmen Belinchon [mailto:[email-masked]]
> Sent: maandag 2 september 2002 16:11
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; Shawn Routhier (E-mail)
> Subject: Re: [Tsvwg] AD review of: draft-ietf-sigtran-sctp-mib-07.txt
> 
> 
> Hi,
> 
> Thanks for a so detailed review.
> 
welcome

> Only included comments where remarks exist,
> 
replies inline too

> 
> > More or less serious issues:
> > - You must decide what to do with the DeleteTCB.
> >   We cannot leave it as an open issue when doc goes to IESG
> >   And this of cours eimpacts last para of sect 3.1.3.1
> 
> It's not an open point. It was already discussed and we 
> agreed that it remains in
> the MIB, if it's demostrated that none implements it then it 
> will be removed when passing to Draft Standard.
> 
Fine... I guess the item should then be removed as an "open issue", no?

> 
> > - I am missing a reference to the/a discontinuity timer object
> >   for your Counters. Such is needed as per RFC2978, sect 7.1.6
> >   and sect 7.1.10
> 
> I guess this RFC number is not correct
> 
Appology. too fast typing. It should be RFC2578 of course, the SMIv2 doc

> 
> > - A number of objects like sctpRtoMin, sctpRtoMax etc have
> >   as data type Unsigned32. That means it can have a value of zero.
> >   I wonder if a zero value makes sense. If it does, then maybe
> >   it has special meaning? If so then pls describe. If it
> >   does not make sense, then better add a range to exclude it.
> >   I also wonder if a value of 1 or 2 millisecodns or such makes
> >   sense. If not, maybe say some words about it or add a lower range
> >   that sort of specifies the minimum that makes sense.
> >   Does Max have to be GE than Min ??
> 
> We didn't want to remove zero value in some objects to allow 
> implementations to have zero for any proprietary use.

That does NOT sounds good for a STDs track document, or so this AD feels

> But maybe we could change some of the objects to
> avoid misuses. Let's see this proposal:
> 
> - sctpRtoMin  Unsigned32 (500..65535)
> The recommended minimum RTO value in the SCTP RFC is 1000 milliseconds,
> the maximum is 60000 milliseconds, and the default value is 30000 
> milliseconds. We could configure all RTO objects to include these RFC
> recommended  values but not being so restrictive.

Think about it as if you were a new reader/implementer who wants to 
implement a STDs track MIB. If you want to allow 0..65535, that is OK,
but a new reader (as I was...) wonders what a very small and specifically
a zero value means or how it behaves. So you want to specify that.

> That is 500-65535 milliseconds. But then it avoids Brian's implementation
> to use zero.

but if that is a proprietary things, then that is NOT GOOD for a stds track
MIB.

> I think we could add a DEFVAL clause for it 
> (set to 1000 milliseconds)
> 
If a DEFVAL makes sense and is agreed to, then I would indeed recommend 
to do so.

> - sctpRtoMax   Unsigned32 (500..65535)
> I think we could add a DEFVAL clause for it (set to 60000 
> milliseconds). Again the
> limitation avoids Brian's implementation to use zero.
> 
> - sctpRtoInitial  Unsigned32 (500..65535)
> I think we could add a DEFVAL clause for it (set to 30000 
> milliseconds). Again the
> limitation avoids Brian's implementation to use zero.
> 
> - sctpMaxAssoc Unsigned32
> I'd change the TYPE to Unsigned32 to avoid using a wrong 
> number, then the
> DESCRIPTION should be changed to "The limit of the total 
> number of SCTP
> associations the entity can support. In entities where the 
> maximum number of
> associations is dynamic, this object should contain the value 0."
> 
> - sctpValCookieLife Unsigned32 (500..65535)
> Recommended value is 60000 milliseconds, so we can limit to 
> the same range as for RTO.
> DEFVAL clause?
> 
> - sctpMaxInitRetr
> Zero value has to be allowed to indicate no retransmissions.
> 
I would Specify (spell out) that that is what it means

> - sctpAssocHeartBeatTimer
> Recommended value is 30000 milliseconds, so we can limit to 
> the same range as for
> RTO. Then we limit the individual solutions as the Brian's one.
> 
> - sctpAssocInStreams
> At least one stream should be configured as incoming, but we 
> could keep value zero in case applications want to use this
> value to mean that it's in the start up phase
> and the negotiation has not finished. I could modify the 
> DESCRIPTION to "Inbound
> Streams according to the negotiation at association start up. 
> Value zero is
> reserved for start up phase when the real value is being negotiated."
> 
Spelling out what such a zero value means (in cases where it is not obvious)
is very useful I would think.

> - sctpAssocOutStreams
> The same as before: "Outbound Streams according to the 
> negotiation at association
> start up. Value zero is reserved for start up phase when the 
> real value is being negotiated".
> 

> - sctpAssocMaxRetr
> No modification. Zero value means no retransmissions.
> 
> - sctpAssocRemAddressRTO
> Change to RTO above modifications: Unsigned32 (500..65535)
> 
> - sctpAssocRemAddressMaxPathRtx
> No modification. Zero value means no retransmissions.
> 
> > - sctpAssocRemHostName is OCTET STRING
> >   Mmm... currently I believe DNS names are US ASCII
> >   If that gets changed in the future, then I would assume it would
> >   possibly some form of UTF-8 ?? Not sure what the best approach
> >   is here... but at least I would like to make the WG aware of
> >   OCTET STRING meaning that it can be any string of octets. So
> >   please make sure to think about this before you decide.
> 
> We could use the DNS behaviour and indicate this in the 
> DESCRIPTION clause.
> 
> There are no more comments to yours remarks. Still left the 
> Compilation Notes, I'll go through it today.
> 

OK. so in general, I think it is clear I do want to see what all the 
zeroes would mean if it is not obvious. 

Bert
> br,
> MCarmen
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 2 Sep 2002 18:48:42 +0200

Hi Bert, 

Please, see my comments inline...

> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, August 26, 2002 5:45 PM
> To: [email-masked]
> Cc: Shawn Routhier (E-mail); Bert Wijnen (E-mail)
> Subject: [Tsvwg] AD review of: draft-ietf-sigtran-sctp-mib-07.txt
> 
> 
> I have tried to not duplicate SHawn's comments. Appology if 
> by accident I do have a duplicate.
> 
already answered by MCarmen.

> - Your MODULE-IDENTITY macro MUSt include a REVISION clause.
>   I would suggest to change:
>       DESCRIPTION
>            "The MIB module for managing an SCTP implementation."
>       ::= {  mib-2 xxxx } -- IANA needs to choose this value
>                           -- when sent to the RFC editor
>   into:
>       DESCRIPTION
>            "The MIB module for managing an SCTP implementation."
>       REVISION "200202060000Z"       -- 06th February 2002
>       DESCRIPTION " Initial version, published as RFC XXXX"
>       -- RFC Editor to assign XXXX
>       ::= {  mib-2 xxxx } -- IANA to assign xxxx
>   Pls keep in mind that REVISION date must be same as LAST-UPDATED.
> 
Agreed.

>   for your Counters. Such is needed as per RFC2978, sect 7.1.6

Are you referring to RFC2578? Anyway you are right, we should include this timer.

>   Does Max have to be GE than Min ??

Yes, we will specify this point in the description
> 
> - sctpMaxAssoc (why not name it sctpMaxAssociations ??)
>   I guess valid values are -1, and 0-0x7fffffff ??
>   If so, then probably best to specify so as a range
> 
We'll add the range here. Do you see it's worth to have 0 as a valid number for the sctpMaxAssoc? If so, things can be kept as today: "-1" means no limit. The other option is to assign "0" to mean no limit.

> - sctpAssocId is an Unsigned32. Value zero is reserved for
>   "no association". But this is an INDEX object. So first
>   of all, we do not want zero as an index in a table, but second,
>   what would a zero entry represent?
>   Shawn does discuss this too.

That's right. We'll correct it.

>   By the way, what is "Initiate Verification Tag" ??
>   Probably known to SCTPers, but not to me... Maybe add a 
>   REFERENCE clause to where it is defined.
> 

Initiate Verification Tag is a unique value that could identify every assotiation univocally. We'll include the reference.

> - sctpAssocRemPrimaryAddressType DESCRIPTION clause talks about 
>   "destination", I think it better uses "remote" instead. 
>   And the 2nd para of this DESCRIPTION is not parsable by me. 
>   Is it real english?
>   But more serious...
>   - The 2nd sentence of the DESCRIPTION clause can be removed.
>     You have IMPORTed this data type from INET-ADDRESS-MIB
>     so everyone understands that they need to look there to
>     find out what it exactly means.
>   - I would think that untill the value is know, that this
>     object gets value unknown (0). And as long as this
>     is zero (unknown) the value of sctpAssocRemPrimaryAddress
>     should probably be the zero length OCTET STRING.

It is not possible that this variable has the value = "unknown". WHen ever you are ready to send an INIT or when you send the INIT ack, you already know at least one local/remote address. Thus we will remove it.

>   - What are you trying to say? That you only support or
>     recognize IPv4 and IPv6 addresses? If so, then pls do say
>     so and refer to types ipv4 and ipv6. So the only values
>     that have to be supported are unknown, ipv4 and ipv6
> 
Agreed.

> - sctpAssocRemPrimaryAddress DESCRIPTION clause talks about 
>   "destination", I think it better uses "remote" instead. 
>   But more serious:
>   - The 2nd sentence I think better be worded as: The type 
>     of this address is determined by the value of 
>     sctpAssocRemPrimaryAddressType.
>   - Explain that the value will be the zero length OCTET
>     STRING untill a known value is received.
> 

After all transport addresses are derived from the INIT or INIT ACK chunk using the above rules, the endpoint shall select one of the transport addresses as the initial primary path. This means that there is a time when this address is unknown. Therefore here we should include this value as well as the zero length octet string you mention.

>   what would a value of zero mean?
>   do values like 1 or 2 milliseconds make sense?
> 

Since the recommended value is 30 seg, I'm afraid this values have not too much sense. But nevertheless from my point of view is not worth to put a low limit to this value.

The zero value is an special case, and I think we may exclude it.

> - sctpAssocState
>   Instead of saying "it is appropriate to return badValue"
>   I think it is better to say: "If any other value is
>   received, then the agent must return a badValue error""".
>   I believe that it is common practice that lots of agents do
>   accept a SET for a value that is exactly the same as the
>   current value (it basically is a NO-OP) and so they would
>   return noErr. If you wanto allow that, then a note to that
>   extend is a good idea.
>   

Agreed. But I would include it in Section 3, is it OK for you?

> - The counters in the sctpAssocTable also need to specify which
>   timer object fiunctions to indicate discontinuity.
> 

Yep. Still pending. We'll add them.

> - sctpAssocLocalAddressType DESCRIPTION clause
>   - remove 2nd sentence
>   - "when the endpoint does still not determeined the address"
>     I cannot parse
>   - "This will be filled in after the INIT or INIT ACK ...."
>     I do not understand this. This is an INDEX column. I would
>     think that as long as you have not reeived the INIT or 
>     INIT ACK, then there seems to be no value to me to have
>     an entry at all, does it?

It's upon the reception of INIT and INIT ACK, when your association (client and server sides respectively) starts making sense, and the time when you create the entries in the MIB.

>     So entries would (in my view) only show up when there
>     is real (INDEX) information available.
> - sctpAssocLocalAddress DESCRIPTION clause
>   - 2nd sentence to be replaced by: The type of this address 
>     is determined by the value of sctpAssocLocalAddressType.
>   - Again, since this is an INDEX object, it seems to me
>     that you would only instanciate an instance once you
>     do have received the INIT or INIT ACK, and so no need
>     to talk about unknown values. It sounds to me as if
>     you only support ipv4 and ipv6 values (but I am not 100%
>     sure of that... so you probably can tell me).

Right. Only ipv4 and ipv6. At least one address for each (local and remote) will be included when the association table is created.

>   - In any event, a "zero value" is kind of a strange concept
>     for a data type (TC) that has an OCTET STRING as the 
>     underlying base data type. Better explain what zero means
>     if you do want to use that.

We'll improved this description.

>   - Last sentence, probably better: The sctpAssocLocalAddress
>     may not be empty due to the SIZE restriction
>   - Shawn discusses some of this as well
> 
> - sctpAssocRemAddresstable
>   - same story about the indexing objects as above
>     for the index objects in LocalAddressTable
> 

OK.

> - sctpAssocRemAddressStatus
>   Enumerations are prefered to start at 1 and not at zero
>   (see RFC2578 sect 7.1.1.)
>   Instead of your own enumeration, you could use
>      sctpAssocRemAddressActive
>          SYNTAX TruthValue
>   A reference to RFC2960 is better made using the 
>   REFERENCE clause as per RFC2578, sect 7.6
> 
Agreed.

> - sctpAssocRemAddressHBFlag
>   same story as for sctpAssocRemAddressStatus.
>   Instead of your own enumeration, you could use
>      sctpAssocRemAddressHBActive
>          SYNTAX TruthValue
>   A reference to RFC2960 is better made using the 
>   REFERENCE clause as per RFC2578, sect 7.6
> 
Agreed.

> - sctpLookupLocalPortTable DESCRIPTION clause
>   I think I understand what you mean to say
>   but it sounds weird in my ears (maybe it is just me)
>   May I suggest:
>     This table allows a management application to find out
>     all the associations that use a specific local port.
> 
> - sctpLookupLocalPortEntry DESCRIPTION clause
>   I think I understand what you mean by the 2nd sentence,
>   but it sounds a repeat of what is in the table description
>   May I suggest for DESCRIPTION:
>     Each entry represents the mapping of one association
>     to a specific local port.
>     
> - sctpLookupLocalPortStartTime
>   do you need this object? Is it not the same value as one
>   would find in sctpAssocStartTime?  If so, then the question
>   is: would a mgmt app want to find just all the associations
>   per port and the startTime for such associations.
>   If the answer is: yes,then fine.
>   If the answer is no, it would need/want to know more about
>   the associations, then it needs to go to the assoc table
>   anyway and can pick up the time from there
>   If the answer is: but we need at least one readable object,
>   then maybe the question is: is this the best/most usefull
>   object? Would assocState not be more usefull?
> 

It was the third approach. But you're right...

> - Similar questions for the other reverse lookup tables.    
> 
> - In the MODULE-COMPLIANCE
>   - change "SNMPv3" in "SNMP".
>   - The discussion about only IPv4/IPv6 and such belongs in another
>     place. Namely in the OBJECT clauses, as in fact you already do.
>     I think I would write the MODULE-COMPLIANCE as follows:
>       sctpCompliance MODULE-COMPLIANCE
>         STATUS  current
>         DESCRIPTION
>            "The compliance statement for SNMP entities which implement
>            SCTP MIB."
>   - I find the optional groups in the MODULE compliance strange.
>        They say: "This will be implemented when statistics 
> are required"
>        and "This should be implemented.... when it is required"
>     But it is the task of the COMPLIANCE statement to specify when it 
>     is or is not required. Possibly you want to indicate that these
>     groups are optional. If so, then just say that they are
>     optional at the discretion of the implemneter.
>     I think however that I would rather make them mandatory, so all
>     groups would (in my view) better be mandatory... 
> 
>   - The OBJECT clauses like:
>            OBJECT  sctpAssocRemPrimaryAddressType
>            SYNTAX  InetAddressType { unknown(0),
>                                      ipv4(1),
>                                      ipv6(2)
>                                    }
>            DESCRIPTION
>                 "It is only required to have IPv4 and IPv6 addresses
>                 without zone indices. Unknown values must also be
>                 supported in case the IP address has a zero 
> string length
>       s/IP address/Internet address/
>       s/zero string length/zero length string/
>                 or an invalid/unknown format.
> 
>                 The address with zone indices is required if an
>                 implementation can connect multiple zones."
>    
>     is great. But you also need (I think) to add the same restriction
>     for the Address itself, aka
> 
>            OBJECT  sctpAssocRemPrimaryAddress
>            SYNTAX  InetAddress (SIZE(0|4|16))
>            DESCRIPTION
>                "An implementation is only required to support globally
>                 unique IPv4 and globally unique IPv6 addresses."
> 
>   - Same for other address types/addresses
> 
OK.

>   - For the object  sctpAssocState, you can formally indicate that
>     only one enum is writable, namely:
>            OBJECT    sctpAssocState
>            WRITE-SYNTAX  INTEGER { deleteTCB(9) }
>            DESCRIPTION
>                "Only the value deletedTCB(9) can be written"  
>
Right.

The rest of your comments seems also reasonable to me. Your input is very valuable.

Thanks a lot for your comments. We'll issue a new version ASAP and send it out to the list for new comments.

Cheers // Javier.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 2 Sep 2002 21:15:39 +0200

Inline, for thos items that needed a response.
Other items clipped out

> From: Javier Pastor-Balbas (ECE)
.. snip ..
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
.. snip ..
> already answered by MCarmen.
Yep and answered by me again
I.e. need to remove it as an "open issue" I think.

.. snip ..
> Are you referring to RFC2578? Anyway you are right, we should 
Yep, mistyped the RFC number

.. snip ..

> We'll add the range here. Do you see it's worth to have 0 as 
> a valid number for the sctpMaxAssoc? If so, things can be 
> kept as today: "-1" means no limit. The other option is to 
> assign "0" to mean no limit.
> 
Not sure... WG needs to decide if zero has a usefull meaning.
As long as you specify what such (non-obvious) values mean
then I think I am OK with it.

.. snip ..
> Since the recommended value is 30 seg, I'm afraid this values 
> have not too much sense. But nevertheless from my point of 
> view is not worth to put a low limit to this value.
> 
Good, either exclude it or be explicit as to what it means

> Agreed. But I would include it in Section 3, is it OK for you?
Section 3 is "explnantory text". You can add it there if you want.
But this sort of info is important to have in the MIB itself too,
so that implemented can immediately see what to do when they are
implementing a specific object.

Also, people who ever extract the MIB will not have section 3, 
and possibly will have to be able to understand what is happening
by just lookinmg at the DESCRIPTION clause.

.. anip ..
> It's upon the reception of INIT and INIT ACK, when your 
> association (client and server sides respectively) starts 
> making sense, and the time when you create the entries in the MIB.
> 
But once you have an entry (that migth be incomplete and have incomplete
 value for this index field), then it is an entry, and you do not
change the index, but would create another entry with other index....

See where I am coming from?

> Right. Only ipv4 and ipv6. At least one address for each 
> (local and remote) will be included when the association 
> table is created.
> 
See above... 

> We'll improved this description.
Thanks

.. snip ..

> Thanks a lot for your comments. We'll issue a new version 
> ASAP and send it out to the list for new comments.
> 
looking forward to that

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 2 Sep 2002 23:07:33 +0200

Inline

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: woensdag 28 augustus 2002 12:31
> To: Wijnen, Bert (Bert)
.. snip ..

> On another note, I would like to see the SCTP MIB come into
> much closer alignment with the TCP MIB.
> 
My understanding was that the authors have been in touch with the 
team that is developing the new TCP MIB (IPv4/IPv6 capable).
Shawn is part of that team too... so maybe he can say a few
words on the exact status of that.

Bert

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 5 Sep 2002 16:53:22 +0200

Hi Bert, 

Regarding to discontinuity timers, I think that we had a similar value called the sctpAssocStartTime, that indicates the time when the association gets the established state (this improved description will be included in the next version). Anyway since discontinuities can happen and not be catched by this variable, we'll add a new discontinuity timer inside the association table. We will also add a comment in the DESCRIPTION clause for every counter within this table to refer to this Time and therefore check the possible discontinuities per association basis. Is that right for you?

Probably a similar object should be introduced for counters included in the revised TCP MIB, don't you think so?

Cheers // Javier.

> Sent: Monday, September 02, 2002 9:16 PM
> To: Javier Pastor-Balbas (ECE); 'Wijnen, Bert (Bert)'; [email-masked]
> Cc: Shawn Routhier (E-mail)
> Subject: RE: [Tsvwg] AD review of: draft-ietf-sigtran-sctp-mib-07.txt
> 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 5 Sep 2002 19:42:54 +0200

Inline

> [mailto:[email-masked]]
> Sent: donderdag 5 september 2002 16:53
> To: 'Wijnen, Bert (Bert)'; [email-masked]
> Cc: Shawn Routhier (E-mail); Maria-Carmen Belinchon-Vergara (ECE)
> Regarding to discontinuity timers, I think that we had a 
> similar value called the sctpAssocStartTime, that indicates 
> the time when the association gets the established state 
> (this improved description will be included in the next 
> version). Anyway since discontinuities can happen and not be 
> catched by this variable, we'll add a new discontinuity timer 
> inside the association table. We will also add a comment in 
> the DESCRIPTION clause for every counter within this table to 
> refer to this Time and therefore check the possible 
> discontinuities per association basis. Is that right for you?
> 
Well, that at least addresses the issue. What you might want to
ask yourself is: is a disconituity timer needed per association,
or would one per table be sufficient?
Mgmt apps will have to poll the discontinuity timer with 
each counter type object they poll, so it would be less traffic
if you have one per table. But if it makes sense to have one per 
association, then of course youy should define them at that lvl

> Probably a similar object should be introduced for counters 
> included in the revised TCP MIB, don't you think so?
> 
Pls feed that into that effort as well.
Shawn, can you check that too please?

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 25 Sep 2002 15:15:00 +0200

FYI, I see that Shawn Thanks Shawn for picking up the ball) 
is now discussing this topic on the IPv6MIB (design team)
mailing list. So hopefully he'll come back with 
feedback and/or an answer.

Thanks,
Bert 

> Sent: maandag 23 september 2002 17:15
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; Shawn Routhier (E-mail);
> [email-masked]
> We're updating the SCTP MIB with the last comments but still 
> need some input
> from TCP.
> 
> br,
> MCarmen
> 
> "Wijnen, Bert (Bert)" wrote:
> 
> >
> > > - Maximum number of associations
> > > TCP MIB defines:
> > > tcpMaxConn OBJECT-TYPE
> > >     SYNTAX     Integer32 (-1 | 0..2147483647)
> > >     MAX-ACCESS read-only
> > >     STATUS     current
> > >     DESCRIPTION
> > >            "The limit on the total number of TCP 
> connections the entity
> > >             can support.  In entities where the maximum number of
> > >             connections is dynamic, this object should contain the
> > >             value -1."
> > >     ::= { tcp 4 }
> > > When trying to align with TCP, the question is what 0 means
> > > here. Actually, we were thinking of limiting the object to
> > > Unsigned32, where 0 means that the maximum number of
> > > associations is dynamic. What is the advantage of
> > > the TCP approach?
> > >
> > I did not yet get the TCP MIB for review. I would indeed have the
> > same questions as I asked about your MIB.
> > Shawn, since you also participate on the TCP mib work???
>