Subject: [ipcdn] [PKT-SIG-MIB] Draft 08 (Summary Of Changes)

From: "Sumanth Channabasappa" <[email-masked]>
Date: Sun, 20 Feb 2005 22:10:43 -0700

Folks,

Reference: draft-ietf-ipcdn-pktc-signaling-08.txt

Please find enclosed a summary of the comments and the proposed
resolutions that were incorporated into the recently submitted D08
submission. 

regards
Sumanth

Comments and resolutions that were incorporated into D08 
-------------------------------------------------------

COMMENT SET #1/7:
----------------------------------------------------------------------
- [Randy: Oct 29, 2004] - *CLOSED*
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01428.html

  Email Subject: Re: [ipcdn] Submission: IETF NCS Signaling MIB 
                 draft 7 (Update)
 
  Issue: Clarification regarding 'pktcNcsEndPntConfigPartialDialTO' and
' pktcNcsEndPntConfigCriticalDialTO'.

  RESOLUTION: Looks like the 'maximum' was unintended. Good catch! 
              Thanks Randy!

  Changed MIB Objects as follows:

      pktcNcsEndPntConfigPartialDialTO     OBJECT-TYPE  
       <...> 
       DESCRIPTION  
           "This object contains the value of the partial dial 
                    ^^^^^ (rephrased "maximum value") ^^^^
            time out." 
       <...>
       ::= { pktcNcsEndPntConfigEntry 3 }  

      pktcNcsEndPntConfigCriticalDialTO     OBJECT-TYPE  
      <...>
      DESCRIPTION  
           "This object contains the value of the critical 
                   ^^^^^ (rephrased "maximum value") ^^^^
            dial time out." 
      <...>
      ::= { pktcNcsEndPntConfigEntry 4 }  

STATUS: *UPDATED*
----------------------------------------------------------------------

COMMENT SET #2/7:
----------------------------------------------------------------------
+ [Satish: Nov 16, 2004] - *CLOSED*
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01439.html

  Email Subject: pktcRingCadence explanation changed from 
                 sig-draft-5 to sig-draft-7

  Issue: Suggestion to revert to the earlier description of 
        'PktcRingCadence' w.r.t repeatability.

  RESOLUTION: 

  - [Sumanth, Nov 17, 2004]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01440.html

  - [Gordon, Nov 17, 2004]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01441.html

ACTION: Comment Accepted.

   PktcRingCadence   ::= TEXTUAL-CONVENTION 
            <...> 
       DESCRIPTION 
            <...> 
   
            The third of the reserved octets indicates 'repeatability'  
            and MUST be either 0x80 or 0x00 - the former value  
            indicating 'non-repeatability' and the latter indicating 
                 ^^^(used to be 'repeatability')^^^
            'repeatability'. 
   ^^^(used to be 'non-repeatability')^^^
            <...> 

STATUS: *UPDATED*
----------------------------------------------------------------------

COMMENT SET #3/7:
----------------------------------------------------------------------

- [Eugene: Dec 8, 2004] - *SEE INDIVIDUAL RESOLUTIONS*
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01453.html

   Email Subject: Comments on draft-ietf-ipcdn-pktc-signaling-07.txt
   Issues: Numerous 

   RESOLUTION: 
      #1 *Accepted*: pktcCodecType -> 
          Change Description to reflect LCO instead of LCD.

      PktcCodecType ::= TEXTUAL-CONVENTION  
      <...>

      DESCRIPTION
      <...>
             The literal codec name is the second column of the table 
             with codec RTP Map Parameters. Literal Codec Name Column 
             contains the codec name used in the local connection 
             options(LCO) of the NCS messages create connection 
             ^^(Used to be 'Local connection descriptor(LCD))^^^
       <...>

STATUS: *UPDATED*

      #2-I *No Change*: 
      Only the bits mentioned within the length depicted by the length
      field (first two octets) hold good for the cadence, the rest do
      not affect the cadence and the hence, the note prevents someone 
      from encoding more octets than as required by the length field.

STATUS: *No Action*

      #2-II *Already addressed*: See COMMENT SET #2/7

STATUS: *No Action*

      #3: *Pending WG Consensus* 

      Propose to change 'pktcNcsEndPntConfigTSMax' as shown below:

      pktcNcsEndPntConfigTSMax
      <...>
      DESCRIPTION
      " This MIB object is used as part of an NCS 
      retransmission algorithm. Prior to any retransmission, 
      the MTA must check to make sure that the time elapsed 
      since the sending of the initial datagram does not exceed 
      the value specified by this MIB Object. If more than 
      Tsmax time has elapsed, then the retransmissions MUST 
      cease.

      Refer to the MIB Object pktcNcsEndPntConfigThist for 
      Information on when the endpoint becomes disconnected."
      <...>
    
STATUS: *UPDATED*

      #4: *Pending WG Consensus*

      Propose to change the description of 'pktcNcsEndPntConfigTdinit' 
      as shown below:

      pktcNcsEndPntConfigTdinit
      <...>
      "This MIB object represents the 'disconnected' initial    
      waiting delay within the context of an MTA's 'disconnected  
      procedure'. The 'disconnected procedure' is initiated when 
      an endpoint becomes 'disconnected' while attempting to 
      communicate with a Call Agent. 

      The 'disconnected timer' associated with the 'disconnected
      Procedure' is initialized to a random value, uniformly 
      distributed between zero and the value contained in this 
      MIB Object.

      For more information on the usage of this timer, please 
      refer to the PacketCable NCS Specification."
      <...>   
STATUS: *UPDATED*

      #5: *Pending WG Consensus*

      Propose to change 'pktcNcsEndPntConfigTdmin' as shown below:

      pktcNcsEndPntConfigTdmin
      <...>   
      DESCRIPTION
      "This MIB object represents the 'disconnected' minimum 
      waiting delay within the context of an MTA's 'disconnected  
      procedure', specifically when local user activity is 
      detected. 

      The 'disconnected procedure' is initiated when 
      an endpoint becomes 'disconnected' while attempting to 
      communicate with a Call Agent. 

      For more information on the usage of this timer, please 
      refer to the PacketCable NCS Specification."
      <...>   
   
STATUS: *UPDATED*

#6 *Pending Approval* 
     Change the description of the following MIB Objects as shown below:

     pktcNcsEndPntConfigMinHookFlash
      <...>   
      DESCRIPTION
      "This is the minimum time a line needs to be on hook for a 
      valid hook flash. The value of this object MUST be 
      greater than the value of 
      pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of 
      pktcNcsEndPntConfigMinHookFlash MUST be less than 
      pktcNcsEndPntConfigMaxHookFlash. This object MUST only be 
      set via the configuration file during the provisioning 
      process.
      Furthermore, given the possibility for the 'pulse dial' 
      and 'hook flash' to overlap, the value of this object MUST

      be greater than the value contained by the MIB Object 
      pktcNcsEndPntConfigPulseDialMaxMakeTime."
      <...>   
          
STATUS: *UPDATED*

      pktcNcsEndPntConfigPulseDialMaxMakeTime
      <...>   
      DESCRIPTION
      " This is the maximum make pulse width for the dial pulse. 
      The value of pktcNcsEndPntConfigPulseDialMaxMakeTime MUST 
      be greater than pktcNcsEndPntConfigPulseDialMinMakeTime. 
      This object MUST only be set via the configuration file 
      during the provisioning process.
      Furthermore, given the possibility for the 'pulse dial' 
      and 'hook flash' to overlap, the value of this object MUST

      be less than the value contained by the MIB Object 
      pktcNcsEndPntConfigMinHookFlash."
      <...>   
      STATUS: *UPDATED*

      #7 *No Change*
      'Alerting Signal', 'Special Dial', 'Special Info', 'release', 
      'congestion' & userDefined 1-4 are defined as part of the 
      following ETSI document:
      TS 101 909-4 v1.4.1 (2004-05) (Thanks to Gordon Beacham & 
      Phillip Freyman for the information)

      STATUS: *NO ACTION*

     #8 *Pending WG Consensus*

     Change the 'default value' of:
     pktcSigDevCIDMode from 'dtAsETS' to ' rpAsETS'

      pktcSigDevCIDMode    OBJECT-TYPE  
      <...>   
           DEFVAL { rpAsETS } 
      STATUS: *UPDATED* 
-----------------------------------------------------------------------

COMMENT SET #4/7:
----------------------------------------------------------------------
+ [Gordon: Jan 06, 2005] - *PROPOSAL ACCEPTED BY GORDON* 
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01460.html

  Email Subject: IETF NCS Sig MIB Tone Table

  Issue: Suggest introduction of a new MIB table pktcSigDevToneEntry

  RESOLUTION:

   - [Randy: Jan 06 2005]
     http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01466.html

   - [Eugene: Jan 12, 2005]
     http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01493.html

   - [Gordon: Jan 17, 2005]
      http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01517.html

Suggestion:

- Move 'pktcSigDevToneType' out of  'pktcSigDevToneTable' and define it
as a MIB Object within 'pktcSigDevConfigObjects'

- Move 'pktcSigDevToneNumFrequencies' out of  'pktcSigDevToneTable' and
define it as a MIB Object within 'pktcSigDevConfigObjects'
 
   pktcSigDevToneNumFrequencies    OBJECT-TYPE  
       SYNTAX       INTEGER(5..16) 
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
         "This MIB Object specifies the number of frequencies 
          supported by the PacketCable MTA for each tone type."  
       ::={ pktcSigDevConfigObjects 33}  

Replace the current definition of 'PktcSigDevToneEntry' with the
following common elements (across all tone types):

    PktcSigDevToneEntry ::= SEQUENCE {
        pktcSigDevToneDbLevel                   TenthdBm,
        pktcSigDevToneWholeToneRepeatCount      Unsigned32,
        pktcSigDevToneSteady                    TruthValue
    }
The above will be indexed by 'pktcSigDevToneType' as done today.

Introduce a table to handle the multiple frequencies for each tone type,
as defined below:

   PktcSigDevMultiFreqToneEntry ::= SEQUENCE {
  	   pktcSigDevToneFrequencyNumber           Unsigned32 ,
         pktcSigDevToneFreqPriCompValue          Unsigned32,
         pktcSigDevToneFreqSecCompValue          Unsigned32,
         pktcSigDevToneFreqSecCompMode           INTEGER,
         pktcSigDevToneFreqSecCompPrtg           Integer32,
         pktcSigDevToneFreqOnDuration            Unsigned32,
         pktcSigDevToneFreqOffDuration           Unsigned32,
         pktcSigDevToneFreqRepeatCount           Unsigned32
   }

The above would be indexed by both 'pktcSigDevToneType' and
'pktcSigDevToneFrequencyNumber'.

The entire table is reproduced below:

   pktcSigDevMultiFreqToneTable    OBJECT-TYPE  
       SYNTAX       SEQUENCE OF PktcSigDevMultiFreqToneEntry
       MAX-ACCESS   not-accessible  
       STATUS       current  

       DESCRIPTION  
           " This MIB table defines the characteristics of tones
             with multiple frequencies. The constraints imposed
             on the tones by the MIB table pktcSigDevToneTable
             need to be considered for MIB objects in this table
             as well."
       REFERENCE  
           "NCS Specification, TS 101 909-4 Specification" 
       ::= { pktcSigDevConfigObjects 35 }  

   pktcSigDevMultiFreqToneEntry    OBJECT-TYPE  
       SYNTAX       PktcSigDevMultiFreqToneEntry
       MAX-ACCESS   not-accessible  
       STATUS       current  
       DESCRIPTION  
           " The different tone types with multiple frequencies 
             that can be provisioned based on country specific needs."
       INDEX { pktcSigDevToneType, pktcSigDevToneFrequencyNumber }  
       ::= { pktcSigDevMultiFreqToneTable 1 }  

   PktcSigDevMultiFreqToneEntry ::= SEQUENCE {
	 pktcSigDevToneFrequencyNumber           Unsigned32 ,
         pktcSigDevToneFreqPriCompValue          Unsigned32,
         pktcSigDevToneFreqSecCompValue          Unsigned32,
         pktcSigDevToneFreqSecCompMode           INTEGER,
         pktcSigDevToneFreqSecCompPrtg           Integer32,
         pktcSigDevToneFreqOnDuration            Unsigned32,
         pktcSigDevToneFreqOffDuration           Unsigned32,
         pktcSigDevToneFreqRepeatCount           Unsigned32
   }

   pktcSigDevToneFrequencyNumber    OBJECT-TYPE  
       SYNTAX       Unsigned32(5..16)
       MAX-ACCESS   not-accessible
       STATUS       current  
       DESCRIPTION  
          "This MIB Object represents the frequency reference 
           of a multi-frequency tone. It is to be noted that
           the maximum number of frequencies for a 
           multi-frequency tone is limited by the MIB Object
           pktcSigDevToneNumFrequencies."  
       ::={ pktcSigDevMultiFreqToneEntry 1}  

   pktcSigDevToneFreqPriCompValue    OBJECT-TYPE  
       SYNTAX       Unsigned32(0..4000)
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
         "This MIB Object represents the value of the primary
          component frequency specific to the frequency reference 
          of a tone type."
       ::={ pktcSigDevMultiFreqToneEntry 2}  

   pktcSigDevToneFreqSecCompValue    OBJECT-TYPE  
       SYNTAX       Unsigned32(0..4000)
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
         "This MIB Object represents the value of the secondary
          component frequency specific to the frequency reference 
          of a tone type."
       ::={ pktcSigDevMultiFreqToneEntry 3}  

   pktcSigDevToneFreqSecCompMode OBJECT-TYPE  
       SYNTAX       INTEGER {
                     ignoreSecondary (1),
                     primaryModulatedBySecondary (2),
                     primarySummedWithSecondary (3)
                    }
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
       "This MIB Object indicates the way the primary 
        and secondary frequency components indicated
        by the MIB Objects 'pktcSigDevToneFreqPriCompValue'
        and 'pktcSigDevToneFreqSecCompValue' are to be used.
        
        A value of primaryModulatedBySecondary(2) indicates 
        that the primary must be used to amplitude modulate
        the secondary. The percentage of amplitude modulation
        to be applied to the secondary is defined by the MIB
        Object 'pktcSigDevToneFreqSecCompPrtg'.

        A value of primarySummedWithSecondary(3) indicates 
        that the primary must be summed with the secondary,
        without any modulation

        A value of ignoreSecondary(1) indicates that the 
        secondary must not be used."
       ::={ pktcSigDevMultiFreqToneEntry 4}  

  pktcSigDevToneFreqSecCompPrtg OBJECT-TYPE  
       SYNTAX       Integer32(0..100)
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
          "This MIB Object represents the percentage of amplitude
           modulation applied to the secondary frequency component
           when the MIB Object 'pktcSigDevToneFreqSecCompMode' is
           set to a value of 'primaryModulatedBySecondary(2)'.
           In all other cases this MIB Object has no meaning."  
       ::={ pktcSigDevMultiFreqToneEntry 5}  

   pktcSigDevToneFreqOnDuration                     OBJECT-TYPE  
       SYNTAX       Unsigned32(0..5000)
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
          "This MIB Object represents the duration for which the
           frequency reference corresponding to the tone type
           is turned on."  
       ::={ pktcSigDevMultiFreqToneEntry 6}  

   pktcSigDevToneFreqOffDuration                     OBJECT-TYPE  
       SYNTAX       Unsigned32(0..5000)
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
          "This MIB Object represents the duration for which the
           frequency reference corresponding to the tone type
           is turned off."  
       ::={ pktcSigDevMultiFreqToneEntry 7}  

   pktcSigDevToneFreqRepeatCount             OBJECT-TYPE  
       SYNTAX       Unsigned32(0..5000) 
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
       "This MIB Object indicates the number of times
       to repeat the cadence cycle represented by the 
       on/off durations (refer to the MIB Objects 
       pktcSigDevToneFreqOnDuration and 
       pktcSigDevToneFreqOffDuration). 

       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 the 
       corresponding tone type. If the value of this MIB
       Object indicates a longer duration than the 
       specified by the TO, the latter overrules the former
       and the desired tone duration will be truncated according
       to the TO.

       However, 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. A value of zero
       means the tone sequence is to be played once but not
       repeated."
       ::={ pktcSigDevMultiFreqToneEntry 8}  
STATUS: *TBD*
-----------------------------------------------------------------------

COMMENT SET #5/7:
----------------------------------------------------------------------

+ [Eugene: Jan 19, 2005] - *Pending Approval* 
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01519.html

  Email Subject: pktcSigDevToneWholeToneRepeatCount description 
                 in draft-07 of the Signaling MIB

  Issue: Comments related to 'pktcSigDevToneTable' and 
         'pktcSigDevToneWholeToneRepeatCount'

  RESOLUTION:

 - [Randy: Jan 19, 2005]
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01520.html

 - [David: Jan 20, 2005]
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01521.html

 - [Randy: Jan 20,2005]
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01522.html

 - [Eugene: Jan 20, 2005]
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01523.html

 - [Randy: Jan 20, 2005]
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01524.html

 - [David: Jan 21, 2005]
   http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01531.html

Suggestion:

*Remove* the following statement from the definition of:
'pktcSigDevToneTable'

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

*Add* the following to the description of the MIB Object '
pktcSigDevToneWholeToneRepeatCount':

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

STATUS: *UPDATED*
-----------------------------------------------------------------------

COMMENT SET #6/7:
----------------------------------------------------------------------
+ [David: Jan 21, 2005] - *Pending Approval*
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01530.html

   Subject: pktcSigDevCodecTable request for clarification
   
   Issue: Suggestions related to pktcSigDevCodecTable

   RESOLUTION:

  - [Jean-Francois: Jan 21, 2005]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01535.html
  
  - [David: Jan 24, 2005]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01543.html

  - [Jean-Francois: Jan 25, 2005]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01554.html

  - [David: Jan 25, 2005]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01555.html

Suggestion:
Include the following statement to the description of the MIB Table '
pktcSigDevCodecTable'

                 "....This table MUST NOT include non-voice codecs...."

On a related note, CODEC Types 'other' and 'unknown' are defined as:
             other           a defined codec not in the enumeration 
             unknown         a codec not defined in PacketCable

Assuming 'other' is a possible new CODEC defined by PacketCable, but not
in the enumeration and 'unknown' is a CODEC not defined at all by
PacketCable - is it ok to keep both?
STATUS: *UPDATED*
-----------------------------------------------------------------------

COMMENT SET #6/7:
----------------------------------------------------------------------
+ [David: Jan 21, 2005] - *Pending Approval*
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01530.html

   Subject: Add new MIBs for dynamic gain plan negotiation and 
            clarify the MIB Object 'pktcSigDevToneDbLevel'.

   Issue: Suggest adding 'pktcNcsEndPntConfigTxGain'  and 
          'pktcNcsEndPntConfigRxGain' as new MIB Objects, 
          part of the table 'pktcNcsEndPntConfigEntry'.

   RESOLUTION:
  - [Phil: Feb 15, 2005]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01591.html

  - [Rich: Feb 15, 2005]
    http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01592.html

  - [Phil: Feb 17, 2005]
    ?? [This email was not found in the archives, but is reproduced 
         at the end of this email] -- Attachment 1

Suggestion:

Add the following MIB Objects:

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 }

Change the description of 'pktcSigDevToneDbLevel' to the following:

pktcSigDevToneDbLevel    OBJECT-TYPE
    SYNTAX       TenthdBm (-250..-30)
    UNITS        "dBm" 
    MAX-ACCESS   read-write 
    STATUS       current
    DESCRIPTION
          "This MIB Object contains the decibel level for each

          analog signal (tone) that is locally generated 
          versus in band supervisory tones) and sourced to 
          the a-b terminals (TE connection point). Each tone 
          in itself may consist of multiple frequencies as 
          defined by the MIB table 
          'pktcSigDevMultiFreqToneTable'. 

          This MIB Object MUST reflect the desired level at 
          the Telco (POTS) a-b (T/R) terminals including the 
          affect of the pktcNcsEndPntConfigRxGain setting on 
          the delivered tone. 

          The wide range of levels for this Object is required 
          to provide signal generator levels across the wide 
          range of gains - but does not imply the entire range 
          is to be achievable given the range of negative 
          values of gain (positive loss). This MIB Object must 
          be set for each tone so as to generate the combined 
             frequency level at the a-b (T/R) terminals."

STATUS: *UPDATED*
-----------------------------------------------------------------------

Changes not part of the comment set include:

- Editorial changes - date/compilation date etc.

- Patent disclosure as per the email from Jean-Francois
[http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01593.html] led
to the check for compliance with Section 5 of RFC 3668
http://www.ietf.org/rfc/rfc3668.txt]. Accordingly, the section formerly
titled 'Intellectual Property' is now named 'Disclaimer of validity' and
the contents updated.

