Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

2019-12-02 Thread Dave Lawrence
Benjamin Kaduk writes: > 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? There's always some risk with any change, right? I'm not trying to be flatly dismissive of the concern. I do, however,

Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

2019-12-02 Thread Brian E Carpenter
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

Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

2019-12-02 Thread Benjamin Kaduk
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

Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

2019-10-24 Thread Brian E Carpenter
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

Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

2019-10-24 Thread Dave Lawrence
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