Subject: Re: [sipcore] Websocket transport in SNMP

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Sep 2013 15:28:22 +0000

Hi Paul, 

Sorry for the late response. Vacation interfered. 

>    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?

Yes, there is little to worry on this respect. Adding (syntactically correct) enumeration values results in a backward compatible change if the other values stay untouched. Also by the time the SIP MIB RFC was issued the standard for writing MIB modules was stable, so the MIB module stands compatible with the current MIB standards and conventions. There are some changes in the way MIB RFCs are written (for example Security Considerations sections), so the work of the supposed volunteer would not be zero, but not dramatic either. 

> * 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?

This is completely up to the WG to decide. 

I hope this helps. 

Regards, 

Dan

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, August 28, 2013 8:46 PM
> To: [email-masked]; Romascanu, Dan (Dan)
> Subject: Re: [sipcore] Websocket transport in SNMP
> 
> Keith,
> 
> I'm glad somebody remembers this.
> 
> On 8/28/13 10:37 AM, DRAGE, Keith (Keith) wrote:
> > 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.
> 
> 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
> 
> 
> > Keith
> >
> >> -----Original Message-----
> >> 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
> >> Subject: Re: [sipcore] Websocket transport in SNMP
> >>
> >>
> >> On Aug 22, 2013, at 12:50 PM, Olle E. Johansson <[email-masked]>
> wrote:
> >>
> >>>> When we looked at the MIB years ago, I think there was physical
> >> laughter. :)
> >>> 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
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >