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

From: Juergen Quittek <[email-masked]>
Date: Sun, 09 Nov 2003 19:17:17 +0100

Mike,

Thanks again for your careful check and the very good comments.
Please see replies inline:

--On 31.10.2003 0:15 h -0800 C. M. Heard wrote:

> On Tue, 21 Oct 2003, Juergen Quittek wrote:
>> > 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.
>
> OK
>
>> >   - 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:
> [ ... details snipped, but each table used ifIndex ... ]
>> 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 [ ... details snipped ... ]
>>
>> 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.
>
> 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

OK. I will fix this in the conformance section after we got feedback
from the IESG.

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

I'm hesitating to go back.  After many discussions, I am convinced
that we found a well balanced compromise.

The management application can read the rohcChannelTable (that is
still indexed by the ifIndex) and find a list of all channels that
are affected with their respective rohcChannelId.  Then it can
use the rohcChannelId as index of all counters in other tables,
which suffered from discontinuity.

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

Yes, this needs to be fixed.

>        ::= { rohcInstanceEntry 2 }
>        ::= { rohcInstanceEntry 4 }

And this also.

>        ::= { 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.

Certainly. If we just change the compliancy statements and
the OID numbering, we can fix this at any stage in the
document process until the 48 hours review by the authors.

If we change the indexing again, we might have to discuss
it with more people.

> Regards,
> Mike

Thanks,

    Juergen

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