On Tue, Nov 14, 2017 at 4:10 AM, Dave Lawrence <[email protected]> wrote: > Dave Lawrence writes: > > The main changes, based on previous feedback, are: > > > > * Clarifying what the action is for Standards Track; > > * Describing the algorithm previously proposed (and still included) as > > one example way of achieving the goals; and, > > * Adding a rough proposal for an EDNS option that could be used for > > explicit signalling. > > > > That last item will be fleshed out more if there's demonstrated > > interest from implementers in having such a thing. > > At the moment I'll observe there are no open issues against the draft, > which is my comically passive-aggressive way of pointing out that it > is obviously perfect and so let's just move it along to Last Call. > > This is now your opportunity to correspondingly observe that someone > is wrong on the Internet and to respond appropriately. At the very > least, we'd like to know whether there is sufficient support for > pursuing the EDNS option or just to take it back out (and leave the > rest of the obviously perfect document as-is). > > Thanks in advance for any feedback, > tale >
I think signaling between the client and resolver is important. I am a little concerned about yet another option that the client might want to send with every query. Can the existence of *any* EDNS option from the client be taken to mean that EDNS options are understood in general, and the resolver is ok to respond with this ENDS option, which the client might not understand but will not choke on? Signalling between the resolver and authoritative server gets more complicated. Probably a good idea, but if the defaults are reasonable, it probably won't need to be used often. -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
