Hi Geoff, I think the number 4 on the slide was different from the one in the mail.
The option on the slide that I mentioned I liked the most was the one that didn't copy the RCODE value from the header, but in effect provided a 16/32/whatever-bit sub-code for whatever the RCODE happened to be. So, for each permissible value of the RCODE field, this new field would provide additional information that was relevant to that value. Compared to the other options presented, this avoids having to specify behaviour for all the unhelpful corner cases of RCODE in message header doesn't match the copy in the new field, new field value (e.g. "validation failed" or something) doesn't make sense for this particular RCODE (e.g. "NOERROR"), etc. Joe > On Nov 13, 2017, at 19:01, Geoff Huston <[email protected]> wrote: > > >> On 13 Nov 2017, at 9:43 pm, tjw ietf <[email protected]> wrote: >> >> To follow up from the meeting this morning, it sounded from the room that >> in the case of these >> four options, #4 was the one which makes the most sense. >> >> > ….. > >> >> 4. 32 bit code field, repeating rcode from elsewhere in the packet >> Like #2, but copies the rcode directly into the error code header >> within the extended-error component of the packet. Redundant but >> clear that the entire 32 bits are needed. >> >> Thoughts? > > > errr - what would it mean if the rcode in the error code header differed > from the rcode value in the extended-error component? > > The issue with duplicated information in a packet is that you then have > add even further consideration to cope with the cases where the expected > thing did not happen. > > Not exactly blown away by #4 myself. > > Geoff > > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
