Current Meeting Report
Jabber Logs

2.8.16 Robust Header Compression (rohc)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional ROHC Page
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/06/2002

Carsten Bormann <>
Lars-Erik Jonsson <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Technical Advisor(s):
Erik Nordmark <>
Mailing Lists:
General Discussion:
To Subscribe:
Description of Working Group:
Due to limited bandwidth, IP/UDP/RTP/TCP packets sent over cellular links benefit considerably from header compression. Existing header compression schemes (RFC 1144, RFC 2508) do not perform well over cellular links due to high error rates and long link roundtrip times, particularly as topologies and traffic patterns become more complex. In addition, existing schemes do not compress TCP options such as SACK or Timestamps.

Another consequence of low bandwidth links is long session setup delays when text-based signaling protocols, such as SIP and SDP, are used. These delays can be significantly reduced by compressing not only the headers, but also the signaling information.

The goal of ROHC is to develop generic header compression schemes that perform well over links with high error rates and long roundtrip times, as well as related signaling compression schemes. The schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long roundtrip times. Ideally, it should be possible to compress over unidirectional links.

Good performance includes both minimal loss propagation and minimal added delay. In addition to generic TCP and UDP/RTP compression, applications of particular interest are voice and low-bandwidth video.

ROHC may develop multiple compression schemes, for example, some that are particularly suited to specific link layer technologies. Schemes in addition to those listed in the milestones below may be added in consultation with the area directors.

A robust compression scheme must:

* assure that the result after decompression is semantically identical to the uncompressed original;

* perform well when the end-to-end path involves more than one cellular link;

* support IPv4 and IPv6.

* provide benefit in the presence of IPSEC.

Creating more thorough requirements documents will be the first task of the WG for each of its specific areas of work, which are:

* 0-byte improvements to RTP header compression

* TCP header compression

* Signaling compression

* SCTP header compression

In addition, the WG will work on MIBs for its compression schemes, as well as the sheperding of RFC3095 to draft standard.

The working group shall maintain connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use.

In addition, the WG should develop a solid understanding of the impact that specific error patterns have on the compression schemes, and document guidelines to Layer 2 designers regarding what Layer 2 features work best to assist Layer 3 and Layer 4 header compression. This work is in coordination with the PILC WG.

Some of the schemes developed in ROHC will be used in wider contexts than just the specific link technologies discussed. The working group will ensure the applicability in particular of the TCP and signaling compression schemes to the general Internet. This includes considering the applicability of the technologies under consideration to open-source implementations.

Finally, working group documents will address interactions with IPSEC and other security implications.

