Changes incorporated in draft-ietf-ipcdn-pktc-signaling-12

Folks,

The co-authors of the I-D titled "Network-Based Call Signaling (NCS) MIB
for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)"
submitted draft-12 before the I-D Submission deadline and this email
summarizes the changes.=20

As a note, it does contain technical changes in addition to the changes
based on feedback received (thanks to those who provided comments).

regards
Sumanth (on behalf of the co-authors)

Link:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-12.t
xt

----------------------------------------------------------------------
1. [Dan] The title of the document includes twice the word 'signaling' -
is this necessary?=20
[Rich] I agree it seems to be redundant. I think occasionally folks
refer to "NCS signaling", which is also a redundant term.
[Sumanth] Agree; additionally removed redundant term 'NCS Signaling'
elsewhere in the document
----------------------------------------------------------------------


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

2. [Dan] idnits complains about un-used references:=20

 - Unused Reference: 'ETSI-TS-101-909-4' is defined on line 3335, but
not referenced'   [ETSI-TS-101-909-4] ETSI TS 101 909-4:"Access and
Terminals (AT);'
 - Unused Reference: 'ETSI-EN-300-324-1' is defined on line 3354, but
not referenced '   [ETSI-EN-300-324-1] ETSI EN 300 324-1 V2.1.1
(2000-04):"V Interfaces'

[Rich] These references do appear in the REFERENCE clauses of several
objects each, e.g. pktcSigPulseSignalTable and pktcSigPulseSignalType. I
suppose these two documents could be explicitly referenced in section 4,
to make the idnits issue go away.

[Sumanth] Can we ignore the idnits bug?=20
----------------------------------------------------------------------

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

3. [Dan] No need for the second paragraph in the Abstract. Anyway, this
is repeated in a 'boilerplate standard' manner in the Introduction
section.
[Rich, PC] I agree.

[Sumanth] Done
----------------------------------------------------------------------


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

4. [Dan] I believe that the following statement is confusing:

   This MIB module also utilizes the syntax definition of the=20
   Differentiated Services Code Point (DSCP) from DIFFSERV-DSCP-TC=20
   [RFC3289] for signaling MIB objects to allow for differentiation=20
   between various types of traffic in the service provider network.=20

I would rather replace it with:

   This MIB module also utilizes the syntax definition of the=20
   Differentiated Services Code Point (DSCP) TC from DIFFSERV-DSCP-TC=20
   [RFC3289] for defining MIB objects that allow for differentiation=20
   between various types of traffic in the service provider network.=20

[Rich, PC] I agree.

[Sumanth] Done
----------------------------------------------------------------------


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

5. [Dan] I could not understand what is meant by:

   This MIB module also utilizes SNMP management MIB architecture from=20
   SNMP-FRAMEWORK-MIB [RFC3411].=20
[RW] I believe this refers to the fact that the MIB module imports
SnmpAdminString as a TC for several MIB objects. Maybe the draft should
just state that.

[Sumanth] This was a legacy statement that could not be traced and has
been removed
----------------------------------------------------------------------


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

6. [Dan]    pktcSigNotification=20
   =20
   pktcSigNotification - this object is used for signaling notification=20
   and reserved for future use.=20

This is not an object, but just an OID. Needs not any explanation
[RW] I agree.
[Sumanth] Removed
----------------------------------------------------------------------

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

7. [Dan] DESCRIPTION clause of pktcSigDevSilenceSuppression

            " This object specifies if the device is capable of=20
             silence suppression (Voice Activity Detection)." =20

Better say:=20

           " This object specifies if the device is capable of=20
             silence suppression (as result of Voice Activity
Detection)." =20
[RW] I agree.
[sumanth] Done
----------------------------------------------------------------------
----------------------------------------------------------------------


8. [Dan] DESCRIPTION clause of    pktcSigDevCidSigProtocol =20

"This object identifies the subscriber line protocol used=20
for signaling on-hook caller id information. Different=20
countries define different caller id signaling protocols to=20
support caller identification. Frequency shift keying (FSK)=20
is most commonly used. Dual tone multi-frequency (DTMF)=20
is an alternative."=20

