Subject: [rohc] Issue list for ROHC TCP

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 15 Feb 2005 11:52:35 +0100

Folks,

I've tried to identify the currently open issues for ROHC-TCP. Probably
there are more issues than this, but it is a start and others should
fill in the missing pieces. I know there is an issue tracker available,
but to me it is clear that it does not work for several reasons; e.g.
the fact that it is not used (updated), and the mail list is not
informed of changes, which is a fundamental requirement if we want to
use such external tools (the mail list is our work archive and the
public place where people should be able to follow what is going on).

So, the open issues I know of right now are:

TCP-1: Does ack and seq scaling have a zero-division issue since
       they appear in the default_methods section?

TCP-2: Ack scaling could be applied to a larger number of packet
       formats. Maybe let _10 and/or _8 use one bit to indicate
       of ack is scaled or not and in that case use 8 bits less?

TCP-3: Since list compression is not defined by FN anymore, text
       for that is needed in the TCP-draft.

TCP-4: We need text on wrap-around of SN/ACK-SN when using scaling.

TCP-5: At least a few people must independently review the content
       of the packet formats so that we have some confidence in
       them.

Follow up on these and add new issues, I'll try to keep track of
which have been closed/added/updated and re-post this regularily.

/L-E

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 8 404 29 61

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 15 Feb 2005 13:01:39 +0100

> which have been closed/added/updated and re-post this regularily.

Shouldn't we try to use the issue tracker instead, and state on the list when/what to add to the tracker instead? I think the problem is the the tool itself, but rather our lack of discipline in using it?

In any case, of course it is good to keep track of issues one way or another - good initiative to bring that back on the table!

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 15 februari 2005 11:53
> To: [email-masked]'
> Subject: [rohc] Issue list for ROHC TCP
> 
> 
> Folks,
>

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 17 Feb 2005 13:52:41 +0100

> The easy way out is to put the assertion in the specific 
> compressed_formats to which it applies.  Clutter, but no new FN 
> features.

I might be lost in my general FN-confusion, but isn't it so that the
residue must be calculated for all formats, also when the values are
sent unscaled?

Marks approach on the other hand looks good to me, lesson learned from
3095 slope-discussion.

/L-E