Subject: Barry Leiba's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS)

From: "Barry Leiba" <[email-masked]>
Date: Thu, 04 Oct 2012 11:33:14 -0700

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

---

From: [email-masked]
Date: Fri, 5 Oct 2012 07:56:35 +0100

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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Oct 2012 07:14:43 -0400

> make the document BCP - or are you happy with standards keywords in an

Actually, I was thinking Proposed Standard, as an Applicability
Statement (see RFC 2026, Section 3.2).  BCP would be an alternative
also.

I think that, *if this is the way the WG decides to go*, it would not
require extensive document changes.  I see it as something like this:

----
a. Make udpzero a Proposed Standard and call it an Applicability
Statement, or make it a BCP.

b. Put the 2119 language into udpzero Section 5.1, instead of in
udpchecksums Section 5.

c. Change the intro paragraph in udpzero Section 5:

OLD
   This section identifies requirements for the protocols that are
   transported over a transport connection that does not perform a UDP
   checksum calculation to verify the integrity at the transport
   endpoints.

NEW (for AS)
   This section is an Applicability Statement that identifies REQUIRED
   restrictions on the use of techniques that involve not performing UDP
   checksum calculations to verify the integrity at the transport endpoints.

NEW (for BCP)
   This section specifies best current practice for REQUIRED restrictions
   on the use of techniques that involve not performing UDP checksum
   calculations to verify the integrity at the transport endpoints.

(Or some similar sort of language to indicate that the restrictions
must be followed.)

d. Change udpchecksums Section 5 to remove the numbered list and the
RFC Editor note, and to make this other change:

OLD
      However, some protocols, such as tunneling protocols that
      use UDP as a tunnel encapsulation, MAY omit computing the UDP
      checksum of the encapsulating UDP header and set it to zero,
      subject to the constraints described in RFCXXXX.

NEW
      However, some protocols, such as tunneling protocols that
      use UDP as a tunnel encapsulation, MAY omit computing the UDP
      checksum of the encapsulating UDP header and set it to zero,
      subject to the constraints described in [I-D.ietf-6man-udpzero],
      Section 5.1.

e. Make udpzero a normative reference.
----

With those changes, most of udpzero remains as informational
exposition leading up to Section 5, and Section 5 is the normative
part.

Barry