[rohc] Errata against ROHC RFCs
Lars Eggert <lars.eggert@nokia.com> Mon, 31 January 2011 12:18 UTC
Return-Path: <lars.eggert@nokia.com>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768AA3A6BEC for <rohc@core3.amsl.com>; Mon, 31 Jan 2011 04:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.781
X-Spam-Level:
X-Spam-Status: No, score=-103.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBcoEfQco3rs for <rohc@core3.amsl.com>; Mon, 31 Jan 2011 04:18:50 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 8E1F33A6938 for <rohc@ietf.org>; Mon, 31 Jan 2011 04:18:50 -0800 (PST)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0VCM2J0032692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 14:22:03 +0200
From: Lars Eggert <lars.eggert@nokia.com>
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com
Content-Type: multipart/signed; boundary="Apple-Mail-8-341733932"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Mon, 31 Jan 2011 14:21:53 +0200
Message-Id: <8BFE2075-5B98-4B58-B66D-0A8F3B9C70DA@nokia.com>
To: rohc@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 31 Jan 2011 14:21:59 +0200 (EET)
X-Nokia-AV: Clean
Cc: David Harrington <ietfdbh@comcast.net>
Subject: [rohc] Errata against ROHC RFCs
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2011 12:18:51 -0000
Hi, several errata have been submitted against ROHC RFCs: http://www.rfc-editor.org/errata_search.php?rec_status=2&area_acronym=tsv&wg_acronym=rohc&presentation=table The TSV ADs would like to enlist the help of the RFC authors and the broader ROHC community in order to determine how to process these, i.e., which should be "verified", "held" or "rejected". Please discuss these errata on this list. Lars PS: IESG guidelines on errata handling: In order to help you determine the correct handling for the errata in step (4), the IESG has come up with a few guidelines: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. 3. Errata on obsolete RFCs should be treated the same as errata on RFCs that are not obsolete where there is strong evidence that some people are still making use of the related technology. 4. Trivial grammar corrections should be Hold for Document Update. 5. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update. 6. Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. 7. Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Rejected.
- [rohc] Errata against ROHC RFCs Lars Eggert
- Re: [rohc] Errata against ROHC RFCs Carsten Bormann
- Re: [rohc] Errata against ROHC RFCs Lars Eggert
- Re: [rohc] Errata against ROHC RFCs rstangarone-ietf
- Re: [rohc] Errata against ROHC RFCs Carl Knutsson
- Re: [rohc] Errata against ROHC RFCs Koruga, Sasha M CTR SPAWARSYSCEN-PACIFIC, 58110
- Re: [rohc] Errata against ROHC RFCs Lars Eggert
- Re: [rohc] Errata against ROHC RFCs Carsten Bormann
- Re: [rohc] Errata against ROHC RFCs Carl Knutsson