Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

"Adrien de Croy" <adrien@qbik.com> Thu, 31 March 2016 20:28 UTC

Return-Path: <adrien@qbik.com>
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 22CA912D825 for <dnsop@ietfa.amsl.com>; Thu, 31 Mar 2016 13:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JqvdusGt3HIi for <dnsop@ietfa.amsl.com>; Thu, 31 Mar 2016 13:28:31 -0700 (PDT)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (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 DF2C912D823 for <dnsop@ietf.org>; Thu, 31 Mar 2016 13:28:30 -0700 (PDT)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v8.5.6 (Build 4877)) with SMTP id <0000687897@smtp.qbik.com>; Fri, 01 Apr 2016 09:28:28 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Adrien de Croy <adrien@qbik.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Date: Thu, 31 Mar 2016 20:28:28 +0000
Message-Id: <emd20a6d5d-7121-44af-925a-82a3fec17474@bodybag>
In-Reply-To: <em62d47c76-b3cc-4ae4-b826-c7d03c455d56@bodybag>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/UsXdMgAnb8kPiD8iJq1liZnI7cY>
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Adrien de Croy <adrien@qbik.com>
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: Thu, 31 Mar 2016 20:28:33 -0000

sorry, that second reference should have also been RFC 2826

neither the word "Maintaining" nor "architectural" are present in 2826 
according to the search function in Chrome.

Adrien


------ Original Message ------
From: "Adrien de Croy" <adrien@qbik.com>
To: "Paul Hoffman" <paul.hoffman@vpnc.org>; "dnsop@ietf.org" 
<dnsop@ietf.org>
Sent: 1/04/2016 9:25:07 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>
>
>------ Original Message ------
>From: "Paul Hoffman" <paul.hoffman@vpnc.org>
>To: "dnsop@ietf.org" <dnsop@ietf.org>
>Cc: "adrien@qbik.com" <adrien@qbik.com>
>Sent: 1/04/2016 12:31:53 a.m.
>Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
>
>>On 30 Mar 2016, at 18:49, John Levine wrote:
>>
>>>Isn't it a little late to be refighting this argument?
>>
>>+1.
>
>I guess now we have some hindsight maybe we could learn from the 
>experiences with .onion and maybe look differently at a proposal for 
>.alt.
>
>
>>
>>Folks: this thread is about a specific document, not every other thing 
>>we have discussed before now. If you want to rediscuss (as I sometimes 
>>do), please at least reference in the document where your argument 
>>fits. That way, the document authors can maybe amend the document if 
>>there is consensus to do so.
>Well I would start with what is presented as a quote from RFC 2826 
>which isn't actually in RFC 2686 and which seems to be the basis for a 
>claim of even doing a special use names registry at all.
>
>In Section 4. Architectural considerations
>
>"Maintaining a globally-unique public namespace that supports different 
>name resolution protocols is hence an architectural requirement..."
>
>Adrien
>
>
>>
>>--Paul Hoffman
>>
>>_______________________________________________
>>DNSOP mailing list
>>DNSOP@ietf.org
>>https://www.ietf.org/mailman/listinfo/dnsop
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop