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 > ietf@xxxxxxxx mailing lists by 2012-12-25. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@xxxxxxxxxxxx 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8