Re: FW: CDR review ROHCoIPSec

Robert,

I have been updating the document based on the comments that I received
during the WG LC.

Apologies -- I did not adjudicate three of your comments.  Please find
my responses to the three points below.

<snip>

> ------ draft-ietf-rohc-IPsec-extensions-hcoipsec-03 ------

<snip>

> >> 2.2.  Security Association Database (SAD)
> >>
> >> Section 2.1 last paragraph & section 2.2:
> >>
> >> The FEEDBACK_FOR ROHC Channel Parameter should only be populated in
> > the
> >> SAD when a SA in the reverse direction is available. Section 2.2
> needs
> >> clarification regarding the purpose/function of each of the ROHC
SAD
> >> configuration items as they relate to the directional processing
> flow
> >> (inbound and outbound) of a particular SA.
> >>
> 
> Your thoughts on this point?

I don't think that Section 2.1 should contain information about the ROHC
SAD configuration items and how they relate to directional processing of
an SA, since Section 2.1 primarily discusses the SPD.

However, I agree that Section 2.2 should be updated.  This section will
need to be updated anyway now that channel parameters are signaled
between the initiator and the responder.  As you recommended, we can add
a discussion on each channel parameter, and how they are relate to
inbound/outbound SAs.

<snip>

>------ draft-ietf-rohc-ikev2-extensions-hcoipsec-07 ------

<snip>

> >> This document needs to state that the final negotiated set of
> profiles
> >> (as transmitted by the responder if the signaling approach
suggested
> >> above is adopted) MUST NOT contain in invalid combination of RoHCv1
> > and
> >> RoHCv2 profiles. For example, a RoHC channel cannot support both
RFC
> >> 3095 UDP/IP and RFC 5225 UDP/IP.
> >>
> 
> Your thoughts on this?

I think that this point was addressed in a separate email.  Since we are
switching to the signaling-based channel parameter negotiation, I think
that the best approach is to prohibit the initiator/responder to signal
multiple versions of the same profile.  

This way, we can ensure that two different versions of the same profile
will never be active on the same ROHC channel.

> >> For the Notify Message Type field, ROHC_SUPPORTED is specified, but
> >> there is no description of what value in that field indicates
> >> ROHC_SUPPORTED. What value should be used? Some reference to the
> need
> >> for IANA to allocate a IKEv2 Notify message registry would be
> >> informative.
> >>
> 
> Your thoughts on this?

We can add a reference in Section 2.1 of the document that points to the
document's IANA considerations section.  Will this address your comment?


We will be finalizing all three documents over the next couple of days
and should have a new revision out very shortly!  Thanks again for your
comments.

Best Regards,
Emre