Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-03.txt

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]


On Thu, Dec 20, 2018 at 6:20 PM Wes Hardaker <[e-mail]> wrote:
>
> [e-mail] 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