Re: Errata against ROHC RFCs

Hi Lars,

Is it possible to include an errata as Calle proposed here: http://www.ietf.org/mail-archive/web/rohc/current/msg05960.html
Specifically, "I would like to change the text in 6.6.11 to say 'for each IPv4 header' instead of 'for each IP header'."
That issue has been a great source of confusion for my team, and the suggested change would quell our concerns.
Thank you.

Regards,
Sasha


On Mon, Jan 31, 2011 at 4:21 AM, Lars Eggert <[email protected]> wrote:
> 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 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rohc
>
>