On Wednesday, December 30, 2015 04:14:07 PM 神明達哉 wrote: > At Thu, 24 Dec 2015 08:01:14 +0530, > > Mukund Sivaraman <[email protected]> wrote: > > https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06 > > > > says in Section 6. Option Format: > > > o A server receiving an ECS option that uses more ADDRESS octets > > > > > > than are needed, or that has non-zero bits set beyond SOURCE > > > PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a > > > signal to the developer of the software making the request to fix > > > their implementation. > > > > FORMERR seems more appropriate than REFUSED for an implementor to notice > > format issues, and perhaps this has been raised on this list already. If > > you can change this, please change this to FORMERR. > > My understanding is that it's fodder for the imaginary followup > standard document (whether it's FORMERR or something else may still be > debatable, but should at least be something other than REFUSED). I > believe you can find the discussion that led to this conclusion in the > ML archive (I didn't like it either but that seemed to be the "rough > consensus").
if the intent is to document existing practice and existing implementations send REFUSED in this situation, then the document should say that. but the document should also say that FORMERR is the correct signal. REFUSED means that some other name server might be willing to process the query. FORMERR means that no name server could process this query. -- P. Vixie
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
