IETF Logo Mail Archive

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

Mark Andrews <marka@isc.org> Mon, 10 October 2016 14:56 UTC

Return-Path: <marka@isc.org>
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 DA6AC129701 for <dnsop@ietfa.amsl.com>; Mon, 10 Oct 2016 07:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Level:
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, SPF_PASS=-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 Fvp0k8-uRVgb for <dnsop@ietfa.amsl.com>; Mon, 10 Oct 2016 07:56:47 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DD912968D for <dnsop@ietf.org>; Mon, 10 Oct 2016 07:56:47 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5B6E23493C7; Mon, 10 Oct 2016 14:56:45 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 490FC16004C; Mon, 10 Oct 2016 14:56:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3372A160069; Mon, 10 Oct 2016 14:56:45 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3vOV2g_vifSh; Mon, 10 Oct 2016 14:56:45 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A29CA16004C; Mon, 10 Oct 2016 14:56:44 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 401EB56260C8; Tue, 11 Oct 2016 01:56:42 +1100 (EST)
To: william manning <chinese.apricot@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <CAAiTEH9Rbw4u3gV9GULQ-8WdoPHf3SXQMTRY+CtfUGrNQSGAWw@mail.gmail.com> <20161010023251.241F1560C844@rock.dv.isc.org> <CACfw2hiV9+qQ_OysHAQ4jd4fJtN2a=mrHqDiTkg4JArQ_LoGtQ@mail.gmail.com>
In-reply-to: Your message of "Mon, 10 Oct 2016 05:44:02 -0700." <CACfw2hiV9+qQ_OysHAQ4jd4fJtN2a=mrHqDiTkg4JArQ_LoGtQ@mail.gmail.com>
Date: Tue, 11 Oct 2016 01:56:42 +1100
Message-Id: <20161010145642.401EB56260C8@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Tci-g6UsWAipR3_vH4UZSDSYHZo>
Cc: Matthew Pounsett <matt@conundrum.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 10 Oct 2016 14:56:49 -0000

In message <CACfw2hiV9+qQ_OysHAQ4jd4fJtN2a=mrHqDiTkg4JArQ_LoGtQ@mail.gmail.com>
, william manning writes:
> 
> Unfortunately we are no longer in the early days of the Internet AND the
> IETF has no business in enforcing compliance with our protocol standards.
> That's for the zone operators to do.  We are not the dns police.  Even Paul
> mocapetris has called for more innovation in the dns space.   We must not
> presume there is just one way to do things.

If the IETF was setting servers that went and checked DNS servers
and informed the operators then the IETF would be in the business
of enforcing protocols.  At this stage I don't see the IETF doing
that nor is this document asking the IETF to do that.

The is a difference between innovation and not exercising care /
lazyness.

Returing FORMERR because you see a EDNS flag you don't understand
is not innovation.

Returing FORMERR because you see a EDNS option you don't understand
is not innovation.

Returing FORMERR because you see a EDNS version you don't understand
is not innovation.

If there was anything innovative in what I'm seeing I'd be all for
it but there isn't.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email