Subject: Adrian Farrel's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Oct 2012 07:39:36 -0700

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:
----------------------------------------------------------------------

Updated Comment with an additional point.

A couple of thoughts 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.

---

Section 5.1 should probably also talk about the management requirements.
Can ports be manually configured for zero checksum? Should
implementations provide management access to say on which ports zero
checksum is operated?