Adrian Farrel has entered the following ballot position for draft-ietf-6man-udpzero-06: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of thughts about this document which I am not raising as a Discuss, but I hope the authors will have a look at. --- Section 5.1 2. Implementations must provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum. An IPv6 node that enables reception of UDP packets with a zero-checksum, must enable this only for a specific port or port-range. This may be implemented via a socket API call, or similar mechanism. I believe "signal" is a confusing word here. Signalling means (to me) that the implementation builds a message and sends it to the remote end. So, "implementations" cannot provide this mechanism - it is the protocol specification that must do it. And a sockets API call provides a way for an implementation to request the zero-checksum feature locally, but it does not provide a way to "signal the set of ports that will ..." Probably, the consistancy of this requirement would be most easily obtained by s/signal/register/ However, that change would leave open the question of how two end points coordinate (i.e. signal) on which ports they will use zero checksum. That is a requirement on the specification of transported protocols, which is exactly what this section is about. --- Section 9 seems to make a valid point, so I am surprised that no conclusions are drawn from what it says. It also seems to me that it is important to drop and log corrupted packets as early as possible. This offers three benefits: 1. Corruptions in the tunnelling encapsulation are detected so that mis-delivery of the tunnelled packets is less likely 2. Causes of corruption can be more effectively isolated (for example, was it the encapsulation mechanism, the transmission, or the storage of the tunnelled packet that introduced the corruption). In particular, where the corruption is the result of an attack, this may be valuable information. 3. The later the corruption is detected and the packet dropped, the more processing has been "wasted" handling the packet. Thus, late detection offers a way to waste transmission/receiver resources. I found some of these points hinted at in the body of the document and in the Summary. Maybe Section 9 is just positioned a little late in the document meaning that the authors didn't feel there was muych to say by the time the reader got there? Might be nice to beef up the Section a little and arrange for it to come before the Summary. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
