I think this is a good topic to review. I think we should look to this. While we do this, can I check your view on the possible document status? - If we need RFC2119 keywords to make the guidelines normative, would we make the document BCP - or are you happy with standards keywords in an informational document?
Gorry > Barry Leiba 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: > ---------------------------------------------------------------------- > > This is a combined DISCUSS on udpchecksums and udpzero. First, let me > say that I have no actual objection to publishing either of these > documents. What I'm concerned about is whether we're saying what we want > to stay as a "standard", so let's discuss that: > > The issue comes when I look at udpzero Section 5.1 and udpchecksums > section 5. The numbered list in the latter is essentially a > word-for-word copy of the numbered list in the former, with the "must"s > and "may"s and "should not"s changed to upper case. It always bothers me > when a significant amount of important text is duplicated like that, but > the real problem comes when I look at what this *says*. > > Because udpzero is informational, when it says, "If a zero checksum > approach were to be adopted by the IETF, the specification should > consider adding the following constraints on usage," that makes no > normative requirement on any future protocol that runs on UDP and decides > to bypass the UDP checksums. Now, of course, we also have a document, > udpchecksums, which defines what to do if you do tunneling on UDP and you > want to skip the outer checksums (because you have inner ones). *That* > document makes this list normative. > > But what happens if, later, someone decides to document how to do, let's > say, media streaming over UDP with zero checksums. The analysis in > udpzero applies, of course, but the new document is under no obligation > to consider it or any of those usage restrictions in Section 5.1. (It > might be that such a document could never get past the current community > and ADs, but I'm not sure we want to leave that to chance.) > > So the question comes to what we want to say normatively. Which is it > that we want a standard saying? > > 1. If you tunnel packets over UDP and want to avoid the UDP checksums, > you need to use this list of restrictions. But other applications over > UDP that want to avoid the UDP checksums can make entirely different > decisions. > > or > > 2. If you do *anything* over UDP and want to avoid the UDP checksums, you > need to use this list of restrictions. And here's how tunneling over UDP > works. > > I think (2) is right, but the way the documents are structured now says > (1). > > Discussion, please.... > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
