Subject: [rohc] sigcomp issue lejo-9

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 25 Apr 2002 09:35:21 +0200

Hi all,

I agree with Carsten that "specification required" is a too weak
requirement for sigcomp version assignment. Assignment should
instead be based on "Standards Action". The IANA section could
then be modified to the following:

"SigComp requires a 2-octet name space, the SigComp_version, to
be assigned by the IANA. Upgraded versions of SigComp must be
backwards-compatible with version 0x0000, described in this
document. Adding additional UDVM instructions and assigning
values to the reserved UDVM memory addresses are two possible
upgrades for which this is the case.

Following the policies outlined in [RFC-2434], the IANA policy
for assigning a new value for the SigComp_version shall require
a Standards Action. Values are thus assigned only for Standards
Track RFCs approved by the IESG."

Any comments?

BR
/Lars-Erik

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research and Experiments
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Apr 2002 10:44:19 +0200

> Track RFCs approved by the IESG."

Yes -- the other part of the issue was whether we actually need two 
bytes for the ID.
For ROHC, we decided to use two bytes in order to express two dimensions:
Different Profiles (one for RTP, one for ESP, one for TCP and so on), 
and different versions ("upgrades") of the same profile.
I don't see the first dimension for the UDVM.
So, 256 different versions should be enough for quite some time (a 
century if we standardize a new version every five months).
Since the UDVM version actually needs to be transported around, one 
additional byte may not be entirely trivial.

Another interesting item raised by your message is that of upward 
compatibility of pre-initialized VM values.  The compressor can 
currently rely on all memory cells being initialized to zero, except 
those identified in the document.  Since a compressor does not indicate 
the UDVM version it expects, UDVMs cannot pre-initialize other VM values 
without possibly causing unexpected results.
On the other hand, initializing the memory is a must for security 
reasons, and being able to rely on zeroes is good for saving superfluous 
initializations.  So maybe we want to reserve an area for extensions?
(Probably taking care not to pollute the efficiently addressable space 
too much further.)

Gruesse, Carsten