Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
draft-ietf-ipngwg-icmp-v3-07

----- New comment

I've cleared my Discuss.  The document addressed my concern.  But it did so some
time back and the shepherding was by the editor and the correspondence was
lost.  The chairs should consider close shepherding rather than expecting the Discussing
ADs to keep documents not in their area in detailed context over many months.

----- Old comment below - still concerned, but given up on...

It's unusual to have a document recycle at Draft Standard.  The list of changes since
2460 includes testable aspects; just to pick from their list: find the embedded invoking
packet even when the type is not recognized and handle the new Time Exceeded
Code 1.   This is the result of a no effort in looking.  I'd be interested to hear that it was 
evident there are multiple implementations, and the consideration was made that 
an updated implementation report was not needed.

Nit: The IANA considerations cite [RFC 3667] but it isn't
in the references, and anyway it's replaced by 3978.

Editorial comments from Elwyn Davies:

This seems to have fixed all my comments, however the removal of the error message format from s2.1 (which was more than I suggested) has left the last paragraph of 2.1 looking very exposed - it is strictly not needed here anymore..  I would suggest either deleteing it altogether or  adding most of the text to the end of 2.4(c), viz.

  This is intended
  to allow the originator of a packet that has resulted in an ICMPv6
  error message to identify the upper-layer protocol and process that
  sent the packet.

ARGHH!
I just realised that the paragraph (3rd from the end) in s2.1 starting 'Type value 255' which talks about future expansion should be talking about type values 255 and 127 now. Thus
s/Type value 255 is/Type values 127 and 255 are/
s/type equals 255/type equals 127 or 255/

Editorial nits:
s1: s/chieve/achieve/