Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07 of the Signaling MIB

From: "Eugene Nechamkin" <[email-masked]>
Date: Thu, 20 Jan 2005 10:37:16 -0800

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

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.

Eugene.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David De Reu
Sent: Thursday, January 20, 2005 12:41 AM
To: [email-masked]
Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description
indraft-07 of the Signaling MIB

Hi all,

> ...
> This can be messy to implement correctly, particularly when one 
> considers how getNext and getBulk work.  As an alternative, I'd
suggest:
> 
> |             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."

Sounds like a good idea. Just one little thing: this applies to
callWaiting1-4, which includes ...2 and ...3. Being a little explicit
doesn't harm, so:

             If the pktcSigDevToneType is set to either of the values
             callWaiting1, callWaiting2, callWaiting3 or callWaiting4,
             then the value of the pktcSigDevToneWholeToneRepeatCount
             object has no effect on the tone.

>From an SNMP point of view, would this wording require that the MTA
has to store the value, without using it, or does this allow the MTA not
even to store a new value?

Regards,

David

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 20 Jan 2005 13:44:40 -0800

Hi -

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

> unamigous feedback to the NMS.

How is it ambiguous?

...

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