Ben, It's certainly a judgment call, but it really does seem that uint_32t has been around so long now that surviving implementations that misuse int for this surely have many other problems too. We'd be talking about resolver code that hasn't been refurbished since 1997 *and* a DNS record with an absurdly large TTL.
I think DNSOP participants are better placed than me to comment. Regards Brian Carpenter On 03-Dec-19 08:33, Benjamin Kaduk wrote: > Hi Brian, > > I agree that this updated text provides more clarity about why the > change is being made, but I am not sure that it fully addresses all of > the concerns you raised, and would appreciate your thoughts. > > Specifically, you had raised the possibility of existing, fielded, > implementations that would behave poorly when presented with input that > has the sign bit set. The DNS-OARC data that indicates such packets have > not been seen in the wild serves only to amplify this uncertainty, since > we have no reason to believe that such a codepath would have been triggered > already and diagnosed. Isn't there still some latent risk of such > fielded implementations that would be incompatible with this change if it > ever did show up on the wire? > > Thanks, > > Ben > > On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote: >> Hi Dave, >> >> Thanks. I think that covers it. I still suspect that the original reason >> was concern about int versus uint confusion, but the new text is fine. >> >> Regards >> Brian Carpenter >> >> On 25-Oct-19 08:35, Dave Lawrence wrote: >>> internet-dra...@ietf.org writes: >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09 >>> >>> This revision addressed the one remaining outstanding issue that Brian >>> Carpenter raised in the Gen-ART Last Call Review. The following text >>> was added to explain why a TTL with the high-order bit set is now >>> handles as a large positive number (then capped down) rather than a >>> negative number (and treated as zero). >>> >>> As for the change to treat a TTL with the high-order bit set as >>> positive and then clamping it, as opposed to [RFC2181] treating it as >>> zero, the rationale here is basically one of engineering simplicity >>> versus an inconsequential operational history. Negative TTLs had no >>> rational intentional meaning that wouldn't have been satisfied by just >>> sending 0 instead, and similarly there was realistically no practical >>> purpose for sending TTLs of 2^25 seconds (1 year) or more. There's >>> also no record of TTLs in the wild having the most significant bit set >>> in DNS-OARC's "Day in the Life" samples. With no apparent reason for >>> operators to use them intentionally, that leaves either errors or >>> non-standard experiments as explanations as to why such TTLs might be >>> encountered, with neither providing an obviously compelling reason as >>> to why having the leading bit set should be treated differently from >>> having any of the next eleven bits set and then capped per Section 4. >>> >>> I also removed the phrasing about 2181's handling of this issue as a >>> "curious suggestion". I recognize it could have an unintended >>> negative connotation against the original authors, though when I wrote >>> the sentence originally I meant it only with its neutral denotation. >>> It was curious to me only because no rationale was provided as to why >>> that particular choice had been made, despite the current assertion >>> that it was obvious as to why. >>> >>> >> > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
