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

Dick Franks <rwfranks@acm.org> Mon, 04 March 2019 23:22 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 B21B013115D for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 15:22:39 -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 rcWvUeE3c7XE for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 15:22:38 -0800 (PST)
Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) (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 33BF9131130 for <dnsop@ietf.org>; Mon, 4 Mar 2019 15:22:38 -0800 (PST)
Received: by mail-it1-f179.google.com with SMTP id g17so1478716ita.2 for <dnsop@ietf.org>; Mon, 04 Mar 2019 15:22:38 -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=G58ERGDUSTz5GstX5U0xfj0bHsISTBKGMj/gcf7Yftc=; b=RuGmB1P9zhscg6iLcaE3NoQw09sU4d+rIKiTmisIVIAn6sFPG07DjUKC2g0VUMVhf5 U8BMsIEgXKTl+xgjht5+7Z7R/ksVgnwNWcrfWG2w4DLctIRoKm3ay9nordkt0aa1jp8d CIS1elaW+jAYywLjbUIE+5vQj9KQP46He2VTtoAzghIAAdvIwT5rXs4pL8/EKpr5FMSd 33I+4vBxWkYYl7tpUaTJ7BbQbPJlmOpsMsHrPrW9dN/Mcx5VJJxQcrQHY9tuSchS3jEz O1kLsNVqi5t0Y4YBH5KwtI0KXJ+aJ1hl5OYZ+khyyucGxxX4TpNjvT4iOB6AhBUxZ8Za +7xg==
X-Gm-Message-State: APjAAAWycIllxy52/EJiGFgruO+uT/fd9t6eXMyBpqHAIL6aVVm/9+3U uhiaILLnxaOpscieFvptzxZh68ONndjOMHwFkmQTbQ==
X-Google-Smtp-Source: APXvYqxo+VMbgzyYNuIc3avDSswChpXpVwrDG8wBZyZxfkntXBGLeLugDMkvDmOJFRWu5trHGG9+pZVqFSQ3esbvlbE=
X-Received: by 2002:a24:a85:: with SMTP id 127mr960996itw.40.1551741757325; Mon, 04 Mar 2019 15:22:37 -0800 (PST)
MIME-Version: 1.0
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <yblef7mp7io.fsf@wu.hardakers.net>
In-Reply-To: <yblef7mp7io.fsf@wu.hardakers.net>
From: Dick Franks <rwfranks@acm.org>
Date: Mon, 4 Mar 2019 23:22:01 +0000
Message-ID: <CAKW6Ri5doXL=uBpEy3Eqrkoyfu9rvt9upH9qxXkzZKUgS_=dMw@mail.gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: Ray Bellis <ray@isc.org>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003a84c905834d080f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/opUgfWctKUz2f0qPuSsSHLFmvKM>
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: Mon, 04 Mar 2019 23:22:40 -0000

On Mon, 4 Mar 2019 at 23:03, Wes Hardaker <wjhns1@hardakers.net> wrote:

> Ray Bellis <ray@isc.org> writes:
>
> > This new draft describes a way for clients and servers to exchange a
> > limited amount of information where the semantics of that information
> > are completely unspecified, and therefore determined by bi-lateral
> > agreement between the client and server operators.
>

8<

What happens when the upstream software changes?  Or the upstream server
> is taken over by a new company that deploys entirely new semantics?  How
> is that change communicated to all the clients?  What if the new bits
> mean something entirely different, potentially the exact opposite?  How
> are conflicts like this handled?
>

The conflict never arises.
As the man said, "[semantics are] determined by bi-lateral agreement".
If the counter-party decides to do something different, it has repudiated
the agreement.

--Dick