Subject: [Sip] FW: Review Comments on draft-ietf-sip-mib-07

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Aug 2003 11:30:40 -0700

First I would to say thanks to the folks that put so much work into this
draft. After reviewing it, I am sure it was a lot of somewhat thankless work
and I like it. I'm going to split my comments up into somewhat major topics
and minor things. I should probably go through stuff in more detail but here
are some initial comments to get things going.

Major Things - some of these are quite debatable so debate them :-)

There is not enough in the MIB to configure any UA or Proxy I have seen. I
don't think this is a problem but I think we should make the configuration
aspect of the MIB optional but the diagnostic and reporting aspect
mandatory. If we decide that configuration is part of what we are doing
here, we need a bunch more stuff. I think we should make this targeted at
status and debug instead of configuration - this would significantly
simplify the MIB.

There are mechanisms to deal with new methods - why no just use these for
all the methods including known ones. It would simplify the MIB and
implementations to be able to deal with things in a uniform generic way
instead of having separate code for OPTION and INVITE.

Why not just report stats for responses based on an array of 100 to 699.
This again would allow very generic treatment. For some things, like 4xx,
responses aggregating all the 4xx into one count does not provide good
information because things like 401 are very normal while other 4xx
correspond to problems.

In all the counts, I don't think we should include retransmissions and we
should have a few counters to do with the UDP transport that take care of
retransmission stats.

Many proxies can control more than one domain at the same time. Need to
support this. 

The UA stuff confuses, registrars, outbound proxies and such - actually
these have been confusing in various version of SIP documents so not
surprising - need to clean up a bit.

Need to work through what things need notification attached to them and what
the filters should look like. For example, I might want to find out if my
invites per second goes above or below a certain value and how often I will
get notified while it out it's normal range.

Minor Things

Most proxies have some sort of dial plan table. Should we support reading
this table as a table of strings but not specify the format for the strings?

Could have flags indicating if enum was done.

The term session is used a little inconsistently with 3261 - suggest that
most places session occurs we replace with dialog.

Proxy/Redirect server - I don't see any value in separating these. I would
just make Redirect a special case of Proxy and not split it apart in the MIB
at all. 

I'm not sure that I really see Proxy and Registrar being very different
other than a Proxy that does not do Registration may have 0 values for a
bunch of things. 

Can you find the number of bad message a proxy has received.

Number of TCP or TLS session failures.

Getting information about the active dialogs on a UA.

Getting information about the previous call on a UA.

Setting log levels.
 
Section 5 - sipCommonStatsOther - lat word of para - replace URIs with
methods

Section 5 -  SipProxyCfg - Canceling branches is not optional and there is
no need to control it from the MIB

If we go down this strange path of sip_proxy_redirect names, I think we need
to provide a ordering of them so that everyone says sip_proxy_redirect and
no one says sip_redirect_proxy.

All the examples that have domain names like ss8.com or cisco.com need to be
changed to example.com.

P19 - sipOrganization - should this be in UA only mib

P19 - maxSipSession - do you mean dialogs or transaction

P19 - sipRequestUriHostMatching  - a proxy that did not do this would be in
violation of the RFC. Don't think we need this.

P21-22 - sipTransportRcv and Snd. I think it is bogus to specify if you can
receive or send on a given port. In things other than UDP this has no hope
of working. In UDP it is of very little use given where we are going with
rport. 

P22 sipPortStatus - making a special exception for 5060 is not right. If
more than one SIP thing is running on the same host, one of them will not be
on 5060. 

P23 sipUriSupported stuff - you have to do sip - why not just make a flag
that indicates if tel is supported or not.

P27 - SipCommonCfgTimerEntry -  Is being able to change all the timers
really a good idea - I don't have an opinion this - I'm just raising the
question.

P 32 - I think per method timers are a bad idea.

P 34 - I think per method retry counts are a bad idea.

P 37 - per method Expires seem like a dubious idea - the app should know how
to set these - I don't see configuration being needed for them

P38 - sipCfgExpiresInvite - proxy should not change this - seems like UA
only at best 

P38 sipCfgExpiresRegister - this is something that the registrar does need
to configure (and perhaps the UA) but not the proxy. The text that the
header value wins on a registrar is wrong.

P 38 - sipCfgExpiresHeaderMethod - this is a strong indication we went down
the wrong path somewhere - I don't like this, not on a train, not ...

P 39 - sipCommonCfgExpiresStatusCodeEntry - no no no this is not right -
this cat should not be in the MIB.

P 42 - sipSummaryTotalTransactions counting forked request as one
transaction is wrong

P 43 - SipMethodDtatsEntry - don't think these should include
retransmissions

P 58 - sipCurrentTransaction - the forked requests are not the same
transaction

P 76 - sipUACfgSipServerAddress - is this the AOR? Where to send the
registration? The outbound proxy? The auth domain for digest? I think this
needs to be broken into a bunch of things. What about UA that can register
to multiple proxies. What does the contact get set to.

P 83 - sipRequestMeaxExpires - in what context? Would need to split this up
- not sure I see any value in it

P 83 - sipProxyStatefulness - give the RFC forces proxies to switch mode - I
am really lost at what this would report or how it be of much value. The
concept of it being read-write is particularly hard for me to imagine.

P 84 - sipProxySendsCancels, sipPRoxyForwardAll1xx - these just seem plain
wrong 

P 84 - sipProxyRecurions - I like this one :-)

P 85 - sipRpxyProvieAlternatives - sounds like a bad idea

P 85 - sipProxyRecrodRoute - I'm very dubious on this one - a proxy would
need to do this because it was doing something that required it. In this
case it' can't run it off and otherwise it probably should be off.

P 86 - sipProxyAuthMethod - bit 1 should probably say mutual TLS, S/MIME is
not yet defined for end to middle auth. I really doubt these bits are enough
to control how say mutual TLS would work

SipProxyNonceLifeTime - a max of 65 seconds is too short - do we really need
this in the mib

P 87 sipNumProxyRequiresFailures - I like this one

P 88 SipRegAllowThridParty - not sure I see the need for this

P 89 sipRegmaxContactExpireyDuration - should not have a DEFVAL

P 90 sipRegUserTable - I don't know enough about SNMP here - If this table
had a few million entries in it would that be ok, could you systematically
access a chunk of it say the 10,000 to 20,000 entry. Going through the
entries one at a time will be too slow. Going through the entries all in one
gulp might hang  things temporarily.

P 91 sipUserAtuhtneitcationFailures - does this reset after a successful
authentication - would like to be able to do notification on a threshold on
it 

P94 - sipContactRetryAfter - I did not know you could do this - in fact, I
don't think you can. Any comments from others?

I'm sure some of my comments are just wrong or misunderstandings. It's hard
to read a MIB and easily get the big picture - perhaps as I think about it
more I will be able to provide better comments. I also should probably go
through the MIB review NTIS stuff that is at
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.
txt

Once again, thanks to the authors - it looks like a lot for work.

Cullen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip