Subject: [rohc] Consensus on the ROHC over IPsec work item

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 23 Nov 2006 14:53:55 +0100

ROHCers,

We are chartered...
 "to develop and/or document proper protocol
  solutions to apply ROHC over IPsec tunnels"

This work has been in its initial phase for a long time now, and
to some extent we tend to be running in circles. There have been
lengthy and complex discussions on the mailing list, and we have
also had several face2face discussions with involvement from both
WG chairs, AD's and various ROHC and IPsec experts. Still, we are
not in a position where I can say the work is "in good progress".

The main reason for the dead-lock feeling around this work is the
key question about whether there is a reason to not only develop
a solution for ROHC over IPsec (as our actual charter text says),
but to also develop a similar solution for legacy HC schemes
(IP-HC, eCRTP). The whole idea of doing further work for those old
schemes has been questioned, and especially whether the ROHC WG
should really do such developments. Since the outcome of these
questions may impact the ROHC solution, we have not been able to
get progress while stuck with this controversy.

We currently have a milestone saying...
 "ROHC encapsulation profile(s) for IPHC/CRTP/eCRTP submitted
  to IESG for publication as Proposed Standard"

This milestone, however, does not represent WG consensus (not
even rough), something that became appearent when discussions got
stared. At the time when the milestone was added, there was not
much said, I had the proposal to go with this approach, I asked
for comments on the charter proposal and got none, so it was
added. Discussions later on suggested we should remove it, but
there was no clear consensus in that direction either, therefore
it is still there.

So, where are we when it comes to consensus on this work item?

1) We do have consensus to develop a ROHC solution for IPsec,
   and this is in line with the actual charter text.

2) If we were not to consider any other HC scheme than ROHC, we
   also have a clear consensus about the technical solution, and
   that matches also our milestones, except for the one listed
   above, which should then go away.

3) We do not have consensus for developing IPsec solutions for
   "legacy HC schemes" (IP-HC and eCRTP), but neither do we have
   consensus for completely dropping that issue.

4) We actually do not have consensus around the encapsulation
   profiles milestone discussed above.

5) Problem is, even if we had consesnsus in 3) above, we still
   have not seen a solution proposal that we have been able to
   get consensus for (which we do for the ROHC-only track), as
   there are undesirable side effects associated with all
   proposals we have seen so far.

Thus, the only workable way forward, as I see it, is to move on
with the ROHC solution according to 2) above and in line with
what is currently in our charter (with the exception of one
independent milestone). Those who want a solution for the
legacy schemes must continue to argue for that, but we should
not let that process delay the work on ROHCoIPsec.

A very general question around which we should in any case try
to establish an IETF opinion is whether we believe the IETF
should continue developing new extensions to the old HC schemes
when ROHC is now established and constitutes a platform for
today's and future HC schemes. At some point, we will have to
drop the old tracks, free some clock cycles and focus on the 
future.

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Ertekin, Emre" <[email-masked]>
Date: Wed, 29 Nov 2006 08:25:16 -0500

Lars-Erik,

Thanks for this summary.  

>    above, which should then go away.

<snip>

> Thus, the only workable way forward, as I see it, is to move on with 
> the ROHC solution according to 2) above and in line with what is 
> currently in our charter (with the exception of one independent 
> milestone). Those who want a solution for the legacy schemes must 
> continue to argue for that, but we should not let that process delay 
> the work on ROHCoIPsec.

I agree with this approach.  To avoid further delay, we should focus our
efforts--for the time being--on the RoHCoIPsec solution.   We can table
the eCRTP discussion for a later date.  

To accommodate this, we will update the IKEv2 Extensions draft to
negotiate strictly RoHC per-channel parameters.  In addition, we will
release an updated HCoIPsec draft.  Both drafts will be released by the
end of next week.

Best Regards,
Emre