Skip to main content

RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
RFC 4019

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    rohc mailing list <rohc@ietf.org>, 
    rohc chair <rohc-chairs@tools.ietf.org>
Subject: Protocol Action: 'RObust Header Compression 
         (ROHC):Profiles for UDP-Lite' to Proposed Standard 

The IESG has approved the following document:

- 'RObust Header Compression (ROHC):Profiles for UDP-Lite '
   <draft-ietf-rohc-udp-lite-05.txt> as a Proposed Standard

This document is the product of the Robust Header Compression Working 
Group. 

The IESG contact persons are Allison Mankin and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-05.txt

Ballot Text

Technical Summary
 
   This document defines ROHC (Robust Header Compression) profiles for
   compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol,
   User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP.
   These profiles are defined based on their differences with the
   profiles for UDP specified in RFC 3095.  Compressing the use of UDP-Lite
   is valuable because the applications which desire partial checksum  
  coverage often also use links where compression is important.
 
Working Group Summary
 
   The working group supported these profiles strongly.  There was a careful
    discussion of the reasons that the UDP-Lite checksum value may not be
    compressed. 
 
Protocol Quality
 
   Prototype implementations of the specification were reported.  Allison Mankin
   reviewed the specification for the IESG.

RFC Editor Notes:

Section 1
The reference number for UDP-Lite is incorrect.
OLD:
UDP-Lite [1]
New:
UDP-Lite [4]

Also, update [4] to RFC 3828
---------
Section 7
The IANA instructions should be left in the
publication, as useful information on the intended
structure of the registry.
---------
Section 5.6
OLD:
   Upon receiving the Mode parameter set to '0', the decompressor MUST
   stay in its current mode of operation and SHOULD refrain from sending
   further mode transition requests for the declined mode for a certain
   amount of time.
NEW:
   Upon receiving the Mode parameter set to '0', the decompressor MUST
   stay in its current mode of operation and SHOULD refrain from sending
   further mode transition requests for the declined mode.

RFC Editor Note