Folks,
Per the discussions in the past about both the TC bit and resolver/forwarding, I've updated the draft with the following text for these two issues. Below is a new section that describes these issues. I *believe* that this might be a good enough middle ground to get us past rough consensus, though I know opinions varied widely on what people's definitions of "perfect" is. [the registry ranges are also updated, but I'm fairly confident we're already at rough consensus for that.] Any objections to this path forward? https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-extended-error-12&url2=draft-ietf-dnsop-extended-error-13 --- 3. Extended DNS Error Processing When the response grows beyond the requestor's UDP payload size [RFC6891], servers SHOULD truncate messages by dropping EDE options before dropping other data from packets. Implementations SHOULD set the truncation bit when dropping EDE options. When a resolver or forwarder receives an EDE option, whether or not (and how) to pass along EDE information on to their original client is implementation dependent. Implementations MAY choose to not forward information, or they MAY choose to create a new EDE option(s) that conveys the information encoded in the received EDE. When doing so, care should be taken to ensure any information is properly attributed since an EDNS0 option received by the original client will be perceived only to have come from the resolver or forwarder sending it. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
