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.
tim On Tue, Oct 17, 2017 at 6:39 AM, Wes Hardaker <wjh...@hardakers.net> wrote: > > Folks, > > We were given feedback during the call for adoption to "use numeric > range codes like those in HTTP". Following that, Warren and I sat down > and came up with some possibilities and would like your feedback about > which of these options you would prefer: > > 1. Individual codes assigned one at a time, per the existing doc > > 2. HTTP like: integer ranges where NNYY indicates the NN integer rcode > and YY indicates the sub-code. Note that this needs a 32 bit error > code field. > > 3. Use a 16 bit error code field, with the 16 bits differ per rcode. > Thus, clients would need to use the combination of rcode and error > code to determine the error. > > 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? > > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
