Subject: [ipcdn] RE: TX-RX gain in Sig MIB Draft

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 22 Jun 2005 16:06:57 -0600

Satish,

Can you propose a range? The original proposal did not contain specific
boundaries (except that imposed by Integer32).

Randy,

While I would agree in general regarding the DEFVAL, this MIB object
would need to go by recommendations (or RECOMMENDATIONS as you pointed
out):

           "The default values are based on the deployed markets. Some  
           recommendations are made as follows: 
           - Based on the default G.711 Vocoder maximum of 3.14 or 3.17

             dBm a default value of '-4 dB' provides a maximum analog  
             signal level at the a-b (T/R) termination point 
           - Based on [ETSI TS 101 909-4], which provides guidance of  
             11 dB loss (-11 dB gain), a default value of '-11 dB' is  
             recommended." 

Is that ok?

Also, thanks for the pointer on [email-masked]'. I got the
following
Warning messages for this MIB:

W1. mailbody:1173: [5] {integer-misuse} warning: use Integer32 instead
of INTEGER in SMIv2
W2. mailbody:1136: [5] {index-element-not-column} warning: index element
`pktcSigDevToneType' of row `pktcSigDevToneEntry' must be a column
W3/ mailbody:1136: [5] {index-element-not-column} warning: index element
`pktcSigDevToneType' of row `pktcSigDevMultiFreqToneEntry' must be a
column

W1 is due to the fact the we use enumerations at various places and W2
and W3 are due to the fact that 
'pktcSigDevToneType' is defined outside of the two tables, but binds
them together.

Anything of concern with these warnings?

The MIB itself is available at:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.tx
t

Thanks
Sumanth

-----Original Message-----
From: Satish Kumar at Texas Instruments 
Sent: Tuesday, June 21, 2005 7:27 PM
To: [email-masked]
Cc: Sumanth Channabasappa
Subject: TX-RX gain in Sig MIB Draft

Hi,

Question on pktcNcsEndPntConfigTxGain  and pktcNcsEndPntConfigRxGain 

The MIB description is pasted below. There is no range of values defined
for these MIBs. Setting random values impact the devices badly. It is
good to retsrict these MIBs with specific range values. 

pktcNcsEndPntConfigTxGain OBJECT-TYPE  
       SYNTAX Integer32  
       UNITS "dB"  
       MAX-ACCESS read-create 
       STATUS current  
       DESCRIPTION  
           "This MIB Object represents the per line transmitter (A/D)  
           gain. A positive number reflects a signal gain, a negative  
           number reflects a signal loss. This MIB Object may provision

           the gain or it may be used to document a non-provisionable  
           gain between the telco (POTS) a-b (T/R) terminals and the  
           analog codec maximum PCM coding limit (PCM maximum coding  
           limit).  Based on the default G.711 Vocoder maximum of 3.14  
           or 3.17 dBm the -4 dB gain default provides Vocoder coding  
           protection against TE maximum signals while also providing  
           an initial loss to minimize analog signal echo. " 
       DEFVAL { -4 }  
       ::= { pktcNcsEndPntConfigEntry 39 } 
    
   pktcNcsEndPntConfigRxGain OBJECT-TYPE  
       SYNTAX Integer32  
       UNITS "dB"  
       MAX-ACCESS read-create  
       STATUS current  
       DESCRIPTION  
           "This MIB Object represents the per line receiver (D/A)  
           gain. A positive number reflects a signal gain, a negative  
           number reflects a signal loss. This MIB Object may provision 
           the gain or it may be used to document a non-provisionable  
           gain for use with the pktcSigDevToneDbLevel Object to set  
           the desired level at the a-b (T/R) terminals.  
    
           The default values are based on the deployed markets. Some  
           recommendations are made as follows: 
           - Based on the default G.711 Vocoder maximum of 3.14 or 3.17

             dBm a default value of '-4 dB' provides a maximum analog  
             signal level at the a-b (T/R) termination point 
           - Based on [ETSI TS 101 909-4], which provides guidance of  
             11 dB loss (-11 dB gain), a default value of '-11 dB' is  
             recommended." 
       ::= { pktcNcsEndPntConfigEntry 40 } 

Comments please..!

Thx, Satish

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 22 Jun 2005 22:00:03 -0700

Hi -

> From: "Sumanth Channabasappa" <[email-masked]>
> To: "Satish Kumar at Texas Instruments" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 22, 2005 3:06 PM
> Subject: [ipcdn] RE: TX-RX gain in Sig MIB Draft
...
>             11 dB loss (-11 dB gain), a default value of '-11 dB' is

The DESCRIPTION that is there clearly says that the RECOMMENDED
default value is -11.  If you mean something else, then the DESCRIPTION
needs work.

> W1 is due to the fact the we use enumerations at various places and W2

But the definition of, for example, pktcSigDevToneNumFrequencies, the
RECOMMENDED type would be Unsigned32.  See
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt
section 4.6.1.1

> 'pktcSigDevToneType' is defined outside of the two tables, but binds
...

This definition is odd, and I agree that it merits at least a warning.
 A not-accessible scalar being used as an index is quite strange.
It should be a columnar object in one of the tables.  Note the requirements
in the guidelines section 4.6.4 .

BTW, for all the RowStatus objects in the mib, note that the guidelines say:

|     - The DESCRIPTION clause of the status column MUST specify which
|       columnar objects (if any) have to be set to valid values before
|       the row can be activated.  If any objects in cascading tables
|       have to be populated with related data before the row can be
|       activated, then this MUST also be specified.
|
|     - The DESCRIPTION clause of the status column MUST specify whether
|       or not it is possible to modify other columns in the same
|       conceptual row when the status value is active(1).  Note that in
|       many cases it will be possible to modify some writeable columns
|       when the row is active but not others.  In such cases the
|       DESCRIPTION clause for each writeable column SHOULD state whether
|       or not that column can be modified when the row is active, and
|       the DESCRIPTION clause for the status column SHOULD state that
|       modifiability of other columns when the status value is active(1)
|       is specified in the DESCRIPTION clauses for those columns (rather
|       than listing the modifiable columns individually).

Randy