[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