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

From: Juergen Quittek <[email-masked]>
Date: Tue, 21 Oct 2003 01:01:15 +0200

Hi Mike,

There was a long idle from my last messages on the ROHC MIB to this one.
Now I want to finish processing issues the issue list by addressing the
two issues that are still left open:

--On 08.08.2003 11:51 h +0200 Juergen Quittek wrote:
> 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).

Together with Lars-Erik, we checked the IPR issues.
They do not apply to the MIB or to MIB implementations.

>   - 11.) (e) ordering of the index components
>         This is discussed in a separate email thread on the list.

We had long discussions on this issue.  So far indexing has looked like:

  rohcChannelTable:       ifIndex, rohcChannelID
  rohcInstanceTable:      ifIndex, rohcInstanceType, rohcChannelID
  rohcProfileTable:       ifIndex, rohcChannelID, rohcProfile
  rohcContextTable:       ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID
  rohcUncmprContextTable: ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID
  rohcRtpContextTable:    ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID
  rohcRtpPacketSizeTable: ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID, rohcRtpPacketSize

We want to change this such that the rohcChannelID becomes unique
for a ROHC MIB implementation independent of the interface or
instance to which the channel belongs.

This simplifies the profile table, all context tables and the
RTP packet size table:

  rohcProfileTable:       rohcChannelID, rohcProfile
  rohcContextTable:       rohcChannelID, rohcContextCID
  rohcUncmprContextTable: rohcChannelID, rohcContextCID
  rohcRtpContextTable:    rohcChannelID, rohcContextCID
  rohcRtpPacketSizeTable: rohcChannelID, rohcContextCID, rohcRtpPacketSize

For the rohc channel table we still want to keep the old indexing
scheme, because we believe it is useful to be able to access channels
per interface and to access Instances by the rohc InstanceType:

  rohcChannelTable:       ifIndex, rohcChannelID
  rohcInstanceTable:      ifIndex, rohcInstanceType, rohcChannelID

Addressing a good suggestion from Abbie

>>>>> On Tue, 8 Jul 2003, Surtees, Abigail wrote:
Abbie> However, looking at it from a MIB point of view I think
Abbie> it is confusing to have a seemingly redundant index.
Abbie>
Abbie> Hence, I suggest that rohcInstanceType continues to be
Abbie> an index but that there is some text added to the draft
Abbie> explaining why it is there and that if you want to
Abbie> uniquely identify one rohc instance (whether compressor
Abbie> or decompressor) then ifIndex and rohcChannelID are
Abbie> sufficient to do this.

we suggest to modify the DESCRIPTION clauses of rohcChannelEntry to

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

         Note, that the rohcChannelID identifies the channel
         uniquely.  The ifIndex is part of the index of this table
         just in order to allow addressing channels per interface."

and of rochChannelID in the rohcChannelTable to

    DESCRIPTION
        "The locally arbitrary, but unique identifier associated
         with this channel.  The value is REQUIRED to be unique
         per ROHC MIB implementation independent of the associated
         interface.

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

and of the rohcInstanceTable to

    DESCRIPTION
        "This table lists properties of running instances
         of robust header compressors and decompressors
         at IP interfaces. It is indexed by interface number,
         the type of instance (compressor or decompressor),
         and and the ID of the channel used by the instance as
         ROHC channel.

         Note that the rohcChannelID uniquely identifies an
         instance.  The ifIndex and rohcInstanceType are part
         of the index, because it simplifies accessing instances
         per interface and for addressing either compressors or
         decompressors only."

A consequence of these changes would be that modules
ROHC-UNCMPRESSED-MIB and ROHC-RTP-MIB do not use anymore the object
ifIndex (or other objects from the IF-MIB and the IF-MIB can be
removed from the IMPORT clause and the DESCRIPTION clause of the
compliance statements.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

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

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 31 Oct 2003 00:15:47 -0800 (PST)

> They do not apply to the MIB or to MIB implementations.

OK

> We had long discussions on this issue.  So far indexing has looked like:
[ ... details snipped, but each table used ifIndex ... ]
> we suggest to modify the DESCRIPTION clauses [ ... details snipped ... ]
> 

Allow me to point out that all three MIB modules have counters
and that each counter points to ifCounterDiscontinuityTime as
its discontinuity indicator.  So it seems to me that there are
two problems here:

- there is still a dependence on the IF-MIB

- the absence of ifIndex from the index list makes it hard for
a management application to find out which counters have
sufferred a discontinuity when an instance if ifConcerDiscontinuityTime
changes.

So, I think you would be better off to re-instate ifIndex to the
INDEX clauses and mention of IF-MIB in the compliance statements.

Another point that I noticed is that the OID assignments for the
columnar objects are not contiguous, doubtless as a result of
removing columns from the tables.  Here is the result of a quick
grep:
       ::= { rohcChannelEntry 2 }
       ::= { rohcChannelEntry 3 }
       ::= { rohcChannelEntry 4 }
       ::= { rohcChannelEntry 5 }
       ::= { rohcChannelEntry 13 }
       ::= { rohcInstanceEntry 2 }
       ::= { rohcInstanceEntry 4 }
       ::= { rohcInstanceEntry 5 }
       ::= { rohcInstanceEntry 6 }
       ::= { rohcInstanceEntry 7 }
       ::= { rohcInstanceEntry 8 }
       ::= { rohcInstanceEntry 9 }
       ::= { rohcInstanceEntry 10 }
       ::= { rohcInstanceEntry 11 }
       ::= { rohcInstanceEntry 12 }
       ::= { rohcInstanceEntry 13 }
       ::= { rohcInstanceEntry 14 }
       ::= { rohcInstanceEntry 15 }
       ::= { rohcInstanceEntry 16 }
       ::= { rohcInstanceEntry 17 }
       ::= { rohcInstanceEntry 18 }
       ::= { rohcInstanceEntry 19 }
       ::= { rohcInstanceEntry 20 }
       ::= { rohcProfileEntry 2 }
       ::= { rohcProfileEntry 3 }
       ::= { rohcProfileEntry 4 }
       ::= { rohcProfileEntry 5 }
       ::= { rohcProfileEntry 6 }
       ::= { rohcContextEntry 2 }
       ::= { rohcContextEntry 3 }
       ::= { rohcContextEntry 4 }
       ::= { rohcContextEntry 5 }
       ::= { rohcContextEntry 6 }
       ::= { rohcContextEntry 7 }
       ::= { rohcContextEntry 8 }
       ::= { rohcContextEntry 9 }
       ::= { rohcContextEntry 10 }
       ::= { rohcContextEntry 11 }
       ::= { rohcContextEntry 12 }
       ::= { rohcContextEntry 13 }
       ::= { rohcContextEntry 14 }
       ::= { rohcContextEntry 15 }
       ::= { rohcContextEntry 16 }
       ::= { rohcContextEntry 17 }
       ::= { rohcContextEntry 18 }
       ::= { rohcContextEntry 19 }
       ::= { rohcContextEntry 20 }
       ::= { rohcContextEntry 21 }
       ::= { rohcContextEntry 22 }
       ::= { rohcRtpContextEntry 3 }
       ::= { rohcRtpContextEntry 4 }
       ::= { rohcRtpContextEntry 5 }
       ::= { rohcRtpContextEntry 6 }
       ::= { rohcRtpContextEntry 7 }
       ::= { rohcRtpContextEntry 8 }
       ::= { rohcRtpContextEntry 9 }
       ::= { rohcRtpContextEntry 10 }
       ::= { rohcRtpContextEntry 11 }
       ::= { rohcRtpContextEntry 12 }
       ::= { rohcRtpContextEntry 13 }
       ::= { rohcRtpContextEntry 14 }
       ::= { rohcRtpContextEntry 15 }
       ::= { rohcRtpContextEntry 16 }
       ::= { rohcRtpContextEntry 17 }
       ::= { rohcRtpPacketSizeEntry 3 }
       ::= { rohcRtpPacketSizeEntry 4 }
       ::= { rohcRtpPacketSizeEntry 5 }
       ::= { rohcRtpPacketSizeEntry 6 }
       ::= { rohcUncmprContextEntry 3 }
       ::= { rohcUncmprContextEntry 4 }
       ::= { rohcUncmprContextEntry 5 }

You may want to consider fixing this if you decide to
re-spin the MIB before publication.

Regards,

Mike