Hi, I have made a review of the draft and have some comments on it.
1. Needs to indicate that it updates RFC2460 (when approved). This usually goes into the header of the front page. The abstract and as part of the introduction. 2. The abstract is way to meager. It needs to make clear, what it does, that there are limitations and that it updates RFC 2460. 3. Style of writing. This is a document that updates and will be the specification of a change of the IPv6 specification. Currently it still reads like a change proposal. From my perspective it needs to be more authoritative. This is something we have decided to do. Thus the document should be written like: 1. Introduction: We are changing the UDP zero checksum rule in IPv6. 2. Short motivation why. 3. Change to specification. Old text that is replaced. New text. Some places where this is evident: - Section 1, last paragraph on page 3: Not long term relevant and using terms that make less sense in an RFC. - Section 1.4 "Recommend Solution": Wrong title. Should be its own main section. First paragraph. 4. Section 1.4: In cases, where the encapsulating protocol uses a zero checksum for UDP, the receiver of packets in the allowed port range MUST NOT discard packets with a UDP checksum of zero. "in the allowed port range" seems wrong, isn't "to a port that has been enabled to receive zero checksum" so that the full sentence reads: In cases, where the encapsulating protocol uses a zero checksum for UDP, the receiver of packets to a port that has been enabled to receive zero checksum MUST NOT discard packets with a UDP checksum of zero. 5. Section 1.4 bullet 1: 1. IPv6 protocol stack implementations SHOULD NOT by default allow the new method. The default node receiver behaviour MUST discard all IPv6 packets carrying UDP packets with a zero checksum. I think "new method" is unclear in this sentence. Yes, I know it is from my draft. However, in the context of actually doing the change it needs to be more crisp and clear. 6. Section 1.4, bullet 3: 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with a zero-checksum. This should remain the case for any datagram received on a port that does not explicitly enable zero-checksum processing. A port for which zero-checksum has been enabled MUST NOT log the datagram. Should we clarify that it MUST NOT log for the reason of it having a zero checksum. It may still be logged but for other reasons. The simplest change appears to say: A port for which zero-checksum has been enabled MUST NOT log the datagram for that reason. 7. Section 1.4, bullet 5: 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, then the tunnel MUST provide an additional integrity verification mechanism. An integrity mechanism is always recommended at the tunnel layer to ensure that corruption rates of the inner most packet are not increased. I think the first "MUST" is actually not correct. I think "MAY" is actually more correct. If you transport IP as inner packet, then you MAY rely on that being corruption verified by itself, the outer header doesn't need to take that responsibility providing that the corruption rate will not be increase. However disallowing additional checks was not the intention here. 8. Section 1.5 should have its own main section. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------