- Added PacketCable 1.5 to reflect the Jan, 2005 release

Attachment:
----------
From: Freyman Phillip-FPF300 [[email-masked]] 
Sent: Thu 2/17/2005 11:07 PM
To: Richard Woundy @ Comcast
cc: Sumanth Channabasappa; [email-masked]'
RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

thanks Rich for the comments...you raise the question of future
migration and use of the proposal.
 
the Tx and Rx levels vary based on locale (N.A. vs Euro vs Asia vs
national standards), by providing MIB variables, this enable common
designs to be applicable across national boundaries (but within an
operators business area).  In this case it may be desireable to set the
loss plans for one operator or even for one user (down to a single line
number) without any need to adapt the loss in the future.  
 
In fact, it has been seen that some TE (CPE) devices detect the MTA loop
current and based on the loop current they adjust their internal analog
gain/loss.  Essentially relating low local loop current/voltage to high
analog signal loss.  So if the MTA is configured to provide a minimum
loop current (good to minimize power consumption), CPE devices may
actually add gain to compensate for the historical analog loop signal
loss (bad for MTAs configured with high analog levels (small loss plans)
per current PacketCable guidance).  
 
Should it become desireable to support an adaptable loss plan (per
connection type or service type within a connection) then this change
would fall under the signalling protocol "solution".  It would seem
logical that these adaptations would only be in effect for the duration
of the connections or might even change within a single connection
(start of call in voice mode with one loss, respond to a fax mode with a
second loss and at the end of the fax to adapt back to the voice mode
loss).  This adaptive loss would only be applicable during a single
session since any change in loss would be related to a specific far end
(short to long analog POTS loop variability) of that connection.  After
the connection is terminated then the loss plan should revert to the
SigMIB settings in preparation for the next call which may be within the
VoIP network or may again be routed to another analog POTS loop.
 
So there are three rationals for the MIB loss plan flexibility with two
potential results...
a "one time" setting based on local operator/user needs (local standards
or loop current) and ...
a future potential need for adaptive loss plan adjustments related to a
specific far end connection requirement.
 
hope this explains the concept in more detail and the relationship
between the MIB values verses a future protocol defined value.
Phil

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