Subject: [rohc] New ROHC Milesstones.

From: Carl Knutsson <[email-masked]>
Date: Thu, 10 Sep 2009 10:35:15 +0200

rohcers,

It is time to update the milestones for the rohc wg. I should have done
this a long time ago. I have sent my suggestion to our AD, but I want to
make sure that it represent the consensus of the group and not just my
opinions. So I need your feedback here. Please send in your comments
about the new milestones.

Below follows my suggestion:

The item I want to mark as "Done" is:

Dec 2006 - Revised ROHC IP/UDP/RTP profiles submitted to IESG for
           publication as Proposed Standard

Mar 2007 - IKE/IPsec extensions for HC-session Parameter Negotiation
           submitted to IESG for publication as Proposed Standard

Mar 2007 - Header Compression over IPsec (HCoIPsec) submitted to IESG
           for publication as Informational

The first item resulted in RFC 5225, the second and the third items
forms the ROHCoIPSec framework and are all drafts):

draft-ietf-rohc-hcoipsec-11
draft-ietf-rohc-ikev2-extensions-hcoipsec-09
draft-ietf-rohc-ipsec-extensions-hcoipsec-05

All ROHCoIPSec have passed the AD evaluation and drafts are now in IETF
last-call.

I would like to add one item:

Sep 2009 - Revised ROHC framework submitted to IESG for publication as
           Proposed Standard

This is the new framework draft that is in WG last-call. It includes a
fix to the feedback format (to make piggybacked feedback possible) and
some editorial changes in the text.

I would like to remove two items.

Feb 2007 - ROHC encapsulation profile(s) for IPHC/CRTP/eCRTP submitted
           to IESG for publication as Proposed Standard
Jan 2007 - RObust Header Compression Protocol Number Registration
           submitted to IESG for publication as Proposed Standard

This was added before I started as a chair and it is not completely
clear to me what the consensus is for this item. I can't really see what
these new legacy profiles solve that can't be solved by existing
profiles. I would like to have this discussion now.

The Protocol Number Registration item is not needed. The registration is
included in the ROHCoIPSec drafts.

I would like to see a change of date for the last item. From Jun 2007 to
Sep 2009. It is long overdue:

Jun 2007 - Recharter of WG to develop additional profiles if needed, or
           possible additional compression schemes. Consideration of
           concluding the working group.

Please send in your comments.

Best Regards,

/Carl Knutsson, ROHC WG Chair

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Sep 2009 11:03:22 +0200

>           to IESG for publication as Proposed Standard

I wrote a draft for that,

http://tools.ietf.org/html/draft-bormann-rohc-avt-crtp-profile-00

As far as I know, this is technically complete and could be submitted  
to WGLC.

> =This was added before I started as a chair and it is not completely
> profiles.

There are no new problems being solved, so much is true.
But they are solved in a different way, and possibly with different  
IPR considerations, based on existing IETF standards documents.
I can't speak to the IPR considerations (and I would not want to  
discuss them on the WG list), but I've heard that some people are  
interested in them in the hallway.

Gruesse, Carsten

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Thu, 10 Sep 2009 11:38:38 +0200

Hello Carl,

Thanks for initiating the update of the ROHC WG charter.
This is indeed overdue.

I agree wrt the three "Done" items (RFC5225 and ROHCoIPSec).
I am fine with adding a milestone for the revised ROHC FW with Sep 2009
as target.
I agree wrt the proposal about removal items (encapsulation and nr
registration).

Further more, I propose to update the following, from:

To:

Sep 2009 - Conclusion of the working group.

I believe that at this point, we can actually agree in-principle for
aiming at concluding the working group (pending AD feedback, of course).

///Ghyslain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Carl Knutsson
Sent: den 10 september 2009 10:35
To: [email-masked]
Subject: [rohc] New ROHC Milesstones.

rohcers,

Best Regards,

/Carl Knutsson, ROHC WG Chair
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Thu, 10 Sep 2009 11:45:49 +0200

Hello Carsten, others,

Given earlier discussions on this topic, my recollection is that there
was no agreement to move this as a working group draft. The reasons for
this was the lack of motivations, requirements or interest in pursuing
this work. Furthermore, this would introduce additional complexity to
our protocol, and the proposed solution has not been reviewed
technically. 

> But they are solved in a different way

Given the admitted lack of a real problem to address, new solutions
appear unnecessary and not worth-while the effort. Further, I do not
believe that getting around some suspected IPRs (to possibly fall into
other IPRs) is a typical motivation for specifying new profiles.

Cheers,

///Ghyslain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Carsten Bormann
Sent: den 10 september 2009 11:03
To: Carl Knutsson
Cc: [email-masked]
Subject: Re: [rohc] New ROHC Milesstones.

As far as I know, this is technically complete and could be submitted to
WGLC.

> clear to me what the consensus is for this item. I can't really see 
> what these new legacy profiles solve that can't be solved by existing 
> profiles.

There are no new problems being solved, so much is true.
But they are solved in a different way, and possibly with different IPR
considerations, based on existing IETF standards documents.
I can't speak to the IPR considerations (and I would not want to discuss
them on the WG list), but I've heard that some people are interested in
them in the hallway.

Gruesse, Carsten

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 10 Sep 2009 12:08:46 +0200

Carsten, Ghyslain,

I agree with Ghyslain here. I am having a hard time seeing any technical
argument that would motivate these new profiles.

/Calle (individual)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Sep 2009 12:26:36 +0200

On Sep 10, 2009, at 12:08, Carl Knutsson [without WG chair hat] wrote:

> I am having a hard time seeing any technical

As I pointed out, there *is* no technical argument to be made for  
using legacy standards.

Unless you consider ease of deployment, availability of debugged  
implementations etc. a technical argument.

In the absence of a general solution to bridge legacy compression into  
ROHC, every HC-over-X document that is trying to get some real-world  
applicability has to provide the solution on its own.  Just like RFC  
4901 did.

The next one in line is
http://tools.ietf.org/html/draft-bormann-rohc-over-802

I can certainly put in a legacy bridge there.  I'd rather use the one  
described in
http://tools.ietf.org/html/draft-bormann-rohc-avt-crtp-profile-00

Gruesse, Carsten

---

From: [email-masked]
Date: Thu, 10 Sep 2009 13:55:21 +0200

> As I pointed out, there *is* no technical argument to be made for  

I think the intent here was to mean "use case where there is a need for such a 
technical solution" ... correct me if I am wrong.

I.e. it is not clear to me that "ease of deployment" is synonym with "use-case 
for such deployment". Typically, for the same reasons that this WG created the 
existing profiles, legacy header compression algorithms would not be deployed 
where ROHC is expected to be deployed. If the argument is to have legacy header 
compression being deployed elsewhere, than there is no need to wrap those 
inside ROHC.

Honestly, from personal standpoint, I must admit I am not so interested in 
entertaining this discussion once more, or to keep this WG alive on artificial 
life-support ...

Cheers,

///Ghyslain

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Sep 2009 17:09:23 +0200

On Sep 10, 2009, at 13:55, [email-masked] wrote:

> where ROHC is expected to be deployed.

Well, as you surely know, ECRTP (RFC 3545) was invented to do exactly  
that.

I think that for the people who have done a lot of work in ROHC, the  
v1 and v2 ROHC profiles appear to be the natural way of doing things,  
so they can't imagine why one would want to use older technologies.   
For people who have been using HC in other contexts, CRTP (or, heaven  
forbid, RFC 1144) may be as natural.  From the point of view of many  
people, CRTP just plain won.  Trying to separate the ROHC framework  
from an important, well established HC method is incredibly bad  
design.  Even after all of our discussions, the only reason I can see  
for such a decision would require some political motivation.

> If the argument is to have legacy header

By the same argument, there is no need for IP.
Having common wrappers saves inventing lots of special-case ones.

> entertaining this discussion once more,

I certainly wouldn't have brought it up, but it is on the charter.
So if we want to lay the WG to rest, we should decide how to dispose  
of it.
Given that we haven't done the right thing yet, it would be wrong for  
me to shut up.
Since we had the discussion, RFC 4901 has clearly shown how the  
alternative looks like, and I'm not happy.

> or to keep this WG alive on artificial
> life-support ...

Certainly not.

Gruesse, Carsten

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 10 Sep 2009 19:12:24 +0200

Hi Emre,

The IPDVB WG is probably a good candidate for the ROHC-over-DVB
document. There will probably be more ROHC-over-X documents in the
future. Sometimes it will not be perfectly clear in which group the
documents will end up. I guess it will be up to the AD to decide how
handle this.

I will try to follow up on all ROHC related documents and give reviews
to the best of my abilities, even after the conclusion (now/later?) of
the group. I hope all rohc wg members will do the same.

/Calle

Ertekin, Emre [USA] wrote:
> Hi, Carl,
> 
> Please find below my comments.
> 
> I am fine with marking these items as "Done".
>  
>> what
> I expressed my interest in this proposal a while back for a number of reasons, including providing a bridge for existing HC implementations into the ROHC framework.  There was pushback from the WG then, still seems like there is pushback now...
> 
> I agree.
> On a separate note: in passing discussions, I have heard interest in the development of a ROHC over DVB spec.  However, I presume that if this work takes place, it would fall under the IPDVB WG. 
>

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 10 Sep 2009 19:19:30 +0200

...and thanks for your input on the milestones.

/Calle

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Thu, 10 Sep 2009 20:39:50 +0200

Carsten, others,

Let's agree that forces beyond us (the presence of this item on the
charter) are unfortunately forcing us to re-hash this once more. I
certainly did not bring this up nor wanted to give it follows, but
somehow the drugs still seem to work after all ...

And yes, I am not positive to this. Especially when, given the time has
come to close this WG after many successful years, from a couple of
years ago a long forgotten draft not missed by anyone resurfaces out of
a discussion on an outdated charter.

>From my perspective, the simple facts remain ...

1) the encapsulation proposed by this draft does not exist today.

To change this, it should be properly motivated with a real problem and
practical use case just like any other work item this WG has worked on
in the past. A simple "we can do this" does not make for a very serious
argumentation.

In my previous mail, I enquired about the very fundaments that are
normally discussed in a WG before agreeing to do some work. After a few
mails, I still fail to recognize a concrete argument. In the end, we
would have yet another specification to agree on, to maintain, to
interopt, to fix if needed, to answer questions about etc.

2) the design choices for ROHC have been related to its envisioned
deployment.

Those choices were partly dictated by the type of links (i.e. lossy)
originally targeted by ROHC where 2507 and 2508 "perform less than well"
[Bormann et al.]. They have different intended application. While ECRTP
may address some of the shortcomings of CRTP and may be considered to
apply to a similar envisioned deployment as ROHC, the need to support
ECRTP inside ROHC is not clear given that ROHC already has a profile
that achieves the same thing (and some more).

Finally, the main drivers of my opinions are myself only, and have
always been no matter how others may interpret my input. No politics
there, just someone convinced that the work here is done and it is time
to wrap up.

Cheers,

///Ghyslain 

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: den 10 september 2009 17:09
To: [email-masked]
Cc: Carl Knutsson; [email-masked]; Ghyslain Pelletier
Subject: Re: [rohc] New ROHC Milesstones.

On Sep 10, 2009, at 13:55, [email-masked] wrote:

> I think the intent here was to mean "use case where there is a need 
> for such a technical solution" ... correct me if I am wrong.
>
> I.e. it is not clear to me that "ease of deployment" is synonym with 
> "use-case for such deployment". Typically, for the same reasons that 
> this WG created the existing profiles, legacy header compression 
> algorithms would not be deployed where ROHC is expected to be 
> deployed.

I think that for the people who have done a lot of work in ROHC, the
v1 and v2 ROHC profiles appear to be the natural way of doing things,  
so they can't imagine why one would want to use older technologies.   
For people who have been using HC in other contexts, CRTP (or, heaven
forbid, RFC 1144) may be as natural.  From the point of view of many
people, CRTP just plain won.  Trying to separate the ROHC framework from
an important, well established HC method is incredibly bad design.  Even
after all of our discussions, the only reason I can see for such a
decision would require some political motivation.

> If the argument is to have legacy header compression being deployed 
> elsewhere, than there is no need to wrap those inside ROHC.

> Honestly, from personal standpoint, I must admit I am not so 
> interested in entertaining this discussion once more,

I certainly wouldn't have brought it up, but it is on the charter.
So if we want to lay the WG to rest, we should decide how to dispose of
it.
Given that we haven't done the right thing yet, it would be wrong for me
to shut up.
Since we had the discussion, RFC 4901 has clearly shown how the
alternative looks like, and I'm not happy.

> or to keep this WG alive on artificial life-support ...

Certainly not.

Gruesse, Carsten

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Sep 2009 13:46:08 +0200

Hi,

As the responsible AD I will give my view on the things that has been
brought up and where there are discussion.

Regarding the milestone:

This work was chartered on the 30th of August 2006. The only draft to
fulfill the WG item ever submitted was
draft-bormann-rohc-avt-crtp-profile-00. It was submitted in March 2007.
Since then there has been zero progress on this. This makes it clear
that there are no energy nor interest for this WG item. That is why I
will not hesitate a single second to kill that WG item.

When it comes to the two new item brought up as potential WG items I
have the following comments:

http://tools.ietf.org/html/draft-bormann-rohc-over-802-02
This can be done as AD sponsored easily. The goal after all was that the
adaptation needed so that ROHC can be used for a specific link layer is
primarily intended to be done by the people that have the link layer
knowledge. This doesn't need to happen in the ROHC WG. So AD sponsored
is one way to get such a specification published. Another could be to do
it in IEEE. I don't have any strong views on this.

http://tools.ietf.org/id/draft-lei-rohc-sigcomp-static-dictionary-01.txt
I haven't seen a single comment from the WG regarding this individual
draft. I do value the WGs input into if this seems to a good idea.

But frankly, the ROHC WG seems to have very little energy left. Based on
the observed progress the last two years I think it is definitely time
to close down this WG and declare success. The WG has produced a number
of specification of good quality. Closing the WG does not prevent future
work on the ROHC specifications or extensions. Simply that the way to
accomplish these are different.

Best Regards

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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-masked]
----------------------------------------------------------------------

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 11 Sep 2009 14:29:44 +0200

Magnus, others,

Magnus, thanks for joining the discussion. I agree with Magnus on all
accounts.

Even if it seems like we will be closing down soon, I want the group to
focus on the last call of drafts draft-ietf-rohc-rfc4995bis-01.txt

http://tools.ietf.org/html/draft-ietf-rohc-rfc4995bis-01

Thanks,

/Calle

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Sep 2009 14:58:53 +0200

Magnus,

I agree with all conclusions you have made.

Let me, however, explain one thing for the record:

> Since then there has been zero progress on this.

No progress was needed, since the spec is technically complete.
I never saw a need to update it.

> This makes it clear
> that there are no energy nor interest for this WG item.

There was lots of energy in 2007!
Energy trying to kill the idea.
(I still haven't heard a single technical reason why.)

> That is why I

I fully agree.

(Since one of the specs that might make use of the ROHC-CRTP bridge  
has recently received new interest, I may want to pursue the draft in  
that context.)

Gruesse, Carsten

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Sep 2009 15:43:37 +0200

> (I still haven't heard a single technical reason why.)

I think the main argument is technical to the extent that additional
profiles for the same thing do reduce interoperability. But I can see
how people equally interpret that as political.

The motivation for creating CRTP profiles within ROHC was also primarily
political.

> (Since one of the specs that might make use of the ROHC-CRTP bridge has
> recently received new interest, I may want to pursue the draft in that
> context.)
> 

Can you expand on this. What do you mean with bridge? A gateway or more
in the meaning of bridging over between ROCH and CRTP?

Cheers

Magnus Westerlund

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Sep 2009 15:54:18 +0200

> in the meaning of bridging over between ROCH and CRTP?

Sorry, bad term.  I meant enabling the use of the CRTP scheme within  
the ROHC framework, so we can use ROHC-over-X standards (like ROHC- 
over-802) to solve the more general HC-over-X problem (with the the  
CRTP/2507 family being the only viable remaining pre-ROHC HC), as  
opposed to introducing RFC4901-style multiplexing points and attendant  
inefficiencies.

Gruesse, Carsten