[rohc] 3-bit CRC and IPv6 ip_id_behavior

[" Sasha Koruga " <[e-mail]>]

Dear ROHC enthusiasts,

I have a question concerning section 6.6.11, “control_crc3_encoding” of RFC 5225, particularly for the RTP profile.  The statement of interest: “ip_id_behavior, one octet for each IP header in the compressible  header chain starting from the outermost header.”
 
For the RTP profile, are the ipv6 ip_id_behaviors included in the crc3 coverage? We are having an internal team debate on the issue, and thus I seek your guidance. 
 
I would personally argue “no”, because at section 6.6.11, ip_id_behavior for the ipv6 header is considered non-existent. Thus, I believe that, although not explicitly stated, the crc3 encoding only includes one octet for each IPv4 header. 
Only later in the text, in the lower layers (section 6.8.2.4), does an ipv6 ip_id_behavior occasionally get defined as RANDOM, but I don't believe that subsequently definitions makes that variable into a control field. 
Furthermore, in the RTP profile section, it states:
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
Thus it only defines one ip_id_behavior_innermost, and not an ip_id_behavior for each IPv6 header, as would be necessary for a control_crc3_encoding that would encode every ipv6 header, and as it did in the UDP profile:
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
I believe the purpose of the RTP definition was to allow functions such as ip_id_sequential_variable() and profile_1_7_flags1_enc() to be used regardless of ipv4 or ipv6, but not to expand the  control_crc3_encoding() process. 
 
Logically, I also don't think it makes sense to compute the CRC3 of ipv6 ip_id_behavior. The purpose of CRC3 is to ensure that our control variables are in sync. However,  ipv6 ip_id_behavior is always defined as RANDOM, so it can never be out-of-sync anyway. Adding it to the CRC3 calculation would be an unnecessary computation. 
 
However, I definitely see why some of my colleagues would argue the other way: that the ip_id_behavior for each and every IP header is included in the CRC3 coverage. They argue that if the intention was to include the ip_id_behavior's of only IPv4 headers, why would it not be stated explicitly as such?
 
If you would clarify your intentions when writing the RFC, that would put our minds to rest. Thank you. 
 
Sincerely,
Sasha Koruga