Re: [rohc] New ROHC Milesstones.

["Ghyslain Pelletier" <ghyslain.pelletier at ericsson.com>]

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:cabo at tzi.org] 
Sent: den 10 september 2009 17:09
To: pelle at cdt.luth.se
Cc: Carl Knutsson; rohc at ietf.org; Ghyslain Pelletier
Subject: Re: [rohc] New ROHC Milesstones.

On Sep 10, 2009, at 13:55, pelle at cdt.luth.se wrote:

>> As I pointed out, there *is* no technical argument to be made for 
>> using legacy standards.
>
> 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.

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 compression being deployed 
> elsewhere, than there is no need to wrap those inside ROHC.

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

> 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