Tim, At 2017-07-25 12:04:04 -0400 tjw ietf <tjw.i...@gmail.com> wrote:
> This draft was the only one which seemed to have broad support in some form > during the meeting last week. To be fair, I think that we could say that this was the only one having complete support during the meeting. Several drafts had support with only a few people whining because it didn't help their own operations. ;) > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 August 2017, 23:59 I support the draft, and am willing to contribute text and review! I have a few points now, in fact: 1. Does it make sense to divide the response codes up into those corresponding to each error type? That is, something like 1xxxx for SERVFAIL, 2xxxx for FORMERR, and so on? 2. Do we mind having lots of error codes? For example, we can go really far and do things likes DNSERR_BADCOMPRESS "name compression used in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than 255 bytes", and so on. We could end up with hundreds of error codes. As a developer I don't mind this too much, as these provide hints about stuff you should be considering, but I can see why some people would prefer to keep it simple. 3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451 for consistency with the HTTP response code. This may be a useful addition to the RPZ draft. ;) Cheers, -- Shane
pgp_s_tUg0sLf.pgp
Description: OpenPGP digitale handtekening
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
