Thanks to editors/authors and reviewers. The doc has a normative references to other docs (still in this WG), so it will get held till those are also approved. Formal announcement will come from iesg secretriat over the next few days. Bert
Questions on sig mib draft-8 tone table representation. 1. According to NCS spec, "ROH Tone is generated by combining four tones at frequencies of 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600 Hertz at a cadence of 0.1 second on, 0.1 second off, repeating." But in the latest IETF signaling draft(ver 8), pktcSigDevMultiFreqToneTable contains provision to store only two frequency components.What would happen in the case that more than two frequencies are required, like in the case of off-hook warning notifications, where four frequencies are used?? 2. Could it be possible to have an example of complex signals that were used to define the requirements from this draft, in form of the MIB elements (e.g. Japanese signal with the different element definitions or complex repetition signals) for testing purposes? 3. pktcSigDevToneFrequencyNumber is the index to pktcSigDevMultiFreqToneTable and its value ranges from 5-16. Why should the index value start from 5??? Comments please... Thanks, Satish Kumar Texas Instruments
The IESG has approved the following document: - 'Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems ' <draft-ietf-ipcdn-docsisevent-mib-06.txt> as a Proposed Standard This document is the product of the IP over Cable Data Network Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. Working Group Summary The Working Group has consensus to publish this document as a Proposed STandard. Protocol Quality(Continue reading)
The following are the questions on SIG draft-08.
1. pktcSigDevToneType currently defined as follows:
pktcSigDevToneType OBJECT-TYPE
SYNTAX INTEGER {
busy(1),
........
userDefined3(20),
userDefined4(21)
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Unique value ranging from 1 to 21 that will correspond
to the different tone types. These tones can be
provisioned based on country specific needs. This
object defines the type of tone being accessed.
The alertingSignal, specialDial, specialInfo, release,
congestion and userDefined1-4 tone types are used in
the E line package."
::= { pktcSigDevConfigObjects 32 }
The object is defined as being "not-accessable". The description clause does
not have clear pointers on how "not-accessable" object is supposed to be used
by the MTA and/or NMS. What is the value this object is supposed to have in
various scenarios ? How this value is supposed to be set to the MTA ?
2. pktcSigDevToneNumFrequencies currently defined as follows:
(Continue reading)> 1. According to NCS spec, "ROH Tone is generated by > combining four tones at frequencies of 1400 Hertz, 2060 > Hertz, 2450 Hertz and 2600 Hertz at a cadence of 0.1 > second on, 0.1 second off, repeating." But in the latest > IETF signaling draft(ver 8), pktcSigDevMultiFreqToneTable > contains provision to store only two frequency > components.What would happen in the case that more than > two frequencies are required, like in the case of off-hook > warning notifications, where four frequencies are used?? Indeed an interesting observation. As I recall, one of the design guidelines for these new MIB objects was to get rid of ... pktcSigDevToneFirstFrequency Unsigned32, pktcSigDevToneSecondFrequency Unsigned32, pktcSigDevToneThirdFrequency Unsigned32, pktcSigDevToneFourthFrequency Unsigned32, pktcSigDevToneFifthFrequency Unsigned32, ... and the likes in the original PktcSigDevToneEntry (see http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01466.html). This is probably why for the pktcSigDevToneFrequencyNumber object there can now be between 5 and 16 frequencies. There has, however, also been a semantic change: in the original table, all frequencies could be present at the same time,(Continue reading)
> 1. pktcSigDevToneType currently defined as follows:
>
> pktcSigDevToneType OBJECT-TYPE
> SYNTAX INTEGER {
> busy(1),
> ........
> userDefined3(20),
> userDefined4(21)
> }
> MAX-ACCESS not-accessible
> STATUS current
...
> The object is defined as being "not-accessable".
This was also the case in previous versions of the draft,
and did not seem to cause trouble?
> 2. pktcSigDevToneNumFrequencies currently defined as
> follows:
>
> 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}
>
(Continue reading)
In order to support tones with more than 2 frequencies, the sig mib
draft-8 can be modified slightly to support these. A new frequency table
has to be added to specify multiple frequencies.
The modified tone table is given below:
pktcSigDevToneType OBJECT-TYPE
SYNTAX INTEGER {
busy(1),
confirmation(2),
dial(3),
messageWaiting(4),
offHookWarning(5),
ringBack(6),
reOrder(7),
stutterdial(8),
callWaiting1(9),
callWaiting2(10),
callWaiting3(11),
callWaiting4(12),
alertingSignal(13),
specialDial(14),
specialInfo(15),
release(16),
congestion(17),
userDefined1(18),
userDefined2(19),
userDefined3(20),
userDefined4(21)
}
(Continue reading)
> This was also the case in previous
> versions of the draft, and did not seem to cause trouble?
Correct, execept that the previous version (draft-07) had this object as a
part of the PktcSigDevToneEntry as an index, which is "not-accessable". The
value of INDEX is provided with the PDU as a part an index part of the OID
being quiried by the particular PDU.
> ...this would be a pre-configured value to indicate the MTA's
> capabilities, i.e. to tell the NMS how many frequencies
> the MTA supports at a maximum. If this is indeed the case,
> then the object should not be read-write, but read-only instead.
If this is the intention, then it's not aligned clearly with the decsription
clause. I think the intention of the object requires further clarification.
Eugene.
-----Original Message-----
From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of
David De Reu
Sent: Tuesday, June 14, 2005 12:37 AM
To: ipcdn <at> ietf.org
Subject: RE: [ipcdn] Questions on SIG draft-08
> 1. pktcSigDevToneType currently defined as follows:
>
> pktcSigDevToneType OBJECT-TYPE
> SYNTAX INTEGER {
> busy(1),
> ........
> userDefined3(20),
(Continue reading)
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.
Title : Cable Device Management Information Base for
Data-Over-Cable Service Interface
Specification Compliant Cable Modems and Cable
Modem Termination Systems
Author(s) : R. Woundy, K. Marez
Filename : draft-ietf-ipcdn-device-mibv2-09.txt
Pages : 91
Date : 2005-6-21
This memo is a revision of the standards track RFC 2669. Please see
"Revision Descriptions" below for a description of changes. This
document obsoletes RFC 2669.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines a basic set of managed objects for SNMP-
based management of DOCSIS-compliant Cable Modems and Cable Modem
Termination Systems.
This memo is a product of the IPCDN working group within the Internet
Engineering Task Force. Comments are solicited and should be
addressed to the working group's mailing list at ipcdn <at> ietf.org
and/or the author.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt
(Continue reading)
Hi,
Question on pktcNcsEndPntConfigTxGain and pktcNcsEndPntConfigRxGain
The MIB description is pasted below. There is no range of values defined
for these MIBs. Setting random values impact the devices badly. It is
good to retsrict these MIBs with specific range values.
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
(Continue reading)
RSS Feed1 | |
|---|---|
3 | |
4 | |
3 | |
4 | |
2 | |
2 | |
6 | |
1 | |
4 | |
2 | |
5 | |
3 | |
4 | |
4 | |
2 | |
4 | |
4 | |
8 | |
2 | |
3 | |
10 | |
20 | |
16 | |
14 | |
15 | |
20 | |
27 | |
58 | |
36 | |
27 | |
37 | |
4 | |
6 | |
7 | |
26 | |
121 | |
7 | |
20 | |
47 | |
35 | |
42 | |
53 | |
19 | |
19 | |
74 | |
16 | |
43 | |
59 | |
22 | |
22 | |
72 | |
40 | |
78 | |
50 | |
37 | |
24 | |
24 | |
37 | |
34 | |
97 | |
51 | |
23 | |
33 | |
13 | |
4 | |
10 | |
11 | |
17 |
