Re: [DNSOP] draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

Wes Hardaker <wjhns1@hardakers.net> Tue, 10 September 2019 23:02 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213CC1208A0 for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 16:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhSgGr2jFNZf for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 16:02:50 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2384712089F for <dnsop@ietf.org>; Tue, 10 Sep 2019 16:02:50 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id A704927C33; Tue, 10 Sep 2019 16:02:49 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: IETF DNSOP WG <dnsop@ietf.org>
References: <EA557043-34D1-43EA-B750-4A17CFC6BE50@icann.org> <ybl36h4aj8x.fsf@w7.hardakers.net> <AFE92D06-8418-4451-A827-D5656C83B796@icann.org>
Date: Tue, 10 Sep 2019 16:02:49 -0700
In-Reply-To: <AFE92D06-8418-4451-A827-D5656C83B796@icann.org> (Paul Hoffman's message of "Tue, 10 Sep 2019 14:07:45 +0000")
Message-ID: <yblzhjbeova.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B1Z9SxOuMlL8UKZXQRS-i5H2l0s>
Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 23:02:58 -0000

Paul Hoffman <paul.hoffman@icann.org>; writes:

> On Sep 9, 2019, at 9:05 PM, Wes Hardaker <wjhns1@hardakers.net>; wrote:
> > 
> > Paul Hoffman <paul.hoffman@icann.org>; writes:
> > 
> > Hi Paul,
> > 
> > Thanks for the comments and good suggestions.  Responses below inside my
> > todo list of action:
> > 
> > 12 Paul Hoffman
> > ===============
> > 
> >  Greetings again. The changes here generally help the document, but
> >  they also highlight some of the deficiencies. A few comments on the
> >  current draft:
> > 
> > 
> > 12.1 NOCHANGE what error codes?
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> >  - The spec does not say anything about the kinds of responses where it
> >  is allowed to send particular extended error codes. For example, if a
> >  response has an RCODE of NOERROR, what does it mean for it to also
> >  have a EDE? Or if the RCODE is FORMERR, can it have an EDE that
> >  relates to DNSSEC validation failure? The exact semantics for the
> >  receiver need to be specified.
> > 
> >  + The EDE was specifically meant to be an "addition" to an existing
> >    reply of *any* RCODE, including NOERROR codes.  There is no
> >    restriction about when you might include one.  Similarly, it makes
> >    no sense for some codes to be returned for some RCODES, but any good
> >    receiver shouldn't segfault either.  I don't think we can specify
> >    all potential combinations in any meaningful way.
> 
> Being silent on this is also bad. Proposed text for the introduction:
> 
> This document does not allow or prohibit any particular extended error
> codes and information be matched with any particular RCODEs. Some
> combinations of extended error codes and RCODEs may seem nonsensical
> (such as resolver-specific extended error codes in responses from
> authoritative servers), so systems interpreting the extended error
> codes MUST NOT assume that a combination will make sense.

I think that works.  I extended it with one more sentence:

      <t>This document does not allow or prohibit any particular
      extended error codes and information be matched with any
      particular RCODEs. Some combinations of extended error codes and
      RCODEs may seem nonsensical (such as resolver-specific extended
      error codes in responses from authoritative servers), so systems
      interpreting the extended error codes MUST NOT assume that a
      combination will make sense.  Receives MUST be able to accept
      EDE codes and text in all messages, including even those with a
      NOERROR RCODE.</t>

-- 
Wes Hardaker
USC/ISI