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

[Jürgen Quittek <[e-mail]>]

Hi Mike,

Unfortunately, it took some time until we could check all your comments.
Again thank you very much for this really helpful work. The document
improved a lot!

Below please find the detailed responses on all of your comments
with two exceptions.

  - 4.) IPR Notices
        We are still checking the patent issues.
        We will post the results on the mailing list
        (with CC to you and Bert).
  - 11.) (e) ordering of the index components
        This is discussed in a separate email thread on the list.

    Juergen

--On June 24, 2003 23:04 h -0700 "C. M. Heard" <[e-mail]> wrote:

[...]
>
> 0.) Title -- s/Robus/Robust/

fixed.

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

done.

> 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:
>
[...]
>
> 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.)

We'll started checking this at the IETF meeting.
We have to continue discussing this on the mailing list.

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

done.

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

done.

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

I replaced "et al." by the complete list of authors, but I do not
know what is wrong with the title?

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

done.

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

done.

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

done. Thank you for the suggestion.

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

done.

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

Copyright notices added to front page and to each MODULE-IDENTITY
statement.

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

I was surprised to see these error messages.
Looks like i used an older, buggy version of 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: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

done.

> 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

done.

> 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: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

done.

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

All fixed. This happened, because I checked the length of lines
for the raw MIB files, not for the formatted I-D, where all MIB
models were indented by three blanks.

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

done.

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

done.

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

done.

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

done.

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

fixed.

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

done.

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

fixed.

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

done.

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

This was exactly the case. But the hidden text was more than
just 'terminated':

o   the state of the CID ('unused', 'active', 'expired', or
    'terminated'), also used as part of the table index,

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

Yes, I removed this feature from an earlier version of the MIB without
consistently removing all text referring to it.  Now, I replaced

   For fault management compressor/decompressor state and mode
   can be checked and the compressor context can be reinitialized.

by

   For fault management compressor/decompressor state and mode
   can be checked.

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

We discussed this issue for some time already. I will summarize the
arguments in a separate message on the mailing list (with CC to you
and Bert) in order to decide what change to apply.

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

added

   o   a flag indicating whether or not using this profile has been
       negotiated with the corresponding (de)compressor.

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

done for all three 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.

See separate email thread on this issue.

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

done. Thanks for the suggestion.

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

applied the following replacements:

    RohcChannelIdentifier:          Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcInstanceClockRes:           Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcInstanceMaxCID:             Integer32 (1..2147483647)
                                    -> Unsigned32 (1..4294967295)
    rohcInstanceCompressionRatio:   Integer32 (0..1000)
                                    -> Unsigned32 (0..1000)
    rohcProfile:                    Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcContextCID:                 Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcContextProfile:             Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcContextDecompressorDepth:   Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcContextAllPacketsRatio:     Integer32 (0..1000)
                                    -> Unsigned32 (0..1000)
    rohcContextAllHeadersRatio:     Integer32 (0..1000)
                                    -> Unsigned32 (0..1000)
    rohcContextAllPacketsMeanSize:  Integer32 (0..2147483647)
                                    -> Unsigned32,
    rohcContextAllHeadersMeanSize:  Integer32 (0..2147483647)
                                    -> Unsigned32,
    rohcContextLastPacketsRatio:    Integer32 (0..1000)
                                    -> Unsigned32 (0..1000)
    rohcContextLastHeadersRatio:    Integer32 (0..1000)
                                    -> Unsigned32 (0..1000)
    rohcContextLastPacketsMeanSize: Integer32 (0..2147483647)
                                    -> Unsigned32,
    rohcContextLastHeadersMeanSize: Integer32 (0..2147483647)
                                    -> Unsigned32

    rohcRtpContextVerifyPeriod:     Integer32 (0..2147483647)
                                    -> Unsigned32
    rohcRtpContextSizesAllowed:     Integer32 (1..2147483647)
                                    -> Unsigned32 (1..4294967295)
    rohcRtpContextSizesUsed:        Integer32 (1..2147483647)
                                    -> Unsigned32 (1..4294967295)
    rohcRtpPacketSize:              Integer32 (0..2147483647)
                                    -> Unsigned32

> /********** 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.

done.

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

done.

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

done.

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

changed to Unsigned32.

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

changed to Unsigned32.

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

Yes, indeed. It is possible that compressed packets are significantly
larger than uncompressed ones.

Changed the syntax of all compression ratio objects
(rohcInstanceCompressionRatio, rohcContextAllPacketsRatio,
rohcContextAllHeadersRatio, rohcContextLastPacketsRatio,
rohcContextLastHeadersRatio) from Integer(0..1000) Unsigned.
For all of them, added the following sentence to the description:

        "Note that compressed packets/headers can be larger than the
         corresponding uncompressed ones.  Therefore, this object
         can return values greater than 1000 when it is retrieved."

> (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

fixed.

The same fix was applied to the following objects in module ROHC-RTP-MIB:

rohcRtpContextSizesAllowed
rohcRtpContextSizesUsed

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

extended the second paragraph of the description:

        "Its value is only valid for decompressor contexts, i.e.
         if rohcInstanceType has the value decompressor(2).  For
         compressor contexts where rohcInstanceType has the value
         compressor(1), this object MUST NOT be instantiated."

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

added to description:
        "Note that compliance with this compliance
         statement requires compliance with the
         ifCompliance3 MODULE-COMPLIANCE statement of the
         IF-MIB [RFC2863]."

> /*** 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.

added to description:
        "Note that compliance with this compliance
         statement requires compliance with the
         rohcCompliance MODULE-COMPLIANCE statement of the
         ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE
         statement of the IF-MIB [RFC2863]."

> /******** 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.

for rohcRtpContextAlwaysPad, rohcRtpContextLargePktsAllowed and
rohcRtpContextVerifyPeriod extended description by:
        "The value of this object is only valid for LLA profiles,
         i.e. if the corresponding rohcProfile has a value of
         0x0005.  If the corresponding rohcProfile has a value
         other than 0x0005, then this object MUST NOT be
         instantiated."
also extended the descriptions of rohcRtpContextNHPs,
rohcRtpContextCSPs, rohcRtpContextCCPs,
rohcRtpContextPktsLostPhysical, rohcRtpContextPktsLostPreLink,
rohcRtpPacketSizePreferred and rohcRtpPacketSizeRestrictedType
by this text.

for rohcRtpContextSizesAllowed and rohcRtpContextSizesUsed,
extended description by:
        "For compressor contexts where rohcInstanceType has the value
         compressor(1), this object MUST NOT be instantiated.

also extended the description of rohcRtpPacketSizeUsed by:
        "The value of this object is only valid for UDP, RTP,
         and ESP profiles, i.e. if the corresponding rohcProfile
         has a value of either 0x0001, 0x0002 or 0x0003.  If
         the corresponding rohcProfile has a value other than
         0x0001, 0x0002 or 0x0003, then this object MUST NOT be
         instantiated."


> (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)/

applied suggested fixes.

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

changed SYNTAX to Unsigned32 (1..4294967295)

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

removed rohcRtpPacketSizeAllowed.

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

added to description:
        "Note that compliance with this compliance
         statement requires compliance with the
         rohcCompliance MODULE-COMPLIANCE statement of the
         ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE
         statement of the IF-MIB [RFC2863]."

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



-- 
Juergen Quittek        [e-mail]        Tel: [phone]
NEC Europe Ltd.,       Network Laboratories        Fax: [phone]
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de













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