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

["Wijnen, Bert (Bert)" <[e-mail]>]

Thanks for your thourough review Mike!

So I guess we'll see answers from the authors/wg and most
probably a new revision sometime in the future (soon I hope,
cause it helps for a MIB doctor to quickly re-check while
the data is still kind of fresh in his/her mind).


Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:[e-mail]]
> Sent: woensdag 25 juni 2003 8:04
> To: ROHC mailing list
> Cc: Wijnen, Bert (Bert)
> Subject: MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt
> 
> 
> >>>>> 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