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

joel jaeggli <joelja@bogus.com> Wed, 30 September 2015 23:21 UTC

Return-Path: <joelja@bogus.com>
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 0F0541ACCDE; Wed, 30 Sep 2015 16:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 a2ihTOjENgLj; Wed, 30 Sep 2015 16:21:50 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 711C51ACCD8; Wed, 30 Sep 2015 16:21:50 -0700 (PDT)
Received: from mb.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t8UNLlT0052705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Sep 2015 23:21:47 GMT (envelope-from joelja@bogus.com)
To: Paul Hoffman <paul.hoffman@vpnc.org>, Ben Campbell <ben@nostrum.com>
References: <20150930223254.13589.7128.idtracker@ietfa.amsl.com> <D77F0485-0C3B-4509-A99E-80E42A6DAC9E@vpnc.org>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <560C6E83.8060508@bogus.com>
Date: Wed, 30 Sep 2015 16:21:39 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Thunderbird/41.0
MIME-Version: 1.0
In-Reply-To: <D77F0485-0C3B-4509-A99E-80E42A6DAC9E@vpnc.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Tg3r0v1vr4WSxloHGJ2fvkEmjgbxgvFO3"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/lam9KexIAe-pMc5uOn-aj_b3rmw>
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:21:52 -0000

On 9/30/15 4:08 PM, Paul Hoffman wrote:
> 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?

The question for the  w.g. is are they aware of it?  the answer to that
is yes.

WRT to do they care care enough to withhold this document, I think we
have very little evidence for that.

> 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
>