From wes@mti-systems.com Mon Sep 3 21:03:42 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 A6BBF21F85F0 for ; Mon, 3 Sep 2012 21:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfBJFwb7KLcY for ; Mon, 3 Sep 2012 21:03:40 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1862721F85E6 for ; Mon, 3 Sep 2012 21:03:40 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.14.4/8.14.4) with ESMTP id q8443dNf026375 for ; Tue, 4 Sep 2012 00:03:39 -0400 Authentication-Results: cm-omr10 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.209] ([69.81.143.209:12448] helo=[192.168.1.115]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id ED/1E-08814-B9D75405; Tue, 04 Sep 2012 00:03:39 -0400 Message-ID: <50457D91.80907@mti-systems.com> Date: Tue, 04 Sep 2012 00:03:29 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: rohc@ietf.org References: <50305E66.5000307@mti-systems.com> In-Reply-To: <50305E66.5000307@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Russ Housley Subject: Re: [rohc] RFC4996bis 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: Tue, 04 Sep 2012 04:03:42 -0000 We haven't seen any responses to this query. This is a reminder nudge in case people have been on vacation, or otherwise slow to respond. Currently, this question is the only thing holding the 4996bis document up, so feedback would be appreciated! On 8/18/2012 11:32 PM, Wesley Eddy wrote: > As you may be aware, the authors of RFC 4996 have been working > on an update that's currently held up in the IESG Review based > on the following DISCUSS comment from Russ: > > """ > The issue below is the same as the one raised in the Gen-ART Review > by Joel Halpern on 16-July-2012. > > Section 5.2.2.2 on negative acknowledgments includes the following: > > > > ... unless it has confidence that information sent after the packet > > being acknowledged already provides a suitable response ... > > > This deals with a specific response to the NACK, it is unclear what > constitutes confidence. Other places in this document that refer to > gaining confidence provide specific descriptions of how it is gained. > The primary methods for gaining confidence are receiving acks or > sufficient transmissions. If all that is meant here is sufficient > transmissions, please say so. > """ > > There seems to be disagreement about whether additional text > would be useful in this regard. > > We'd like to hear from people on this ROHC mailing list who > either have implemented or might implement this specification > as to whether or not more clarity is needed here, or if it's > really not useful or a good idea to add such text. > -- Wes Eddy MTI Systems From klaus.warnke@acticom.de Tue Sep 4 03:48:18 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 DF94321F85ED for ; Tue, 4 Sep 2012 03:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QdjF+ex75hz for ; Tue, 4 Sep 2012 03:48:18 -0700 (PDT) Received: from mail.acticom-networks.com (mail.acticom-networks.com [87.106.254.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0B12E21F85E6 for ; Tue, 4 Sep 2012 03:48:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.acticom-networks.com (Postfix) with ESMTP id 221881C00F54 for ; Tue, 4 Sep 2012 12:48:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at acticom-networks.com Received: from mail.acticom-networks.com ([127.0.0.1]) by localhost (mail.acticom-networks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+2rlIGFp-BX for ; Tue, 4 Sep 2012 12:48:15 +0200 (CEST) Received: from godfather.bln.acticom.de (backupsrv [87.139.237.181]) by mail.acticom-networks.com (Postfix) with ESMTP id 559781C00F4B for ; Tue, 4 Sep 2012 12:48:15 +0200 (CEST) Received: from [192.168.33.27] (tornado.bln.acticom.de [192.168.33.27]) by godfather.bln.acticom.de (Postfix) with ESMTP id EABD4F3AD0 for ; Tue, 4 Sep 2012 12:48:14 +0200 (CEST) Message-ID: <5045DC6E.3050302@acticom.de> Date: Tue, 04 Sep 2012 12:48:14 +0200 From: Klaus Warnke User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "rohc@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [rohc] RFC5225 IP-ID with co_common and Random behavior and tos_tc changes 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: Tue, 04 Sep 2012 10:48:19 -0000 Hello everybody, if the ip-id has a random behavior, it is sent in the irregular chain as defined in ipv4() encoding method and ipv4_innermost_irregular format. This encoding method has a DEFAULT section, which also defines that tos_tc is encoded static (and other). If I understand den ROHC FN right, the format ipv4_innermost_irregular could not be used, if the tos_tc could not encoded by the static encoding method. But then I can not use co_common format to transmit tos_tc changes, because the ip_id is not included in co_common if the behavior is random. Is this correct? Regards, Klaus -- Klaus Warnke klaus.warnke@acticom.de http://www.acticom.de Tel +49-30-4849.6891 acticom GmbH Schwedter Str. 9b, 10119 Berlin, Germany Managing Directors: Olaf Kehrer, Gerrit Schulte Commercial Register: Berlin-Charlottenburg HRB 73245 VAT-ID DE205131766 From klaus.warnke@acticom.de Tue Sep 4 03:56:06 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 C602021F862A for ; Tue, 4 Sep 2012 03:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwRgqpwq+7xy for ; Tue, 4 Sep 2012 03:56:06 -0700 (PDT) Received: from mail.acticom-networks.com (mail.acticom-networks.com [87.106.254.214]) by ietfa.amsl.com (Postfix) with ESMTP id 352E521F8554 for ; Tue, 4 Sep 2012 03:56:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.acticom-networks.com (Postfix) with ESMTP id 5C7C91C00F54 for ; Tue, 4 Sep 2012 12:56:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at acticom-networks.com Received: from mail.acticom-networks.com ([127.0.0.1]) by localhost (mail.acticom-networks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZTVokguCpAq for ; Tue, 4 Sep 2012 12:56:04 +0200 (CEST) Received: from godfather.bln.acticom.de (backupsrv [87.139.237.181]) by mail.acticom-networks.com (Postfix) with ESMTP id 45CFE1C00F4B for ; Tue, 4 Sep 2012 12:56:04 +0200 (CEST) Received: from [192.168.33.27] (tornado.bln.acticom.de [192.168.33.27]) by godfather.bln.acticom.de (Postfix) with ESMTP id 93E87F3AD0 for ; Tue, 4 Sep 2012 12:56:03 +0200 (CEST) Message-ID: <5045DE43.70705@acticom.de> Date: Tue, 04 Sep 2012 12:56:03 +0200 From: Klaus Warnke User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "rohc@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [rohc] rfc5225 msn_lsb improvement 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: Tue, 04 Sep 2012 10:56:06 -0000 Hello everybody, I think, the msn_lsb() encoding method could be improved: msn_lsb(k) { ... COMPRESSED none { ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE); master =:= lsb(k, 1); } ... } For reorder ratio REORDERING_NONE the master =:= lsb(k, -1); is sufficient. That is, offset_param = -1, If there is no reordering, there is no need to have a lower bound -1 before the ref_value. If the msn increase by +1, the lower bound could be ref_value +1. See also rfc3095: a) For field values that are expected always to increase, p can be set to -1. The interpretation interval becomes [v_ref + 1, v_ref + 2^k]. Any comments? Regards, Klaus -- Klaus Warnke klaus.warnke@acticom.de http://www.acticom.de Tel +49-30-4849.6891 acticom GmbH Schwedter Str. 9b, 10119 Berlin, Germany Managing Directors: Olaf Kehrer, Gerrit Schulte Commercial Register: Berlin-Charlottenburg HRB 73245 VAT-ID DE205131766