[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ipcdn] Submission: IETF NCS Signaling MIB draft 7 (Update)
Hi All,
Based on the comments received so far,
draft-ietf-ipcdn-pktc-signaling-07 has been submitted for posting. Find
enclosed the changes that have been incorporated into this version of
the draft.
Note: Gordon Beacham incorporated/consolidated a majority of the changes
indicated below. (Thanks Gordon!)
Thanks also to everyone else for the numerous
reviews/suggestions/comments. (Keep them coming!)
regards
Sumanth
****************************************************
Part 1:
****************************************************
1) lines limited to 72 characters:
trailing blanks make line 26 too long (73 characters)
trailing blanks make line 99 too long (73 characters)
trailing blanks make line 2206 too long (73 characters) trailing blanks
make line 2226 too long (73 characters) trailing blanks make line 2240
too long (73 characters) trailing blanks make line 2301 too long (73
characters)
AI: Fix in final formatting.
2) some pages have more than 58 lines
AI: Fix in final formatting.
3) pages not separated by FF character
AI: Fix in final formatting.
4) the words "INTERNET-DRAFT" should be in upper left
corner of first page
AI: Changed.
5) IPR Boilerplate: OK, but note that alternative wording for "plural"
authors has been presented on the WG chairs list:
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
AI: Changed.
6) Internet-Draft boilerplate: text is OK, but formatting is strange.
No change. Not clear what is "strange".
7) Filename: broken by strange formatting on first page
AI: Changed.
8) author list: present, but mal-formatted
AI: Fixed formatting.
9) Introduction: missing. (2.2 #5)
AI: Added Introduction section.
10) IANA considerations: contradictory, (2.2 #7b) seems to apply, since
an OID needs to be allocated.
AI: Added the following per 8/4 IPCDN reflector message from Dave
Thaler.
The MIB module in this document uses the following IANA-assigned OBJECT
IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER Value
---------- -----------------------
pktcSigMib { mib-2 XXX }
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for XXX under the mib-2 subtree and to
record the assignment in the SMI Numbers registry. When the assignment
has been made, the RFC Editor is asked to replace XXX (here and in the
MIB module) with the assigned value and to remove this note.
11) authors' addresses: need cleanup
(e.g., the first in the list uses normal US postal
address format, but the last in the list doesn't.)
AI: Changed.
12) Keywords: text references RFC 2119, but it is missing from the list
of normative references.
AI: Added normative reference: [RFC2119].
13) formal language use: MIB compilation: smilint objects to
pktcSigDevCodecType (an index of pktcSigDevCodecEntry) being read-only.
It should be not-accessible.
AI: Changed.
14) References:
[PKT-SP-MGCP-IO9-040113] is never cited.
[PKT-SP-PROV-IO8-040113] is never cited.
[PKT-SP-CODEC-IO5-040113] is never cited.
[PKT-SP-MIB-MTA-I08-040113] is never cited.
[ETSI TS 101 909-9] is never cited.
[TR 101 183] is never cited.
[RFC3289], while referenced in the MIB module, is not
cited in the text of the document.
[RFC3291], while referenced in the MIB module, is never cited.
[RFC3261] is never cited.
[RFC3435] is never cited.
MIB module IMPORTS from SNMP-FRAMEWORK-MIB, but it's
missing from the normative references and not cited in text.
AI: Deleted: [RFC3261], added normative references: [ITU-T-J169],
[RFC3411]. Cited reference in introduction and overview sections.
****************************************************
Part 2:
****************************************************
1) abbreviations expanded on first use: need to add expansions for:
IPR
LCD
CRCX
MDCX
DSP
SDP
DOCSIS
CODEC (also shows up as "codec" and "Codec")
RTP
FSK
MAP
rg
rs
cr
"Blvd" needs a "."
"Inc" needs a "."
"Corp" needs a "."
PCMU
PCMA
FQDN
MIBMTA
RSIP
LCD
CMS
RJ
"frequences" should be "frequencies"
"playout" should be "play out" (where it is a verb rather than a noun)
"dBm" also appears as "dbm"
AI: Expanded abbreviations on first use. Fixed spelling.
2) two spaces after end of sentence: document needs to be fixed so that
TWO spaces occur after "." at the end of a sentence. (2223bis 3.1 (7)
AI: Fix in final formating.
3) Table of contents / order of sections: the sections of the document
are not in the order specified by 2223bis section 4.
AI: Fixed. Added Introduction. Reordered references after IANA section.
Moved IPR after author's addresses.
4) Authors' Addresses and IPR Boilerplate (Full Copyright Statement)
sections are supposed to NOT have numbers.
AI: Changed.
5) On title page, an Author's name should be on a single line, as should
his/her affiliation. 2223bis section 4.1
AI: Changed.
6) Document is inconsistant in the use of "a"/"an" before acronyms
pronounced beginning with a vowel. (E.g. "MTA".) Suggest using "An"
consistently.
AI: Changed.
7) Document uses both "endpoint" and "Endpoint". Is a distinction
intended?
AI: Changed to lower case except at the start of a sentence.
8) "the widest range of marketplaces as is possible" ->
"the widest possible range of markets"
AI: Changed.
10) format of references:
a) Author lists need a "," before the "and" if
there are more than two authors. See the reference sections in
2223
bis for examples.
b) If there is more than one author, an "and" is needed
c) if there is more than one author, the last author's name is
written as "F. Lastname" rather than "Lastname, F."
AI: Changed formatting.
****************************************************
Part 3 (1-13), Part 4 (14-30)
****************************************************
1) guidelines 3.2 para 1: need to describe relationship to other
modules. for example, interfaces MIB since ifIndex is part of indexing
scheme.
AI: Added descriptive text to overview section.
2) guidelines 3.2 para 2: need to document in narrative MIB modules
(other than SMIv2 docs) from which things are imported
AI: Duplicate, see above.
3) guidelines 3.7.2: IANA considerations section needs to note that the
mib-2 oid assignment for the module identity is needed
AI: Duplicate, see part 1 # 10 above.
4) the module name and the module-identity descriptor don't follow the
recommended practices in guidelines appendix C (second bullet) and other
descriptors don't follow the recommended practices in the third and
fifth bullets) (I assume TenthdBm is intended for re-use by other MIB
modules)
AI: Changed module identity descriptor to pktcIetfSigMib per appendix C
bullet 2.
5) TenthdBm: "This data type" -> "This textual convention"
AI: Changed.
6) PktcCodecType: "Textual Convention defines " -> "This textual
convention defines"
AI: Changed.
7) PktcCodecType: the ASN.1 comments aren't technically part of the TC.
The descriptions of what the various enumerations should be given in the
DESCRIPTION clause. (The ASN.1 comments don't hurt, but they're not
enough.)
AI: Changed.
8) PktcCodecType: the "MUST" is inappropriate. It sounds like the
intent is to mandate how a registry would operate. Is the likelihood of
additional values being added to this enumeration high enough to justify
creating an IANA registry, rather than keeping the TC in this MIB
module?
AI: Changed.
9) (general) What are "international objects"? Does this term need to be
defined?
AI: The use of "international" is a legacy issue dating from initial MIB
creation.
10) PktcRingCadence: is a "cadence period" the same thing as a "cadence
cycle"?
AI: Changed period to cycle.
11) PktcRingCadence: the sentence "Each bit
after the third octet represents 50 ms and 1 represents
ring and 0 represents silent." might be clearer if the
first "represents" were replaced with "corresponds to", and if the first
"and" were "where". ("silent" -> "silence" wouldn't hurt.)
AI: Changed.
12) PktcRingCadence: are implementations required to enforce any
constraints on the values of a) the bit count field, b) the repeatable
field, c) the 3 on-off transition limit, d) values for bits beyond the
bit count, e) an octet-string length other than the minimum required to
encode whatever length is specified in the bit count field?
[Sumanth]: A separate reflector thread was started to solicit comments
from IPCDN members and the current recommendation is:
"This object provides an encoding scheme for ring cadences, including
repeatability characteristics. All octets and bit-strings in this object
MUST be encoded in network-byte order.
The first three higher order octets are reserved. The octets that follow
are used to encode a 'bit-string', with each bit corresponding to 50
milliseconds. A bit value of '1' indicates the presence of a ring-tone
and a bit value of '0' indicates the absence of a ring-tone, for that
duration (50 ms). (Note: A minimum number of octets required to encode
the bit-string MUST be used. )
The first two of the reserved octets MUST indicate the length of the
encoded cadence (in bits) and MUST range between 1 and 264. (Note: The
length in bits MUST also be consistent with the number of octets that
encode the cadence). The MTA MUST ignore any unused bits in the last
octet, but MUST reflect the value as provided on a subsequent SNMP GET.
The third of the reserved octets indicates 'repeatability' and MUST
be either 0x80 or 0x00 - the former value indicating
'repeatability' and the latter indicating 'non-repeatability'.
The MTA MUST reject attempts to set a value that violates any of
the above requirements."
----------------------------------------------------------------------
The addition below has NOT been incorporated (Do we need it?
Unresolved):
PktcRingCadence (TC). There was a suggestion for additional text for the
fourth
octet: "The ring cadence representation starts with the first 1 in the
pattern
(the leading 0s in the MSB are padding and are to be ignored)."
Apparently
there was some confusion trying to configure the ring cadence. [sumanth]
I think we can drop this. No one seems to have a strong opinion.
13) PktcSigType: is any guidance needed on when to use reserved(2) and
when to use other(1)?
AI: Changed description.
14) pktcSigDevCodecComboIndex: where does the range
constraint (1..255) come from? There's nothing in the document to
justify that particular upper bound.
AI: No change. See reflector discussion.
15) pktcSigDevCallerIdSigProtocol: the DESCRIPTION needs to spell out
what is meant by each enumeration
AI: Changed description.
16) pktcSigDev*Cadence: wouldn't it be simpler to put these
ten objects into a table? just a thought....
AI: No change.
17) pktcSigDefMediaStreamDscp: There's no antecedant for
"the new connection". Is "new connections" intended?
AI: Added the following before sentence starting with "When" to provide
context for "new connections":
Any currently active connections are not affected by updates to this
object.
18) pktcSignalingIndex: where does the range constraint
(1..255) come from? There's nothing in the document to
justify that particular upper bound.
AI: No change. See reflector discussion.
19) pktcSigDefNcsReceiveUdpPort: where does the lower range constraint
come from?
AI: No change. IANA registers ports 0-1023 and port 1024 is indicated as
reserved.
20) pktcSigPowerRingFrequency: for each of the enumeration values, the
DESCRIPTION clause should spell out what that value means.
AI: Changed description.
21) pktcSigPulseSignalType: should spell out what each enumeration value
means in the DESCRIPTION.
AI: Changed description to list enumerations.
22) pktcSigPulseSignalFrequency: does the "must" mean "MUST"
in the sense that an attempt to write a value incompatible with the
instance's pktcSigPulseSignalType must be rejected? What value does it
take / can it be set to for "inapplicable" signal types?
AI: Changed must to MUST. Added description for returning inconsistent
value for an inapplicable signal type.
23) pktcSigPulseSignalDbLevel: What value does it take / can it be set
to an inapplicable signal types?
AI: Added description for returning inconsistent value for an
inapplicable signal type.
24) pktcSigPulseSignalDuration: what happens when something attempts to
set this to a value that doesn't fall on one of the increment
boundaries, or on the wrong increment boundary for the specific signal
type?
AI: Added description for returning inconsistent value for incorrect
increment for a signal type.
25) pktcSigPulseSignalPulseInterval: same questions.
AI: Added description for returning inconsistent value for incorrect
increment for a signal type.
26) pktcSigPulseSignalRepeatCount: "must" means "MUST", right? Same
questions as (24) and (25).
AI: Change must to MUST. Added description for returning inconsistent
value for incorrect range.
27) pktcSigDevCIDFskAfterRing: how does one know whether a system is
"international" or not? Is the table supposed to be of defaults? When
"not used", what happens when one tries to get/set this object?
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
28) pktcSigDevCIDFskAfterDTAS: same questions as (27)
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
29) pktcSigDevCIDFskAfterRPAS: same questions as (27)
For example, what happens when a system is not international but the
pktcSigDevCIDMode is rpAsETS?
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
30) pktcSigDevCIDRingAfterFSK: same as (27)
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
****************************************************
Part 5 (31-71)
****************************************************
31) pktcSigDevCIDRingAfterFSK: what is the purpose of
the table in the DESCRIPTION?
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
32) pktcSigDevCIDDTASAfterLR: explain what is meant
by international, specify how it behaves for get/set
on "non-international" systems, explain what the
table in the DESCRIPTION is for, and specify what the
"not used" behaviour is.
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
33) pktcSigDevVmwiFskAfterDTAS: same as (32)
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
34) pktcSigDevVmwiFskAfterRPAS: same as (32)
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
35) pktcSigDevVmwiDTASAfterLR: same as (32)
AI: Replaced historical MIB use of "international" with e line package.
Added description for returning inconsistent value.
36) pktcSigDevRingCadenceTable: what is V5.2?
V5.1 is mentioned elsewhere, but those references
don't match this one.
AI: Deleted "In V5.2" since E line package contained in 101 909-4, which
defines the ring cadences is already noted in the description and
references.
37) pktcSigDevRingCadenceTable and pktcSigDevRingCadenceIndex: The
indexing should probably be 0..127, since that's how its done in the
protocol. Adding an offset of 1 doesn't add value in this case, and it
appears to increase the likelihood of confusion for the user.
AI: Changed to 0 to 127 to match ETSI spec and updated description in
associated table objects.
38) pktcSigDevRingCadenceTable: what is the lifecycle of entries in this
table? When/How are they created and deleted? Do they persist across
reboots or power failures?
AI: No change. The description already indicates the objects do not
persist across reboots.
39) pktcSigDevRingCadenceEntry: the DESCRIPTION is the one
that belongs on pktcSigDevRingCadenceIndex.
AI: Moved description.
40) pktcSigDevToneTable: the structure of this table is
a bit awkward. It *might* make more sense if it were broken into two
tables. The first, indexed by pktcSigDevToneType, would hold
pktcSigDevToneDbLevel, pktcSigDevToneFreqType,
pktcSigDevToneNumFrequencies, pktcSigDevToneWholeToneRepeatCount,
pktcSigDevToneNumOnOffTimes, and pktcSigDevToneSteady.
The second would be indexed by pktSigDevToneType and an Unsigned32
(1..4), collapsing pktcSigDevToneFirstFrequency,
pktcSigDevToneSecondFrequency, pktcSigDevToneThirdFrequency, and
pktcSigDevToneFourthFrequency into pktSigDevTonesFrequency, collapsing
pktcSigDevToneFirstToneOn, pktcSigDevToneSecondToneOn,
pktcSigDevToneThirdToneOn, and pktcSigDevToneFourthToneOn into
pktcSigDevTonesOn, and collapsing pktcSigDevToneFirstToneOff,
pktcSigDevToneSecondToneOff, pktcSigDevToneThirdToneOff, and
pktcSigDevToneFourthToneOff into pktSigDevTonesOff. This is only a
suggestion.
Also:
4. pktcSigDevToneTable (pending) - 12 new objects to be proposed per
findings from international trials that the current MIB defintion does
not support. I have not posted these to the reflector yet as the work is
still in progress.
[sumanth] The above suggestion is not incorporated in this version.
This requires more work and perhaps a future revision will address this.
41) pktcSigDevToneTable: The DESCRIPTION says "Any
definition of the tones callWaiting1-4 in this table
should just contain the audible tone itself and NOT
contain the delay between tones or the tone repeat count."
In those cases, how will pktcSigDevToneWholeToneRepeatCount
behave on get/set?
AI: Changed. Added the following text to the description:
If the pktcSigDevToneType is callWaiting1-4, the
pktcSigDevToneWholeToneRepeatCount does not apply and MUST be ignored on
SNMP set/get operations.
42) pktcSigDevToneEntry: the DESCRIPTION has the text that should be on
pktcSigDevToneType. The phrase "that are being supported" appears to be
at odds with the language in pktcSigDevToneTable that says "for each
possible index, an entry MUST be defined".
AI: Moved description.
43) pktcSigDevToneType: what is meant by "triggered"? This sounds at
odds with the language in pktcSigDevToneTable that says "for each
possible index, an entry MUST be defined".
AI: Changed "triggered" to "used in".
44) pktcSigDevTone*Frequency: "could" seems odd in these four. Is this
intended to mean that the device might do something else?
AI: Changed "could be" to "are".
45) pktcSigDevTone*ToneOn and pktcSigDevTone*ToneOff: the DESCRIPTIONS
are unclear. For example, does pktcSigDevFirstToneOn represent the
length of time that the tone will be on, or does it represent the amount
of time that must pass before the tone is turned on? For
pktSigDevFirstToneOff, for example, does its value represent the length
of time that the tone will be off, or does is represent the amount of
time that must elapse after the tone is turned on before it is turned
off, or does it represent the amount of time from the beginning of the
cadence that must elapse before the tone is turned off?
AI: Changed description. ToneOn = length of time tone is on. ToneOff =
length of time tone is off.
46) pktcNcsEndPntConfigTable: there is something wrong with this
sentence in the DESCRIPTION:
"Each endpoint can be assigned to a its own CMS."
AI: Deleted "a".
47) pktcNcsEndPntConfigEntry: punctuation in DESCRIPTION:
"Entries in pktcNcsEndPntConfigTable ? Each entry"
AI: Changed.
48) pktcNcsEndPntConfigCallAgentId: "it is highly recommended not to
change this object's value through management station during normal
operations." Do you mean "during normal operation, using SNMP to change
this object's value is NOT RECOMMENDED" or "during normal operation, the
use of management operations to change this object's value is NOT
RECOMMENDED"?
AI: Changed "through management station" to "using SNMP".
49) pktcNcsEndPntConfigCallAgentUdpPort: why the limited port range?
Where did 2727 come from?
AI: No change. Duplicate, see above. 2727 is the IANA default for the
MGCP CA port:
mgcp-callagent 2727/tcp Media Gateway Control Protocol Call Agent
mgcp-callagent 2727/udp Media Gateway Control Protocol Call Agent
50) pktcNcsEndPntConfigCallAgentUdpPort: "it is highly recommended not
to change this object's value through management station during normal
operations." Do you mean "during normal operation, using SNMP to change
this object's value is NOT RECOMMENDED" or "during normal operation, the
use of management operations to change this object's value is NOT
RECOMMENDED"?
AI: Changed "through management station" to "using SNMP".
51) pktcNcsEndPntConfigPartialDialTO:
"contains maximum" -> "contains the maximum" (The description and the
descriptor make it sound like the device may use any timeout value, as
long as that timeout value is less than this object's value. Is that
really the intent? Compare the DESCRIPTIONs of this,
pktcNcsEndPntConfigBusyToneTO, and pktcNcsEndPntConfigCriticalDialTO.
AI: Added "the". Remainder of comment is unclear.
52) pktcNcsEndPntConfigTSMax: "max" -> "maximum"
It's not clear from the description what this object controls. It
defines a period that is bounded on one end by "the sending of the
initial datagram" (whatever that is) but does not say what event is at
the other end of the interval.
AI: Changed max to maximum. Changed description per PC NCS spec.
53) pktcNcsEndPntConfigMax1: the description says this is a threshold,
but doesn't say what object or delta/interval it is compared to, and
doesn't say what happens when the threshold is crossed.
AI: Changed description. Max1 is defined in the PC MGCP spec.
54) pktcNcsEndPntConfigMax2: same as (53)
AI: Changed description. Max2 is defined in the PC MGCP spec.
55) pktcNcsEndPntConfigMax1QEnable: the description is unclear. Where is
timer Max1 defined? The only other Max1 in this document is a
threshold, rather than a timer. Also, there is an ambiguity in the
sentence. It can be read to mean "when Max1 expires, this object will
enable or disable the query operation" as well as to mean "the query
operation initiated whenever Max1 expires is enabled/disabled by this
object."
AI: Changed description to refer to thresholds. Max1 and Max2 are
thresholds defined in the PC MGCP spec.
56) pktcNcsEndPntConfigMax2QEnable: same as (55)
AI: Changed description to refer to thresholds. See above (55).
57) pktcNcsEndPntConfigMWD: the first and second sentences of the
description don't work well together. Taken together, they say the MTA
will restart every MWD seconds (or less). This is probably not what is
intended.
AI: Changed description to refer to initial power on and restart
procedure per the PC NCS spec.
58) pktcNcsEndPntConfigTdinit: same problem as (57) Could be fixed by
changing "after" to "before", but I'm not sure that's what was intended.
AI: Changed description to refer to initiating the disconnect procedure
with the call agent per PC NCS spec.
59) pktcNcsEndPntConfigTdmin, pktcNcsEndPntConfigTdmax, and
pktcNcsEndPntConfigTdinit don't work well together. As currently
written, the disconnected procedure will be initiated three times, once
for each of these three timers. Furthermore, are there any constraints
on their relative values? For example, is it OK to set
pktcNcsEndPntConfigTdmin to a value larger than that of
pktcNcsEndPntConfigTdmax?
AI: No change. These values and their relationships are defined in
detail in the PC NCS spec.
60) pktcNcsEndPntConfigRtoMax / pktcNcsEndPntConfigRtoInit: is there any
relationship between these two objects? Why do they have different
units?
AI: No change. MGCP uses exponentially increasing timers for
retransmission. RTO init is the configured initial retransmission timer
value in milliseconds (per PC MGCP 4.4.2).
61) pktcNcsEndPntConfigStatus: RFC 2579 (page 8, "NOTE WELL") requires
any use of RowStatus to specify whether columns may be modified when the
row is active, and (page 17) under what circumstance it should/may be
taken out of service. See MIB review guidelines section 4.6.4 for
details.
[sumanth]
No restrictions. Made changes to reflect guidelines posted in section
4.6.4 of:
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines
-03.txt
----------------------------------------------------------------
See comment posted from NCS reflector dated 9/3 from Eugene. [Eugene's
comments
> 1. Is the intent for the read-create objects in this table to
> be modified while the row is active?
Currently, there are no restrictions on the on the modification of any
of the exesting conceptual columns. Some implementations may enforce the
cross reference integrity of the value in the CallAgentID column with
the CMS table. But it's not a mandatory behavior.
> 2. If telephony service is canceled or the endpoint is
> disconnected, MAY (or MUST) the MTA set the row to inactive?
I am not sure what particular is meant by "telephony service is
canceled" but there are several conditions which are making the
endpoint disabled: CallAgentID can be set to "" (empty), the row can be
completely deleted, ifAdminStatus is set to down(2), MtaDisabled is set
to true(1), "pktcNcsEndPntConfigStatus" is set to "notInService" by the
NMS (for whatever reason).
If the endpoint becomes "disconnect", the "pktcNcsEndPntStatusError" MIB
Object must be set to disconnected(3) state.
Both of these scenarios do not require the MTA to change the
"pktcNcsEndPntConfigStatus" value, and the row is still in "active"
state (if it exists).
In all other respects, handling of "pktcNcsEndPntConfigStatus" object is
goverened by SNMPv2-TC SMI.
Eugene.
]
------------------------------------------------------------------------
-
63) pktcNcsEndPntStatusError: the DESCRIPTION says "Otherwise, the
state is unused." Is "state" the same thing as "status" in the rest of
the DESCRIPTION? What value does this object have when it is "unused"?
AI: Replaced "Othewise the state is unused." with "If
pktcMtaDevCmsIpsecCtrl is disabled for the associated Call Agent, the
noSecurityAssociation status is not applicable and should not be used by
the MTA."
64) pktcNcsEndPntStatusError: suggest changing
"Otherwise, pktcMtaDevCmsIpsecCtrl is enabled," ->
"Otherwise, when pktcMtaDevCmsIpsecCtrl is enabled,"
AI: Changed.
65) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash:
are there any constraints on the relationship of the values of these
two?
AI: Changed description to indicate the max hook flash must be greater
than min hook flash.
66) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash,
etc.: "This object must only be set via the configuration file during
the provisioning process." Is this intended to prohibit provisioning by
means other than a configuration file?
AI: Yes.
67) pktcNcsEndPntConfigPulseDialMinMakeTime,
pktcNcsEndPntConfigPulseDialMaxMakeTime,
pktcNcsEndPntConfigPulseDialMinBreakTime,
pktcNcsEndPntConfigPulseDialMaxBreakTime, and
pktcNcsEndPntConfigPulseDialInterdigitTime:
constraints with respect to each other? with respect to Hook Flash?
AI: Changed descriptions to indicate the max must be greater than min.
No formal relationship between min/max make/break. Hook flash is
generally longer duration than dial pulse but there is no formal spec.
68) Problems in object descriptors (review guidelines
AI: No change. Comment about object descriptors is not clear.
69) MIB review guidelines appendix C. These are
only *suggested* naming conventions, but they're worth considering,
especially since the current draft is mostly consistant. Current
aberrations that I noticed:
PKTC-IETF-SIG-MIB DEFINITIONS ::= BEGIN
but
pktcSigMib MODULE-IDENTITY
pktcSigMib MODULE-IDENTITY
and
PktcSigType ::= TEXTUAL-CONVENTION
but
PktcCodecType ::= TEXTUAL-CONVENTION
PktcRingCadence ::= TEXTUAL-CONVENTION
(Assuming
TenthdBm ::= TEXTUAL-CONVENTION
is intended for external use.)
pktcSigMib MODULE-IDENTITY
and
pktcSigMibObjects OBJECT IDENTIFIER ::= { pktcSigMib 1 }
pktcSigDevConfigObjects OBJECT IDENTIFIER ::=
pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 }
pktcSigConformance OBJECT IDENTIFIER ::= { pktcSigMib 2 }
pktcSigCompliances OBJECT IDENTIFIER ::= { pktcSigConformance 1 }
pktcSigGroups OBJECT IDENTIFIER ::= { pktcSigConformance 2 }
but
pktcNcsEndPntConfigObjects OBJECT IDENTIFIER ::=
pktcSigCapabilityEntry OBJECT-TYPE
but
pktcSignalingIndex Unsigned32,
pktcSignalingType PktcSigType,
pktcSignalingVersion SnmpAdminString,
pktcSignalingVendorExtension SnmpAdminString
pktcSigMib MODULE-IDENTITY
but
pktcNcsEndPntConfigTable OBJECT-TYPE
and
pktcNcsEndPntConfigCallAgentId SnmpAdminString,
pktcNcsEndPntConfigCallAgentUdpPort InetPortNumber,
pktcNcsEndPntConfigPartialDialTO Unsigned32,
pktcNcsEndPntConfigCriticalDialTO Unsigned32,
pktcNcsEndPntConfigBusyToneTO Unsigned32,
pktcNcsEndPntConfigDialToneTO Unsigned32,
pktcNcsEndPntConfigMessageWaitingTO Unsigned32,
pktcNcsEndPntConfigOffHookWarnToneTO Unsigned32,
pktcNcsEndPntConfigRingingTO Unsigned32,
pktcNcsEndPntConfigRingBackTO Unsigned32,
pktcNcsEndPntConfigReorderToneTO Unsigned32,
pktcNcsEndPntConfigStutterDialToneTO Unsigned32,
pktcNcsEndPntConfigTSMax Unsigned32,
pktcNcsEndPntConfigMax1 Unsigned32,
pktcNcsEndPntConfigMax2 Unsigned32,
pktcNcsEndPntConfigMax1QEnable TruthValue,
pktcNcsEndPntConfigMax2QEnable TruthValue,
pktcNcsEndPntConfigMWD Unsigned32,
pktcNcsEndPntConfigTdinit Unsigned32,
pktcNcsEndPntConfigTdmin Unsigned32,
pktcNcsEndPntConfigTdmax Unsigned32,
pktcNcsEndPntConfigRtoMax Unsigned32,
pktcNcsEndPntConfigRtoInit Unsigned32,
pktcNcsEndPntConfigLongDurationKeepAlive Unsigned32,
pktcNcsEndPntConfigThist Unsigned32,
pktcNcsEndPntConfigStatus RowStatus,
pktcNcsEndPntConfigCallWaitingMaxRep Unsigned32,
pktcNcsEndPntConfigCallWaitingDelay Unsigned32,
pktcNcsEndPntStatusCallIpAddressType InetAddressType,
pktcNcsEndPntStatusCallIpAddress InetAddress,
pktcNcsEndPntStatusError INTEGER,
pktcNcsEndPntConfigMinHookFlash Unsigned32,
pktcNcsEndPntConfigMaxHookFlash Unsigned32,
pktcNcsEndPntConfigPulseDialInterdigitTime Unsigned32,
pktcNcsEndPntConfigPulseDialMinMakeTime Unsigned32,
pktcNcsEndPntConfigPulseDialMaxMakeTime Unsigned32,
pktcNcsEndPntConfigPulseDialMinBreakTime Unsigned32,
pktcNcsEndPntConfigPulseDialMaxBreakTime Unsigned32
AI: Changed MIB module name to pktcIetfSigMib. No other name changes
made.
70) MIB review guidelines section 3.2 second paragraph
AI: Duplicate, see above. Overview section changed to include narrative
on MIB modules.
71) MIB review guidelines section 3.7.2
AI: Duplicate, see above. IANA section added.
************************************************
Sumanth's collection:
*********************************************************
In the DESCRIPTION of a number of MIB objects, the term "international
systems" has been replaced by "E package" in draft 6. This introduces
the side-effect that a number of MIB objects that have nothing to do
with E package support, now only have to be supported when the E package
is supported. The following MIB objects are the ones I believe have
nothing to do with the E package, since the caller ID and VMWI
transmissions are triggered using the L package:
pktcSigDevCIDMode
pktcSigDevCIDFskAfterRing
pktcSigDevCIDFskAfterDTAS
pktcSigDevCIDFskAfterRPAS
pktcSigDevCIDRingAfterFSK
pktcSigDevCIDDTASAfterLR
pktcSigDevVmwiFskAfterDTAS
pktcSigDevVmwiFskAfterRPAS
pktcSigDevVmwiDTASAfterLR
An MTA for the international market that does however not support the E
package, will want to support the above MIB objects.
Maybe we can revert to the description of "international systems"?
Thanks,
Regards,
David
[Sumanth] This was turned down since 'International Systems' is not
defined. Changed it to be 'Euro-PacketCable' instead.
*********************************************************
****************************************************
Reflector Comments
****************************************************
1. Changed default value of pktcNcsEndPntConfigMaxHookFlash from 500 to
800.
2. Added text to description to indicate wholetonerepeatcount and
pktcSigDevToneSteady do not override the duration in an associated
timeout (TO) object.
****************************************************
Other
****************************************************
* Added ilbc and bv16 to PktcCodecType.
* Deleted pktcSigDevCodecType object from the pktcSigGroup group -
this clears a compile error for some MIB compilers.
* Posted and updated text for pktcSigDevToneWholeToneRepeatCount
and pktcSigDevToneSteady per issue raised by Satish.
* Reverted changes to objects identified by tcomlabs in posting
dated 9/30. Shame on me for late night editing and not checking package
compliance.
* pktcSigDevToneTable (pending) - 12 new objects to be proposed
per findings from international trials that the current MIB defintion
does not support. I have not posted these to the reflector yet as the
work is still in progress.
Regards
Sumanth
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn