On 7/25/17, 12:04, "DNSOP on behalf of tjw ietf" <dnsop-boun...@ietf.org on behalf of 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. >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[tools.ietf.org] >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. It's funny that the older you get and the more you see the same old question the less clear what the right answer is. I thought the intent of EDNS was to extend things like the response codes. "Extension Mechanisms for DNS (EDNS(0))" [https://www.rfc-editor.org/std/std75.txt] includes "EDNS provides a mechanism to ... provid[e] extra data space for ... return codes (RCODEs)." So entertaining a WG work item/draft on EDNS'ing RCODEs is a no-brainer, I mean, bring it on. But the draft itself isn't exactly the way I'd go about solving the problem. Does that mean it shouldn't be adopted? I suppose not, I suppose the answer is to adopt it and change it mercilessly. In a separate message, I'll send some comments about the draft. I don't know if I'll be tuned in enough to follow up (I don't often take time to read the list like I used to do), so I won't promise anything beyond that. It's a matter of time and priorities.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
