Thanks John The editorial nits we will take care of in an update. Many of these are new due to the significant changes, and this is in fact the first chance to comment on them. Thus, do not feel bad for it being IETF last call. On 2012-12-18 00:56, John William Atwood wrote: > Comments on draft-ietf-6man-udpchecksums-06 > > > > Bullet 3, sub-bullet 1. What does it mean, "the 5-tuple with a zero > checksum enabled"? I _believe_ that you are trying to indicate that the > delivery mechanism has a data structure with the 5-tuple and an > indication that this context has enabled zero checksums and that the > incoming packet has a zero checksum and that the 5-tuple matches the one > in the data structure. I am not sure what to suggest, but the potential > for erroneous coding seems high to me. A packet matching an existing context which has zero checksum enables receives a packet not intended for this context, but due to some corruption event of the address information it arrives in this context. You are correct that there is basically nothing you can do against this unless you actually have a checksum to detect the corruption. In the case of a tunneling protocol is is also likely that the tunneling protocol is so thin, i.e. no or few headers that using them to detect that this packet is not intended for this context is difficult. Correctly I think this is something you have to accept when using non-checksum protected receivers. It can occur but more than 10000 times as common when using Internet checksums. > > Bullet 3, sub-bullet 1. If a payload is matched to the wrong context, > why is it delivered as if it were correct? Is there something that I am > missing here? The receiving context interprets the packet according to the rules of the existing context. If nothing in this processing is tripped then what was in that packet will be used as a valid packet in that context. To be clear here, we are describing the cases using full knowledge of what occurs, but the receiving node can't see the difference between a corrupted zero-checksummed packet and a correct one. That is what it requires the checksum to do. > > Page 9, replacement text, para 1, lines 6-9. This sentence has no > subject. I suggest the following text: > > "As an alternative usage for some protocols, such as protocols that use > UDP as a tunnel encapsulation, the zero-checksum mode MAY be enabled for > specific sets of ports." > > I note, however, that the phrase "zero-checksum mode" is probably not > defined anywhere in RFC2460, so it may be necessary to be more specific > here: "a packet with a zero checksum MAY be allowed for specific sets of > ports." The zero-checksum mode is intended to be defined by this text, where the zero-checksum mode is defined by the rules in draft-ietf-6man-udpzero. I have some difficulties determining what changes would improve this. 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.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------