Subject: [sip] sip mib - summary of changes due to LC comments

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 8 May 2006 03:42:03 -0600

Here is a summary of the sip mib changes due to last call comments.

Let me and Kevin know if we missed anything. A new ID will be posted on Friday May 12 reflecting those changes unless we hear anything.

Jean-François

--- Comments #1, #2, #3 from Samir Srivastava
Closed; no changes required.
See http://www1.ietf.org/mail-archive/web/sip/current/msg13855.html
And subsequent emails from Dan and Cullen.

--- Comments from Cullen Jennings
See http://www1.ietf.org/mail-archive/web/sip/current/msg13924.html

--- Comment #4 re: SipTransportProtocol
Closed;
See http://www1.ietf.org/mail-archive/web/sip/current/msg13966.html
New proposed new text:
     SipTransportProtocol ::= TEXTUAL-CONVENTION
              STATUS current
              DESCRIPTION
                   "This convention is a bit map.  Each bit represents a
                    transport protocol.  If a bit has value 1, then that
                    selected transport protocol is in some way dependent
                    on the context of the object using this convention.
                    If a bit has value 0, then that transport protocol
                    is not selected.  Combinations of bits can be
                    set when multiple transport protocols are selected.

                    bit 0 : a protocol other than those defined here.
                    bit 1 : User Datagram Protocol.
                    bit 2 : Transmission Control Protocol.
                    bit 3 : Stream Control Transmission Protocol.
                    bit 4 : Transport Layer Security Protocol over TCP.
                    bit 5 : Transport Layer Security Protocol over SCTP.
              SYNTAX     BITS {
                               other(0),  -- none of the following
                               udp(1),
                               tcp(2),
                               sctp(3),   -- RFC4168 
                               tlsTcp(4)  
                               tlsSctp(5) -- RFC 4168
              }
   --         REFERENCE "RFC 3261, Section 18"
   --         REFERENCE "RFC 4168"

--- Comment #5
Cullen wrote:
> sipMaxTransactions - I really don't know how I would decide what to
> report in most proxies or what an administrator would do with this
> information. Max transaction per second would be a a way that might 
> make more sense to me.
I thought it was per second as well but you're right, re-reading the text, it is not what is meant.
Resolution: change text to reflect that sipMaxTransactions is max transactions per second.
New text:
      sipMaxTransactions OBJECT-TYPE
          SYNTAX     Unsigned32 (1..4294967295)
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
               "This object indicates the maximum number of simultaneous
                transactions per second that the SIP entity can handle.
                In general the value of this object SHOULD reflect a
                level of transaction processing per second that is
                considered high enough to impact the systems CPU and/or
                memory resources to the point of deteriorating SIP call
                processing but not high enough to cause catastrophic
                system failure."

--- Comment #6
Cullen wrote:
> In sipOptionTagTable, I did not see how the HeaderField stuff ended up
> with 0xA0. I imagine this is all right, it was just not obvious to me 
> how this all worked.
Resolution: editorial change.
The BITS data type is defined by SMIv2 and folks deal with it through SNMP agents & tools. But the text in the example could be more explicit to say, for e.g.:
                Example: if a user agent client supports and requires
                the server to support reliability of provisional
                responses (IETF RFC 3262), this table contains a
                row with the option tag string '100rel' in sipOptionTag
                and the OCTET STRING value of '1010 0000' or '0xA0' in
                sipOptionTagHeaderField.
 -> note: given the example, we will also add an informative reference to RFC 3262

--- Comment #7
Cullen wrote:
> It seem that not many people use sipOrganization - do we really want
> this is the mandatory group.
Ok.
Resolution: remove sipOrganization from sipCommonConfigGroup.

--- Comment #8
Cullen wrote:
> Given the many ways that UA determine what the next hop is, the
> sipUACfgServerAddr left me feeling pretty uncomfortable.
Resolution: No changes required.
This table is for *basic* sip ua config and it is basic for sure yet usable by some of the UA implementation. You can picture a simple case when a UA is given its registrar server and/or an outbound sip proxy address.
I poked around using well-known names of SIP UA vendor companies (soft phone and hard IP phones), and I quickly looked at their SIP configuration menus and I found the following configurable via soft menus:
	- SIP Proxy (used by some IP phones and soft clients)
	- Outbound Proxy
	- Register with Proxy: Indicates whether to enable SIP registration. This parameter is ignored if a SIP proxy server is not specified. ==> this would be a case where the Entityrole is both proxy && registrar.
Arguably, I agree we do not get into how UAs may discover their registrar, outbound sip proxies or P-CSCFs and things may get more complicated. But once the discovery mechanism is complete, this table can be updated by the UA (note that we made this read-only because of the many ways UAs can discover this or get configured for this).

--- Comment #9
> On the sipProxyAUthMethod, what do you do if using both TLS and Digest.
> TLS often uses Digest at the same time.
Resolution: No changes required.
The MIB object allows this to be expressed: both the TLS and Digest bits would be turned on (set to '1').

--- Comment #10
> in sipProxyAuthRealm, the comment about this may need to be stored per
> user was concerning. I agree that in some cases it may need to be. 
> However, I don't see how this MIB could work when it is per user. Do 
> we just say this item is empty or ignored if it is per user? Does the
> MIB work if it is per user and I just don't understand how?

Agree, this needs to be clarified to have consistent implementations.
Resolution: 
   - indicate that this object is the *default* realm value used by the proxy in Proxy-Authenticate headers and,
   - add a note to say that in case of per user storage, the default value is ignored by the proxy.
Proposed new text:
         sipProxyAuthRealm OBJECT-TYPE
             SYNTAX     SnmpAdminString
             MAX-ACCESS read-only
             STATUS     current
             DESCRIPTION
                  "This object reflects the default realm value used in
                  Proxy-Authenticate headers.  Note that this MAY need
                  to be stored per user, in which case, this default
                  value is ignored."
           ...snip

--- Comment #11: 
> sipRegAlloowThirdParty - there are two definitions in common usage for
> 3rd party reg. This is one of them. However, I don't know of any
> deployment situations that allow this type of 3rd party reg. It is 
> the other type that are allowed in practice. Do we need to this at
> all? Do we need to update?
Resolution: add reference to RFC 3261 section 10.2 in description txt Proposed new text:
         sipRegAllowThirdParty OBJECT-TYPE
             SYNTAX     TruthValue
             MAX-ACCESS read-only
             STATUS     current
             DESCRIPTION
                  "This object reflects whether or not the Registrar
                  SHOULD allow third party registrations as defined
                  in RFC 3261 section 10.2.
           ...snip

--- Comment #12
 > sipUserAuthenticationFailures - when there is a successful
> authentication, does this reset to zero.
No based on the def of Counter32. 
Also, based on the semantics of a Counter32 (rfc2578, rfc4181 section 4.6.1.2), it is not ok to put in the DESCRIPTION clause of a Counter32/64 that there is a requirement that it MUST reset at any specific time/event (e.g. here, successful registration). 
Also, note that the counter may not be initiated with a creation value of zero - if we think we need this, we should look at ZeroBasedCounter32 (rfc2021).
Proposed resolution: by default, no changes.
If folks feel strongly about this, and comment back on the thread, an alternative could be using ZeroBasedCounter32.

--- Comment #13
> s/Jennins/Jennings/ :-)
Sorry, thank you for catching this. Will be corrected.

_______________________________________________
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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 May 2006 10:56:24 -0700

The proposed resolutions are all fine with me.

On May 8, 2006, at 2:42 AM, Jean-Francois Mule wrote:

> Let me and Kevin know if we missed anything. A new ID will be  
> posted on Friday May 12 reflecting those changes unless we hear  
> anything.
>
> Jean-François
>
> The BITS data type is defined by SMIv2 and folks deal with it  
> through SNMP agents & tools. But the text in the example could be  
> more explicit to say, for e.g.:
> This table is for *basic* sip ua config and it is basic for sure  
> yet usable by some of the UA implementation. You can picture a  
> simple case when a UA is given its registrar server and/or an  
> outbound sip proxy address.
> I poked around using well-known names of SIP UA vendor companies  
> (soft phone and hard IP phones), and I quickly looked at their SIP  
> configuration menus and I found the following configurable via soft  
> menus:
> 	- Register with Proxy: Indicates whether to enable SIP  
> registration. This parameter is ignored if a SIP proxy server is  
> not specified. ==> this would be a case where the Entityrole is  
> both proxy && registrar.
> Arguably, I agree we do not get into how UAs may discover their  
> registrar, outbound sip proxies or P-CSCFs and things may get more  
> complicated. But once the discovery mechanism is complete, this  
> table can be updated by the UA (note that we made this read-only  
> because of the many ways UAs can discover this or get configured  
> for this).
>
>
> --- Comment #9
>    - indicate that this object is the *default* realm value used by  
> the proxy in Proxy-Authenticate headers and,
> Also, based on the semantics of a Counter32 (rfc2578, rfc4181  
> section 4.6.1.2), it is not ok to put in the DESCRIPTION clause of  
> a Counter32/64 that there is a requirement that it MUST reset at  
> any specific time/event (e.g. here, successful registration).
> Also, note that the counter may not be initiated with a creation  
> value of zero - if we think we need this, we should look at  
> ZeroBasedCounter32 (rfc2021).
> If folks feel strongly about this, and comment back on the thread,  
> an alternative could be using ZeroBasedCounter32.
>
>
> --- Comment #13
>> s/Jennins/Jennings/ :-)