Subject: [sipcore] Websocket transport in SNMP

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Aug 2013 14:53:15 +0200

During the IETF in Berlin I had a discussion with Adam (as chair) about the need for updating the SNMP MIBs for SIP as we add a new transport. I tried to discuss it with Paul, but noticed that he silently began thinking about completely different things while running away. :-)

I contacted the ops and mib people wg and they clearly said it's our responsibility in sipcore to update the TC that includes the transport bits.

Just for the archives and a todo-list somewhere in the cloud.

/O

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Aug 2013 13:06:28 +0000

This should not be a big deal if the future authors resist the temptation of other updates and extensions besides the SipTCTransportProtocol TC. Until then the value other(0) must be used by implementations to designate the websockets transport. 

Regards, 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Olle E. Johansson
> Sent: Thursday, August 22, 2013 3:53 PM
> To: [email-masked] WG
> Subject: [sipcore] Websocket transport in SNMP
> 
> During the IETF in Berlin I had a discussion with Adam (as chair) about
> the need for updating the SNMP MIBs for SIP as we add a new transport. I
> tried to discuss it with Paul, but noticed that he silently began
> thinking about completely different things while running away. :-)
> 
> I contacted the ops and mib people wg and they clearly said it's our
> responsibility in sipcore to update the TC that includes the transport
> bits.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 09:46:33 -0400

Just to clarify my position on this:

I recognize that MIBs have value.
But its not an area for which I have any experience, knowledge, or 
interest. Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP, 
MMUSIC, having been involved in creation of SIP MIBs.

But if SIPCORE is the proper place to do the work, and there are people 
willing and able to do it, then I have no objection to the work being 
done in SIPCORE.

	Thanks,
	Paul

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Aug 2013 14:03:04 +0000

Hi Paul,

> Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP,

Actually RFC 4780 was the product of the SIP MIB WG. 

Regards,

Dan

> Behalf Of Paul Kyzivat
> Sent: Thursday, August 22, 2013 4:47 PM
> To: [email-masked]
> Subject: Re: [sipcore] Websocket transport in SNMP
> 
> interest. 
> > During the IETF in Berlin I had a discussion with Adam (as chair)
> > about the need for updating the SNMP MIBs for SIP as we add a new
> > transport. I tried to discuss it with Paul, but noticed that he
> > silently began thinking about completely different things while
> > running away. :-)
> >

---

From: Mary Barnes <[email-masked]>
Date: Thu, 22 Aug 2013 09:51:45 -0500

Dan, you mean a product of the SIP WG - correct (i.e., not SIP MIB WG)?

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Aug 2013 11:03:12 -0400

I'm not sure if SIPCORE is the right WG... not that I think it matters much where it's done.
But just adding another enumeration bit value to SipTCTransportProtocol is pretty uncontroversial and could just be done with AD sponsorship instead of a WG, imo.

Regardless, does anyone actually implement and use the SIP MIB?

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Aug 2013 17:14:05 +0200

> Regardless, does anyone actually implement and use the SIP MIB?
We have an implementation in Kamailio.

/O
>> Just for the archives and a todo-list somewhere in the cloud.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Aug 2013 11:23:50 -0400

> We have an implementation in Kamailio.

Really?  I'll have to take a look at Kamailio's implementation sometime.  Did you only implement a very few specific things from it?  

When we looked at the MIB years ago, I think there was physical laughter. :) 

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 12:14:56 -0400

> Actually RFC 4780 was the product of the SIP MIB WG.

OK. I was around, but don't remember it. But I do see that it was.

I'm sorry I didn't remember.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 12:20:45 -0400

> But just adding another enumeration bit value to SipTCTransportProtocol is pretty uncontroversial and could just be done with AD sponsorship instead of a WG, imo.

*If* that is all that is required, and its clear to those who manage 
such things that this is the correct way to do it, then I agree.

IMO the main point of doing it in a WG is so that knowledgeable people 
will review it and comment if there are better ways, or other things 
that should be considered, etc.

For instance, is it really necessary for MIBs to have their own 
definitions for things that exist in IANA registries? Or should addition 
to a registry automatically enable support in the MIB?

I can ask that question in the abstract, unemcumbered with any knowledge 
of existing practice in MIBs, technological limitations, etc. But I 
expect that there are a set of people equipped to have that discussion. 
I just don't know if they are in the sipcore wg.

	Thanks,
	Paul

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Aug 2013 16:21:00 +0000

Of course, sorry for the imprecision :)

From: Mary Barnes [mailto:[email-masked]]
Sent: Thursday, August 22, 2013 5:52 PM
To: Romascanu, Dan (Dan)
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] Websocket transport in SNMP

On Thu, Aug 22, 2013 at 9:03 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul,

Regards,

Dan

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Paul Kyzivat
> To: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Aug 2013 16:24:37 +0000

> to a registry automatically enable support in the MIB?

This is not possible, I am afraid. There is no such level of 'automation' in definition of MIB modules. There is something that can be done however - to make the TC a separate module that is maintained by IANA, so that adding new enumeration values can be made by IANA (as values are added in the registry) instead of requiring the modification of the RFC each time. 

Regards,

Dan

> Sent: Thursday, August 22, 2013 7:21 PM
> To: [email-masked]
> > But just adding another enumeration bit value to
> SipTCTransportProtocol is pretty uncontroversial and could just be done
> with AD sponsorship instead of a WG, imo.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Aug 2013 18:50:47 +0200

> Really?  I'll have to take a look at Kamailio's implementation sometime.  Did you only implement a very few specific things from it?  
We have not implemented all, but a subset that matches.
> When we looked at the MIB years ago, I think there was physical laughter. :) 
I can understand why. Some parts are innovative.

/O

