Hi Gordon,


Yes, the more I look at it, the more I like it,
it makes everything much easier, more uniform and cleaner I think !



Thanks,
  Best regards,
   Wim


-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] 
Sent: 06 March 2004 01:02
To: 'Wim De Ketelaere'; Beacham Gordon-CGB005; 'Eugene Nechamkin';
ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant


Wim,

Thank you for your comments. If I understand proposed solution
correctly, I believe you are suggesting a change could be made to the TC
as follows:

PktcRingCadence   ::= TEXTUAL-CONVENTION 
       STATUS        current 
       DESCRIPTION
		 This object represents a ring cadence and repeatable
characteristics.
             The first two octets of the bit string represent the length
in bits of 
             the duration of the cadence. The third octet is used to 
             represent repeatable characteristics. 00000000 means 
             repeatable, and 10000000 means non repeatable. Each Bit 
             after the third octet represents 50 ms and 1 represents 
             ring and 0 represents silent. The first bit of the fourth 
             octet is the first bit of the ring cadence. A total of 264 
             Bits can be set to represent 13200 ms of total cadence 
             cycle.
	SYNTAX	OCTET STRING (SIZE(4..36))

The following object descriptions would change (i.e., remove the
duration and repeatable characteristics sentences) and the DEFVAL would
be removed:

pktcSigDevRgCadence
pktcSigDevRsCadence
pktcSigDevR0Cadence
pktcSigDevR1Cadence
pktcSigDevR2Cadence
pktcSigDevR3Cadence
pktcSigDevR4Cadence
pktcSigDevR5Cadence
pktcSigDevR6Cadence
pktcSigDevR7Cadence

The following object SYNTAX would change to use the PktcRingCadence TC:

pktcSigDevRingCadence

The following objects could then be deleted:

pktcSigDevStandardRingCadence -> would now be covered by
pktcSigDevRgCadence (L package) pktcSigDevRingSplashCadence -> would now
be covered by pktcSigDevRsCadence (L package)

You could then update your "Clarification of L Package for
Euro-PacketCable Document v6.0 (2004/1/20)" to reflect these changes, if
there is agreement.

Gordon

-----Original Message-----
From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com]
Sent: Monday, March 01, 2004 12:07 AM
To: 'Beacham Gordon-CGB005'; 'Eugene Nechamkin'; ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant


Hi Gordon,


I asked you the difference between those two MIB-object a long time ago,
and you pointed out that a different object was needed for Europe
because of the difference in total time and needed granularity.

If the total duration difference needs to be supported, it needs to be
supported without the need 
for the E-package. 

As it is important that basic calls can be supported without an MTA that
support the E-package, 
and you clarified that for Europe a longer cadence is needed. Based on
that it seems the normal way to go to have the two extra MIB-objects. By
that a CMS can support both European and US market without any changes
on the CMS !

Please note that for now the E-package is still optional, as far as I
know no CMS supports it !



A solution would be to have the definition adjusted for the MIB so it
supports both US and European requirements:

the duration of the cadence can be adjusted by having leading zeroes.
The total number of bits needs to be increased to support a longer
maximum length, and more granularity (50 ms).

This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7
take the definition of the 
for now European-only cadence. This allow the needed flexibility while
having only one mib-object to specify the cadences. This can be done by
adjusting the textual convention (PktcRingCadence)


This would mean that an MTA can have exactly the same mapping from NCS
to MIB for the L-package, independent of the region in which it will be
used, and independent from possible E-package support.


Thanks,
  Best regards,
    Wim







-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] 
Sent: 27 February 2004 23:46
To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere;
ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant



Exactly. This is precisely what the pktcSigDevRingCadenceTable object is
defined to handle (international ring cadences to 13.2s) using the V5.x
"cr(x)" mechanism noted in the object description. For example, an
international operator could define cr5 for standard ring and cr9 for
ring splash, etc for up to 128 international cadences.

V5.x defined 128 possible ring cadences for international ring messages
without concern for what those cadences are named. The 101 909-4 spec
does not name these cadences either and the name should not be a concern
for the MIB definitions.

Gordon

-----Original Message-----
From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]
Sent: Friday, February 27, 2004 2:13 PM
To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant


It's might also be worth noting that the "pktcSigDevRgCadence" and
"pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence"
and "pktcSigDevRingSplashCadence" - on the other have different
requirement for the Cadence timing granularity, hence the
"pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used
to represent Euro-PC Cadence resolution requirement reflected in
"pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence".

Eugene.

-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Beacham Gordon-CGB005
Sent: Friday, February 27, 2004 1:59 PM
To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant



Interesting. Thanks for pointing that out. However, I don't follow why
the mapping has been made that way in the "Clarification of L Package
for Euro-PacketCable Document v6.0 (2004/1/20)."

The objects referenced in 2.19 and 2.21 for the L package rg and rs
cadences are in the international group with a max cadence of 13.2s. The
other distinctive ring cadences in the above document map to core L
package objects r0..r7 with a max cadence of 6.0s. The cadence mapping
seems to be inconsistent. I would have expected the 2.19 and 2.21
cadence for rg/rs to be mapped to the pktcSigDevRgCadence and
pktcSigDevRsCadence core L package objects. International cadences would
then be handled via the E package extensions and associated object
(pktcSigDevRingCadenceTable).

Wim,

Can you comment/clarify why the rg/rs cadences are mapped to objects in
the international group instead of the pktcSigDevRgCadence and
pktcSigDevRsCadence objects? Thanks.

Gordon

-----Original Message-----
From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]
Sent: Wednesday, February 25, 2004 5:21 PM
To: Beacham Gordon-CGB005; ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplashCadence are redundant


> The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence 
> objects are redundant.
I am not sure I can completely agree with this statement (if I
understand it correctly). Both of these objects are required for
Euro-L-package, because of the way the RG and RS signalls are currently
defined:

For Euro-L-Package: 
   - RG -> pktcSigDevStandardRingCadence
   - RS -> pktcSigDevRingSplashCadence

The "pktcSigDevRingCadenceTable" contains the cadence values for the
E-package. Having in mind that E-package is optional, and L-package is
mandatory, I am not sure I understand how pktcSigDevStandardRingCadence
and pktcSigDevRingSplashCadence can be "merged" into the
"pktcSigDevRingCadenceTable".

Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain
the RG and RS cadencies for Euro-L-Package along with the values for
E-package? If yes, I think the proper mapping of the table indexes to
the corresponding signal should be somehow defined, and corresponding
modifications of the Euro-L-Package should also be put in place. 

Though from the MIB optimization stand point of view the proposed
modification might make sense, however, from the currently imlemented
and intended funtionality prospective it looks unnecessary (please
correct me if my understanding of your proposal deviates from what you
had in mind).


Eugene Nechamkin,
Broadcom Corp.,
ph: (604) 233-8500


-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Beacham Gordon-CGB005
Sent: Wednesday, February 25, 2004 11:01 AM
To: ipcdn@ietf.org
Subject: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplashCadence are redundant



The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence
objects are redundant. These objects are recommended to be deleted from
the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence
and pktcSigDevRingSplashCadence objects is a carryover from the L line
package and they are not needed in the E line package. Instead, normal
ring and ring splash cadences can be defined using the
pktcSigDevRingCadenceTable object.

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
gordon.beacham@motorola.com


_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn


_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn







_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn