From rohc_team@dialine.fr Mon Feb 27 08:03:01 2012 Return-Path: X-Original-To: rohc@ietfa.amsl.com Delivered-To: rohc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33E21F87AF for ; Mon, 27 Feb 2012 08:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXvquUev7MLK for ; Mon, 27 Feb 2012 08:03:00 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) by ietfa.amsl.com (Postfix) with ESMTP id 53F9321F87AE for ; Mon, 27 Feb 2012 08:02:58 -0800 (PST) Received: from [127.0.0.1] (unknown [88.185.172.218]) by smtp6-g21.free.fr (Postfix) with ESMTP id B4B3582346 for ; Mon, 27 Feb 2012 17:02:51 +0100 (CET) Message-ID: <4F4BA931.8000203@dialine.fr> Date: Mon, 27 Feb 2012 17:02:57 +0100 From: RoHC Team User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120227-0, 27/02/2012), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Mon, 05 Mar 2012 00:27:15 -0800 Subject: [rohc] RFC4996 IP-ID with co_common and Random behavior X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rohc_team@dialine.fr List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 20:51:50 -0000 Hello everybody, We are coding the RFC4996 and we don't understand how to send the value of the IPv4 IP-ID field, using the co_common compressed format, when the IP-ID has a random behavior. With the co_common format, there are : ip_id_indicator ip_id_behavior and ip_id =:= optional_ip_id_lsb( ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) with : optional_ip_id_lsb(behavior, indicator) { UNCOMPRESSED { ip_id [ 16 ]; } COMPRESSED short { ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); ENFORCE(indicator == 0); } COMPRESSED long { ip_id =:= irregular(16) [ 16 ]; ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); ENFORCE(indicator == 1); } COMPRESSED not_present { ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || (behavior == IP_ID_BEHAVIOR_ZERO)); } } So, if ip_id_behavior is RANDOM, ip_id is not compressed (not present) ! And we can't send the value ... Why not ip_id =:= irregular(16) [ 16 ]; when behavior is RANDOM ? There is a contradiction with the paragraph 8.1 page 44/45 saying : All of the compressed base headers transmit LSB-encoded MSN bits, the TCP Push flag, and a CRC, and in addition to this, all the base headers in the sequential packet format set contain LSB-encoded IP-ID bits. o Common header format: The common header format can be used for all kinds of IP-ID behavior and should be useful when some of the more rarely changing fields in the IP or TCP header change. Since this header format can update control fields that decide how the decompressor interprets packets, it carries a 7-bit CRC to reduce the probability of context corruption. This header can basically convey changes to any of the dynamic fields in the IP and TCP headers, and it uses a large set of flags to provide information about which fields are present in the header format. Thanks for help, Best regards FWX. From carl.knutsson@effnet.com Mon Mar 5 00:39:15 2012 Return-Path: X-Original-To: rohc@ietfa.amsl.com Delivered-To: rohc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC6921F85C3 for ; Mon, 5 Mar 2012 00:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f9MxoJ3OC0I for ; Mon, 5 Mar 2012 00:39:15 -0800 (PST) Received: from lists.levonline.com (lists.levonline.com [217.70.33.37]) by ietfa.amsl.com (Postfix) with ESMTP id DA37D21F85BD for ; Mon, 5 Mar 2012 00:39:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by lists.levonline.com (Postfix) with ESMTP id 8FAB7268151 for ; Mon, 5 Mar 2012 09:39:13 +0100 (CET) Received: from lists.levonline.com ([127.0.0.1]) by localhost (lists.levonline.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGZm0HgJqjm6 for ; Mon, 5 Mar 2012 09:39:12 +0100 (CET) Received: from traktor2.skognet.levonline.com (webhotel.fordon.levonline.com [217.70.32.2]) by lists.levonline.com (Postfix) with ESMTP id C12CB2680E3; Mon, 5 Mar 2012 09:39:12 +0100 (CET) Received: from [192.168.101.21] (c-7e0371d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.3.126]) (authenticated bits=0) by traktor2.skognet.levonline.com (8.13.8/8.13.8) with ESMTP id q258dEDk001447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 09:39:15 +0100 Message-ID: <4F547BAA.6080909@effnet.com> Date: Mon, 05 Mar 2012 09:39:06 +0100 From: Carl Knutsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rohc_team@dialine.fr References: <4F4BA931.8000203@dialine.fr> In-Reply-To: <4F4BA931.8000203@dialine.fr> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org Subject: Re: [rohc] RFC4996 IP-ID with co_common and Random behavior X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 08:39:15 -0000 Hi, Comment inline. Cheers /Calle On 02/27/2012 05:02 PM, RoHC Team wrote: > Hello everybody, > > We are coding the RFC4996 and we don't understand how to send the value > of the IPv4 IP-ID field, using the co_common compressed format, when the > IP-ID has a random behavior. > > With the co_common format, there are : > ip_id_indicator > ip_id_behavior > and ip_id =:= optional_ip_id_lsb( ip_id_behavior.UVALUE, > ip_id_indicator.CVALUE) > > with : > > optional_ip_id_lsb(behavior, indicator) > { > UNCOMPRESSED { > ip_id [ 16 ]; > } > > COMPRESSED short { > ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; > ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || > (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); > ENFORCE(indicator == 0); > } > > COMPRESSED long { > ip_id =:= irregular(16) [ 16 ]; > ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || > (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); > ENFORCE(indicator == 1); > } > > COMPRESSED not_present { > ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || > (behavior == IP_ID_BEHAVIOR_ZERO)); > } > } > > > > So, if ip_id_behavior is RANDOM, ip_id is not compressed (not present) > ! And we can't send the value ... > > Why not ip_id =:= irregular(16) [ 16 ]; when behavior is RANDOM ? > The FN is correct. IP-ID is sent in the irregular chain. > > > There is a contradiction with the paragraph 8.1 page 44/45 saying : > > All of the compressed base headers transmit LSB-encoded MSN bits, the > TCP Push flag, and a CRC, and in addition to this, all the base > headers in the sequential packet format set contain LSB-encoded IP-ID > bits. > > o Common header format: The common header format can be used for all > kinds of IP-ID behavior and should be useful when some of the more > rarely changing fields in the IP or TCP header change. Since this > header format can update control fields that decide how the > decompressor interprets packets, it carries a 7-bit CRC to reduce > the probability of context corruption. This header can basically > convey changes to any of the dynamic fields in the IP and TCP > headers, and it uses a large set of flags to provide information > about which fields are present in the header format. > I can't find any contradiction. Please be more specific. From rohc_team@dialine.fr Mon Mar 5 01:59:09 2012 Return-Path: X-Original-To: rohc@ietfa.amsl.com Delivered-To: rohc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1C21F871E for ; Mon, 5 Mar 2012 01:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKgA3I93CnhP for ; Mon, 5 Mar 2012 01:59:08 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99021F8717 for ; Mon, 5 Mar 2012 01:59:05 -0800 (PST) Received: from [127.0.0.1] (unknown [88.185.172.218]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1BBE282370; Mon, 5 Mar 2012 10:58:57 +0100 (CET) Message-ID: <4F548E67.5060402@dialine.fr> Date: Mon, 05 Mar 2012 10:59:03 +0100 From: RoHC Team User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Carl Knutsson References: <4F4BA931.8000203@dialine.fr> <4F547BAA.6080909@effnet.com> In-Reply-To: <4F547BAA.6080909@effnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120304-1, 04/03/2012), Outbound message X-Antivirus-Status: Clean Cc: rohc@ietf.org Subject: Re: [rohc] RFC4996 IP-ID with co_common and Random behavior X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rohc_team@dialine.fr List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:59:09 -0000 Hello Carl, When using co_common compressed packet format, described page 80 of the RFC, ip_id is optionaly sent with the optional_ip_id_lsb{} method. Ok. But when the IP-ID behavior is random, the value is not present in the header : COMPRESSED not_present { ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || (behavior == IP_ID_BEHAVIOR_ZERO)); } So I don't understand how to send IP-ID random value ... Perhaps you think of the ipv4_innermost_irregular{} method, page 63, but I don't understand how to use this method and the compressed format co_common{} ... And I don't have any samples or reference captures file : only the RFC text! Thank you for your help and explanation. Best regards, FWX. Le 05/03/2012 09:39, Carl Knutsson a écrit : > Hi, > > Comment inline. > > Cheers > > /Calle > > On 02/27/2012 05:02 PM, RoHC Team wrote: >> Hello everybody, >> >> We are coding the RFC4996 and we don't understand how to send the value >> of the IPv4 IP-ID field, using the co_common compressed format, when the >> IP-ID has a random behavior. >> >> With the co_common format, there are : >> ip_id_indicator >> ip_id_behavior >> and ip_id =:= optional_ip_id_lsb( ip_id_behavior.UVALUE, >> ip_id_indicator.CVALUE) >> >> with : >> >> optional_ip_id_lsb(behavior, indicator) >> { >> UNCOMPRESSED { >> ip_id [ 16 ]; >> } >> >> COMPRESSED short { >> ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; >> ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || >> (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); >> ENFORCE(indicator == 0); >> } >> >> COMPRESSED long { >> ip_id =:= irregular(16) [ 16 ]; >> ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || >> (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); >> ENFORCE(indicator == 1); >> } >> >> COMPRESSED not_present { >> ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || >> (behavior == IP_ID_BEHAVIOR_ZERO)); >> } >> } >> >> >> >> So, if ip_id_behavior is RANDOM, ip_id is not compressed (not present) >> ! And we can't send the value ... >> >> Why not ip_id =:= irregular(16) [ 16 ]; when behavior is RANDOM ? >> > > The FN is correct. IP-ID is sent in the irregular chain. > >> >> >> There is a contradiction with the paragraph 8.1 page 44/45 saying : >> >> All of the compressed base headers transmit LSB-encoded MSN bits, the >> TCP Push flag, and a CRC, and in addition to this, all the base >> headers in the sequential packet format set contain LSB-encoded IP-ID >> bits. >> >> o Common header format: The common header format can be used for all >> kinds of IP-ID behavior and should be useful when some of the more >> rarely changing fields in the IP or TCP header change. Since this >> header format can update control fields that decide how the >> decompressor interprets packets, it carries a 7-bit CRC to reduce >> the probability of context corruption. This header can basically >> convey changes to any of the dynamic fields in the IP and TCP >> headers, and it uses a large set of flags to provide information >> about which fields are present in the header format. >> > > I can't find any contradiction. Please be more specific. > > > From raffles@gluft.com Mon Mar 5 15:02:30 2012 Return-Path: X-Original-To: rohc@ietfa.amsl.com Delivered-To: rohc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDC21E8015 for ; Mon, 5 Mar 2012 15:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhM4jx9rcQZF for ; Mon, 5 Mar 2012 15:02:29 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 251AC21E8011 for ; Mon, 5 Mar 2012 15:02:29 -0800 (PST) Received: from [192.168.1.66] (93-97-78-217.zone5.bethere.co.uk [93.97.78.217]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MBjiJ-1SCh9A48H9-00AtQj; Tue, 06 Mar 2012 00:02:28 +0100 Message-ID: <4F5545FD.1020203@gluft.com> Date: Mon, 05 Mar 2012 23:02:21 +0000 From: Raffles User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rohc@ietf.org References: <4F4BA931.8000203@dialine.fr> <4F547BAA.6080909@effnet.com> <4F548E67.5060402@dialine.fr> In-Reply-To: <4F548E67.5060402@dialine.fr> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:SpiH2tt9W7zcj/MNNMX0nwkUBehg3P5wJRgmfCjNxhQ yif+0IsYK4nEwBHiwHPPpl5ulGr6vg2geyLsiNvpRQgrg2y12U IBqPckk8lGbMqYoXSzP0ZCDWP0XeKiy/mG2dHauqN8g1UBxmEt CPtp0i63NsdBZBbZYPHtRm3X6dFoKTvH+MS6kie2S4gUvUMg8E 811BxjvE6JzDxNgv6a064984ohqAUvia9P2+rQ6vsyZirhSo1G ywZ4OX36qdNFK7VYex4wu2gRLWhrTMYZLvkTbfOS9L+S37jN9x m+zk6ZSta2e4NX/n04nXAT8mxURaIoO6Sw9Im9aV1E7eLGcITJ SQcoXmh/CwsGoztUKe4c= Subject: Re: [rohc] RFC4996 IP-ID with co_common and Random behavior X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:02:30 -0000 Hello,

It looks like you are looking at the optional_ip_id_lsb encoding method on page 76. This encoding method is only used in the co_common compressed format (page 80), which I believe is what you are concerned with. In the optional_ip_id_lsb encoding method, the compressed ip_id has no bindings in the "not_present" case. That is, the not_present format leaves the ip_id to be defined elsewhere - it does not define it as absent (i.e. zero bits compressed length), which is, I suspect, how you may have interpreted the FN.

The English name for the format I think has misled you here. Remember that the header is defined in multiple chains (section 6.2 on page 21). I haven't looked but I assume the "not_present" format name is referring to the fact that the ip_id is not present in this chain. The ip_id must be defined in a different chain in this case. If it was not defined anywhere then the spec would be in error.

Caveat I am not that familiar with RFC 4996 so I may have misunderstood, but this is how the FN looks to me.

I hope this helps

Regards

R@ffles

On 05/03/2012 09:59, RoHC Team wrote:
 Hello Carl,

 When using co_common compressed packet format, described page 80 of the RFC, ip_id is optionaly sent with the optional_ip_id_lsb{} method. Ok.

 But when the IP-ID behavior is random, the value is not present in the header :

     COMPRESSED not_present {
       ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
               (behavior == IP_ID_BEHAVIOR_ZERO));
     }

 So I don't understand how to send IP-ID random value ...

 Perhaps you think of the ipv4_innermost_irregular{} method, page 63, but I don't understand how to use this method and the compressed format co_common{} ...

 And I don't have any samples or reference captures file : only the RFC text!

 Thank you for your help and explanation.

 Best regards,

              FWX.

Le 05/03/2012 09:39, Carl Knutsson a écrit :
Hi,

Comment inline.

Cheers

/Calle

On 02/27/2012 05:02 PM, RoHC Team wrote:
  Hello everybody,

  We are coding the RFC4996 and we don't understand how to send the value
of the IPv4 IP-ID field, using the co_common compressed format, when the
IP-ID has a random behavior.

  With the co_common format, there are :
  ip_id_indicator
  ip_id_behavior
  and ip_id =:= optional_ip_id_lsb( ip_id_behavior.UVALUE,
                                    ip_id_indicator.CVALUE)

  with :

optional_ip_id_lsb(behavior, indicator)
  {
    UNCOMPRESSED {
      ip_id [ 16 ];
    }

    COMPRESSED short {
      ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
      ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
              (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
      ENFORCE(indicator == 0);
    }

    COMPRESSED long {
      ip_id =:= irregular(16)  [ 16 ];
      ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
              (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
      ENFORCE(indicator == 1);
    }

    COMPRESSED not_present {
      ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
              (behavior == IP_ID_BEHAVIOR_ZERO));
    }
  }



  So, if ip_id_behavior is RANDOM, ip_id is not compressed (not present)
! And we can't send the value ...

  Why not ip_id =:= irregular(16)  [ 16 ]; when behavior is RANDOM ?


The FN is correct. IP-ID is sent in the irregular chain.



  There is a contradiction with the paragraph 8.1 page 44/45 saying :

    All of the compressed base headers transmit LSB-encoded MSN bits, the
    TCP Push flag, and a CRC, and in addition to this, all the base
    headers in the sequential packet format set contain LSB-encoded IP-ID
    bits.

   o  Common header format: The common header format can be used for all
       kinds of IP-ID behavior and should be useful when some of the more
       rarely changing fields in the IP or TCP header change.  Since this
       header format can update control fields that decide how the
       decompressor interprets packets, it carries a 7-bit CRC to reduce
       the probability of context corruption.  This header can basically
       convey changes to any of the dynamic fields in the IP and TCP
       headers, and it uses a large set of flags to provide information
       about which fields are present in the header format.


I can't find any contradiction. Please be more specific.



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


-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: raffles@gluft.com
w: gluft.com

         O                  O
 OOOOOO  O  O    O OOOOOO OOOOO
 O    O  O  O    O OOOOO    O
 OOOOOO  O  OOOOOO O        O
 OOOOOO
      we  care  about  software

-----------------------------------------------------------------
Gluft Ltd. Registered No.: 6795336      VAT No.: 974 2755 83
The information contained in this e-mail and any attachments is
proprietary to Gluft Ltd and must not be passed to any third
party without permission. This communication is for information
only and shall not create or change any contractual relationship.

Please consider the environment before printing. Thank you.
-----------------------------------------------------------------
From kristofer.sandlund@ericsson.com Thu Mar 15 08:34:02 2012 Return-Path: X-Original-To: rohc@ietfa.amsl.com Delivered-To: rohc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9761121F8554 for ; Thu, 15 Mar 2012 08:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cetQ+17kIwjL for ; Thu, 15 Mar 2012 08:34:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DEEC621F854D for ; Thu, 15 Mar 2012 08:34:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-f3-4f620be8d1a4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 88.E1.17856.8EB026F4; Thu, 15 Mar 2012 16:34:01 +0100 (CET) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.209]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 15 Mar 2012 16:34:00 +0100 From: Kristofer Sandlund To: "rohc@ietf.org" Date: Thu, 15 Mar 2012 16:33:59 +0100 Thread-Topic: FYI: Update to RFC4996 available Thread-Index: Ac0CwQrCtC9UfNLHQyCM+fwfa+nc9w== Message-ID: <61D017C9E2225D4A974A141907F3CD104A835AC600@ESESSCMS0361.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rohc] FYI: Update to RFC4996 available X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:34:02 -0000 Hi, for those who still read this list, we've made a draft for RFC4996bis, which is being run as an AD-sponsored individual submission. This will obsolete RFC4996 (ROHC-TCP). The draft can be found here: http://www.ietf.org/internet-drafts/draft-sandlund-rfc4996bis-00.txt I don't expect to make any further revisions of this draft. Read the new section 9 for a list of changes and motivations on why we needed an update to this draft. I recommend those that have implementations of RFC4996 to update according to this draft. BR, Kristofer