Goals and Milestones:
Done  Submit I-D on Requirements for IP/UDP/RTP header compression.
Done  Submit I-D of layer-2 design guidelines.
Done  Submit I-D(s) proposing IP/UDP/RTP header compression schemes.
Done  Submit I-D of Requirements for IP/TCP header compression.
Done  Requirements for IP/UDP/RTP header compression submitted to IESG for publication as Informational.
Done  Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
Done  Resolve possibly multiple IP/UDP/RTP compression schemes into a single scheme.
Done  Submit I-D on IP/TCP header compression scheme.
Done  IP/UDP/RTP header compression scheme submitted to IESG for publication as Proposed Standard.
Done  IP/TCP compression scheme submitted to IESG for publication
JAN 01  Possible recharter of WG to develop additional compression schemes.
JAN 02  Initial draft on general signaling compression security analysis.
JAN 02  Requirements and assumptions for signaling compression
JAN 02  Signaling compression scheme submitted to IESG for publication as Proposed Standard, including security approach for SIP compression usage.
JAN 02  Layer-2 design guidelines submitted to IESG for publication as Informational.
APR 02  LLA mapping examples submitted to IESG for publication as Informational.
APR 02  I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.
MAY 02  General signaling compression security analysis submitted to IESG for publication as Informational.
MAY 02  ROHC MIB submitted to IESG for publication as Proposed Standard.
AUG 02  ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard.
SEP 02  ROHC framework submitted to IESG for publication as Draft Standard.
SEP 02  ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard.
SEP 02  Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
SEP 02  IP/TCP compression scheme submitted to IESG for publication as Proposed Standard.
DEC 02  Requirements for IP/SCTP header compression submitted to IESG for publication as Informational.
DEC 02  IP/SCTP compression scheme submitted to IESG for publication as Proposed Standard.
Done  Possible recharter of WG to develop additional compression schemes.
  • - draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt
  • - draft-ietf-rohc-tcp-requirements-04.txt
  • - draft-ietf-rohc-signaling-req-assump-06.txt
  • - draft-ietf-rohc-sigcomp-07.txt
  • - draft-ietf-rohc-epic-lite-01.txt
  • - draft-ietf-rohc-mib-rtp-02.txt
  • - draft-ietf-rohc-rtp-lla-r-mode-03.txt
  • - draft-ietf-rohc-sigcomp-extended-04.txt
  • - draft-ietf-rohc-sigcomp-udvm-00.txt
  • - draft-ietf-rohc-tcp-02.txt
  • - draft-ietf-rohc-rtp-impl-guide-01.txt
  • - draft-ietf-rohc-sctp-requirements-00.txt
  • - draft-ietf-rohc-tcp-field-behavior-00.txt
  • Request For Comments:
    RFC3095 PS RObust Header Compression (ROHC)
    RFC3096 I Requirements for robust IP/UDP/RTP header compression
    RFC3242 PS A Link-Layer Assisted ROHC Profile for IP/UDP/RTP
    RFC3243 I Requirements and assumptions for ROHC 0-byte IP/UDP/RTP compression
    RFC3241 PS ROHC over PPP

    Current Meeting Report

    Minutes of the ROHC WG session at IETF 55
    Marriott Marquis, Atlanta, USA
    Monday morning, 2002-11-18
    Chairs: Carsten Bormann & Lars-Erik Jonsson
    Reported by: Lars-Erik Jonsson
    Note takers: Pete McCann, Gorry Fairhurst
                 Christian Schmidt & Mark West 
    Slides are available at
    Morning session, 0900-1130
    * WG admonishments (Carsten Bormann)
    Carsten reviewed the IETF working group principles, the IETF 
    standardization process and the IPR rules defined by RFC 2026.  People are 
    encouraged to read RFC 2026 and RFC 2418, which define our processes. We are 
    here to make the internet work, and we use rough consensus and running code 
    instead of voting. The ROHC WG is chaired by Lars-Erik Jonsson and 
    Carsten Bormann, with support from our area directors, Allison Mankin and 
    Scott Bradner. Note that the real work is done on the mailing list, 
    although face-to-face meetings can sometimes help the progress. Meeting 
    time should be used to advance difficult issues, not for 
    presentations. We do assume that people have read the drafts.
    Finally, Carsten stressed the RFC 2026 IPR policy, which says that any 
    contribution must identify whether the contributor(s) is(are) aware of any 
    IPR issues related to the contribution.
    * Agenda bashing (Carsten Bormann)
    Carsten presented the proposed agenda, which was accepted without 
     - Chair admonishments and agenda bashing   
     - WG and document status update
     - ROHC RTP, Draft Standard preparations update
     - Signaling compression
     - ROHC over wireless Ethernet media
     - TCP profile
     - Formal header compression notation
    * WG and document status (Lars-Erik Jonsson)
    Lars-Erik reviewed WG goals, milestones and document status.  The Lower 
    Layer Guidelines document and the LLA R-mode extension are currently in 
    AUTH48 and will thus soon be published. The SigComp documents have passed 
    IANA registration but are still waiting in the RFC Editor's queue. ROHC has 
    currently no documents on the IESG table. At the moment, the WG has 5 
    documents related to ROHC RTP and the Draft Standard process, 4 
    documents for the TCP profile work (plus the notation document which is 
    also to some extent part of the TCP work), and one document for SCTP 
    requirements. The SCTP work is currently on hold due to a lack of 
    interest in compression of SCTP.
    We will be few months late with the ROHC MIB, but that is a minor issue. The 
    LLA mapping examples document and the ROHC RTP Draft Standard 
    documents are not yet available, but will soon be. Lots of 
    preparation work for Draft Standard have been done, but this is a long 
    process. The TCP work is now progressing and is on track, although we will 
    probably have to adjust the finalization date a few months. 
    * ROHC RTP, Draft Standard preparations update (Lars-Erik Jonsson)
     - MIB & ROHC terminology and mapping examples
    The MIB is now rather stable and it is thus time to read it and 
    comment. It will be updated once more to include support for the LLA 
    profile. The "Terminology and channel mapping examples" draft provides 
    reference material for the MIB and the goal is to have these two 
    documents last-called in the WG in December.
    Drafts: draft-ietf-rohc-mib-rtp-04.txt
     - Implementation status & feature test list
    Four ROHC interop events have been held so far. At the last interop, "ROHC in 
    the city" in Berlin, there were four implementations present from 
    Effnet, Ericsson, Acticom, and ICR (Singapore). First extensive IPv6 tests 
    were successfully performed by Ericsson and Effnet, and initial testing of 
    list compression was also carried out between Acticom and Ericsson.  
    Preliminary reports on the results point to potential ambiguities in the 
    list compression specification, but this will have to be further 
    A test case document is now available in an initial version. The purpose of 
    this document is to specify a list of feature tests that will have to be 
    carried out to take 3095 further to Draft Standard, and also to 
    document current interoperability test status. This document should be the 
    basis for future interoperability tests.
     - Implementer's Guide
    There have been two additions to the implementer's guide in the new 
    version, based on mailing list discussions. The first 
    clarification is about the interpretation interval for timestamp bits. 
    RFC3095 defines two different interpretation intervals, but it is not 
    clear that both these are used, and which one to use depends on the 
    timestamp encoding mechanism used. Normal W-LSB compression uses one 
    interval and timer-based compression uses the other. The 
    implementer's guide now explains this, and also how to reliably switch 
    between them.
    The other issue clarified is about profile negotiation. Profile numbers are 
    16-bit identifiers, while only the 8 LSB's of these are sent when 
    initializing new contexts. This means that the negotiation protocol must 
    ensure that there cannot be two profiles with the same LSB's available 
    after negotiation. Two profiles with the same LSB's are thus not 
    supposed to be concurrently used over a channel.  There is no problem with 
    ROHC-over-PPP in this regard. 
     - A ROHC profile for IP only, purpose & problem
    RFC 3095 defines profiles for uncompressed, IP/UDP, IP/UDP/RTP and 
    IP/ESP. The ROHC WG has agreed to define an IP-only profile as a 
    complement to these. The purpose of this profile is to make the RFC 3095 
    profile suite complete, to allow one with an RFC 3095 
    implementation to easily modify that for IP-only compression, as a 
    mechanisms to use for e.g. transport protocols not yet supported by a ROHC 
    profile. The intent is thus not to define a ROHC-lite profile, that would be a 
    different work item.
    The main issue that has been identified for the definition of the IP 
    profile is the question of how to terminate the static chain when there is no 
    single protocol that would end the chain, as it is for the case of UDP. The 
    proposed solution is to terminate the chain when there is anything other 
    than IP/IPv6 in the Protocol/Next Header field.
    One thing that complicates the issue is the potential presence of more than 2 
    IP headers. The profiles defined in 3095 can compress one or two IP 
    headers, but since the UDP header must terminate the chain, 
    compression would be totally disabled if there are more than two IP 
    headers. This is a non desirable limitation for the IP profile. 
    However, since the IP profile does not require one specific header to 
    terminate the static chain, a rule saying that the static chain is 
    implicitly terminated after a second IP header portion would ensure that the 
    two initial IP headers can always be compressed. The question is whether it 
    would be easy to provide the means to compress an arbitrary IP header 
    chain. Two potential solutions for this were presented. One way could be to 
    handle additional IP headers with list compression. Another way could be to 
    allow the static chain to be of arbitrary length and add a dynamic header 
    portion to compressed headers for all IP headers but the first two. The 
    latter was suggested as the preferred choice because it would be a minor 
    modification, require no new data structures and mean that the dynamic 
    header portion would be the same for IR, IR-DYN and Compressed packets.
    Draft: draft-ietf-rohc-ip-only-00.txt 
     - Next steps
    The work for taking RFC 3095 further has started, but there are lots of 
    things to do to make this happen. The MIB will be updated and 
    last-called in the WG during December. The IP profile will be updated to 
    address the issues previously discussed and last-called in the WG. The test 
    list document must be improved and we should start collecting status on 
    interoperability. Potential findings from the Berlin interop must 
    further be evaluated, and the implementer's guide updated, if 
    necessary. Finally, an initial version of the "3095 surgery plan" must be 
    Richard Price asked whether it would make sense to define an IP profile 
    also as part of the TCP work, which would probably be a simpler 
    profile. L-E responded that there might be different reasons for having an IP 
    profile, and nothing prevents us from having more than one. The profile 
    currently being defined would be an obvious choice with 3095, but there 
    could be another one that is easy to implement with TCP. This is 
    something we should consider later on.
    * Signaling compression
     - SigComp User Guide and testing (Richard Price)
    Richard covered two documents, the SigComp User Guide and a new 
    individual submission with SigComp torture tests. The User Guide is an 
    informational companion to SigComp, providing a UDVM assembly language and 
    bytecode for well-known decompression algorithms. The last update 
    included an enhanced assembly language, "raw" bytecode for each 
    decompressor, and examples of compressed messages. It has been proposed to 
    add an other decompression algorithm, TCCB, to the user guide. One 
    problem with that algorithm is that the TCCB compressor is not defined in 
    any referable documentation. Carsten made clear that it is not part of our 
    work to publish compression algorithms, and the authors should consider 
    publishing it elsewhere. Other items that are under consideration for the 
    next version of the draft are error recovery considerations and 
    explanations of resource management issues. It might also be useful to add 
    more detailed message flows.
    The torture test draft provides tests for each UDVM instruction, focuses on 
    boundary and error cases, and covers issues not typically found in 
    well-behaved code but that might be exploited by malicious users. The 
    current version only tests the UDVM, and further tests are needed to test 
    other SigComp entities, such as the state handler and the 
    dispatcher. Richard asked for additional suggestions, but did not get any.
    Finally, Richard announced that SigComp will be tested at the next SIPit 
    event in Stockholm, February 24-28. 
     - SigComp Feedback (Adam Roach)
    Adam gave an overview presentation of the problem addressed by the 
    SigComp NACK and SigComp recovery drafts, as well as the potential 
    solutions proposed. The problem could in general be expressed as "when a 
    SigComp message cannot be decoded by the recipient (for whatever 
    reason), the sender needs to learn of such a failure".  A couple of error 
    scenarios where this would become an issue were also presented.
    Three potential approaches to the problem were then proposed.
    The first solution would be to stay with what we already have in SigComp and 
    use application timeouts or signal by implicit means, by setting the state 
    memory size to zero. This approach requires no additional 
    standardization, but is not very efficient and requires additional 
    messages in the reverse direction and would add delay.  Carsten noted that 
    there has been some experience that timeouts are a problem, and given that we 
    have two drafts might be an indication there is a need to do 
    something. Richard commented that the number of drafts is not 
    necessarily enough to prove there is a problem.  This might be tightly 
    coupled to the actual environment, because one might have different 
    mechanisms available for solving this problem.  Keith Drage noted that this 
    has been discussed also in 3GPP, with the conclusion that it is not a 3GPP 
    specific issue and should thus be handled as part of our SigComp work in 
    ROHC. Richard claimed that at least the original problem statements can be 
    solved by existing SigComp mechanisms. It may be that we need new error 
    codes to recover more quickly, but we need error cases where partial 
    failure will happen. Adam commented that losing partial state in 
    handsets may not be likely, but in 3G architectures compartments might be 
    discarded in servers even if they are still needed. Keith suggested that we 
    should do some documentation, independent of the outcome of these 
    discussions. Richard and Adam argued whether current SigComp would be good 
    enough to solve the problems or not. Carsten noted that some form of 
    diagnostics mechanisms would be a useful addition to SigComp in any case. 
    Lars-Erik then asked the room whether there were any real objections to do 
    work in this area, with no response.  Richard wondered is this assumed 
    additional standardization, to which Carsten responded that this is 
    something we will have to figure out.
    Adam continued with more material on the potential approaches. The second 
    solution would be to add a reset message to reset one or all 
    compartments. This approach is good because it should be easy to 
    implement and provide immediate recovery. On the other hand is it a kind of 
    "sledge hammer" solution, and there might be IPR concerns to consider. It 
    also only works if the recipient can identify the compartment to which the 
    message belongs.
    The third approach is to define specific error messages indicating the 
    cause of failure, allowing the compressor to do fine-grained 
    adjustments. With this approach, error recovery will not be more costly 
    than necessary, various error cases can be handled, and we would also get a 
    debugging and diagnostics mechanism. Disadvantages may be more 
    complicated standardization and implementation, and a need for 
    stand-alone feedback messages. Interesting side effects of this are the 
    possibility to implement an optimistic compression approach, and network 
    diagnostics abilities.
    Adam then presented some performance examples to compare the three 
    different approaches, and that was followed by a long discussion about the 
    error scenarios and the actual motivation for doing work on this. There was 
    no clear outcome, more than that the usefulness for diagnostics might 
    itself be a sufficient motivation. Carsten noted that we will have to come up 
    with specific examples, based on clear assumptions, then we can take a 
    Drafts: draft-roach-sigcomp-nack-00.txt
     - Static Dictionary for SIP/SDP (Carsten Bormann)
    Carsten reported about the SIP/SDP static dictionary status. For version 
    -04, the IETF last-call ended on November 15. There have been some 
    positive signals from the IESG, but no formal approval yet. The problem 
    with this document is that it tries to petrify a snapshot of the SIP/SDP 
    protocol development, and we really need to decide on when is the right 
    time to do this petrification. A version -05 is already available with some 
    minor changes.  Unfortunately, as soon as we tweak anything, the 
    dictionary changes significantly - about half the text of the 
    document. Carsten asked for comments on when to finally freeze this. Adam 
    Roach answered that the best time would have been last March, and now we 
    should freeze it as soon as possible. Zhigang Liu commented that 3GPP 
    would like this by end of this year, which Carsten concluded means as soon as 
    possible, and that is now.
    * ROHC over Wireless Ethernet Media 
     - Motivation and possible approaches (Kris Fleming) 
    Kris Fleming gave a presentation of the motivation for and high level 
    technical content of the "ROHC over Wireless Ethernet Media" draft. WLAN and 
    WPAN links are often bandwidth limited and would therefore benefit from 
    header compression. They have also typical loss and delay patterns that 
    would motivate the use of ROHC in such scenarios. Since voice over IP is and 
    will be commonly used in these networks, header compression will 
    continue to be useful. If a generic solution for applying ROHC in these 
    environments could be defined independent of the physical layer 
    technology, that would simplify both standardization and 
    implementation. Such a generic solution should in that case be defined by 
    the IETF.
    Solutions that have been considered are ROHC over PPP over Ethernet, since 
    both ROHC-over-PPP and PPP-over-Ethernet already exist. The drawbacks of 
    combining these two into a complete solution are the unnecessary 
    overhead, and the unnecessary complexity. The advantage is of course that 
    all components already exist. Another potential approach that has been 
    considered is to reuse an existing protocol for negotiation, but define 
    something new for encapsulation. For IPv6, neighbor discovery could 
    potentially be used for negotiation, but it is not really intended to 
    discover link layer capabilities.
    The proposed "ROHC over WEM" defines a simple negotiation protocol, and an 
    encapsulation. Kris gave a quick overview, and then asked whether there was 
    any interest in doing this in ROHC.
    Carsten commented that a key question is where in the protocol stack it 
    would make sense to do this. In the original ROHC work, Ethernet was 
    completely ignored since adding header compression to it was 
    considered to be of less value, e.g. due to the minimal frame size.  In 
    802.11, the headers are rather large and are sent at a lower rate than the 
    data. The gain from header compression could then be questioned. Greg 
    Daley noted that with Mobile IP we might get lots of tunneling headers, and 
    that would increase the gain from header compression.
     - ROHC over Ethernet issues (Carsten Bormann)
    Carsten had prepared some discussion material on this issue. We have a 
    pretty large design space here, and before we do anything we must 
    explore it so that we know what we are trying to invent.
    First of all, there is the issue about which negotiation protocol to use, if 
    we would have to invent a new one. For IPv6, neighbor discovery (ND) seems to 
    be an obvious choice. For IPv4, one could think of using ARP, but that 
    sounds difficult at this point in the evolution of this protocol. If PPPoE 
    was used, we would get lots of unnecessary things and still have to 
    invent a new encapsulation. One could also potentially think of using ND 
    also for IPv4.
    Secondly, we have the encapsulation issue. Ethernet requires padding, 
    which is neither needed nor desired over the wireless links. If we do 
    compression over the whole Ethernet, bridges between the wired and 
    wireless parts must know about the padding scheme and translate or strip 
    padding. This will easily get complicated. It might make sense to do this in 
    the wireless access points instead, but then we would not get a generic 
    scheme and it would be very unclear whether this would be a ROHC WG 
    A long discussion about the architectural placement of compression in 
    these scenarios followed. Pat Calhoun suggested that this should be done by 
    other bodies, for the links that would really benefit from header 
    compression. Kris argued for doing a general solution and avoid having to do 
    the work over and over again, while others then noticed that link 
    specific solutions would probably give better gain, and we should 
    remember that not all link layers would at all benefit from using 
    compression. Carsten concluded that all comments just indicate that we do 
    not have a clear architectural choice, there are several possible 
    options. It is also very unclear whether this is appropriate work for the 
    IETF and the ROHC WG. We will have to continue these discussions on the 
    mailing list.
    * TCP profile (Ghyslain Pelletier)
    Ghyslain gave a short overview of the changes and next issues for the ROHC 
    TCP profile. With a new editor, the document now looks completely 
    different, although the technical content has not at all changed very 
    much. The structure is now better aligned with 3095, and various 
    redundancies have been removed. The mode concept has also been removed to 
    reflect previous consensus to make modes a pure implicit thing for ROHC 
    TCP. Compression always starts in a unidirectional manner, and switches to a 
    bi-directional operation once a first feedback packet is received. This has 
    simplified the document significantly. States and state transitions have 
    also been clarified.
    The next step will be to define the inner workings of the context 
    replication mechanism. We have an understanding and agreement about the 
    concept, but there are much work left on the details. The goal is to have 
    most of this nailed down in the next version. Remaining issues are then 
    packet formats, and minor details in the compressor and 
    decompressor logic. Carsten asked whether we any quantitative measure on the 
    size of TCP flows that we are optimizing for with context 
    replication. Mark West commented that the requirements are rather short on 
    this, we have just agreed broadly what we mean, but we have not put 
    numbers to it. Carsten noted that we should remember to stop tweaking when 
    the impact is not significant anymore, and Mark agreed that the 
    important gain will probably be from saving IP address overhead.
    * Formal header compression notation issues (Mark West)
    Mark gave an update on the formal notation work, there have just been some 
    minor changes since Yokohama. An alternative way of defining the 
    mappings and a more implementation neutral definition.  The key goal has 
    been to define reversible mappings between the uncompressed and 
    compressed field values. The pseudo-code has been removed because it 
    became too implementation specific. Pre- and post-conditions are now used to 
    capture mapping behavior. Mappings are now composed from other 
    mappings, which makes documentation more compact and new mappings are 
    easier to define. A mapping example was presented.
    The questions raised were mainly the same as last time in Yokohama.  Are we 
    happy with the combined notation, is identification and generation of 
    meta-data part of the "grammar", and is there an issue with the 
    interface to the (unspecified) coding rules? There were no comments from the 
    The way forward would now be to try to define the minimum needed for 
    interoperability, and then figure out how to make use of this for 
    compression of TCP.
    Lars-Erik noted that there has not been much activity on the mailing list, 
    and asked whether there have been any inputs from others. Mark answered 
    that this there have really not been any. Lars-Erik then pointed out that if 
    we do this, it should be good enough so that we do not have to change it 
    every time we apply it. Those who think it is a good idea are 
    therefore encouraged to contribute to the mailing list discussions. 
    Carsten agree that we need a bigger group to work on this draft, so 
    interested people will have to speak up.
    * Summing up (Lars-Erik Jonsson)
    We thus have two new issues that we will have to discuss further, 
    SigComp Feedback/Recovery and ROHC over Wireless Ethernet Media.  We have 
    agreed to do something to the former, while we still do not have enough 
    background material to decide exactly what to do. For the latter issue, we 
    will have to figure out whether it is possible for us to do anything that 
    makes sense and can be justified.
    Thanks for