RE: [rohc] 3GPP2's need for

Rohit, Thomas,

I am also expecting feedback on the following:

> But why not instead ask this WG to speed up and focus on
> RoHCv2, see with the RFC-editor if we can get an RFC number
> reserved and see with IANA if profile numbers can be reserved
> for RoHCv2 profiles, and complete RoHCv2 properly?

Especially wrt to feedback received that the long-term solution in 3GPP2
would be RoHCv2.

Best regards,

///Ghyslain

Ghyslain Pelletier (LU/EAB) wrote:
> Biplab, Chokri, Jun, Haipeng, Rohit, all,
> 
> I don't really believe in coming to IETF asking for IETF
> members to blindly put a rubber-stamp on a draft. But sure it
> can work. I have a whole bunch of RoHC-competent people in my
> corridor that I could ask to send in a friendly mail to
> support me on this list. I just don't think that would have
> any value, it brings no technical value. I am not sure either
> that I believe that "something is better than nothing" wrt
> draft-kapoor. 
> 
> RFC3095 was published too quickly, because of time pressure
> from 3GPP. The implementer's guide has grown since then and
> now we are finally publishing it. Sure, we can do it again
> and spend several years fixing draft-kapoor once it gets
> published to fix all the issues it does not address. RFC3095
> is not an easy spec to digest and to implement right. It
> scares me to think of removing the underlying assumption that
> there is no reordering, fixing lsb and making some recommendations.
> 
> Anyway, I've given a significant number of hints as to what
> should be worked on for this draft. I also think that the
> thought to reuse existing implementations over links that can
> reorder packets is appealing; this is one of the reasons we
> wrote RFC4224. Unfortunately, I don't believe that the result
> would be good in a product that is meant for the long term,
> and I don't believe that the
> modifications/testing/maintenance that it would require to an
> existing RFC3095 implementation would be that trivial either.
> So we've decided to make RoHCv2 ... for a lack of believing
> that the path proposed by the combination of fixing lsb
> encoding and making RFC4224 mandatory is the path of least resistance.
> 
> I respect different opinions on this. I am just trying to do
> the right thing. Hence why I think that this draft should be
> endorsed by 3GPP2 instead. I am not planning to be that vocal
> about this anymore, unless the solution takes a shape that
> makes more sense to me.
> 
> But why not instead ask this WG to speed up and focus on
> RoHCv2, see with the RFC-editor if we can get an RFC number
> reserved and see with IANA if profile numbers can be reserved
> for RoHCv2 profiles, and complete RoHCv2 properly?
> 
> We've got excellent feedback from all of you guys, and we've
> certainly appreciated it, so why not focus on this?
> 
> ///Ghyslain
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc