[rohc] Questions about the MIB!

["West, Mark (ITN)" <[e-mail]>]

Hi ROHC-ers,

If you haven't been put off by my use of 'MIB' in the subject line, then 
read on!

Having just read through the draft MIB, a couple of questions have 
arisen which I think may benefit from a wider audience...

Firstly, I'm curious to know how many fellow implementors have done 
anything with the packet-size / payload-size restrictions?  (I know we 
haven't ;-)

Secondly, the more general issue is this: there is a quantity of 
information about contexts which is based on the profiles defined in 
RFC-3095.  (For example, referring to the modes as U, O and R and states 
as IR/FO/SO).  This makes absolute sense with regard to RFC 3095.  I am 
interested to know what anyone thinks about the impact of splitting 
3095, however!  How much of the MIB can/should be based on specific 
profile details, rather than 'generic' framework?  (Clearly in the cases 
mentioned above, opaque numeric identifiers could be used)
Anyway, it's a general issue that it would be nice to have some input on...

On a related note, there are a number of configuration parameters which 
only really have 'per profile' significance (for example 'k_1' and 
'n_1').  These parameters are specific to certain profiles .  'k and n' 
also make a useful example, in that k_1 and n_1 are likely to be chosen 
based on the link characteristics.  So, we have values that are 
per-profile and should be configurable (at least) per-interface.  (I 
suppose it makes sense, anyway, to know which profiles are supported on 
any given interface...)

Where a context is using a particular profile, it is not clear to me 
whether or not it is desirable to be able to 'tweak' these values on a 
per-context basis.  Again, any thoughts?

Cheers,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone [phone]   Fax  [phone]

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)