Subject: [MIB-DOCTORS] RE: For final review before submission: SIP MIB draft12 mods - Al l comments and our proposed fixes and responses

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 6 Sep 2006 16:39:30 +0200

My responses/comments to your answers to my comments
(only those for which I do not agree or have further
comments; most of your answers were/are/fine):

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Wednesday, September 06, 2006 15:56
> To: Bert Wijnen (E-mail)
> Subject: RE: For final review before submission: SIP MIB 
> draft12 mods -
> All comments and our proposed fixes and responses
> 
> 4/ ####################################################

.. snip ..

> > ----- SIP-COMMON-MIB

.. snip ..

> 
> > 3.sipServiceNotifEnable DESCRIPTION clause suggests to return a badValue
> >   error. a badValue is NOT a value to be returned by SNMPv2c/v3. It is
> >   only there for backward SNMPv1 compatibility. So suggesting that as
> >   an error value in an SMIv2 MIB module is not correct!
> > 
> >   Not sure I completely understand DESCRIPTION. It seems like a SIP entity can
> >   choose to support notifications or not. In the former case it must support
> >   all of them, in the latter case it would support none at all. So it seems
> >   one would not see an entity that supports only 2 uut of 3 or some other
> >   mix?
> > 
> >   If my interpretation/understanding is correct (in any event, it would be
> >   good to make it clear in the DESCRIPTION clause) I think the correct
> >   approach would be that the object is allowed to be supported in read-only
> >   mode in case the entity does NOT support any notifications. This is done
> >   via a MIN-ACCESS in the MODULE-COMPLIANCE.
> >   Another approach (which also allows a mix of supported/non-supported
> >   noticifcations, and so is the prefered way in my view) would be to
> >   return a error of "inconsistentValue".
> >   It cannot return badValue (see Elements of Procedure pages 19/20 of
> >   RFC3416). It could return inconsistentValue (step 10 on page 19/20
> >   of RFC3416) to achieve what you seem to want.
> > 
> >   So the simplest fix is to: s/badValue/inconsistentValue/
> >   and to clarify the DESCRIPTION clause as to what is exactly intended
> >   (no support for ALL notifications, or an option to support only
> >    a subset)
> Agreed. Clarified the text as follows in the DESCRIPTION clause:
> "...
>                 Support for these notifications is OPTIONAL: either
>                 none or all notification values are supported.
>                 If they are not implemented, this object's value has
>                 no meaning and MUST return 0.  Setting this object in
>                 that circumstance SHOULD result an 'inconsistentValue'
>                 error.
>                 If notifications are supported, this object's default
>                 value SHOULD reflect sipServiceColdStart and
>                 sipServiceWarmStart enabled and sipServiceStatusChanged
>                 disabled.
>                 This object value SHOULD persist across reboots."
> 

I am still somewhat worried about this. The full text is:

      sipCommonCfgServiceNotifEnable OBJECT-TYPE
          SYNTAX     BITS {
                           sipCommonServiceColdStart(0),
                           sipCommonServiceWarmStart(1),
                           sipCommonServiceStatusChanged(2)
          }
          MAX-ACCESS read-write
          STATUS     current
          DESCRIPTION
               "This object specifies which SIP service related
                notifications are enabled.   Each bit represents
                a specific notification.  If a bit has a value 1,
                the associated notification is enabled and will
                be generated by the SIP entity at the appropriate
                time.
                Support for these notifications is OPTIONAL: either
                none or all notification values are supported.
                If they are not implemented, this object's value has
                no meaning and MUST return 0.  Setting this object in
                that circumstance SHOULD result an 'inconsistentValue'
                error.
                If notifications are supported, this object's default
                value SHOULD reflect sipCommonServiceColdStart and
                sipCommonServiceWarmStart enabled and
                sipCommonServiceStatusChanged disabled.
                This object value SHOULD persist across reboots."

          DEFVAL { { sipCommonServiceColdStart,
                     sipCommonServiceWarmStart } }
          ::= { sipCommonCfgEntry 7 }

I think I now understand that indeed, an agent supports (must support) 
ALL BITs or NONE at all. 
If it supports ALL BITs, then each of them can have a value of 1 or 0.

So if an agent returns 0 (I assume you mean 3 bits with each of them 
being zero), then I could interpret that as if the object is supported,
but that none of the notifications are enabled. 

So now that I understand the intention better, I have this comments:

If an implementation does not support this object at all, it should
return on a GET a noSuchObject exception (or so I think).

The fact that the whole object is optional can be expressed in
the MODULE-COMPLIANCE as follows:

     OBJECT sipCommonCfgServiceNotifEnable
     STATUS       current
     MIN-ACCESS   not-accesible
     DESCRIPTION "this object is optional and does not need to be supported."

- A GET request would result in a noSuchObject exception (bullet 2 on
  page 11 of RFC3416)
- A GETNEXT/GETBULK request would just skip the object
- A SET request would return a noAccess (bullet 1 on page 20 of RFC3416)

> 
> > 4.I see no mention of which discontinuity timer applies to the
> > counters
> >   in sipSummaryStatsTable. Same for sipStatusCodesTable,
> >   sipCommonStatsRetryTable and sipOtherStatsTable.
> 
> Added a note:
> "
>                 Discontinuities in the value of this counter can occur
>                 at re-initialization of the SIP entity or service."
> "
> 

That still does not explain how a NMS can detect that (and at what time)
a discontinuity occured, right? The way I read it, it can happen
when the SNMP agent in the SIP entity restarts, but it can also happen
when the SIP entity itself restarts, but the agent keeps running.
How (in that latter siotuation) can an NMS detect that a discontinuity
occured. Normally we point to a discontinuity timer object for that.

> except for the sipStatusCodesTable:
>                 Discontinuities in the value of this counter can occur
>                 at re-initialization of the SIP entity or service, or
>                 when the monitoring of the Status code is temporarily
>                 disabled."
> 
Same comment as above

> 
> > 5.I see no persistency behaviour defined for created entries in the
> >   sipStatusCodesTable
> Added:
>                 Entries created in this table should not persist
>                 across reboots"
> 

I find the use of "should" not very helpfull. I would rather say
"must not" ... But I can live with it.

.. snip ..

> > ------- SIP-SERVER-MIB
> > 
> > maybe in need of a fi:
> > 1.sipNumProxyRequireFailures does not specify which (if any)
> >   discontinuity timer applies.
> >   Same for: sipUserAuthenticationFailures
> >   Same for counters in sipRegStatsTable
> Added:
>                    Discontinuities in the value of this counter can
>                    occur at re-initialization of the SIP entity or
>                    service."
> > and for sipUserAuthenticationFailures
>                    Discontinuities in the value of this counter can
>                    occur due to successful user authentications, and
>                    at re-initialization of the SIP entity or
>                    service."

But (same as comment on discontinuity above) still not tell me how
I (as an NMS or NM APP) can detect that the did in fact occur?
We need a discontinuity timer object that you point to.
L

.. snip ..

> 5/ ################################################################
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Friday, August 04, 2006 5:24 PM
> > To: Romascanu, Dan (Dan); [email-masked]; Jean-Francois Mule;
> > [email-masked]; [email-masked]
> > Cc: Cullen Jennings (E-mail); [email-masked]; Dean Willis (E-
> > mail)
> > Subject: RE: draft-ietf-sip-mib-11.txt - naming conventions
> > 
> > All,
> > 
> > You may recall that in my recent review of your MIB document I
> > mentioned
> > several times my concern about naming-consistency and sugegsted
> > various changes to try and avoid possible future name clashes.
> > 
> > Today I was working on some other stuff, and I ran into 
> RFC1694, which
> > has
> > a MIB module that is named
> > 
> >           SIP-MIB DEFINITIONS ::= BEGIN
> > 
> >           IMPORTS
> >              MODULE-IDENTITY, OBJECT-TYPE, Counter32,
> >              Integer32, IpAddress                     FROM 
> SNMPv2-SMI
> >              TimeStamp, TEXTUAL-CONVENTION            FROM SNMPv2-TC
> >              MODULE-COMPLIANCE, OBJECT-GROUP          FROM 
> SNMPv2-CONF
> >              transmission, ifIndex, mib-2             FROM RFC1213-
> > MIB;
> > 
> >           --  This is the MIB module for the SMDS Interface objects.
> > 
> >           sipMIB MODULE-IDENTITY
> >               LAST-UPDATED "9403311818Z"
> >               ORGANIZATION "IETF Interfaces Working Group"
> >               CONTACT-INFO
> >                 "        Tracy Brown
> >                  Postal: Bell Communications Research
> >                          331 Newman Springs Road
> >                          P.O. Box 7020
> >                          Red Bank, NJ  07701-7020
> >                          US
> > 
> >                     Tel: +1 908  758-2107
> >                     Fax: +1 908  758-4177
> >                  E-mail: [email-masked]
> > 
> >                          Kaj Tesink
> >                  Postal: Bell Communications Research
> >                          331 Newman Springs Road
> >                          P.O. Box 7020
> >                          Red Bank, NJ  07701-7020
> >                          US
> > 
> >                     Tel: +1 908 758 5254
> >                     Fax: +1 908 758 4177
> >                  E-mail: [email-masked]."
> >               DESCRIPTION
> >                    "The MIB module to describe
> >                    SMDS interfaces objects."
> >               ::= { mib-2 36 }
> > 
> > 
> > As you can imagine, they have a lot of names/descriptors that also
> > start with "sip".
> > 
> > So making sure that all YOUR objectnames/descriptors are properly
> > prefixed
> > with the module names, i.e.
> > 
> >    sipCommon
> >    sipServer
> >    sipUA
> > 
> > seems pretty important to me.
> Yes, this is critical and it has been done for all objects.
> 
> > For the TCs, maybe you can also think of a way to avoid future name
> > clashes.
> We have renamed the TCs as well to:
> SipTCxxx
> 

Thanks for going through the massive work-item of renaming.
But I think it saves us all a lot of aggrevation/problems in the future.
I think it is/was worth the effort.

Bert

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors