Subject: Re: [rohc] MIB

From: Juergen Quittek <[email-masked]>
Date: Thu, 06 Mar 2003 21:28:13 +0100

Mark,

Sorry for the late reply.
Thank you very much for all the comments.
Please find detailed replies inline.

    Juergen

-- West, Mark (ITN) wrote on 04 February 2003 09:04 +0000:

>
> Hi all,
>
> Having been asked to have a read the MIB for ROHC, I finally got around to it.  Here are my comments.  Mostly these are just a few typos.  Anyway...
>
> 4.1.2. 'notIn&Use' -> 'notInUse'?

Fixed.

> 4.1.4. the state of the CID seems to be missing an entry...
> 	'conrtext' -> 'context'

Fixed.

> 	'mean packets size' -> 'mean packet size'

Fixed.

> Since a row in the rohcContextTable is created when a context is initialised, I was wondering whether it makes sense to create a contxt in the 'unused' state?  I suppose if you view creating a pool of unassigned contexts to use, they would be 'unused'.

Yes, you are right. This was one of the thoughts behind introducing state 'unused'.
For example, if you do not use LARGE_CIDS, you might want to report on all 16 CIDs.
But I agree, that state 'unused' is not really necessary. However, it does not
harm also and may give a little bit more expressiveness in some situations.

> I don't think anything needs to change -- I'm just thinking out loud!
>
> 4.3. This is just a random thought, but... I noticed that the LLA profiles are bundled in with the ROHC-RTP profiles.  On one level this clearly makes sense, since they compressing the same thing.  On the other hand, there a quite a lot of things that
> are LLA specific and have no relevance to the 'regular' RTP profiles.  If it's not possible/too much of a change, I wouldn't bother, but... is it possible to have the LLA bits as an extension of the original RTP profiles, rather than included.

We discussed this several times with Ghyslain and others.
The conclusion was that the LLA profile has a lot in common
with the RTP profile, but it is not possible - with given
SMI limitations - to define the LLA profile as an extension
of the RTP profile without re-wiriting almost everything.

> 5.
>
> Definition of rohcChannelEntry seems suspicious -- referring to 'scripts in non-volatile memory'...

Yep, This was a copy-and-paste-error. It's fixed.

> rohcChannelType: 'ight' -> 'might'

Fixed.

> rohcInstanceVersion: I assume that this a 'vendor specific' version?  (i.e. I'm not aware of any 'version' of rohc, per se, but only of the profiles...

Yes.
The text says "version number of the implementation",
not "version number of the specification".

> rohcInstanceLargeCIDs: 'retireved' -> 'retrieved'

Fixed.

> rohcInstanceMRRU: 'according to .' According to what?!

Removed "according to".

> rohcInstanceContextStorageTime: 'rohcInstanceContextExpireTime' doesn't appear anywhere in the MIB..!

Fixed.

> rohcInstancePackets: 'Counter of passing' -> 'Counter of packets passing'

Fixed.

> rohcInstanceCompressionRatio: would it be useful to have the compression ratio for just the headers as well as the overall compression ratio?

We discussed this some time ago. Ghyslain or Lars-Erik,
or both of them said no.

> rohcProfileTable: I can understand this storing a list of the profiles supported by the decompressor (and, I assume, this would cover the compressor for that instance?) but I'm not sure about the injunction that the compressor MUST NOT use a profile
> not in the list.  A compressor can only use a profile that has been negotiated (in some way) with the peer decompressor.  I guess you could use the MIB to do that, but...

I replaced the text according to Lars-Erik's suggestion.

> rohcProfileVersion: I assume that this some 'vendor specific' version, since rohc profiles have a version encoded into the profile identifier...

Yes.
The text says "version number of the implementation",
not "version number of the specification".

> rohcContextCIDState: can a CID change state from 'active' to 'active'..?

No. The state machine per CID is

                        +--> 'terminated' -+
                        |                  |
'unused' ---> 'active' -+                  |
                 ^      |                  v
                 |      +--> 'expired' --->+
                 |                         |
                 +-------------------------+

> rohcContextStorageTime: 'rochContextCIDState' -> 'rohcContextCIDState'

Fixed.

> rohcContextFeedbacks: 'feddbacks' -> 'feedbacks'

Fixed.

> rohcContextAllPacjetsMeanSize: 'in byte rounded' -> 'in bytes rounded'

Fixed.

> rohcContextAllHeadersMeanSize: 'in byte rounded' -> 'in bytes rounded'

Fixed.

> rohcContextLastHeadersMeanSize: 'in byte rounded' -> 'in bytes rounded'

Fixed.

> rohcRtpContextState 'noContex' -> 'noContext'

Fixed.

> 6. Well, ok, not directly related to the text in the security considerations but...  Is there no way of using the MIB to control the mode in which a decompressor operates?  There aren't many changes that you might like to be able to make to a rohc
> instance, but that struck me as a possibility.

We discussed configuring a context by means of the MIB two times at
ROHC sessions. Both times, the conclusion was: We don't need it.

> Cheers,

Thanks.

>
> Mark.
>
> --
> Mark A. West, Consultant Engineer
> Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
> Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433
>
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

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