I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6lowpan-hc-13.txt Reviewer: David L. Black Review Date: January 17, 2011 IESG Telechat date: January 20, 2011 Summary: This draft is on the right track, but has open issues, described in the review. This draft is a complete redesign (in the form of new headers) of the IPv6 header compression support for IEEE 802.15.4 in order to make the result usable in practice, and hence obsoletes the old formats. The draft reflects experience with the technology and contains a wealth of design details to obtain as much leverage as possible from compression. While I did not go through all of the header details, the draft looks like it's in good shape and the result of careful consideration. I have one open issue. The draft allows UDP checksums to be omitted when there are higher level integrity checks in place, and says the following about verification that those checks are in place: With this specification, a compressor in the source transport endpoint MAY elide the UDP checksum if it is authorized by the Upper Layer. The compressor SHOULD NOT set the C bit unless it has received such authorization. .... A forwarding node MAY imply authorization from an incoming packet if the C bit is set. A forwarding node that cannot unambiguously derive such authorization SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression. Omission of UDP checksums has a lousy track record, suggesting that both of the above should be "MUST NOT" instead of "SHOULD NOT". There are plenty of storage "war stories" about someone who ran NFS over UDP with checksums turned off and later discovered corrupted files. There may be something special about 802.15.4 that makes this sort of corruption less of a risk, but I strongly request that the IESG discuss whether to change both of the above "SHOULD NOT" statements to "MUST NOT" with an explanation of the significant risks to data integrity (e.g., there's a reason why RFC 2460 made the UDP checksum mandatory). idnits 2.12.05 generated a few miscellaneous warnings, none of which require changes to the draft. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
