Re: New ROHC Milesstones.

Carsten Bormann <[email protected]> Thu, 10 Sep 2009 17:09:23 +0200
Newsgroups gmane.ietf.rohc
Message-ID <[email protected]>
On Sep 10, 2009, at 13:55, [email protected] 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