From wes@mti-systems.com Sat Aug 18 20:33:08 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 77F1F21F8468 for ; Sat, 18 Aug 2012 20:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 sLQ2ucYm6fqD for ; Sat, 18 Aug 2012 20:33:03 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 216CF21F845C for ; Sat, 18 Aug 2012 20:33:03 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7J3X1H1019834 for ; Sat, 18 Aug 2012 23:33:01 -0400 Authentication-Results: cm-omr5 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:38643] helo=[192.168.1.115]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F3/86-08981-D6E50305; Sat, 18 Aug 2012 23:33:01 -0400 Message-ID: <50305E66.5000307@mti-systems.com> Date: Sat, 18 Aug 2012 23:32:54 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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: Sun, 19 Aug 2012 03:33:08 -0000 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 wwwrun@rfc-editor.org Thu Aug 16 01:03:21 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 BC35021F8600 for ; Thu, 16 Aug 2012 01:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 nzyt2tx2LBDr for ; Thu, 16 Aug 2012 01:03:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4711F21F859F for ; Thu, 16 Aug 2012 01:03:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AB0DDB1E002; Thu, 16 Aug 2012 01:01:44 -0700 (PDT) To: ertekin_emre@bah.com, christou_chris@bah.com, ro@breakcheck.com, kivinen@iki.fi, cabo@tzi.org, wes@mti-systems.com, martin.stiemerling@neclab.eu, carl.knutsson@effnet.com From: RFC Errata System Message-Id: <20120816080145.AB0DDB1E002@rfc-editor.org> Date: Thu, 16 Aug 2012 01:01:44 -0700 (PDT) X-Mailman-Approved-At: Sun, 19 Aug 2012 10:28:18 -0700 Cc: rohc@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org Subject: [rohc] [Editorial Errata Reported] RFC5857 (3320) 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, 16 Aug 2012 08:03:21 -0000 The following errata report has been submitted for RFC5857, "IKEv2 Extensions to Support Robust Header Compression over IPsec". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5857&eid=3320 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.1.2 Original Text ------------- This section describes five ROHC Attribute Types: MAX_CID, ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU. The value allocated for each ROHC Attribute Type is specified in Section 4. Corrected Text -------------- This section describes five ROHC Attribute Types: MAX_CID, ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU. The value allocated for each ROHC Attribute Type is specified in Section 5. Notes ----- Section 4 of RFC 5857 is "Security Considerations". Values of ROHC Attribute Types listed in Section 5. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5857 (draft-ietf-rohc-ikev2-extensions-hcoipsec-12) -------------------------------------- Title : IKEv2 Extensions to Support Robust Header Compression over IPsec Publication Date : May 2010 Author(s) : E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann Category : PROPOSED STANDARD Source : Robust Header Compression Area : Transport Stream : IETF Verifying Party : IESG