This object has a MAX-ACCESS clause of read-write. The DESCRIPTION
should rather say:

"This object is used to configure the subscriber line protocol used for
signaling on-hook caller id information. Different countries define
different caller id signaling protocols to support caller
identification.=20
- setting this object at a value fsk(1) sets the subscriber line
protocol to be Frequency Shift Keying (FSK)=20
- setting this object at a value dtmf(2) sets the subscriber line
protocol  to be Dual tone multi-frequency (DTMF)."=20

[RW] I agree.

[Sumanth] Done
----------------------------------------------------------------------


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

9. [Dan] I believe that pktcSignalingVersion has a significance only for
pktcSignalingType ncs(3). If true, this needs to be mentioned in the
object DESCRIPTION clause.=20
[RW] Or alternatively, the pktcSignalingVersion is relevant only for a
particular pktcSignalingType value. As an example, the semantics of
pktcSignalingVersion "2.0" would depend on the value of
pktcSignalingType, say ncs(3) or sip(4) -- making up the latter
enumeration. :^)

[Sumanth] This was meant to indicate allow for other protocols to reuse
the MIB (hence the 'other'). Can we leave it as-is?
----------------------------------------------------------------------


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

10. [Dan] It is not clear what value reserved(2) means in the
PktcSigType TC.
'for future use' does not make too much sense, if this value will become
meaningful in the future you cannot change the semantics of this
enumerated value. I suggest to skip this value and use only other and
ncs
[RW] I agree. For example, we could not decide after publication that
'reserved(2)' really meant 'sip'.
[sumanth] Done
----------------------------------------------------------------------

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

11. [Dan] It is not clear what level of interoperability can the
pktcSignalingVendorExtension object offer if the encoded string is
vendor specific. I suggest to take this oibject out.=20
[RW] I agree with the concern, but I wonder if this object can be
salvaged. Authors: is the encoding of this object equivalent to the
encoding of the 'VendorExtensionParameter' on page 134 of the NCS
specification,
<http://www.packetcable.com/downloads/specs/PKT-SP-MGCP-I11-050812.pdf>?
That MGCP protocol syntax has a well-defined encoding, that could be
leveraged for the value of this MIB object as well.
[Dan] I suggest that at 11 you document better the object and mention
the format that you referred in your explanation in the DESCRIPTION
clause.

[Sumanth] How about we say:
"
The syntax for this MIB Object in ABNF ([RFC 4234]) is specified =20
to be zero or more occurrences of vendor extensions, as follows:
   pktcSignalingVendorExtension  =3D
                   *["X" ("-"/"+") 1*6(ALPHA / DIGIT) ";"]
"
If so, its done :))
----------------------------------------------------------------------

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

12. [Dan] It does not make sense to specify DEFVAL clauses for read-only
objects (pktcSigDefNcsReceiveUdpPort, pktcSigPowerRingFrequency). If
configuration by SNMP is not allowed, setting the instrumentation at the
desired state has not any relation with the SNMP agent.=20
[RW] I tend to agree, although this "overcommunication" approach has
been used in other drafts that have originated in this WG before. As one
specific example see 'pktcMtaDevDhcpServerAddressType' in
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-09.txt
> -- this draft is on the RFC Editor's Queue intended for proposed
standard; it was approved last February.
[Dan] I suggest that at 12 you rather than using DEFVAL you mention in
the DESCRIPTION that you expect an agent to return those values after
initialization, but it should be clear that such an action is performed
at the instrumentation level, and not at the level of the SNMP agent.
(what happens if the value is read by CLI?)

 [Sumanth] Agree with Dan; I removed the DEFVAL and added a statement to
indicate the indicated default values, unless modified via MTA
configuration. Does that make sense?
----------------------------------------------------------------------
----------------------------------------------------------------------

13. [Dan] Inconsistent use of keywords in the DESCRIPTION clause of
pktcSigDevToneDbLevel. Actually I believe that there is no place here
for a MUST. Instead of 'This MIB Object MUST reflect the desired
level...' rather say 'This MIB object reflects ...'

[RW] I agree.
[Sumanth] done
----------------------------------------------------------------------
----------------------------------------------------------------------

