Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

From: "Sumanth Channabasappa" <[email-masked]>
Date: Mon, 25 Jul 2005 08:23:01 -0600

Proposed changes to draft-ipcdn-pktc-signaling-08:
-------------------------------------------------
(ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t
xt)

OPEN ISSUE (Need inputs):
---- ----- 
+ Definition of the MIB Object 'pktcSigDevToneSteady'. This seems to
allow for dual interpretation.

Strongly recommended changes (based on feedback received in the IPCDN
WG):
-------- ----------- -------    

Recommendation #1 (Reason: Technical):
-------------------------------------
+ pktcSigDevMultiFreqToneTable

- Extend the MultiFrequency table to support 4, instead of 2 frequencies
today (First, Second, Third, Fourth instead of Pri and Sec). i.e. 

  - pktcSigDevToneFirstFreqValue            

  - pktcSigDevToneSecondFreqValue                    

  - pktcSigDevToneThirdFreqValue            

  - pktcSigDevToneFourthFreqValue

- Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need
for anything more than 8 tones per tone type)

- Make all the entries in this table to be 'read-only' (Reason: Will not
require updating during run-time)

- Update the DESCRIPTIONs appropriately (Reason: Addition of 4
frequencies changes the Modulation/Summation schemes)

Recommendation #2:
-----------------

+ Deletion of MIB Objects

    - Delete the MIB Objects 'pktcNcsEndPntConfigTxGain' and
'pktcNcsEndPntConfigRxGain' (Reason: Proposal withdrawn)

    - Delete the MIB Object 'pktcSigDevToneNumFrequencies' (Reason:
Redundant)

Editorial/Semantic Changes:

---------------------- ----------

- Rename 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber'
(Reason: Semantics)

- Move the MIB Object 'pktcSigDevToneType' to the Tone Table (Reason:
MIB author guidelines)

Additional suggested changes:
----------  -------- --------
- 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB
Object, easing implementation.

Define FreqToneTable as being indexed only by pktcSigDevToneNumber
(unique index for each entry)

   pktcSigDevMultiFreqToneEntry    OBJECT-TYPE  
       ...............

       INDEX {pktcSigDevToneNumber}  
       ::= { pktcSigDevMultiFreqToneTable 1 }  

   PktcSigDevMultiFreqToneEntry ::= SEQUENCE {

         pktcSigDevToneNumber                    Unsigned32,
         pktcSigDevFreqToneType                  ToneType
.
.
.
   }

   pktcSigDevToneNumber OBJECT-TYPE  
       SYNTAX       Unsigned32(1..168) 
       MAX-ACCESS   not-accessible
       STATUS       current  
       DESCRIPTION  
          "This MIB Object is a unique number identifying each entry in
..."

regards
Sumanth

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

---

From: "T, Shivakumar" <[email-masked]>
Date: Tue, 26 Jul 2005 11:13:24 +0530

Having a single index would really make things easier if a tonenumber
can uniquely identify a tone type.
Let's assume the following default entries are present in multifreq tone
table:

ToneNumber ToneType
-------------------
    1         1
    2         1
    3         2
    4         3        
    5         3
    6         3
    7         4
    8         4
    9         5  
   10         5
-------------------

Now tone type 2 has only one entry in the above table. In order to have
say 2 entries for tone type 2, should we add an entry in the config file
with index 4 or index 11. In either case the tonenumber can get changed
for other tone types.
One solution is to reserve the tonenumbers for a particular tone type.
Since the tonenumber can range from 1-8, tonenumber 1-8 can be for
tonetype 1, tonenumber 9-16 can be for tonetype 2 and so on. With this
even the tonetype can be removed from the multifreq tone table.

Shiva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sumanth Channabasappa
Sent: Monday, July 25, 2005 7:53 PM
To: [email-masked]
Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

 

Recommendation #2:
-----------------

regards
Sumanth

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 26 Jul 2005 00:28:38 -0700

