Last of review comments on draft-ietf-ipcdn-pktc-signaling-05.txt

Hi -

This is the last of my review comments on
draft-ietf-ipcdn-pktc-signaling-05.txt, based on
the MIB review guidelines.


31) pktcSigDevCIDRingAfterFSK: what is the purpose of
the table in the DESCRIPTION?

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.

33) pktcSigDevVmwiFskAfterDTAS: same as (32)

34) pktcSigDevVmwiFskAfterRPAS: same as (32)

35) pktcSigDevVmwiDTASAfterLR: same as (32)

36) pktcSigDevRingCadenceTable: what is V5.2?
V5.1 is mentioned elsewhere, but those references
don't match this one.

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.

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?

39) pktcSigDevRingCadenceEntry: the DESCRIPTION is the one
that belongs on pktcSigDevRingCadenceIndex.

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.

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?

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".

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".

44) pktcSigDevTone*Frequency: "could" seems odd in these four.
Is this intended to mean that the device might do something else?

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?

46) pktcNcsEndPntConfigTable: there is something wrong with
this sentence in the DESCRIPTION:
             "Each endpoint can be assigned to a its own CMS."

47) pktcNcsEndPntConfigEntry: punctuation in DESCRIPTION:
           "Entries in pktcNcsEndPntConfigTable ? Each entry"

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"?

49) pktcNcsEndPntConfigCallAgentUdpPort: why the limited port range?
Where did 2727 come from?

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"?

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.

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.

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.

54) pktcNcsEndPntConfigMax2: same as (53)

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."


56) pktcNcsEndPntConfigMax2QEnable: same as (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.

58) pktcNcsEndPntConfigTdinit: same problem as (57)  Could be
fixed by changing "after" to "before", but I'm not sure that's
what was intended.

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?

60) pktcNcsEndPntConfigRtoMax / pktcNcsEndPntConfigRtoInit: is
there any relationship between these two objects?  Why do they
have different units?

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.

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"?

64) pktcNcsEndPntStatusError:  suggest changing
            "Otherwise, pktcMtaDevCmsIpsecCtrl is enabled," ->
            "Otherwise, when pktcMtaDevCmsIpsecCtrl is enabled,"

65) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash:
are there any constraints on the relationship of the values
of these two?

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?

67) pktcNcsEndPntConfigPulseDialMinMakeTime,
pktcNcsEndPntConfigPulseDialMaxMakeTime,
pktcNcsEndPntConfigPulseDialMinBreakTime,
pktcNcsEndPntConfigPulseDialMaxBreakTime, and
pktcNcsEndPntConfigPulseDialInterdigitTime:
constraints with respect to each other?  with respect to Hook Flash?

68) Problems in object descriptors (review guidelines

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


70) MIB review guidelines section 3.2 second paragraph

71) MIB review guidelines section 3.7.2


Let me know if any of these comments need further clarification.

Randy