[Gen-art] Genart last call review of draft-ietf-dnsop-serve-stale-07

[Brian Carpenter via Datatracker <[e-mail]>]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-dnsop-serve-stale-07

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-serve-stale-07.txt
Reviewer: Brian Carpenter
Review Date: 2019-09-17
IETF LC End Date: 2019-09-25
IESG Telechat date:  

Summary: Ready with issue
--------

Major issues:
-------------

"(It [RFC2181] also has the curious suggestion that a value in the
range 2147483648 to 4294967295 should be treated as zero.)"

I don't see why that is "curious". That is the range of unsigned
32-bit integers that would be negative if treated as signed 32-bit
integers. And in any case, the statement seems unfair to the authors
of RFC2181, which actually says this:

"It is
hereby specified that a TTL value is an unsigned number, with a
minimum value of 0, and a maximum value of 2147483647... this value
shall be encoded in the less significant 31 bits..."

It's not a "suggestion"; since the RFC does not use RFC2119 keywords,
it's a requirement. It's unambiguous, and obviously motivated by
resilience to coding errors around signed vs unsigned integers. That
was a legitimate concern in 1997. As best as I can tell, in 1997
standard C did not include uint32; you needed to use unsigned long int
and hope it was mapped to 32 bits.

So the current draft overrides this choice made in RFC2181. Since that
choice had an obvious (but unstated) motivation, how do we know that
allowing TTLs above 2147483647 will not trigger long-standing coding
bugs?

There's an alarm bell later in the draft:

"Regarding the TTL to set on stale records in the response,
historically TTLs of zero seconds have been problematic for some
implementations, and negative values can't effectively be
communicated to existing software."

You bet. If the TTL is specified as an unsigned 32 bit integer, and
stored in a uint32, negative values are impossible. But if the coding
is sloppy and used long int, "if ttl > 0" could go horribly wrong.

Maybe it's all OK and there is no old resolver code out there with coding
errors for values above 2147483647. Did the WG discuss this? I think the
"curious suggestion" text above should be replaced by a brief discussion
of why RFC2181 made the change that it did, and why it's now safe to
reverse it.