---

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Aug 2013 14:42:50 -0400

> I can understand why. Some parts are innovative.

Uh huh.  Name one innovative part.  

I didn't mean we ignored it because it did new things - we ignored it because it (a) didn't do enough, in the sense that the things it covered were minimal, and more importantly (b) it assumed a specific internal system architecture/data model.

But this isn't really a slam against the RFC - every standardized MIB definition has this problem.  When you assume a specific config/stats/implementation data model, devices that have a different one can't pretend they don't.

That's why we laughed at it - not because it was fundamentally wrong or broken, but because the things we make configurable/collect-stats-for/etc. follow a different data model; and we thought it was funny that the IETF expected there to be "one to rule them all".

So I was asking if anyone had implemented it, to see if at least someone had that data model and it was worth updating the RFC.  Apparently it is.  :)

-hadriel

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Aug 2013 12:51:50 -0600

On 8/22/13 12:42 PM, Hadriel Kaplan wrote:
> I didn't mean we ignored it because it did new things - we ignored
> it because it (a) didn't do enough, in the sense that the things
> it covered were minimal, and more importantly (b) it assumed a
> specific internal system architecture/data model.

FWIW and IMHO, this is why there hasn't been much interest in a MIB
for XMPP.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Aug 2013 21:12:39 +0200

22 aug 2013 kl. 20:51 skrev Peter Saint-Andre <[email-masked]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

I agree. But we've taken bits and pieces as inspiration. That's a good start.
Starting all over again is a lot of work.

If it's only we, then there's no point in updating the RFC. I have already added
the missing bit in Kamailio.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 16:08:55 -0400

> This is not possible, I am afraid. There is no such level of 'automation' in definition of MIB modules. There is something that can be done however - to make the TC a separate module that is mainta…

Then perhaps we should introduce something into IANA registries that 
indicates "when this registry is updated the xxx MIB definition must 
also be updated".

	Thanks,
	Paul

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 23 Aug 2013 08:30:17 +0000

Yep, ways can be found to synchronize the content of the IANA registry with the enumeration in an IANA-maintained TC.

Regards,

Dan

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, August 22, 2013 11:09 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> >> definitions for things that exist in IANA registries? Or should
> >> addition to a registry automatically enable support in the MIB?
> >>
> >
> > This is not possible, I am afraid. There is no such level of
> 'automation' in definition of MIB modules. There is something that can
> be done however - to make the TC a separate module that is maintained by
> IANA, so that adding new enumeration values can be made by IANA (as
> values are added in the registry) instead of requiring the modification
> of the RFC each time.
> 
> >>> I'm not sure if SIPCORE is the right WG... not that I think it
> >>> matters
> >> much where it's done.
> >> SipTCTransportProtocol is pretty uncontroversial and could just be
> >> done with AD sponsorship instead of a WG, imo.
> >>
> >> IMO the main point of doing it in a WG is so that knowledgeable
> >> people will review it and comment if there are better ways, or other
> >> things that should be considered, etc.
> >>
> >> definitions for things that exist in IANA registries? Or should
> >> addition to a registry automatically enable support in the MIB?
> >>
> >> I can ask that question in the abstract, unemcumbered with any
> >> knowledge of existing practice in MIBs, technological limitations,
> >> etc. But I expect that there are a set of people equipped to have
> that discussion.
> >> responsibility in sipcore to update the TC that includes the
> >> transport bits.
> >>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Aug 2013 14:37:41 +0000

The SIP MIB was defined in the SIP WG.

SIP was told that all protocols needed one, and a group of people provided a candidate, and therefore we needed to progress it.

It proved almost impossible to give it rigorous review from the protocol experts, therefore it was progressed on the basis that what was there was correct, but potentially incomplete.

As such I can well understand what Hadriel is saying here.

It is also a warning that apart from the issue under discussion, many other useful things will also be missing.

However reopen the document and you will face the same issue as the SIP WG faced when it was first produced - trying to get sufficient review to ensure it was complete.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hadriel Kaplan
> Sent: 22 August 2013 19:43
> To: Olle E. Johansson
> Cc: [email-masked] WG
> I didn't mean we ignored it because it did new things - we ignored it
> because it (a) didn't do enough, in the sense that the things it covered
> were minimal, and more importantly (b) it assumed a specific internal
> system architecture/data model.
> 
> But this isn't really a slam against the RFC - every standardized MIB
> definition has this problem.  When you assume a specific
> config/stats/implementation data model, devices that have a different one
> can't pretend they don't.
> 
> That's why we laughed at it - not because it was fundamentally wrong or
> broken, but because the things we make configurable/collect-stats-for/etc.
> follow a different data model; and we thought it was funny that the IETF
> expected there to be "one to rule them all".
> 
> So I was asking if anyone had implemented it, to see if at least someone
> had that data model and it was worth updating the RFC.  Apparently it
> is.  :)
> 
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 13:46:04 -0400

Keith,

I'm glad somebody remembers this.

> However reopen the document and you will face the same issue as the SIP WG faced when it was first produced - trying to get sufficient review to ensure it was complete.

So this issue may open a can of worms.

I hear one person asking to update the MIB definition in one very small 
way. I imagine we can get a volunteer to do that much. But that leaves a 
number of questions:

* do we have a sufficient body of people to review that change?
   Superficially anybody can look at a change that adds one more
   value to an enumeration and say "ok, its syntactically correct and
   addresses the new value requested". But is that enough?
   What about:
   - is this backward compatible?
   - does this revised MIB meet current MIB standards and conventions?

* when updating the MIB, are we obligated to do more? In particular
   are we expected to consider what else it ought to contain but doesn't?
   If so, do we have people willing and qualified to do this?

Dan - can you give some guidance here?

	Thanks,
	Paul