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