Re: [DNSOP] Comments on draft-ietf-dnsop-extended-error version 10
Wes Hardaker <wjhns1@hardakers.net> Mon, 30 September 2019 21:05 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 8F8C512016E for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 14:05:58 -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 wefOWLPDHD23 for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 14:05:57 -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 4AA0B12007C for <dnsop@ietf.org>; Mon, 30 Sep 2019 14:05:57 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 5222A299DD; Mon, 30 Sep 2019 14:05:48 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Mats Dufberg <mats.dufberg@internetstiftelsen.se>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
References: <1BBB6AC2-263F-42A9-99FC-48BAC3B4AF7E@iis.se>
Date: Mon, 30 Sep 2019 14:05:48 -0700
In-Reply-To: <1BBB6AC2-263F-42A9-99FC-48BAC3B4AF7E@iis.se> (Mats Dufberg's message of "Mon, 30 Sep 2019 12:46:39 +0000")
Message-ID: <yblimp94hqr.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/ktljP3knbtCKd5V-SnqznYN6k1o>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-extended-error version 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:05:59 -0000
Mats Dufberg <mats.dufberg@internetstiftelsen.se> writes: > Section 1 ends with "Receivers MUST NOT change the processing of > RCODEs in messages based on extended error codes" but it is not fully > clear what that statement means in the light of the description in the > beginning of the same section where the motivation for extended error > codes is that the resolver cannot know what specific error that is > behind, e.g., REFUSED and there does not know what the best next step > is. See the discussion with Eric about new wording for that sentence. That being said, I think your point is valid about misunderstanding the purpose as well. So I've added this sentence to the end of the first paragraph: What error messages should be presented to the user or logged under these conditions?</t> Seem ok? > Both section 3.18 (filtered) and section 3.19 (prohibited) has code 17. In the > registry table (4.2) it is code 17 and 18, respectively. Fixed, thanks. > Both 3.14 (Cached error) and 3.20 (Stale NXDOMAIN answer) reports that the > RCODE returned was taken from cached. In 3.20 it is described in detail what > the resolver has done before the answer is returned, whereas in 3.14 there are > not details at all. > > 3.14 needs more specification of when to use cached SERVFAIL. Hmm... What more would I put other than "the resolver is to include this when it returns a SERVFAIL from the cache?" I've changed the text to The resolver is returning the SERVFAIL RCODE from its cache. Which I think is clearer. > I think that the last sentence in 3.20 ("This is typically caused [...] result > of a DoS attack against another network") does not belong to a standard > document. I've changed it to this: This is may be caused, for example, by problems communicating with an authoritative server, possibly as result of a DoS attack against another network. Which removes "typically", which I think you're right is out of place. I don't think removing the sentence is helpful to the reader, so I'd rather fix it. > In 3.22 it would be better to say that the operation or query is not supported > ("Not supported"). As the text is now it is unclear by whom it is deprecated. Ok, I'm fine with that. Changed. > I suggest that the sentence "This may occur because its most recent > zone is too old, or has expired, for example" is removed from 3.25 > since there could be multiple reasons and it is not needed to give an > example in a standard document. I'm not sure why you think examples aren't useful in standards documents? IMHO, they're used all the time (the IMAP RFC is one of my favorites that is full of example usages). In the previous example you brought up above, I agree that we shouldn't be determining commonality of possibilities. But I think examples in generally greatly help the reader determine how to more accurately interpret a specification. -- Wes Hardaker USC/ISI
- [DNSOP] Comments on draft-ietf-dnsop-extended-err… Mats Dufberg
- Re: [DNSOP] Comments on draft-ietf-dnsop-extended… Wes Hardaker