Found 1 record.

Status: Held for Document Update (1)

RFC 3816, "Definitions of Managed Objects for RObust Header Compression (ROHC)", June 2004

Errata ID: 737
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-23
Held for Document Update by: Lars Eggert

1a)
  Section 4.1.2., near the bottom of page 5, says:

                                                  "...  But when
   accessing the rohcInstanceTable (and the rohcContextTable that shares
   a part of its index with the rohcInstanceTable) there are many cases
   where either a compressor contexts or a decompressor contexts are of
   interest.  ..."

  It should say:

                                                  "...  But when
   accessing the rohcInstanceTable (and the rohcContextTable that shares
   a part of its index with the rohcInstanceTable) there are many cases
|  where either a compressor context or a decompressor context are of
   interest.  ..."

1b)
  Section 4.3.1., near the bottom of page 8, says:

                 "...  For compressor contexts it optionally contains
   managed object containing the numbers of allowed and used packet
   sizes.  ..."

  It should say:

                 "...  For compressor contexts it optionally contains
|  managed objects containing the numbers of allowed and used packet
   sizes.  ..."


2) Textual issues in the ROHC-MIB definition

2a)
  The DESCRIPTION clause of the `RohcChannelIdentifierOrZero'
  TEXTUAL-CONVENTION (near the bottom of page 10),

         "A number identifying a channel.
          The value of 0 is indicates that
          no channel is identified."

   should be:

         "A number identifying a channel.
|         The value of 0 indicates that
          no channel is identified."

2b)
  The DESCRIPTION clause for `rohcChannelEntry' (extending from
  the last 2 lines on page 11 to page 12) contains inappropriate
  text -- obviously borrowed from the Script MIB (RFC 3165,
  page 18, last 3 lines) and unintentionally left un-edited:

     "An entry describing a particular script.  Every script that
      is stored in non-volatile memory is required to appear in
      this script table.

      Note ..."

  This should be replaced by appropriate text, e.g.,

|    "An entry describing a particular ROHC channel.

      Note ..."

  [ Please add whatever you consider appropriate here! ]

2c)
  The DESCRIPTION clause for `rohcChannelFeedbackFor', on page 13,
  seems to me to be not strict enough. Perhaps,

      "If no feedback information is transferred on this channel,
       then the value of this ID is 0.  If the channel type is set
       to notInUse(1), then the value of this object must be 0.
       If the channel type is rohc(2) and the value of this object
       is a valid channel ID, then feedback information is
       piggy-backed on the ROHC channel.  If the channel type is

  should be replaced by:

      "If no feedback information is transferred on this channel,
       then the value of this ID is 0.  If the channel type is set
       to notInUse(1), then the value of this object must be 0.
       If the channel type is rohc(2) and the value of this object
|      is non-zero, then feedback information for this channel is
|      piggy-backed and/or interspersed on the same ROHC channel;
|      hence the value of this object must be equal to the value
|      of the indexing rohcChannelID.  If the channel type is
       dedicatedFeedback(3), ..."

  [or similar].

  Rationale:
  As far as I understand RFC 3095 (Section 5.2.2 et al.),
  it is not possible to intersperse or/and piggyback feedback
  information of another channel on a ROHC channel carrying
  payload packets.

2d)
  The DESCRIPTION clause for `rohcInstanceVendor', on page 15,
  contains two issues. Its first sentence contains the word
  "description" instead of "compression", and the second sentence
  is subject to mis-interpretation due to unfortunate placement of
  the words "allocated for the vendor".
  I propose to change the text:

      "An object identifier that identifies the vendor who
       provides the implementation of robust header description.
       This object identifier SHALL point to the object identifier
       directly below the enterprise object identifier
       {1 3 6 1 4 1} allocated for the vendor. ...

  to better read:

      "An object identifier that identifies the vendor who
|      provides the implementation of robust header compression.
       This object identifier SHALL point to the object identifier
|      allocated for the vendor directly below the `enterprise'
|      object identifier {1 3 6 1 4 1}. ...


2e)
  The DESCRIPTION clause for `rohcInstanceContextStorageTime',
  on page 17, says:

                      ... .  The value of this object is used
     to initialize rohcContexStorageTime object when a new
     context is created.
     Changing ...

  where it should better say:

                      ... .  The value of this object is used
|    to initialize the rohcContexStorageTime object when a new
     context is created.
     Changing ...

2f)
  To better distinguish the counters for payload (i. e. IP) packets
  from the counters IR packets, I recommend to enhance the sentence:

      "Counter of all packets passing this instance."

  to read:

|     "Counter of all IP packets passing this instance."

  in the DESCRIPTION clauses of following two objects:

  o   `rohcInstancePackets'       (page 18),
  o   `rohcContextPackets'        (page 25).

2g)
  The DESCRIPTION clause for `rohcProfileVendor', on page 21,
  contains the same two issues as the DESCRIPTION clause for
  `rohcInstanceVendor'. Hence, the modification given above,
  under 2d), should be applied here as well.

2h)
  The DESCRIPTION clause for `rohcProfileNegotiated', on page 21,
  contains a small typo. It says:

     "When retrieved, this boolean object returns true
      if the profile has been negotiated to be used at
      the instance, i.e., is supported also be the
      corresponding compressor/decompressor."

  It should say:

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

2i)
  The DESCRIPTION clause for `rohcContextStorageTime', on page 24,
  contains an improper self-reference. Therefore, replace the text:

               ... .  This object returns  the remaining time
      that the row may exist before it is aged out.  The object
      is initialized with the value of the  associated
      rohcContextStorageTime object.  After expiration ...

  by:

               ... .  This object returns the remaining time
      that the row may exist before it is aged out.  The object
      is initialized with the value of the associated
|     rohcInstanceContextStorageTime object.  After expiration ...

          ^^^^^^^^

2j)
  The DESCRIPTION clauses for `ContextAllPacketsMeanSize' and
  `rohcContextAllHeadersMeanSize', on page 28, are concluded with
  the sentence:

      The mean value is given in byte rounded to the next
      integer value."

  This should be:

      The mean value is given in bytes rounded to the next
      integer value."

  [ Note: I wished this RFC (and many other MIB RFCs, too) would
    make frequent use of the UNITS clause specified in STD 58 ! ]


3) Textual issues in the ROHC-RTP-MIB definition

3a)
  The DESCRIPTION clause for `rohcRtpContextNACKs', on page 42,
  says:

     "The number of all dynamic negative feedbacks (ACK) sent
      or received in this context, respectively.
      ..."

  It should say:

|    "The number of all dynamic negative feedbacks (NACK) sent
      or received in this context, respectively.
      ..."

3b)
  The DESCRIPTION clause for `rohcRtpContextSNACKs', on page 42,
  says:

     "The number of all static negative feedbacks (ACK) sent
      or received in this context, respectively.
      ..."

  It should say:

|    "The number of all static negative feedbacks (STATIC-NACK)
|     sent or received in this context, respectively.
      ..."

It should say:

[see above]

Notes:

from pending

Report New Errata