Subject: [dispatch] SIP SNMP MIB and new transports

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 4 Apr 2013 22:12:20 +0200

Hi!

RFC 4780 defines an OID for transports. If we add new transports (websockets) we need to expand this table. The RFC in itself doesn't outline a procedure for extending it. 

Should the draft for websockets transport extend the MIB?

In the Kamailio SNMP implementation, I have used bit 6 for ws and 7 for wss.

/O

------

SipTCTransportProtocol ::= 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
       "
    REFERENCE "
RFC 3261, Section 18 and RFC 4168
"
    SYNTAX      BITS {
                  other(0),  -- none of the following
                  udp(1),
                  tcp(2),
                  sctp(3),   -- 
RFC4168

                  tlsTcp(4),
                  tlsSctp(5) -- 
RFC 4168

                }

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Apr 2013 23:25:39 +0800

Olle,

> Should the draft for websockets transport extend the MIB?

It is too bad this wasn't raised sooner, e.g. during WGLC.
draft-ietf-sipcore-sip-websocket-08 is now with the editor,
so it is really too late to address this in that draft now.

So if something needs to be done about this then I guess it will require 
a separate draft.

For the moment, ISTM the obvious work around is:

> In the Kamailio SNMP implementation, I have used bit 6 for ws and 7 for wss.

I know *nothing* about mibs, but when looking at 4780 I don't see any 
evidence that it was designed with a mechanism for extension as new 
transports are defined. Is there some way to fix that, and link it to a 
new IANA registry?

	Thanks,
	Paul

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Apr 2013 08:20:20 +0000

Hi,

> Is there some way to fix that, and link it to a
> new IANA registry?

Yes, there is a way. It involves updating RFC 4780 by placing the SipTCTransportProtocol under IANA change control. Actually it may be a good idea to transfer all the TCs in the SIP MIB under the control of IANA, so that they can be extended if and when there is a need to add new values to the enumerations or bitmaps. Thus the TCs do become the registries. The IANA considerations policy section also needs to be updated in order to define the RFC 5226 policy for updating the registries (for example ' Expert Review (or Designated Expert))'

It's not a horrendous task if it is focused on this specific change and the impulse to make other updates to RFC 4780 is resisted. 

Regards,

Dan
(Technical Advisor for the SIP WG when the SIP MIB was written)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, April 05, 2013 6:26 PM
> To: [email-masked]
> Subject: Re: [dispatch] SIP SNMP MIB and new transports
> 
> Olle,
> 
> > RFC 4780 defines an OID for transports. If we add new transports
> (websockets) we need to expand this table. The RFC in itself doesn't
> outline a procedure for extending it.
> >
> draft-ietf-sipcore-sip-websocket-08 is now with the editor, so it is
> really too late to address this in that draft now.
>