RE: re: Signaling MIB - Draft 3 - Last Call - Default val ues

>- pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence
...
> Instead, how about "The default value for this object is as specified in 
> the "L" package as defined in the PacketCable NCS specification".

As NCS Spec does not have any specific reqs for L-package except for ref to GR-506 (appendix A.2 of the NCS Spec), we feel comfortable with the original tComLabs' proposal: "A default value MUST be provided, but it is left up to the implementation to choose a reasonable default."


>- pktcSigDevToneTable
>"The MTA device 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."
...
> This statement is not necessary. By utilizing the DEFVAL clause an 
> initial value for each parameter associated with a row can be established. 
> Unfortunately, I see the DEFVAL clause is missing in many of the table objects. 
> Consequently, I would recommend a DEFVAL clause be added for the following objects:
> pktcSigDevToneFirstFrequency    	DEFVAL { 0 }
> pktcSigDevToneSecondFrequency 	DEFVAL { 0 }
....

As "0" values beaing the defaults for these object will actually generate no audible tone, we feel that instead of trying to consolidate all values for these object amoung all countries, the original tComlabs' proposal will serve the purpose better. 


>- pktcSigDevRingCadenceTable
>"The MTA device is allowed to provide appropriate default values for each of the ring cadences." 
> How about:
> "The MTA is allowed to predefine the ring cadence for one or more rows in the pktcSigDevRingCadenceTable."

We do not see the real difference between these two, and original tComlabs' proposal seems to be satisfactory. 

Eugene Nechamkin,

Broadcom Corp,
(604) 233-8500


-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email protected]]
Sent: Thursday, February 05, 2004 3:57 PM
To: '[email protected]'
Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default
val ues


My comments:
>- pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence
>"A default value MUST be provided, but it is left up to the implementation to choose a reasonable default." - 
It seems to me that having a requirement of this nature in the MIB is not meaningful. Also, I don't see how "reasonable" can be tested. An arbitrary value is not meaningful. Instead, how about "The default value for this object is as specified in the "L" package as defined in the PacketCable NCS specification".

>- pktcSigDevToneTable
>"The MTA device 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."

This statement is not necessary. By utilizing the DEFVAL clause an initial value for each parameter associated with a row can be established. Unfortunately, I see the DEFVAL clause is missing in many of the table objects. Consequently, I would recommend a DEFVAL clause be added for the following objects:

pktcSigDevToneFirstFrequency    	DEFVAL { 0 }
pktcSigDevToneSecondFrequency 	DEFVAL { 0 }
pktcSigDevToneThirdFrequency	DEFVAL { 0 }
pktcSigDevToneFourthFrequency	DEFVAL { 0 }
pktcSigDevToneFirstToneOn		DEFVAL { 0 }
pktcSigDevToneFirstToneOff		DEFVAL { 0 }
pktcSigDevToneSecondToneOn	DEFVAL { 0 }
pktcSigDevToneSecondToneOff	DEFVAL { 0 }
pktcSigDevToneThirdToneOn		DEFVAL { 0 }
pktcSigDevToneThirdToneOff		DEFVAL { 0 }
pktcSigDevToneFourthToneOn	DEFVAL { 0 }
pktcSigDevToneFourthToneOff	DEFVAL { 0 }
pktcSigDevToneWholeToneRepeatCount	DEFVAL { 0 }
pktcSigDevToneSteady			DEFVAL { false } 

The DEFVAL approach would also minimize any operator configurations.
>- pktcSigDevRingCadenceTable
>"The MTA device is allowed to provide appropriate default values for each of the ring cadences." 
How about:

"The MTA is allowed to predefine the ring cadence for one or more rows in the pktcSigDevRingCadenceTable."

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email protected]


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