On Tue, Jan 13, 2015 at 11:28 PM, Paul Vixie <[email protected]> wrote:
> > > Warren Kumari <[email protected]> > Tuesday, January 13, 2015 8:19 PM > ... I'm surprised that no-one has yet commented on the 'Let's just co-opt > the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or > not, and are scared to ask :-) W > > > i think you're not kidding, but that you'll ignore input you consider > "grumpy", so i wasn't going to mention any specific defect. instead i'll > ask: what's your use case? do you, or your employer, or indeed anybody > anywhere, need this feature? for what? > *Need* the feature? Nope, it's just an optimization. It seemed to me that DNSSEC allows you to actually have some faith in the additional data, and so its worth revisiting if we can use it. I have no idea what my employer thinks of this - I wrote it because it seemed interesting to me. In general they like things that make the user experience faster, and (if this works), it should do that, so... probably they'd like it.... but who knows.... > > i've long believed that just as A and AAAA are optional additional-data in > MX and SRV and NS responses, so it should be that A should be optional > additional-data for AAAA responses, and AAAA should be optional > additional-data for A responses. > > those are use cases i understand, and where the protocol impact is > negligible, as in, it could be an FYI. > Yup. Those seem reasonable. This is (IMO) just an extension of that idea... > > what have you got for "multiple-responses" in terms of motivation for the > complexity of a protocol change? > I don't see this as a large protocol change - the 'only over tcp' was only put in to mitigate the "this will make packets huge" concern that I figured some people would have.. Other than that there is signaling support - which I put in because I figured it didn't hurt. The actual including multiple responses bit doesn't really seem to violate protocol - as you said re: A and AAA as optional additional-data in MX and SRV and NS, and AAAA for A, A for AAAA. The motivation for this is just efficiency / reducing latency - looking up foo.example, getting a CNAME to bar.example and then looking that up in another transaction seems inefficient and inelegant. Similarly, looking up www.example, getting the webpage and then doing a bunch of separate lookups for all the resources in it, like images.example, js.example, css.example simply seems wasteful, and offends me :-) [0] This optimization might not be worth it - but I figured drafts are cheap, and worth discussing... If the consensus is that this is not worth doing, I'm fine to abandon the work. > > (if this is what you meant when you said you were expecting grumpy > responses, feel free to ignore me.) > Nah, that wasn't a grumpy response. "Your draft is bad *and you should feel bad*" would be.... W [0]: These examples are somewhat self-inflicted pain - you could have skipped the CNAME, and you could also have put all the resources on www.foo. > > -- > Paul Vixie > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
