Re: RE: TX-RX gain in Sig MIB Draft

Hi -

> From: "Sumanth Channabasappa" <[email protected]>
> To: "Satish Kumar at Texas Instruments" <[email protected]>; <[email protected]>
> Sent: Wednesday, June 22, 2005 3:06 PM
> Subject: [ipcdn] RE: TX-RX gain in Sig MIB Draft
...
> 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?

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

> Also, thanks for the pointer on '[email protected]'. 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

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

> and W3 are due to the fact that
> 'pktcSigDevToneType' is defined outside of the two tables, but binds
> them together.
...

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