> On 14 Nov 2017, at 8:19 am, Joe Abley <jab...@hopcount.ca> wrote: > > Hi Geoff, > > I think the number 4 on the slide was different from the one in the mail.
I thought so too, but I wasn’t sure if it was me not paying attention in the WG meeting or not! > > 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. and that makes sense to me, considering my perspective of the risk associated with duplication of protocol field values > > 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. > thanks Joe, Geoff _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
