Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 01 February 2012 18:56 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8F11E8080; Wed, 1 Feb 2012 10:56:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328122560; bh=Wrv/kGUR1wtKEaa+4dslEZmT+ybrBwXLhza0Do31ccY=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=q5+NTnZK4UWeAea8+MNqqsPtaAp0qX/yY8VBULeQatS6LQXoxZRJHjWmcYVlza4L5 kmU0w/Mi2YuDHB3p0W5O/sivLwSe47FoAUJFUOjp1GZ0iWuY1tRX5DH6IrNVXT0baV A/RgCkqlqV53ffPAqT8gBm8KL/Rpr25BOmbiONA0=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E572811E8080 for <dnsext@ietfa.amsl.com>; Wed, 1 Feb 2012 10:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level:
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aANF+QwtH91t for <dnsext@ietfa.amsl.com>; Wed, 1 Feb 2012 10:55:59 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C020111E8071 for <dnsext@ietf.org>; Wed, 1 Feb 2012 10:55:53 -0800 (PST)
Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q11Ito2c022173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dnsext@ietf.org>; Wed, 1 Feb 2012 11:55:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4F2967EF.8070502@nlnetlabs.nl>
Date: Wed, 01 Feb 2012 10:55:50 -0800
Message-Id: <4A30B716-F051-41F5-B237-29C6397289A5@vpnc.org>
References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F2967EF.8070502@nlnetlabs.nl>
To: DNSEXT Working Group <dnsext@ietf.org>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Big:

5.10 is long, scary, and useless for most environments because most environments will have just one trust anchor. Please add the following after the first paragraph of the section:

When DNSSEC was first published, many sites had multiple (and sometimes nested) trust anchors. Now, it is believed that very few do. If a site has a single trust anchor, the information in this entire section can safely be skipped.

Medium:

5.6 (setting the DO bit in replies) suggests resolvers should "be liberal in what they accept". That's a bit vague. Instead, say what you mean "In order to interoperate with implementations that ignore this rule on sending, resolvers need to allow either the DO bit to be set or unset when receiving responses". However, that's still not as honest as I would like. "Because some implementations ignore this rule on sending, the rule for receivers is now that they MUST NOT expect the DO bit to be set as it was sent."

In 5.8, it is unclear what "protect" means. Either clarify what is being protected or use a different word.

Small:

1.1 should start "The clarifications and changes to ..."

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext