comments on draft-ietf-ipcdn-pktc-signaling-05.txt (part 3)

Hi -

Here are my starting comments on draft-ietf-ipcdn-pktc-signaling-05.txt
based on draft-ietf-ops-mib-review-guidelines-03.txt for issues
I haven't already commented on.

1) guidelines 3.2 para 1: need to describe relationship to other modules.
for example, interfaces MIB since ifIndex is part of indexing scheme.

2) guidelines 3.2 para 2: need to document in narrative MIB modules
(other than SMIv2 docs) from which things are imported

3) guidelines 3.7.2: IANA considerations section needs to note that the
mib-2 oid assignment for the module identity is needed

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)

5) TenthdBm: "This data type" -> "This textual convention"

6) PktcCodecType: "Textual Convention defines " -> "This textual
convention defines"

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

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?

9) (general) What are "international objects"? Does this term need
to be defined?

10) PktcRingCadence: is a "cadence period" the same thing as a "cadence
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.)

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?

13) PktcSigType: is any guidance needed on when to use reserved(2)
and when to use other(1)?

***more to come***

Randy