IETF Logo Mail Archive

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

Joe Abley <jabley@hopcount.ca> Tue, 14 November 2017 01:48 UTC

Return-Path: <jabley@hopcount.ca>
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 77BB01270A3 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 17:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 Gg9AEHcKDTNA for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 17:48:32 -0800 (PST)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C4B1270FC for <dnsop@ietf.org>; Mon, 13 Nov 2017 17:48:32 -0800 (PST)
Received: by mail-pg0-x22f.google.com with SMTP id z184so8734130pgd.13 for <dnsop@ietf.org>; Mon, 13 Nov 2017 17:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uphbbzWd5lYxKJ9mfOmCJBOYxx6vD7etKsDWaILkm58=; b=f+zafc+QF5HLY43KnbxknzMFRceB6mGRF/j0egNu0k/tnQTgCQVotCw+Mr3kcj0XHK B6IV8evRm6g50Qd1ojoHl5PsELswWvbzSOGechEnYI+POl8/Acf0WivfKCQDnv0iyKJM Eqwls7xdkZmdfvXzWJkn4sMgmHKtlbXtpHUUs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uphbbzWd5lYxKJ9mfOmCJBOYxx6vD7etKsDWaILkm58=; b=Mg8sutugzyOEBVnKzP1Ofl0zvk3e97InzwdIi349vFmyj4gC0bls0HOF9wRyDg8JSh daVHYvOBqXzJ4l1Q0ad2TNDIwQ1Zi1i9wfLU8jM4D97SAQ6g88B7wh+QBFaWpNxMjGWJ EfdarPD8L2YSKMUAV63X0TEx/kJk/z1e8GGt4fyQFTGd/8LFqgCcGuCddTE6EMjMEYVK Ug4yfJwriGLS0YjaGnXtA9ds5mnmhgjT9CV6x4p5soU3kWjCgrMTWUWyRwHmF4kPLzzN L7G/A02dWz9Ltqi3HhLU7HiEZ+/sIO1fbHsN42I8beq7uF6EKSyCiGiNbuFAL4roqZ30 xasA==
X-Gm-Message-State: AJaThX7PiBUkI4zLqLDDpLMI1lFX+zFiwd17nuV+KZbt5BeUewX+cgEm PBl1EjwEp89irzNbrcnx8mtVEG+hZkQ=
X-Google-Smtp-Source: AGs4zMbr50RFeU8nHnDWpffSMjczqwxqR9Gk/6o6MPAXzFCt3BgfBzCnLxEKjfZW2KXIjDoKKw9rqg==
X-Received: by 10.84.232.76 with SMTP id f12mr10537172pln.195.1510624111632; Mon, 13 Nov 2017 17:48:31 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:5cb5:2fa:3be:e25a? ([2001:67c:370:128:5cb5:2fa:3be:e25a]) by smtp.gmail.com with ESMTPSA id a19sm36245122pfh.30.2017.11.13.17.48.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:48:30 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (15B150)
In-Reply-To: <CAKr6gn03XiZvCx4LsWLGQy8F4ap3w48OR8jY8Fb=RS3Z3LB6YA@mail.gmail.com>
Date: Tue, 14 Nov 2017 09:48:28 +0800
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A70D4EF3-A19D-4E8E-AE34-652F6B7166EF@hopcount.ca>
References: <yblpo9md8fk.fsf@wu.hardakers.net> <CADyWQ+G-e+zqGkFK7vPQdXBDRvyv-Gxw75N1z+A6L8ULR=+izQ@mail.gmail.com> <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <e9a3bbc4-0c03-b66c-eb2b-a1c1b336424b@bellis.me.uk> <20171114013049.GA19865@laperouse.bortzmeyer.org> <CAKr6gn03XiZvCx4LsWLGQy8F4ap3w48OR8jY8Fb=RS3Z3LB6YA@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9q8TjDqKd3S3YPNj48pY_gcI5W4>
Subject: Re: [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: Tue, 14 Nov 2017 01:48:33 -0000

On Nov 14, 2017, at 09:37, George Michaelson <ggm@algebras.org> wrote:

> Stephane, I don't entirely understand your response. old systems can
> never understand new code point assignments, or know what to do with
> it, no proposed change can alter this. Middleboxes dropping unexpected
> things will hit almost any proposed modification of packets in flight.

The implication is, I think, that some new code points are more likely to survive the attention of Sauron's Middleware than others.

We have seen claims in the past that new RRTYPEs, new EDNS(0) options, new EDNS(i) with i > 0, new records in ADDITIONAL sections, etc that will all fall fail of middleware or other dependent systems. What's not clear is the relative impact of each, but it seems intuitively true that the impact of each is probably not the same.

For example, I bet it's more practical to implement a new EDNS(0) option than it is to deploy EDNS(1), but I have no science to back up that intuition.

If only there was some kind of research group adept at wide-scale measurement from the end-user perspective that could shed some light on this!


Joe

v2.23.0 | Report a Bug | By Email