RE: pktcRingCadence (former pktcSigPowerRingFrequency description change)

I renamed the subject field of the e-mail thread for better
"trackability".
 
As to the proposal, I am not sure what is the motivation to change the
existing description clause. The currently exiting description seems to
be quite adequite.
 
Eugene.

________________________________

From: [email protected] [mailto:[email protected]] On Behalf
Of Sumanth Channabasappa
Sent: Wednesday, October 20, 2004 10:56 PM
To: Eugene Nechamkin; Beacham Gordon-CGB005; [email protected]
Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change


Hi,
 
I was looking at some of the comments regarding 'pktcRingCadence' and
would like to propose the following text:
 
(This also takes care of removing the text initially proposed by Satish
to which others, including myself agree to.)
 
"This object provides an encoding scheme for ring cadences, including
repeatability characteristics. 

 

The first three octets are reserved. The octets that follow are used to
encode a 'bit-string', with each bit corresponding to 50 milliseconds. A
bit value of '1' indicates the presence of a ring-tone and a bit value
of '0' indicates the absence of a ring-tone, for that duration (50 ms).
This entire bit-string MUST be placed using network-byte order and
encoded as octets that preserve that ordering.

 

The first two of the reserved octets indicate the length of the encoded
'bit-string' and MUST range between 1 and 264. (Note: The length MUST
also be consistent with the number of octets that encode the cadence).
The third of the reserved octets indicates 'repeatability' and MUST
support only the values 0x80 or 0x00 - the former value indicating
'repeatability' and the latter indicating 'non-repeatability'.

 

The MTA MUST reject attempts to set any values which violate the above
requirements."

 

 

It is currently described as:

 

"

This object represents a ring cadence and repeatable

characteristics in bit string format. The first two

octets of the bit string represent the bit-length  of

the duration of the cadence (i.e., the number of bits that

follow the third octet). The first two octets MUST

represent a value between 1 and 264. Any other values MUST

be rejected. The bit count needs to be consistent with the

OCTET STRING's length. If there are unused octets, the SNMP

set MUST be rejected. If the length implied by the bit

count is greater than the OCTET STRING's length the SNMP

set MUST be rejected. The third octet is used to

represent repeatable characteristics. 00000000 means

repeatable, and 10000000 means non repeatable. The value of

the repeatable field MUST be 0x00 or 0x80. Each bit

after the third octet corresponds to 50 ms where 1

represents ring and 0 represents silence. The first bit of

the fourth octet is the first bit of the ring cadence. All

bits are counted in network order such that the octet with

only the first bit set will look like 10000000 bit

sequence. A total of 264 bits can be set to represent

13200 ms of total cadence cycle. There will be at most 3

on/off transitions per cadence cycle. If there are more

than three on-to-off transitions, the SNMP set MUST be

rejected. "

 

 

Comments?

 

Thanks

Sumanth

 

 

 

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email protected]] 
	Sent: Wednesday, October 20, 2004 12:47 PM
	To: Sumanth Channabasappa; Beacham Gordon-CGB005; [email protected]
	Subject: RE: [ipcdn] pktcSigPowerRingFrequency description
change
	
	
	Yes, this addresses my conserns.
	 
	Eugene.

________________________________

	From: Sumanth Channabasappa [mailto:[email protected]] 
	Sent: Wednesday, October 20, 2004 11:03 AM
	To: Eugene Nechamkin; Beacham Gordon-CGB005; [email protected]
	Subject: RE: [ipcdn] pktcSigPowerRingFrequency description
change
	
	
	Hi Eugene,
	 
	 
	How about:
	 
	"The default value for this object is dependent on the primary
usage area of the device. For devices compliant with PacketCable (North
America)  it MUST be set to f20Hz and for devices compliant with
IPCablecom (Europe)  it MUST be set to f25Hz."
	 
	 
	Sumanth

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email protected]] 
		Sent: Wednesday, October 20, 2004 11:50 AM
		To: Beacham Gordon-CGB005; [email protected]; Sumanth
Channabasappa
		Subject: RE: [ipcdn] pktcSigPowerRingFrequency
description change
		
		
		 
		While not disagreeing with the proposal to delete the
DEFVAL clause from the MIB Object definition, I am not completely
comfortable with the fact that IETF MIB draft would make a reference to
the document ([PKT-SP-MIB-SIG]) which will be obsolete when draft
becomes an RFC (or soon thereafter). Besides, I am not sure to which
extent the mentioning of compliency with the [PKT-SP-MIB-SIG] or with
the [ITU-T-J169] is unambigous. Not sure presisely what this
"compliency" means. What's the intention here - to say that for MTAs
compliant with NorthAmerican-PC the defval should be f20 but for MTAs
compliant with Euro-PC the defval should be f25Hz ? I think the
reference to the compliency should be made less ambiguous. 
		 
		Eugene.

________________________________

		From: [email protected]
[mailto:[email protected]] On Behalf Of Beacham Gordon-CGB005
		Sent: Tuesday, October 19, 2004 8:48 AM
		To: [email protected]; '[email protected]'
		Subject: [ipcdn] pktcSigPowerRingFrequency description
change
		
		
		The following changes are recommended to the description
of the pktcSigPowerRingFrequency object.
		 
		delete: DEFVAL { f20Hz }
		add: This default value for this object MUST be f20Hz
for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this
object MUST be f25Hz for MTAs compliant to [ITU-T-J169].
		 
		Gordon

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