[rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt

["C. M. Heard" <[e-mail]>]

>>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote:
Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt
Bert> in the next week or two?

>>>>> On Fri, 13 Jun 2003, C. M. Heard replied:
CMH> I will volunteer to do this.  Based on a quick look I think
CMH> I should be able to turn around the review before June 26th.

As noted above, I've volunteered to do a MIB Doctor review of
<draft-ietf-rohc-mib-rtp-06.txt>.  For the most part, I have been
pleased with the quality of that document.  However, there are a
number of things that do need to be corrected, or at least looked
at, before the document goes to the IESG.  The detailed review
comments below follow the checklist from Appendix A of the draft
guidelines document <draft-ietf-ops-mib-review-guidelines-01.txt>.
Those who wish to respond to these review comments should do so on
the ROHC mailing list, with copies to Bert Wijnen and myself.

0.) Title -- s/Robus/Robust/

1.) I-D Boilerplate -- OK

2.) Abstract -- acronyms used in the abstract must be expanded on
first use, except for those acronyms that everyone in the IETF can
reasonably be expected to know (see Sections 4.5 and 2.9 of
<draft-rfc-editor-rfc2223bis-06.txt> or its successor document).
Certainly ROHC and LLA will need to be expanded;  I'm not sure about
ESP and RTP -- please check with the RFC Editor.  Here is a partial
fix:

 This memo defines a portion of the Management Information Base (MIB)
 for use with network management protocols in the Internet community.
 In particular, it describes a set of managed objects that allow
 monitoring of running instances of RObust Header Compression (ROHC).
 [ ... ]

The remainder is left to the authors to sort out.

3.) MIB Boilerplate -- OK

4.) IPR Notices -- the required notices from RFC 2026 Sections
10.4(A) and 10.4(B) are present and no claims are noted;  this
is OK if indeed there are no relevant IPR disclosures.  Note,
however, that a search of the IPR statements on the IETF web site
does reveal some claims that seem like they _might_ be relevant:

   Search Results for query = '(robust or robustness or robustly)
   and (header or head or headed or heading or headings or heads
   or headers) and (compression or compressions)'
   _________________________________________________________________

 Match: [All....] Format: [Long.] Sort by: [Title........]
 Refine search: ______________________________ Search
   _________________________________________________________________

 Documents 1 - 4 of 11 matches. More * 's indicate a better match.
   _________________________________________________________________

 [ERICSSON-ROCCO] *
        ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE
        UNDERTAKING In the AVT Working Group in the Internet
        Engineering Task Force, a proposal "RObust Checksum-based
        header COmpression (ROCCO)" dated June 22, 1999 has been
        made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at
        Lulea University ...
        http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557
        bytes

 [ERICSSON-SIGCOMP.txt] * * * *
        ... that might possibly have technical relations to the
        Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt.
        This draft is part of the Signaling Compression work
        taking place in the Robust Header Compression (ROHC) WG.
        See further Ericsson's general IPR statement:
        http://www.ietf.org/ietf/IPR/ERICSSON ...
        http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02,
        466 bytes

 [NOKIA-RFC3095.txt] *
        ... : 1) "CID field handling in ROHC": FI 20002100, US
        09/954562, PCT/FI01/00819 2) "Variable length context
        identifier for real time header compression": FI 20002307,
        US 09/978479, PCT/FI01/00902 3) "Variable length encoding of
        compressed data": US 09/536638, US 60/164330, ...
        http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02,
        1373 bytes

 [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] *
        ... This is to advise the IETF that Telefonaktiebolaget LM
        Ericsson believes it owns patents and patent applications
        which may relate to RFC 3095, "RObust Header Compression
        (ROHC): Framework and four profiles: RTP, UDP, ESP, and
        uncompressed".  See further Ericsson's general IPR
        statement: http://www.ietf.org/ietf/IPR/ERICSSON ...
        http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST-
        HEADER-COMPRESSION.txt 09/27/02, 439 bytes

 Return to the Seach Page
   _________________________________________________________________

 ht://Dig 3.1.6

The document authors and the WG should examine these IPR disclosures
and either determine for sure that none are required in order to
implement the MIB module or else add the notice from RFC 2026
Section 10.4(D).  (The reviewer will be satisfied if the authors
reply that the IPR section in the document is OK as it stands.  All
that's being requested is an assurance that you have done your
homework.)

