[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.