Subject: [ipcdn] pktcSigDevToneWholeToneRepeatCount description in draft-07 of the Signaling MIB

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 18 Jan 2005 19:08:35 -0800

The draft-07 of the Signaling MIB contains the following wording on the
requirement for pktcSigDevToneWholeToneRepeatCount object:

             If the pktcSigDevToneType is callWaiting1-4, the 
             pktcSigDevToneWholeToneRepeatCount does not apply and MUST 
             be ignored on SNMP get/set operations.

I have two issues here:

1. The MUST requirement above should be located in the description of
the object which it refers to, i.e. it should be moved to the
DESCRIPTION clause of the pktcSigDevToneWholeToneRepeatCount object.

2. The requirement above is not speific on what particulary it means
"MUST be ignored on SNMP get/set operations". Does this mean that all
SNMP GET/SET must be dropped as ifi they did not exist ? Does this mean
that MTA must return "success" of the SNMP operation without actually
doing anything ? 

To address these concerns the following is proposed:

1. Change the DESCRIPTION of the pktcSigDevToneTable:

           " The Tone Table defines the various tone operations. Any 
             definition of the tones callWaiting1-4 in this table 
             should just contain the audible tone itself and NOT 
             contain the delay between tones or the tone repeat count. 
             The delay between tones or the repeat count is controlled 
             by the objects pktcNcsEndPntConfigCallWaitingDelay, and 
             pktcNcsEndPntConfigCallWaitingMaxRep. The MTA MUST 
             make sure that, after the provisioning cycle, the table is 
             fully populated (i.e., for each possible index, an entry 
             MUST be defined) using reasonable defaults for each row 
             that was not defined by the provisioning information. 
             Objects in this table do not persist across MTA reboots."  

2. Change the DESCRIPTION of the pktcSigDevToneWholeToneRepeatCount:

           "This is the repeat count, which signifies how many times 
            to repeat the entire on-off sequence. Setting this object 
            may result in a tone duration longer or shorter than the 
            overall signal duration specified by the time out (TO) 
            object for a particular signal. If the repeat count results 
            in a longer tone duration than the signal duration 
            specified by the TO, the tone duration defined 
            by the TO object for a particular signal always represents 
            the overall signal duration for a tone. In this case, the 
            tone duration repeat count will not be fully exercised and 
            the desired tone duration will be truncated per the TO 
            setting. If the repeat count results in a shorter tone 
            duration than the signal duration specified by the TO, the 
            tone duration defined by the repeat count takes precedence 
            over the TO and will end the signal event. In this case, 
            the TO represents a time not to be exceeded for the signal. 
            It is recommended to ensure proper telephony signaling that 
            The TO duration setting should always be longer than the 
            desired repeat count time duration.
            
            If the pktcSigDevToneType is set to either of the values 
            callWaiting1, .. callWaiting4, the 
            the MTA MUST return "noSuchInstance" for all SNMP SET/GET 
            operations on pktcSigDevToneWholeToneRepeatCount object."  

Eugene.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 18 Jan 2005 22:18:56 -0800

Hi -

> From: "Eugene Nechamkin" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, January 18, 2005 7:08 PM
> Subject: [ipcdn] pktcSigDevToneWholeToneRepeatCount description in draft-07 of the Signaling MIB

...
> 2. Change the DESCRIPTION of the pktcSigDevToneWholeToneRepeatCount:
...
>             operations on pktcSigDevToneWholeToneRepeatCount object."
...

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

Randy

---

From: "David De Reu" <[email-masked]>
Date: Thu, 20 Jan 2005 09:41:04 +0100

Hi all,

> |             pktcSigDevToneWholeToneRepeatCount object has no

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 20 Jan 2005 08:06:07 -0800

Hi -

> From: "David De Reu" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, January 20, 2005 12:41 AM
> Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07of the Signaling MIB
>

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

---

From: "David De Reu" <[email-masked]>
Date: Fri, 21 Jan 2005 11:21:06 +0100

> defined, and that would not be good.

For what it's worth: based upon these and other comments from Randy, I feel
his suggestion is the simplest and most clean one. It would in this case
also be useful to clarify the "store-and-ignore" semantics in the
DESCRIPTION clause, so that the exact requirements are clear to everyone.

Regards,

David

_____________________________________________________
David De Reu
tComLabs
Stapelplein 70/004 – 9000 Ghent – Belgium
Tel: +32 9 269 22 91 – Fax: +32 9 329 31 74
www.tComLabs.com
_____________________________________________________