In case when pktcSigDevMultiFreqToneTable is indexed by one index
(pktcSigDevToneNumber), particular values of the indexes and their
assignments to the particular ToneTypes do not matter. The only condition for
indexes is to be unique for each row in the pktcSigDevMultiFreqToneTable.
This way the table does not have any restrictions on the number of rows with
the same value of the "ToneType". 

In the example below, if additional entry of ToneType=2 is required it should
be introduced with the unique index value of pktcSigDevToneNumber=11.

Eugene.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of T,
Shivakumar
Sent: Monday, July 25, 2005 10:43 PM
To: Sumanth Channabasappa; [email-masked]
Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

Having a single index would really make things easier if a tonenumber can
uniquely identify a tone type.
Let's assume the following default entries are present in multifreq tone
table:

ToneNumber ToneType
-------------------
    1         1
    2         1
    3         2
    4         3        
    5         3
    6         3
    7         4
    8         4
    9         5  
   10         5
-------------------

Now tone type 2 has only one entry in the above table. In order to have say 2
entries for tone type 2, should we add an entry in the config file with index
4 or index 11. In either case the tonenumber can get changed for other tone
types.
One solution is to reserve the tonenumbers for a particular tone type.
Since the tonenumber can range from 1-8, tonenumber 1-8 can be for tonetype
1, tonenumber 9-16 can be for tonetype 2 and so on. With this even the
tonetype can be removed from the multifreq tone table.

Shiva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sumanth Channabasappa
Sent: Monday, July 25, 2005 7:53 PM
To: [email-masked]
Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

- Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need for
anything more than 8 tones per tone type)

- Update the DESCRIPTIONs appropriately (Reason: Addition of 4 frequencies
changes the Modulation/Summation schemes)

Recommendation #2:
-----------------

Additional suggested changes:
----------  -------- --------
- 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB Object,
easing implementation.

Define FreqToneTable as being indexed only by pktcSigDevToneNumber (unique
index for each entry)

   pktcSigDevToneNumber OBJECT-TYPE  
       SYNTAX       Unsigned32(1..168) 
       MAX-ACCESS   not-accessible
       STATUS       current  
       DESCRIPTION  
          "This MIB Object is a unique number identifying each entry in ..."

regards
Sumanth

---

From: "T, Shivakumar" <[email-masked]>
Date: Tue, 26 Jul 2005 13:17:49 +0530

The next available tonenumber may be different for various manufacturers
or software images. It's an additional overhead for the operator to
first find out the next tone number and accordingly generate config
files for those entries.

Shiva.

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2005 12:59 PM
To: T, Shivakumar; Sumanth Channabasappa; [email-masked]
Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

In case when pktcSigDevMultiFreqToneTable is indexed by one index
(pktcSigDevToneNumber), particular values of the indexes and their
assignments to the particular ToneTypes do not matter. The only
condition for
indexes is to be unique for each row in the
pktcSigDevMultiFreqToneTable.
This way the table does not have any restrictions on the number of rows
with
the same value of the "ToneType". 

In the example below, if additional entry of ToneType=2 is required it
should
be introduced with the unique index value of pktcSigDevToneNumber=11.

Eugene.

-----Original Message-----
Of T,

can

ToneNumber ToneType
-------------------
    1         1
    2         1
    3         2
    4         3        
    5         3
    6         3
    7         4
    8         4
    9         5  
   10         5
-------------------

Now tone type 2 has only one entry in the above table. In order to have
say 2
entries for tone type 2, should we add an entry in the config file with
index
4 or index 11. In either case the tonenumber can get changed for other
tone
types.
One solution is to reserve the tonenumbers for a particular tone type.
Since the tonenumber can range from 1-8, tonenumber 1-8 can be for
tonetype
1, tonenumber 9-16 can be for tonetype 2 and so on. With this even the
tonetype can be removed from the multifreq tone table.

Shiva

-----Original Message-----
Of

for

frequencies

Recommendation #2:
-----------------

Object,
easing implementation.

(unique
index for each entry)

regards
Sumanth