[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rohc] MIB



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'?

4.1.4. the state of the CID seems to be missing an entry... 
	'conrtext' -> 'context'
	'mean packets size' -> 'mean packet size'
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'.  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.

5.

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

rohcChannelType: 'ight' -> 'might'

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

rohcInstanceLargeCIDs: 'retireved' -> 'retrieved'

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

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

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

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

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

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

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

rohcContextStorageTime: 'rochContextCIDState' -> 'rohcContextCIDState'

rohcContextFeedbacks: 'feddbacks' -> 'feedbacks'

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

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

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

rohcRtpContextState 'noContex' -> 'noContext'

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.

Cheers,

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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc