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:02:07 +0200

Bert,

--On 08.08.2003 15:11 h +0200 Wijnen, Bert (Bert) wrote:

> When I see things like:
>
>    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]."
>
> I'd say that instead of [RFC2863], it would probably be better
> to use (RFC 2863).
> The reason is that when the MIB module gets extracted from the
> RFC, then the citation is lost, and besides, (RFC 2863) seems
> to me to be a clearly enoug ptr to the document.

Thanks for this hint.

I'll commit this modification to all three MIB modules.

    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

> Thanks,
> Bert

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

---

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

Mike,

--On 08.08.2003 10:26 Uhr -0700 C. M. Heard wrote:

> On Fri, 8 Aug 2003, Jürgen Quittek wrote:
>
>> 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!
>
> Thanks for the detailed point-by-point responses.  You no doubt have
> already seen Bert's suggestion for how to avoid citations in the MIB
> module, so I only have a couple of points to add.

Yes.

>> > (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?
>
> The title is listed as "An RObust Header Compression [...]";  the
> word "An" is extraneous.  Here is how the it looks in RFC 3241:
>
> [RFC3095]   Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
>             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
>             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
>             T., Yoshimura, T. and H. Zheng, "RObust Header Compression
>             (ROHC): Framework and four profiles: RTP, UDP, ESP, and
>             uncompressed", RFC 3095, July 2001.
>
> The one in RFC 3242 is similar.

Fixed it.

>> > 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 :-(
>
> Actually, that's true.  It turns out that previous versions of
> smilint didn't check for failure to import the base types that were
> "inherited" from SMIv1.  I was bitten by this when I wrote the WIS
> MIB ... ironically, I had checked SMICng 2.2.07, which did not
> require any SMIv2 base types to be imported.  The problem is fixed
> in current versions of smilint and SMICng.
>
> Regarding 11(e):
>> > 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.
>
> Actually, I think that you have already provided a good rationale
> for the existing indexing scheme.  Back on 8 Jul 2003, I wrote:
>
> % >>>>> On Mon, 7 Jul 2003, Juergen Quittek wrote:
> % Juergen> Initially, rohcInstanceType was no index. Probably this
> % Juergen> is the reason why we forgot to make it non-accessible.
> % Juergen> But after some discussions with rohc people, partiularly
> % Juergen> including with Lars-Erik, we found that when accessing
> % Juergen> the MIB a management station would typically look either
> % Juergen> for compressors or for decompressors, but not for
> % Juergen> particular channels.
> %
> % That makes sense.
> %
> % Juergen> Without the rohcInstanceType being part of the index, a
> % Juergen> management station looking for a particular compressor
> % Juergen> or looking for all compressors would need to browse
> % Juergen> through all compressor and decompressor contexts, read
> % Juergen> the type and ignore them if they are decompressors.
> % Juergen>
> % Juergen> But with the rohcInstanceType as n index before the
> % Juergen> channel ID, you can first select whether you ant to
> % Juergen> browse compressors or decompressors and then go through
> % Juergen> the (shorter) list of specific contexts.
> % Juergen>
> % Juergen> I think this is helpful and matches requirements of rohc
> % Juergen> management stations.
> %
> % This explanation also provides a response to review comment 11(e),
> % as it provides a good reason why rohcInstanceType should precede
> % rohcChannelID in the INDEX clauses where it appears.
>
> Abigail Surtees did ask for some explanatory text explaining why
> rohcInstanceType is present as an index, which you agreed to
> provide;  and if, when you add that text, you would also note (as
> is done above) the reason why is appears before rohcChannelID,
> then as far as I'm concerned the issue is closed.

As explained in an earlier mail, we suggest to change the indexing
but still follow Abigail's recommendation to explain the indexing
scheme better than we did so far.

> Mike

Thanks,

    Juergen