IETF Logo Mail Archive

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

Dick Franks <rwfranks@acm.org> Tue, 05 March 2019 10:55 UTC

Return-Path: <rwfranks@gmail.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 8AB29131059 for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 02:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 3VxieAolZV-8 for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 02:55:26 -0800 (PST)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 6064012941A for <dnsop@ietf.org>; Tue, 5 Mar 2019 02:55:26 -0800 (PST)
Received: by mail-io1-f54.google.com with SMTP id x3so6662249ior.6 for <dnsop@ietf.org>; Tue, 05 Mar 2019 02:55:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yQeueQciOuIAhr614V45Vlqy2watyZlXBTkaOagJ3+A=; b=Zr6mkPHxERs4r40OfyeJs7Gbc34O6/x/5XIO1sEJ8gTPcxMGRmaIEjhA7/vcOzUC8s sgyoCtVoyWiNqcTVaFHX35ZrcZrqm3LPDmViLMVGzTPr4bmZ8TH6X/nScEfXdPYV4uDf Vot53hQFwkKp4uxlTZ8qQuFODSq/FU7v7stTTD38y1pUMhuhr5/YsR+gjzeTBB+1rFrg bo/bj8yHmd0icMjz3U/bmkmuq1vUE32juo5RTF847nh4vnVay921iorwZV3UPsyPTwGs LC8VsXQvtwSiB62ROCBe/i6cA4SC1uxMmgbwZ/E4HAxXvAecWIrcpFcqKU181v4a7mgy L9KQ==
X-Gm-Message-State: APjAAAV+B3AlxVCNO0c9833A6YvnT1B+kqV6D5r860FWjuCtyEAIkclB laOswjPF6ZFzF32b1NUWttF1+fHNScgOlCKx8UlDOQ==
X-Google-Smtp-Source: APXvYqyQn5Xb/J/OYhiuXe8gBhPP0Xtx96JUuaqMRQi6A0kNJr18qds0J6LYrnFvfl1NIbdurucqSVsDiZ7XNMhLqzk=
X-Received: by 2002:a6b:c545:: with SMTP id v66mr13081940iof.40.1551783325435; Tue, 05 Mar 2019 02:55:25 -0800 (PST)
MIME-Version: 1.0
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <accf01be-9813-c708-073e-e5f22948ccbc@time-travellers.org> <a3dd345a-3be5-9a40-e3e6-f6a29d04fcd4@bellis.me.uk>
In-Reply-To: <a3dd345a-3be5-9a40-e3e6-f6a29d04fcd4@bellis.me.uk>
From: Dick Franks <rwfranks@acm.org>
Date: Tue, 05 Mar 2019 10:54:49 +0000
Message-ID: <CAKW6Ri6AnhKTm4LwERjnfArPWUQeCmwZ5SBsdWp9Y6amXuWLJA@mail.gmail.com>
To: Ray Bellis <ray@bellis.me.uk>
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e18a11058356b52b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6MPmlmStCYpuevOmysbiTpdCYBo>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 05 Mar 2019 10:55:29 -0000

On Tue, 5 Mar 2019 at 09:27, Ray Bellis <ray@bellis.me.uk> wrote:

8<

Stretching the analogy to BGP communities slightly (the authors had
> already discussed this internally when working on the draft, and Wes has
> made that comparison too):
>
> Folks *could* have decided to use some unassigned BGP Path attribute
> value to carry similar information, but each implementor would have had
> their own special version of it.   Making it _standardised_ is what
> allows support to be ubiquitous (and interoperable).
>

But that is not the case here.
Even if the mechanism were to become standardised and ubiquitous, each
instance would be interoperable only between two specific consenting
parties.
IMHO this falls into the "local use" category.

--Dick

v2.23.0 | Report a Bug | By Email