Draft: draft-bonica-internet-icmp-14 Reviewer: Chisholm, Sharon Review Date: Thursday 1/18/2007 2:27 PM CST IETF LC Date: 1/19/2007 Summary: This document is on the right track, but there are open issues that should be resolved before publishing Comments --------- 1. I don't see why more care wasn't taken to ensure interoperability with existing ICMP specifications and implementations. 1.1 Section 5 should really define three classes of applications - (legacy) support non-extended - (legacy support non-extended and non-compatible extensions - (new) support non-extended, non-compatible extensions and compatible extensions It should list how a consumer can tell the messages apart and what implementers can do to maximize interoperability. 1.2 Each of the sections in section 5 should be more clear as to whether or not backwards compatibility (interoperability) is guaranteed, possible or not possible. It reads more like the results of a lab experiment then requirements against implementations. Reading between the lines it seems like section 5.1 can't guarantee compatibility but it is likely unless implementers do some of the things noted. Similarly for 5.2. 5.3 seems a bit more promising. 1.3 Section 5.5 should make it mandatory to "include a non-default operation mode to also interpret non-compliant responses." Nits ----- 1. Shouldn't the title of the document be more along the lines of "Extended ICMP to Support Multi-part Messages" or "Modified ICMP to Support Multi-part Messages" 2. In section 2, last paragraph, last sentence, it says "whenever a packet is dropped to to TTL expiration." 3. In section 3, it says "The following is a summary of changes to ICMP that are proposed by this memo:", but that should likely now read "introduced by this memo". 4. Section 4 lists all the ICMP messages and says that "Many ICMP messages are extensible as currently defined" but doesn't say which are which. This information is given in section 4.6. It would seem cleaner if these were combined into a single section. 5. Section 4, after the bullets, the first paragraph starts with "Many ICMP messages are extensible as currently defined" while the second paragraph starts with "Many ICMP messages are not extensible as currently defined" which is awkward. I would suggest replacing one or the other with "Some" or "Many other" or something to indicate which is the more common or be more neutral. They both can't be many. 6. In section 4, on page 7, about half way down, it says "Because the sixth octet of each of the impacted ICMPv4 messages was reserved for future use" which explains how we can just start using these bits. This explanation should come earlier in the document. 7. In section 4.6, last paragraph, it raises a requirement against future ICMP extensions which seems a bit too buried in the document. 8. In section 5, third paragraph is says "Some ICMP implementations, produced between 1999 and the present," but the present is a moving target. Suggest specific date or say "time of publication of this memo". 9. In section 5.1, first paragraph, last sentence it says "To date, only two applications falling into this category have been identified and the degree to which they are effected is minimal." Is this saying they mostly behaved as expected as defined in the ICMP documents? The phrase is way too loose. Similarly the next paragraph talks about minimal impact. 10. In section 5.2, fifth paragraph, it says "parse an ICMPv4 message incorrectly " which is a bit ambiguous. Do we mean tradition ICMPv4 messages or the ones defined in this memo or for this use case do they look the same? 11. In section 5.2, fifth paragraph, the bullets list three conditions under which the message won't get parsed properly, two of which don't seem to apply to the use case of 'Non-compliant Application Receives ICMP Message With No Extensions' 12. In section 5.2, last paragraph is says "A similar analysis can be performed for ICMPv6. However, the numeric constants would change as appropriate." This should really read about the expectation on achieving backwards compatibility (interoperability), not the expectation on lab results. 13. In section 5.3, second paragraph it says "Provided that the entire ICMP messages does not exceed." That should be "message" 14. In section 5.3, second paragraph is says "However, each vendor will decide how many octets to include." That should say "However, each implementation will decide how many octets to include." 15. Section 5.3 should be written in the context of how to achieve interoperability/backwards compatibility. 17. In section 5.5, last paragraph it says "will treat the following octets" but I think that should be "will treat the octets that follow" to not confuse it with document text indicating that the list will be outlined below in the RFC. 18. In section 6, first paragraph, last sentence says "by the first 128 octets of the "original datagram" field, ICMP extensions and NAT will not interact with one another." Interact seems a poor choice of words. It can be interpreted as either interoperate (good) or interfere (bad). 19. In section 6, second paragraph, is it saying you will get interaction with NATS unless implementations do something that is not explicitly forbidden or is it something that is illegal? 20. In section 7, first paragraph, it says "This memo proposes an optional ICMP Extension Structure that can be appended to the ICMP messages referenced in Section 4.6 of this document" which makes it sounds like the messages were originally defined in this document, but they weren't. An additional reference to the RFC(s) they were defined in would help. 21. In section 7, second paragraph, it says "MAY process selected objects while ignoring others." which makes it sound arbitrary. I believe based on what is in the next sentence that they are only ignoring stuff they don't understand? 22. In section 7, the version of this stuff is defined to be 2. Do other ICMP messages have different versions? Is this a way to tell them apart when they are received?