Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Petr Špaček <[e-mail]>]

On 31. 10. 19 20:08, Eric Orth wrote:
> On Fri, Oct 25, 2019 at 9:29 AM Petr Špaček <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Would it be possible to get some time allocation of your UX design folks, before we set the protocol in stone?
> 
> 
> Not likely, unfortunately.  Downside of not having specific plans yet.  Makes it difficult to allocate UX experts.
> 
>     - Is the current version with "no categorization" okay?
>     - Will it be okay in future if dnsop starts adding new codes?
>     - Or should we add some inherent categorization into the protocol to make it future-proof?
>     - If a categorization is needed, what form is best for UX? (please suggest!)
> 
> 
> Speaking for myself from a non-UX perspective (and I am not a UX expert), forward compatibility of error codes is a common pitfall in many similar systems.  Once error receivers start relying on specific error codes to produce specific essential behavior, expandability often gets locked out because you can't replace those codes with new ones that receivers might not immediately recognize.  And having a receiver only know "unknown" error is usually pretty bad.  Attempts to solve these issues usually involve stuff like categorization, user-visible messages, and multiple ordered errors, but my anecdotal experience is that it's pretty rare for such mitigations to be fully supported by all sides to the level where it actually helps and expandability still ends up limited.
> 
> But specifically to EDE, I think the general circumstances make us fine without taking any specific steps to mitigate forward compatibility.  It's mostly been designed just for "supplemental" signalling.  And at least for the general use cases, eg browsers, I doubt enough recursives will ever (or be able to) support it for the stub to rely on receiving a recognized EDE.  It will always need to be a nice-to-have with the receiver able to provide good behavior if no EDE (or an unrecognized new EDE) is received.
> 
> So no, I don't think categorization is necessary to make EDE useful.  In fact, I think it would probably make things more complicated than necessary.

Thanks!

Based on this feedback I'm dropping my former request to build categorization into the protocol, so the "flags" field can rest in peace.

Thanks everyone for patience with me. Let's move to the forwarding question! :-)

-- 
Petr Špaček  @  CZ.NIC