Re: [DNSOP] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10

Paul Hoffman <paul.hoffman@icann.org> Mon, 30 September 2019 21:40 UTC

Return-Path: <paul.hoffman@icann.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 D0712120170 for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 14:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 dVfiX5itFBn9 for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 14:40:37 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 5CF1112013D for <dnsop@ietf.org>; Mon, 30 Sep 2019 14:40:37 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa2.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id x8ULeaoC007556 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Mon, 30 Sep 2019 21:40:36 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 14:40:34 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1473.005; Mon, 30 Sep 2019 14:40:34 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] Processing error codes in draft-ietf-dnsop-extended-error-10
Thread-Index: AQHVd9E65+KCQzr6oEq5zayXwkPalqdFNRaA
Date: Mon, 30 Sep 2019 21:40:33 +0000
Message-ID: <6419da25-924e-8d54-0700-48a4cd6d4d34@icann.org>
References: <CAMOjQcEtDBR29yKmOTvnx-7B7SmC9pox_kzOCKs4jBMQr1VSTA@mail.gmail.com> <yblblv15wv0.fsf@w7.hardakers.net>
In-Reply-To: <yblblv15wv0.fsf@w7.hardakers.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <0A4C425F7A3D72459C61F108FA33F423@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-30_12:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xUFwQARzoZV-6LP6G-QBYb6Jgl0>
Subject: Re: [DNSOP] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10
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: Mon, 30 Sep 2019 21:40:39 -0000

On 9/30/19 1:53 PM, Wes Hardaker wrote:
> Eric Orth <ericorth=40google.com@dmarc.ietf.org> writes:
> 
>> I object to the addition of "Receivers MUST NOT change the processing
>> of RCODEs in messages based on extended error codes."
> 
> Actually, I agree with you.  That text was from suggestion and I put it
> in unaltered.  I thought about changing it to a SHOULD NOT.

 From RFC 2119:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

Saying "SHOULD NOT" without helping the reading understand the implications is dangerous and will lead to lack of interoperability. Either this document specifies the exact places where an EDE can change the processing of the RCODE, or the current MUST NOT wording is correct.

It is feeling like there is widespread confusion about the purpose of EDEs. Some folks (apparently including the document authors) want to be be able to use the presence of an EDE to change the way resolvers act. It would be really good if there was a list of which EDEs might be used to change specific RFCs so that the WG can understand this better. In specific, the core DNSSEC RFCs specify how to handle certain RCODEs in certain circumstances with MUST-level requirements. Does this document change those requirements?

--Paul Hoffman