[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ipcdn] [pkt-sig-mib] Comments/Resolutions on draft 07
Folks,
Reference: draft-ietf-ipcdn-pktc-signaling-07.txt
Please find enclosed a summary of the comments and the proposed
resolutions since draft 07. We plan to prepare a new draft proposal
(draft-08) based on the following comments/proposed resolutions by
Thursday, Feb 14, 2005.
Please let me know if I missed any comments or if you have objections or
alternate proposals.
regards
Sumanth
Last submission:
---------------
Draft - 07
(ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.t
xt)
Summary of changes since D06:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01423.html (Oct
28, 2004)
Next planned submission:
-----------------------
Feb 14, 2005 (Thu)
Comments received so far on D07 (Summary + resolutions):
-------------------------------------------------------
COMMENT SET #1/6:
----------------------------------------------------------------------
- [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 }
----------------------------------------------------------------------
COMMENT SET #2/6:
----------------------------------------------------------------------
+ [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')^^^
<...>
----------------------------------------------------------------------
COMMENT SET #3/6:
----------------------------------------------------------------------
- [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))^^^
<...>
#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.
#2-II *Already addressed*: See COMMENT SET #2/6
#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."
<...>
#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."
<...>
#5: *Pending WG Consensus*
Propose to change 'pktcNcsEndPntConfigTdinit' as shown below:
PktcNcsEndPntConfigTdinit
<...>
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."
<...>
#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."
<...>
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."
<...>
#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)
#8 *Pending WG Consensus*
Change the 'default value' of:
pktcSigDevCIDMode from 'dtAsETS' to ' rpAsETS'
pktcSigDevCIDMode OBJECT-TYPE
<...>
DEFVAL { rpAsETS }
-----------------------------------------------------------------------
COMMENT SET #4/6:
----------------------------------------------------------------------
+ [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}
-----------------------------------------------------------------------
COMMENT SET #5/6:
----------------------------------------------------------------------
+ [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."
-----------------------------------------------------------------------
COMMENT SET #6/6:
----------------------------------------------------------------------
+ [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?
-----------------------------------------------------------------------
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn