Re: pktcSigDevToneWholeToneRepeatCount descriptionindraft-07 of the Signaling MIB

Hi -

> From: "Eugene Nechamkin" <[email protected]>
> To: "David De Reu" <[email protected]>; <[email protected]>
> Sent: Thursday, January 20, 2005 10:37 AM
> Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount descriptionindraft-07 of the Signaling MIB
>

>
> |             If the pktcSigDevToneType is set to either of the values
> |             callWaiting1 or callWaiting4, then the value of the
> |             pktcSigDevToneWholeToneRepeatCount object has no
> |             effect on the tone."
>
> Though this approach addresses one concern on how the value in this
> object affects the tone generation functionality of the MTA, it does not
> address the SNMP behavior of the MTA, and also does not provide for the
> unamigous feedback to the NMS.

How is it ambiguous?

> The following might address all of those:
>
>             If the pktcSigDevToneType is set to any of the values
>             callWaiting1, callWaiting2, callWaiting3 or callWaiting4,
>             then the value of the pktcSigDevToneWholeToneRepeatCount
>             object has no effect on the tone. In this case, the MTA
>             MUST return "noSuchInstance" for all SNMP SET operations,
>             and "noError" for all SNMP GET operations on
>             pktcSigDevToneWholeToneRepeatCount object.
...

I think this counter-proposal has some problems.

    1) it would violate SNMP protocol to return noError if, for example, VACM
       prohibits access to the object of the get-request.

    2) returning noSuchInstance in response to a set-request violates SNMP
       protocol.  See RFC 3416 section 4.2.5, which spells out the permissible
       responses.

    3) it's even more complicated for the implementor than the original proposal,
       requiring "custom" access methods for both get and set requests, as well
       as special-case logic for get-next and get-bulk, since this column would
       have to be processed differently from the others.

    4) it doesn't address the behaviour when the value of pktcSigDevToneType
       is changed.

Randy