14. [Dan] In several places the term 'SNMP Management Station' is being
used.
I prefer 'SNMP Manager application'.=20
[RW] I tend to agree, especially after reading sections 7.5 and 7.7 of
RFC 3410, and seeing RFC 3413 "Simple Network Management Protocol (SNMP)
Applications".
[Sumanth] Corrected
----------------------------------------------------------------------
----------------------------------------------------------------------

15. [Satish]=20
        The MIB pktcSigDevToneDbLevel defined in draft-11 has range
(-250..-30) with default value as -40dBm. Normal dial tone is at -13dB
(means -130dBm). Current default value is a too loud signal. I would
recommend to change the defailt to -120 along with the range to
(-250..-110)
[Eugene]=20
This proposal looks reasonable given the fact that POTS specification
seems to not require a full existing range of (-250, -30). The proposed
default value is also reasonable.
[Sumanth] Done

----------------------------------------------------------------------
----------------------------------------------------------------------
=20
16. [Eugene]  Refer  to " Issues with Tone Generation in Signaling MIB
draft-11 (Eugene, v1).doc"
Summary: Japan's "NTT Telephone service interfaces, edition 5"
Specification defines two call waiting tones - "Incoming Identification
Tone" (IIT) and "Specific Incoming Identification Tone" (SIIT)
containing the following tone sequence:

Either of these tones corresponds to the following tone generation
schema:
1.	16 Hz is modulated to carry the 400 Hz signal, ModulationRate
within 85%, on for 500msec, at -25 dBm or more but less than -14 dBm
2.	16 Hz is modulated to carry the 400 Hz signal, off for 0 ~ 4
secs
3.	400 Hz not modulated, on for 50 ms at -25 dBm or more but less
than -14 dBm
4.	400 Hz not modulated, off for 450ms=20
5.	400 Hz not modulated, on for 50 ms at -25 dBm or more but less
than -14 dBm
6.	400 Hz not modulated, off for 3450ms ([4000 - (50+450+50)])
7.	Steps 3 thru 6 are repeated.
As standard requires, to generate either of those call waiting tones,
the tone sequence should contain non-repetitive frequency group (step-1
+ step-2) immediately followed by a repetitive frequency group (step-3 +
step-4 + step-3 + step-4 + step-5) with the duration of 4000 msec in
total.=20
The current composition of the Tone Generation MIB Tables in draft-11
("pktcSigDevToneTable" and "pktcSigDevMultiFreqToneTable") is such that
it can accommodate either non-repetitive tone sequence or repetitive
tone sequence, and does not allow the mixture of those.

Proposal:
To address the problem, the composition of the Tone Generation Tables
defining various Tone Types should allow for the combination of the
repetitive and non-repetitive parts in the definition of the particular
tone.=20
In the current draft-11, the "pktcSigDevToneTable" MIB Table is defined
in such a way that it allows only for one row for each particular tone
type. By doing so, this table can define only either the repetitive tone
(when pktcSigDevToneWholeToneRepeatCount > 0) or non-repetitive tone
(when pktcSigDevToneWholeToneRepeatCount =3D=3D 0). Such composition of =
the
"pktcSigDevToneTable" MIB Table excludes the possibility for the tone
type to be represented by a mixture of non-repetitive and repetitive
parts.
To allow for the various definitions of the Tone Types, the composition
of the "pktcSigDevToneTable" MIB Table should be expanded.=20

[Sumanth]  Incorporated

----------------------------------------------------------------------
----------------------------------------------------------------------
17. [Satish] Requested clarification to the MIB Object
'pktcSigDevR5Cadence' to indicate that it is a non-repeatable signal.
[Sumanth] The request in return is to clarify this in the "L Package"
specification
----------------------------------------------------------------------
----------------------------------------------------------------------
18. [Eugene] Add clarification to 'pktcSigDevToneSteady'
"If pktcSigDevToneTable contains multiple rows with this=20
Object set to 'true', the steady tone is applied to the=20
last repeating frequency group of the tone."
[Sumanth] Done

----------------------------------------------------------------------
=20
=20