Re: AD comments on draft-ietf-rohc-hcoipsec-10

Ertekin, Emre [USA] skrev:

>  
>> 2. I understand that one the negotiation mechanism is sufficient to
>> ensure that the decompressor doesn't get a profile or more CID then it
>> can handle. However, wouldn't it be suitable to recommend at least
> some
>> basic set of functionality that is mandatory to support to ensure
>> better
>> interoperability and minimal achieved functionality.
> 
> We could update the drafts to specify a "minimum mandatory set of
> capabilities" that a compressor/decompressor must support.  However, the
> motivation for not specifying this "minimum mandatory set of
> capabilities" is that we wanted to remain consistent with traditional
> hop-by-hop ROHC specs/implementations.  I took a look at RFCs 3095 and
> 3241, and these do not specify a minimum set of profiles, CIDs, etc., a
> ROHC instance must support.  The ROHC/PPP only suggests values for these
> parameters (similarly, we suggest values for these parameters in our
> drafts).
> 
> Correct me if I a wrong, but I think that the only mandatory capability
> is the uncompressed profile...and the utility of this profile is limited
> in the context of ROHCoIPsec.
> 
> Presumably, with all the other pre-configurations (e.g., SPD) that are
> required between two IPsec implementations to get an SA up, we can
> mitigate the interoperability concerns that you allude to through this
> pre-configuration process (e.g.,  simply synchronize ROHC parameters
> between two IPsec implementations).  Therefore, I would like to leave
> the drafts as-is, but I am open to further discussion.

Okay, I can see us continuing on this track.

> 
>> 3. When I read this document I get the impression that it would be
>> suitable to be published as a proposed standard because it defines so
>> much how things shall interact. So can you please motivate why you
>> think
>> Informational is more suitable?
> 
> Back when we started this draft, we intended it to be a informational
> requirements document.  Over time, the requirements flavor changed, but
> the general intent is still the same, i.e., to provide some
> background/guidance for the IKEv2 and IPsec drafts.  

I think I am primarily worried about the part in the document that
discusses the need for two SAs and how data is triaged between the ROHC
and non-ROHC one. This is in my eyes normative parts of the solution. It
is the text in Section 6.1 that sounds my alarm bells on this topic.

A lot may be obvious but isn't it part of the technical solution that
makes ROHC over IPsec work? I know we are in a grey area here.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------