IETF Logo Mail Archive

Re: [dbound] On (not) moving forward

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 30 March 2016 13:47 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE0912D6B2 for <dbound@ietfa.amsl.com>; Wed, 30 Mar 2016 06:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 a-PpzWb5KanB for <dbound@ietfa.amsl.com>; Wed, 30 Mar 2016 06:47:08 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B853C12D658 for <dbound@ietf.org>; Wed, 30 Mar 2016 06:44:22 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id z68so61264403vkg.3 for <dbound@ietf.org>; Wed, 30 Mar 2016 06:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tnLIjluPZSitPFYzpaak/cpc8NuzUAzLqg9U2utn74s=; b=DDlYrOHLIZuBie8GrG022H7ktSNK3E8jmqnQiDzlVqfc0EWndggC5C48gyIwAc/8wb p2zS7kltzRKCeVNFWAI6nbjYjJ4tCkZfvmt3rW+0SY2+p1y4FlONvcLJKwaD5zw495J3 quuQWU6Sk07xQjVXMN1hiv1DJl186lO8zhExMxjEMzbZyUOWOV5UHUf3hvGGz4fp4b20 9/ce67B8q7D0MzPAWl81LeeoY8UVgdfati6xppu6xOAGbtYB5pf5hwYAGeAmlw8VIv2/ eh6mpp59Uam8KzariTUd88ywk/Qw02CMQjVZ3ahZNPjI6ez1m3hna1x5hUOC48nD5LZV IPig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tnLIjluPZSitPFYzpaak/cpc8NuzUAzLqg9U2utn74s=; b=aQwy7AfLGjjaYW3X9IApPlotlsagmjhjPk0zdvauP6KnrBF1sCMk9wp1WaI2k12ugx GFqSgD6QfMyU8Qv39DVIIqKJsOMWE+cteesmtD/JDDfAXd7hZy2rx4AiRo3+2pCcSLLs 81iCoO4wBzSH9OhttRZ3LSvcG5KxjRDqulfzYvDn5ukYEa2rSv5WDuRhDYsrmlruA4SD px4hTfNmHwzGA56zO1osz6ISvWmowrTA/WVncHr3j0TWK7j/JxdZBsnuYVFUfY0smLMl cTlLzVyMTpGTD8ZsuVzczNi5W95z+604nQ8guiZ8co02R/uRyrjzxhJNYLJElfM99UMu 0/Lw==
X-Gm-Message-State: AD7BkJLaC0K8+TfTxCSrUpl546I5Yz/QnOQNf1gNjBHDIz4o6FttMbFP9IEtYXs6g59dPD9qI9PIcWRYEOluiA==
MIME-Version: 1.0
X-Received: by 10.31.151.11 with SMTP id z11mr5126047vkd.131.1459345461842; Wed, 30 Mar 2016 06:44:21 -0700 (PDT)
Received: by 10.103.43.5 with HTTP; Wed, 30 Mar 2016 06:44:21 -0700 (PDT)
In-Reply-To: <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org>
References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <BDA80845-43DB-43EC-B371-DD1770A604CA@vpnc.org> <56F8F033.40209@mozilla.org> <CAL0qLwadNjhWVNOCxdypyRZ9yyhuvPWHKCPpb1Ub49y3QT-Hnw@mail.gmail.com> <F65E8756-3FB4-40CD-8FD7-77E2979DDBC6@vpnc.org> <56F9E01D.4050007@it.aoyama.ac.jp> <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org>
Date: Wed, 30 Mar 2016 06:44:21 -0700
Message-ID: <CAL0qLwZutfDY+LKWRnyzFDnjtxzkqEdObx1LXpZR872ng1Vxxg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="001a1140f86adb9c12052f44577b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dbound/HGAEHRFMnqN31Ff5X8idMox9UFs>
Cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [dbound] On (not) moving forward
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2016 13:47:10 -0000

On Mon, Mar 28, 2016 at 7:09 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On 28 Mar 2016, at 18:53, Martin J. Dürst wrote:
>
> The problem would be with the operators. It's quite possible that DNS
>> operators would start adding such records if there's a standards track
>> spec. I could even imagine them to be motivated to add the relevant records
>> if there is *one* experimental spec. But multiple experimental specs? Not a
>> splitter of a chance, if you as me.
>>
>
> Why not? If they only had to pick one of three, why is that harder than
> picking one of one?


A desire to interoperate, I would imagine.  I would want to pick the same
one other operators will use, and that other clients will use.  Otherwise,
to be sure of participation, I have to implement all three.

-MSK

v2.23.0 | Report a Bug | By Email