Re: pktcSigDevToneWholeToneRepeatCount description indraft-07of the Signaling MIB

Hi -

> From: "David De Reu" <[email protected]>
> To: <[email protected]>
> Sent: Thursday, January 20, 2005 12:41 AM
> Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07of 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.

Thanks for the correction.  The "either" language in the original
proposal tripped me up.  My bad.  :-)  Perhaps "either" should
be "any" in this case?

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

>From an implementor / onetime toolkit vendor perspective, it's simpler
to store and ignore, which is what default access methods would
do.  Not storing a value would require a non-default access method
to be written, since the access method would need conditional logic
to decide whether it could skip storing the value.  Also, from a testing
perspective, if MTAs are permitted to disregard the value supplied
in a set-request, then the value returned by a get-request is not well
defined, and that would not be good.

Randy