[DNSOP] draft-ietf-dnsop-extended-error code options

Wes Hardaker <wjhns1@hardakers.net> Mon, 16 October 2017 22:39 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 ABD6B13457A for <dnsop@ietfa.amsl.com>; Mon, 16 Oct 2017 15:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.958
X-Spam-Level:
X-Spam-Status: No, score=0.958 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no 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 I2WZ-MMhD0gg for <dnsop@ietfa.amsl.com>; Mon, 16 Oct 2017 15:39:13 -0700 (PDT)
Received: from mail.hardakers.net (unknown [168.150.236.43]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED34A133205 for <dnsop@ietf.org>; Mon, 16 Oct 2017 15:39:12 -0700 (PDT)
Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 7ADD7226DB for <dnsop@ietf.org>; Mon, 16 Oct 2017 15:39:12 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: dnsop@ietf.org
Date: Mon, 16 Oct 2017 15:39:11 -0700
Message-ID: <yblpo9md8fk.fsf@wu.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iIA_-kwY862-0tE98r8ZaLeyCmc>
Subject: [DNSOP] draft-ietf-dnsop-extended-error code options
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Oct 2017 22:39:14 -0000

Folks,

We were given feedback during the call for adoption to "use numeric
range codes like those in HTTP".  Following that, Warren and I sat down
and came up with some possibilities and would like your feedback about
which of these options you would prefer:

  1. Individual codes assigned one at a time, per the existing doc

  2. HTTP like: integer ranges where NNYY indicates the NN integer rcode
     and YY indicates the sub-code.  Note that this needs a 32 bit error
     code field.

  3. Use a 16 bit error code field, with the 16 bits differ per rcode.
     Thus, clients would need to use the combination of rcode and error
     code to determine the error.

  4. 32 bit code field, repeating rcode from elsewhere in the packet
     Like #2, but copies the rcode directly into the error code header
     within the extended-error component of the packet.  Redundant but
     clear that the entire 32 bits are needed.

Thoughts?

-- 
Wes Hardaker
USC/ISI