Hi Stewart, See inline for comments
On 2012-10-08 05:37, Stewart Bryant wrote: > Stewart Bryant has entered the following ballot position for > draft-ietf-6man-udpchecksums-04: Discuss > > 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. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to > get to yes on this draft also, since I support the liberalization of this > protocol design when used for tunnelling. Specifically point 6 in this > draft is relevant to this discussion. Acknowledged > Additionally a tunnel may not have any way of knowing if the payload is > protected (as you suggest), since normally a tunnel has no knowledge of > the payload characteristics. No, but a tunnel know what general class of traffic it encapsulates. Is it IPv4 that has at least IPv4 header checksums and possibly non-zero transport checksums, or are they some type of other L2 frames that has checksums as part of their frame headers. It is this type of knowledge in the tunnel payload we want the tunnel designer to consider if they need additional checksums or not. > > In point 7 you suggest that an application cannot rely on packet length. > When PWs are used for tunneling we rely on exactly that (except in the > case of packets shorter than 64 octets for Ethenet padding reasons), and > I am not aware of any reported issues. Thus when the application is > tunnel encap/decap there is a body of evidence that suggests that this > OK. First of all, I would like to understand a bit more about these experiences from pseudowires. Which type of psuedowires are we talking about here. And the derived experiences over which type of lower layer are being used. Is this IPv6/UDP or something else like MPLS? Secondly, it is likely that psuedowires is designed such that an error in the length field do not result in any corruption of any state or irregularities in processing that cause any substantial issues beyond possibly loosing that packet from its intended context. From my perspective, trying to say that there is no risk with removing the UDP checksum even for a limited context is like trying to prove a negative. I am certain that some environments have very low corruption rates, but there might be other environments for IPv6 where it is much higher. I wished someone would repeat Stone and Patridge's investigation to get better understanding of the behaviors of IPv4 and IPv6 in this regards at different points in today's Internet. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > There is some text in the earlier part of document that looks like it > should be written in RFC2119 format. In this case it is not important > because the normative change is later and this used RFC2119 directives, > however the authors should consider making the document self consistent > in this regard. I guess you are referring to some text in the discussion. There are similarities in the discussion with the specification text as it is motivation why things are like they are. But I think the section differences and in addition the actual normative text is formulated in a different way that makes it unsuitable to apply RFC 2119 text on that earlier sections. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
