Re: [DNSOP] Ben Campbell's Discuss on draft-ietf-dnsop-root-loopback-04: (with DISCUSS and COMMENT)

"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 30 September 2015 23:08 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65051AC42A; Wed, 30 Sep 2015 16:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 cM6g1G6NHzTu; Wed, 30 Sep 2015 16:08:49 -0700 (PDT)
Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 C081F1AC429; Wed, 30 Sep 2015 16:08:49 -0700 (PDT)
Received: from [10.32.60.140] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8UN8exk072578 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2015 16:08:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.140]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Ben Campbell <ben@nostrum.com>
Date: Wed, 30 Sep 2015 16:08:40 -0700
Message-ID: <D77F0485-0C3B-4509-A99E-80E42A6DAC9E@vpnc.org>
In-Reply-To: <20150930223254.13589.7128.idtracker@ietfa.amsl.com>
References: <20150930223254.13589.7128.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/dVgdUslo96ZocvvFCwwZ64itGgs>
Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-root-loopback@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-root-loopback.ad@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dnsop-root-loopback.shepherd@ietf.org
Subject: Re: [DNSOP] Ben Campbell's Discuss on draft-ietf-dnsop-root-loopback-04: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 30 Sep 2015 23:08:51 -0000

On 30 Sep 2015, at 15:32, Ben Campbell wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is just a process discuss:
>
> The IPR disclosure at http://datatracker.ietf.org/ipr/2539/ says that 
> due
> to the early state of the draft, license terms will be provided later.
> Obviously the draft is beyond early stages now. Does it make sense to 
> ask
> for an update before progressing this draft?

That's a question for the IESG, not the DNSOP WG, correct?

Having said that, it's not clear why the IESG would want to allow 
Verisign, or anyone else who says that they have a patent that they say 
they believe applies, to block progression of a document in the IETF. 
For an informational document such as this, maybe the damage of waiting 
months for a response is not a big deal, but doing so kinda sets a bad 
precedent for more timely standards track documents.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> -- section 1, paragraph 7: "Thus, recursive resolver software such as
> BIND will not need to add
>  much new functionality, but recursive resolver software such as
>  Unbound will need to be able to talk to an authoritative server"
>
> It might be useful to mention the properties of BIND and Unbound that
> make the difference.

We did that in the sentence preceding the one quoted. That is, the 
property is that BIND also contains an authoritative resolver, but 
Unbound does not.

>
> -- 1, paragraph 8: "Because of the significant operational risks
> described in this
>  document, distributions of recursive DNS servers MUST NOT include
>  configuration for the design described here."
>
> This made my day!

Glad to hear it! Others seemed to have chuckled over our disclaimer of 
originality in Section 7. If we can elicit as much laughter here as for 
an April 1 RFC, Warren and I have done our jobs.

--Paul Hoffman and Warren Kumari