5.) References -- there are some missing normative references and
some of the existing references contain minor errors or don't
exactly follow the current RFC style.  The style issues are listed
only for completeness;  RFC Editor will fix that in any case.

(a) RFC 3411 needs to be added as a normative reference since
SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB
(c.f. <draft-ietf-ops-mib-review-guidelines-01.txt> Section 3.5).

(b) RFC 2863 needs to be added as a normative reference since
IF-MIB appears in the IMPORTS statement of all three MIB
modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB.

(c) [RFC3095] has an incorrect title and an author list that's not
in the standard form.

(d) [RFC3242] has an author list that's not in the standard form.

(e) [RFCXXXX] has an author list that's not in the standard form,
and it might be helpful to readers to indicate the I-D that will
eventually turn into this RFC-to-be.

6.) Security Considerations Section -- there are two read/write
objects but only one is mentioned.  A possible fix would be to
revise the first paragraph to read as follows:

 The managed objects defined by the ROHC-MIB module, the
 ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not
 have a MAX-ACCESS value of read-write and/or read-create except
 rohcInstanceContextStorageTime and rohcContextStorageTime, both of
 which have a MAX-ACCESS value of read-write.  These objects
 determine how long context information is stored after its
 termination.  Unauthorized access to these objects can have one of
 two negative effects.  If they are set to a value lower than
 required, e.g. to zero, then context information about past contexts
 might get lost.  If they are set to a very high value, then context
 information will not be deleted and memory consumption of the agent
 implementation might become very high.  However, unauthorized access
 to these objects cannot cause harm to existing ROHC connections nor
 can it allow manipulation of running instances of ROHC in a
 malicious way.

The fourth paragraph says "[a]lthough the security risks arising
from the ROHC-MIB module are not considered to be high", but the
second paragraph says "[it is] important to control even GET and/or
NOTIFY access to these objects and possibly to even encrypt the
values of these objects when sending them over the network via
SNMP."  That seems contradictory.  It is therefore suggest to
modify the fourth paragraph so that it reads as originally written
in the standard security considerations template:

 It is RECOMMENDED that implementers consider the security features
 as provided by the SNMPv3 framework (see [RFC3410], section 8),
 including full support for the SNMPv3 cryptographic mechanisms (for
 authentication and privacy).

7.) IANA Considerations Section -- OK (none present and none
required).

8.) Copyright notices -- the abbreviated copyright notices that are
supposed to appear on the front page and in the DESCRIPTION clause
of each MODULE-IDENTITY invocation are missing and need to be added.
See http://www.ietf.org/ID-nits.html section 1.2,
<draft-rfc-editor-rfc2223bis-06.txt> section 4.3, and
<draft-ietf-ops-mib-review-guidelines-01.txt> section 3.8.

9.) MIB compilation -- the following problems are reported by smilint:

This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)
has been processed to get the following results:
smilint -m -s -l 6 -i namelength-32 ROHC-MIB

ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-MIB:184: [5] {index-element-accessible} warning: index element
`rohcInstanceType' of row `rohcInstanceEntry' should be
not-accessible in SMIv2 MIB

FIXES:
(a) add Counter32 to the list of things imported from SNMPv2-SMI
(b) change MAX-ACCESS value of rohcInstanceType to not-accessible
(c) remove rohcInstanceType from rohcInstanceGroup


This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)
has been processed to get the following results:
smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB

ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base
type `Counter32' must be imported from SNMPv2-SMI
ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base
type `Counter32' must be imported from SNMPv2-SMI

FIX: add Counter32 to the list of things imported from SNMPv2-SMI


