Subject: [ipcdn] Responses to comments on IETF Sig MIB draft 5

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Fri, 3 Sep 2004 12:47:01 -0700

Responses to comments on IETF Sig MIB draft 5
 
****************************************************
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 formating.
 
2) some pages have more than 58 lines
 
AI: Fix in final formating.
 
3) pages not separated by FF character
 
AI: Fix in final formating.
 
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 wgchairs 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?
 
AI: Open. A separate reflector thread has been started to solicit comments from IPCDN members on adding normative requirements.
 
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.
 
AI: No change.
 
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.
 
AI: Open. Issue posted to the PC NCS/PROV reflector for input.
 
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.
 
****************************************************
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.
 
Gordon Beacham
Motorola, Inc.
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn