On Sun, Nov 3, 2024 at 10:46 AM Paul Vixie <paul= 40redbarn....@dmarc.ietf.org> wrote:
> On Sunday, November 3, 2024 10:09:22 AM UTC Stephane Bortzmeyer wrote: > > > On Sat, Nov 02, 2024 at 08:35:47PM +0000, > > > Paul Vixie <paul=40redbarn....@dmarc.ietf.org> wrote > > > > > > a message of 59 lines which said: > > > > The version number in the initiation is the one that the initiator > > > > is expecting in the response. > > > > > > Do you mean that: > > > > > > Requestor -> EDNS = 0 > > > Responder -> EDNS = 1 > > > > > > is forbidden? RFC 6891 does not say so, quite the opposite "the > > > VERSION of each response SHOULD be the **highest** implementation > > > level of the **responder** [emphasis mine]" > > no, and marka has the right explaination. joao cleaned this up in the -BIS > document. as stated, the responder's given version number is the highest > that it supports, but the responder's use of EDNS features will be limited > by the requester's version number. this allows passive signaling of > potentially higher version numbers which could be cached by the requester. > > while we have not added a second version number yet (which we should -- > along the lines of "grease" where we occasionally revise the version number > just to force the negotiation logic), there are only two ways a new version > number would be used. first, the requester might start with its highest > known version number and then back down (iteratively) using a BADVERS > signal from that responder. this is suboptimal. second, the passive method > described above. this is currently optimal. > I find it fascinating that working on greasing is helping to sharpen our collective understanding of EDNS version negotiation rules, and where we might want to improve, change, or clarify things (I'm sure other protocol minutiae will be uncovered). Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