This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)
has been processed to get the following results:
smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB

ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI
ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type
`Counter32' must be imported from SNMPv2-SMI

FIX: add Counter32 to the list of things imported from SNMPv2-SMI

10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html
that is not covered above:

(a) there are several places in the MIB modules where the lines
extend beyond column 72.  Most (but not all) of these could be fixed
by eliminating the three-space indentation.  Althought the RFC
Editor can probably do this, it will save time and reduce the
proabability of formatting errors in the final RFC if the authors
would fix it themselves.  See ID-nits section 1.1.

(b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to
the list of imperatives (although the standard boilerplate in RFC
2119 does not include it, it is used in the Security Considerations
section and it is defined in RFC 2119).

(c) in Section 3, "Overview", 3rd paragraph: s/means/a means/

(d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/

(e) in Section 4, "Structure of the MIB modules", 1st paragraph:
s/Section 6/Section 5/

(f) in Section 4, "Structure of the MIB modules", 2nd and 4th
paragraphs:  most acronyms must be expanded upon first use,
except for those that everyone in the IETF can reasonably be
expected to know.  Note that this rule applies separately for
the body of the memo and the abstract;  see Sections 4.7 and 2.9
of <draft-rfc-editor-rfc2223bis-06.txt> or its successor document
and review comment (2) above.

(g) in Section 4.1, "The ROHC-MIB module", first paragraph:  the
tables are mentioned in a different order than they appear in the
MIB module, which has rohcChannelTable before rohcInstanceTable.
Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with
the order in this paragraph but are "swapped" relative to the MIB
module.  It might be better if the order in the text matched that
of the MIB module.

(h) in Section 4.1, "The ROHC-MIB module", last paragraph:
unexpanded acronym CID.

(i) in Section 4.1.1, "rohcInstanceTable", 4th bullet:
s/storagetime/storage time/

(j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed
text from:

 o   the state of the CID ('unused', 'active', 'expired', or

to:

 o   the state of the CID ('unused', 'active', 'expired', or
     'terminated'.

Note: a common cause of missing text in an I-D is a line in the
nroff source that starts with a single quote as the first character
of the line.

11.) Technical content -- the following comments pertain to the
material in Sections 3, 4, and 5.  Please note that I am not an
ROHC subject matter expert and so I do not have the knowledge to
attempt a detailed verification that the MIB objects are indeed
fit for the intended purposes.  I'm presuming that the WG has
already done that, so I've concentrated on MIB design issues.
Issues already covered under (9) above won't be repeated here.

(a) in Section 3, "Overview", next to last paragraph, it is stated
that "the compressor context can be reinitialized."  I didn't see
any read-write or read-create objects in the MIB module that would
support such a capability.  If indeed there is no support for such
a capability then the claim should be removed.

(b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3,
"rohcProfileTable", and also in the corresponding definitions in
the ROHC-MIB module in Section 5:  it is not clear why one needs a
vendor, version number, and implementation description in both of
these tables.  Indeed, except for the descriptors and OIDs that
are assigned, the definitions of rohcInstanceVendor,
rohcInstanceVersion, and rohcInstanceDescr are identical with those
for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr
(respectively).  It seems to me that the objects rohcProfileVendor,
rohcProfileVersion, and rohcProfileDescr could be eliminated without
loss of capability.  The designers may also wish to consider moving
rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into
the rohcChannelTable or perhaps even turning them into scalars.

(c) in Section 4.1.3, "rohcProfileTable", there is no mention of
the per-profile Boolean flag that indicates whether the profile
has been negotiated to be used at the instance.

(d) in Section 5, all MIB modules:  the MODULE-IDENTITY invocations
need to be changed in the following ways:

 - WG mailing list info (and optionally, charter page URL) needs to
   be present in the CONTACT-INFO clause;

 - there needs to be a REVISION/DESCRIPTION clause pair with a date
   identical to that in the LAST-UPDATED clause and a description
   indicating that the module is the initial published version;

 - the DESCRIPTION clause needs to include an abbreviated copyright
   notice (per (8) above).

See <draft-ietf-ops-mib-review-guidelines-01.txt> sections 3.8 and
4.5 for more details.  As an example, the ROHC-MIB MODULE-IDENTITY
invocation could be changed from:

rohcMIB MODULE-IDENTITY
    LAST-UPDATED "200209251358Z"
    ORGANIZATION "IETF Robust Header Compression Working Group"
    CONTACT-INFO
        "Juergen Quittek
         NEC Europe Ltd.
         Network Laboratories
         Kurfuersten-Anlage 34
         69221 Heidelberg
         Germany
         Tel: [phone]
         E-mail: [e-mail]"
    DESCRIPTION
        "This MIB module defines a set of basic objects for
         monitoring and configuring robust header compression.
         The module covers information about running instances
         of ROHC (compressors or decompressors) at IP interfaces.

         Information about compressor contexts and decompressor
         contexts has different structure for different profiles.
         Therefore it is not provided by this MIB module, but by
         individual modules for dofferent profiles."
    ::= { mib-2 XXX }
-- XXX to be assigned by IANA.

to something along the lines of:

rohcMIB MODULE-IDENTITY
    LAST-UPDATED "200306250000Z"  -- June 25, 2003
    ORGANIZATION "IETF Robust Header Compression Working Group"
    CONTACT-INFO
       "WG charter:
          http://www.ietf.org/html.charters/rohc-charter.html

        Mailing Lists:
          General Discussion: [e-mail]
          To Subscribe: [e-mail]
          In Body: subscribe your_email_address

        Editor:
          Juergen Quittek
          NEC Europe Ltd.
          Network Laboratories
          Kurfuersten-Anlage 34
          69221 Heidelberg
          Germany
          Tel: [phone]
          E-mail: [e-mail]"
    DESCRIPTION
        "This MIB module defines a set of basic objects for
         monitoring and configuring robust header compression.
         The module covers information about running instances
         of ROHC (compressors or decompressors) at IP interfaces.

         Information about compressor contexts and decompressor
         contexts has different structure for different profiles.
         Therefore it is not provided by this MIB module, but by
         individual modules for different profiles.

         Copyright (C) The Internet Society (2003).  This version
         of this MIB module is part of RFC yyyy;  see the RFC
         itself for full legal notices."
-- RFC Ed.: replace yyyy with actual RFC number & remove this notice

    REVISION    "200306250000Z"  -- June 25, 2003
    DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this notice

    ::= { mib-2 XXX }
-- XXX to be assigned by IANA.

with the dates changed as appropriate.  [Note also a typo fix:
s/dofferent/different/.]  Similar changes apply to the other
MIB modules.

(e) in Section 5, all MIB modules:  the ordering of the index
components is not consistent throughout.  Specifically, although
all tables are indexed by ifIndex and rohcChannelID, the tables
without rohcInstanceType as an index component all have
{ ifIndex, rohcChannelID, ... } as a common prefix, while those
with rohcInstanceType do not:  their common prefix is
{ ifIndex, rohcInstanceType, rohcChannelID, ... }.  While this
will certainly work, and may be legitimate if one wishes to have a
different sort order in different tables, the MIB designers should
be aware that it tends to make the implementation harder than it
otherwise would be, because there is less indexing code that can
be shared between different tables.  Unless there was a specific
reason for choosing the specific index order that is in the draft,
the authors may wish to consider changing the order of the leading
components in the tables that have rohcInstanceType as an index
component from:

    INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... }

to:

    INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... }

The affected row objects are rohcInstanceEntry and rohcContextTable
in the ROHC-MIB module, rohcUncmprContextEntry in the
ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and
rohcRtpPacketSizeEntry in the ROHC-RTP-MIB module.

(f) in Section 5, all MIB modules:  none of the Counter32 objects
has a discontinuity time indicator.  Such an indicator is required
if events other than a reboot may result in a discontinuity (i.e.,
non-monotonic counting behaviour);  see the first bullet of Section
4.6.1.2 of <draft-ietf-ops-mib-review-guidelines-01.txt>.  Since
each counter is associated with a specific interface, a good
solution in this case is to use IF-MIB's ifCounterDiscontinuityTime
for this purpose, as is done in the EtherLike-MIB (RFC 2665),
the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289).  That
would mean adding the following or similar text

         Discontinuities in the value of this counter can
         occur at re-initialization of the management
         system, and at other times as indicated by the
         value of ifCounterDiscontinuityTime.

to the DESCRIPTION clause of each of the Counter32 objects.

(g) in Section 5, all MIB modules:  it is observed that many objects
are defined with SYNTAX values of of Integer32 (0..2147483647),
Integer32 (1..2147483647), and Integer32 (0..1000).  While this is
certainly acceptable, it is brought to the authors' attention that
Unsigned32 is preferred when the range of values is non-negative;
see <draft-ietf-ops-mib-review-guidelines-01.txt> Section 4.6.1.1.
Changes, if any, are left to the authors' discretion.  (Note:
current usage is consistent for all objects;  if a change is made,
please be sure to do so everywhere;  but see 11(m) first.)

/********** The following comments apply to the ROHC-MIB **********/

(h) In the DESCRIPTION clause of rohcChannelID it says:

         The value is expected to remain constant at least from one
         re-initialization of the entity's network management system
         to the next re-initialization.

I know that this same language is used in the IF-MIB, but it turns
out that indices that don't remain fixed across reboots can lead
to problems.  See the thread "Referential integrity across reboots"
at this URL:  http://ops.ietf.org/lists/mibs/mibs.2002/#00140
Suggested remedy:  change the above text to:

         The value is REQUIRED to remain constant at least from one
         re-initialization of the entity's network management system
         to the next re-initialization.  It is RECOMMENDED that the
         value persist across such re-initializations.

(i) In the DESCRIPTION clause of rohcChannelFeedbackFor:
s/feddback/feedback/

(j) In the following object definition it is not specified what
value the object should assume if there is no feedback channel:

rohcInstanceFBChannelID OBJECT-TYPE
    SYNTAX      RohcChannelIdentifier
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Identifier of the channel used for feedback."
    ::= { rohcInstanceEntry 4 }

Shouldn't the DESCRIPTION clause state that the value 0 is used in
that case?  It would seem to be consistent with the instructions in
the RohcChannelIdentifier DESCRIPTION clause to do this.

(k) In the following object definition:

   rohcInstanceMRRU OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Maximum reconstructed reception unit.  This is the
            size of the largest reconstructed unit in octets that
            the decompressor is expected to reassemble from
            segments (see RFC 3095, Section 5.2.5). Note that this
            size includes the CRC. If MRRU is negotiated to be 0,
            no segment headers are allowed on the channel."
       REFERENCE
           "RFC 3095, Section 5.1.1"
       ::= { rohcInstanceEntry 11 }

the SYNTAX value and the DESCRIPTION clause are at odds.

FIX:  change the SYNTAX value to Integer32 (0..2147483647)

(l) In the following object definition:

rohcInstanceContextsCurrent OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Number of currently active contexts created by this instance."
    ::= { rohcInstanceEntry 15 }

a more appropriate SYNTAX value would be Integer32 (0..2147483647)
since the number of contexts cannot possibly be negative.

(m) In the following object definition:

rohcInstanceCompressionRatio OBJECT-TYPE
    SYNTAX      Integer32 (0..1000)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates the compression ratio so far over all
         packets on the channel served by this instance.  The value is
         defined as 1000 * bytes(compressed) / bytes(original) rounded
         to the next integer value.  The number of bytes corresponds
         to all bytes of all IP packets including the IP header but
         excluding all lower layer headers."
    ::= { rohcInstanceEntry 20 }

Is it theoretically possible for the compression ratio to exceed unity
in certain unfavorable cases?  If so, then the range needs to be
changed to allow for that, or the DESCRIPTION clause needs to state
that the value is set to 1000 if the actual compression ratio exceeds
unity.  In the latter case a more appropriate SYNTAX value would be
Gauge32 (0..1000) (see <draft-ietf-ops-mib-review-guidelines-01.txt>
Section 4.6.1.1).  NOTE:  THIS COMMENT APPLIES TO ALL COMPRESSION
RATIO OBJECTS.

(n) I'm not sure if I properly understood the DESCRIPTION clause of
the following object:

rohcProfileNegotiated OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "When retrieved, this boolean object returns true
         if the profile has been negotiated to be used at
         the instance, i.e. is supported also by the
         corresponding compressor/decompressor."
    ::= { rohcProfileEntry 7 }

My understanding is that an instance of this object corresponding to
a particular <ifIndex, rohcChannelID, rohcProfile> triple should
have the value true(1) if and only if at least one context with the
same <ifIndex, rohcChannelID> values is using that profile -- in
other words, if and only if some instance of rohcContextProfile for
the same <ifIndex, rohcChannelID> values is equal to the rohcProfile
value.  If this understanding is _not_ correct, then clarification
of the DESCRIPTION clause would be in order.

(o) Several DESCRIPTION clauses in the ROHC-MIB refer to the
non-existent object rohcContextType.  They should refer instead to
rohcInstanceType.  The objects in question are:

rohcContextDecompressorDepth
rohcContextDecompressorFailures
rohcContextDecompressorRepairs

(p) In the following object definition [n.b. the above correction
has been assumed to be applied]:

rohcContextDecompressorDepth OBJECT-TYPE
    SYNTAX      Integer32 (0..2147483647)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates whether reverse decompression, for
         example as described in RFC 3095, Section 6.1, is used
         on this channel or not, and if used, to what extent.

         Its value is only valid for decompressor contexts, i.e.
         if rohcInstanceType has the value decompressor(2).

         The value of the reverse decompression depth indicates
         the maximum number of packets that are buffered, and thus
         possibly be reverse decompressed by the decompressor.
         A zero (0) value means that reverse decompression is not
         used."
    ::= { rohcContextEntry 7 }

it is not clear whether this object should have the value 0 for
compressor contexts, or whether it should not be instantiated at
all for such contexts.

(q) The rohcCompliance DESCRIPTION clause should mention that the
ROHC-MIB requires the IF-MIB as a prerequisite.  See Section 4.8 of
<draft-ietf-ops-mib-review-guidelines-01.txt>, last paragraph
before end note.  Examples may be found in the dot3Compliance2
statement in <draft-ietf-hubmib-etherif-mib-v3-03.txt>, the
mauModIfCompl3 statement in <draft-ietf-hubmib-mau-mib-v3-04.txt>,
or the etherWisCompliance in <draft-ietf-hubmib-wis-mib-07.txt>
(although it is requested that the embedded citations be avoided).

/*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/

(r) The rohcUncmprCompliance DESCRIPTION clause should mention that
the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as
prerequisites.  See 11(q) above for examples.

/******** The following comments apply to the ROHC-RTP-MIB ********/

(s) The DESCRIPTION clauses of several columnar objects in the
rohcRtpContextTable state that those objects are valid only for
certain profiles or for certain contexts.  The objects in question
are:

rohcRtpContextAlwaysPad
rohcRtpContextLargePktsAllowed
rohcRtpContextVerifyPeriod
rohcRtpContextSizesAllowed
rohcRtpContextSizesUsed

If the intent is that those objects are to be instantiated only for
the profiles or contexts to which they apply, then that fact should
be made explicit in the DESCRIPTION clauses.

(t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and
rohcRtpContextSizesUsed both appear to have the same three
typographical errors:

 rohcRtpContextSizesAllowed  OBJECT-TYPE
     SYNTAX      Integer32 (1..2147483647)
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The value of this object is only valid for decompressor
          contexts, i.e. if rohcContextType of the cooresponding
                            ^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^
          rohcContextEntry has the value compressor(2).
                                         ^^^^^^^^^^^^^

          This object contains the number of different packet sizes
          that may be used in the context."
     REFERENCE
         "RFC 3095, Section 6.3.1"
     ::= { rohcRtpContextEntry 10 }

   rohcRtpContextSizesUsed  OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The value of this object is only valid for decompressor
            contexts, i.e. if rohcContextType of the cooresponding
                              ^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^
            rohcContextEntry has the value compressor(2).
                                           ^^^^^^^^^^^^^

            This object contains the number of different packet sizes
            that are used in the context."
       REFERENCE
           "RFC 3095, Section 6.3.1"
       ::= { rohcRtpContextEntry 11 }

Suggested fixes:  s/rohcContextType/rohcInstanceType/
                  s/cooresponding/corresponding/
                  s/compressor(2)/decompressor(2)/

(u) There are some design issues with the rohcRtpPacketSizeTable:

- the index column rohcRtpPacketSize with has values in the range
0..2147483647.  In fact RFC 3095 Section 6.3.1 stipulates that
PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive
integers, i.e., the value 0 is excluded as it does not make sense.
FIX:  change the range to 1..2147483647.  (This also avoids
running afoul of the SMIv2 rule that index values of zero should
be avoided, except in special cases.)

- the TruthValue column rohcRtpPacketSizeAllowed seems to be
unnecessary.  Given that RFC 3095 Section 6.3.1 stipulates that
"packet sizes not in the set of values for [PACKET_SIZES_ALLOWED]
MUST NOT be used", it seems that an agent would never need to
instantiate any of the other columns if rohcRtpPacketSizeAllowed
had the value false(2).  In other words, any row for which this
objects is false should simply be absent from the table.

(v) The rohcRtpCompliance DESCRIPTION clause should mention that
the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as
prerequisites.  See 11(q) above for examples.

This concludes the review of <draft-ietf-rohc-mib-rtp-06.txt>.

Regards,

Mike Heard


_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc