Hi, While it is not exactly what I would want, I am satisfied with the changes below and consider my comments resolved.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com On Thu, Dec 20, 2018 at 6:20 PM Wes Hardaker <wjh...@hardakers.net> wrote: > > internet-dra...@ietf.org writes: > > > Title : Extended DNS Errors > > Authors : Warren Kumari > > Evan Hunt > > Roy Arends > > Wes Hardaker > > David C Lawrence > > Filename : draft-ietf-dnsop-extended-error-03.txt > > Pages : 12 > > Date : 2018-12-20 > > 4 Donald Eastlake > .. 4.1 DONE two dimensional table is unneeded > .. 4.2 DONE rcodes are only 4 bits > 4 Donald Eastlake > ================= > > I like the Extended Error Code using EDNS idea. This was effectively > what was done with TSIG and TKEY that have an expanded Error field > inside the RR. However: > > > 4.1 DONE two dimensional table is unneeded > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> I don't see any reason for the complex two-dimensional table to > new error codes. Given that 16 bits is available for "INFO-CODE" > (which I think, to follow the DNS nomenclature used in TSIG and TKEY, > should just be called "Error"), I don't see why these extended error > codes, which provide more detail beyond the top level Error code > value, can't be from the single unified DNS error code table. That > way, wherever you get a DNS Error code (from RCODE or the EDNS > extended error field or the TSIG or TKEY error fields or wherever, > there is just one table to look it up in. For example, you could > Reserve 4096 through 8191 for this purpose, which is probably enough > values :-) > > + response: this was discussed multiple times in previous working > group meetings and on the mailing list, and the general consensus > was to use a multiple-lookup table. Continue reading into the next > issue for further information on a decent compromise: > > 4.2 DONE rcodes are only 4 bits > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> Since RCODEs are 4 bits, I don't see why a 16-bit RESPONSE-CODE > field is required. Even if you want to be able to provide additional > information for the 12-bit error codes of RCODE as extended by base > EDNS, there is still enough room in the previous 16-bit word which has > 15 unused bits in it. Just move the RESPONSE-CODE up into the previous > word > > + Response: you're right about the 4 bits of course. Somehow our > initial remembrance of this got lost in the double table issue. So > to simplify both this issue, and the previous, we've decided to > merge the two codes into a 4-bit RCODE value and a 12-bit INFO-CODE > value. This actually allows implementers to treat it easily as two > codes, if they'd prefer, or a single 16b-bit code if they'd rather > handle it that way while preserving interoperability between > everything. > > -- > Wes Hardaker > USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
