Re: Notes from the HCoIPsec Side-Session at IETF (03/20/06)

On Apr 5, 2006, at 6:47 AM, Lars-Erik Jonsson ((LU/EAB)) wrote:

>
> Emre,
>
>> 2) Resolution of the HCoIPsec alternatives: There was
>> consensus that the only difference between the two approaches
>> is the way to identify uncompressed packets.  The first approach
>> uses the "uncompressed profile" as the demultiplexing point, and
>> the second approach uses the "next header" field.  Since the
>> second approach provides a greater reduction in overhead,
>> HCoIPsec efforts will proceed with the second approach, as
>> detailed in the alternatives draft.  IANA will be requested
>> to allocate one value from the next header field for "compressed
>> headers".
>
> This looks fine, but from our point of view I assume the above
> should not say "compressed headers" but "ROHC (packets)", right?
>

I would think not, as regular IPHC is still used as well. Whether the  
SA is using ROHC or IPHC is dependent on the SA, and does not need to  
be encoded in the packet.

>
>> 7) The following documents that are required to achieve HCoIPsec:
>>    a.  HCoIPsec Framework
>
> As per previous discussions where we said this should not have to
> be a standards track document since it would not really define
> any new protocol, did you discuss this or do you have a different
> view if this after the Dallas side-session?
>
>
>>    b.  Definition of a new next header field value (IANA
>>        allocation) that indicates "compressed headers"
>
> I guess the protocol value (for next header) should be "ROHC"
>

Nope. See above.

jan

>
>> 8) Discussion on unifying header compression algorithms:
>> Perhaps define a new ROHC Profile, which will enable IPHC/(e)CRTP
>> to be plugged into ROHC framework.  This way, only one value
>> needs to be allocated from IANA.
>
> Yes, this I believe is a good idea!!
>
>
>> 10) The HCoIPsec framework is currently a chartered item
>> within the ROHC WG.
>
> Well, actually it is not. We have a WG draft, but that does not
> mean it is a chartered item. We will have to make a request to
> make this a WG item, and there nail down which drafts to produce.
>
> BR
> /L-E