Re: Last Call: <draft-ietf-6man-udpchecksums-06.txt> (IPv6 and UDP Checksums for Tunneled Packets) to Proposed Standard

[John William Atwood <[e-mail]>]

Comments on draft-ietf-6man-udpchecksums-06

The following are comments on grammatical issues with the above-noted
document.  I apologize for waiting until IESG last call to make these
comments.

Abstract, line 5.  "for suitable" -> "for a suitable"

Page 3, para 4, line 2.  "Automatic IP Multicast Without Explicit
Tunnels" -> "Automatic Multicast Tunneling"

Page 4, section 3, para 1, second sentence.  This sentence has two
subordinate clauses and no principal clause.  I suggest removing the
second "where": in line 5:
"software, where the cost" -> "software, the cost"

Page 5, section 4.1, para 1, lines 4-5.  "thought safe" -> "thought to
be safe"

Bullet 1, line 1.  "Context (i.e. tunneling" -> "Context (i.e.,
tunneling)  (See below for the explanation.)

Line 9.  "that affect not only the" -> "that may affect much more than the"

Bullet 2, line 8.  "with both a non-zero-checksum and ones" -> "with a
non-zero-checksum and datagrams"   (There are two things wrong here.
First, the use of "both" could be taken to imply that the datagrams must
have both types of checksums (in the same packet), which is not what you
intend.  Second, when "both" is used, the two things referenced by
"both" should be "equal" grammatically.  In this case, one is "non-zero
checksum" and the other is "ones" (i.e., datagrams).  The proposed
rewording removes these problems.)

Bullet 3, line 1.  "packets" -> "packet"

Line 2.  "i.e." -> "i.e.,"

Line 4.  "i.e." -> "i.e.,"

Note:  Bullets 1 and 2 each begin with a sentence: "Context should be",
"Keep-alive datagrams should be".  Bullet 3 begins with a "header",
which is not a sentence.  In addition, it appears to me that you are
listing four things in the first sentence, and five things in the second
sentence.  Finally, you talk about the "protocol" with two senses in
sentence two.  I suspect that the second reference is really the
"protocol number" inside the tunneled packet.  You might consider
restructuring the first two sentences of the third bullet as follows:

"An attempt should be made to detect corruption of the address
information in an encapsulating packet.  A robust tunnel protocol should
track tunnel context based on the 5-tuple (tunneled protocol number,
IPv6 source address, IPv6 destination address, UDP source port, UDP
destination port)."

The third sentence should be left as it is.

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.

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?

Bullet 4 (on page 6).  Again, there is a "header", not a sentence.
However, at least this time the header ends with a colon, rather than a
period.

Page 7, Section 4.2, bullet 1, line 1.  "semantics that" -> "semantics,
which"  (See note at the end about which/that.)

Line 8.  "that an" -> "that any"

Bullet 3, line 5.  "effect" -> "affect"

Page 8, Bullet 1, line 6.  "spend" -> "spending  (to match "processing")

Section 4.3, line 5.  "needs" -> "need"  (has to agree with "protocols".)

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."


NOTE on use of "which" and "that".  "that" is used when the phrase
following it is _required_ if we are going to be able to completely
identify what is being talked about, while "which" is used to introduce
supplementary information.  Some examples:

1) If there are three houses on the street, and only one of them is at
the corner, then you say:
"The house that is on the corner needs to be painted."
2) If there are three houses on the street, and only one of them is
yellow, then you say:
"The yellow house, which needs to be painted, is for sale."

In the first case, the observer cannot identify the exact house until
its position is given.  In the second case, the house is completely
identified by its colour, and the information about the need to be
painted is supplementary information.  This information is set off with
commas, and introduced with "which".

NOTES on the use of "i.e." and "e.g.".
"i.e." is an abbreviation for "id est", a Latin phrase meaning "that
is".  As such, it should be punctuated as if it were the full phrase.
Unless there is a parenthesis on one side or the other, it is always
preceded by a comma and a space, and always followed by a comma.
"e.g." is an abbreviation for "exempli gratia", a Latin phrase meaning
"for example".  It should also be punctuated as if the full phrase were
present.  Unless there is a parenthesis on one side or the other, it is
always preceded by a comma and a space, and always followed by a comma.


On 12/11/2012 8:15 PM, The IESG wrote:
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'IPv6 and UDP Checksums for Tunneled Packets'
>   <draft-ietf-6man-udpchecksums-06.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2012-12-25. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document provides an update of the Internet Protocol version 6
>    (IPv6) specification (RFC2460) to improve the performance in the use
>    case when a tunnel protocol uses UDP with IPv6 to tunnel packets.
>    The performance improvement is obtained by relaxing the IPv6 UDP
>    checksum requirement for suitable tunneling protocol where header
>    information is protected on the "inner" packet being carried.  This
>    relaxation removes the overhead associated with the computation of
>    UDP checksums on IPv6 packets used to carry tunnel protocols.  The
>    specification describes how the IPv6 UDP checksum requirement can be
>    relaxed for the situation where the encapsulated packet itself
>    contains a checksum.  The limitations and risks of this approach are
>    described, and restrictions specified on the use of the method.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 

-- 
Dr. J.W. Atwood, Eng.             tel:   [phone] x3046
Distinguished Professor Emeritus  fax:   [phone]
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[e-mail]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8