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

Ray Bellis <ray@bellis.me.uk> Fri, 08 March 2019 14:53 UTC

Return-Path: <ray@bellis.me.uk>
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 1BC35129AB8 for <dnsop@ietfa.amsl.com>; Fri, 8 Mar 2019 06:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.net
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 8bhyAghym1BO for <dnsop@ietfa.amsl.com>; Fri, 8 Mar 2019 06:53:39 -0800 (PST)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 67082131359 for <dnsop@ietf.org>; Fri, 8 Mar 2019 06:53:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UeVb8edDKJXlkWO3jPQRECqbmh8wQVXWa9QMoqxrWfI=; b=L1ka9l7ikhsgJNPJufjHAYapwZ dvGtYFwtd8mWXwz+Q+Ec4FqsGlMUoNm6DoysTe8cnM+0jO4WR5gUdFQDV1PaGE76gIEWkEHvQcTtB jcPa6Uhf2U1A3W1QB22BGHbEqFBQdYrPNKL2xOwQMnPIRNEOEJJDZx1PFktv/oCbaPMQ=;
Received: from [88.212.170.147] (port=58757 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h2GsT-00078Z-8a (Exim 4.89) (return-path <ray@bellis.me.uk>); Fri, 08 Mar 2019 14:53:37 +0000
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop@ietf.org
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <yblef7mp7io.fsf@wu.hardakers.net> <CAKW6Ri5doXL=uBpEy3Eqrkoyfu9rvt9upH9qxXkzZKUgS_=dMw@mail.gmail.com> <ybla7iap5nx.fsf@wu.hardakers.net> <B137690E-8063-4416-BFE2-706F0589AD5F@isc.org> <yblsgw125x4.fsf@w7.hardakers.net> <40758bbd-5289-8e21-8043-3c3d09c6b8d1@nic.cz> <bd27789a-e6f8-adca-874f-a4c298f0891f@bellis.me.uk> <alpine.LRH.2.21.1903072249100.7137@bofh.nohats.ca> <5f06e2ad-3710-4dbf-3c04-ca31f8b19c4a@bellis.me.uk> <alpine.LRH.2.21.1903080916520.20997@bofh.nohats.ca>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <e07b94d6-d974-4e4f-5519-a90cc0e98979@bellis.me.uk>
Date: Fri, 08 Mar 2019 14:53:36 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.21.1903080916520.20997@bofh.nohats.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ksy0x-h8a6e1M2NQ-bxK9QeVLK4>
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: Fri, 08 Mar 2019 14:53:42 -0000

On 08/03/2019 14:28, Paul Wouters wrote:

> But assigned and left completely opague is not really suitable for
> "heterogenous off-the-shelf software". These different vendors must
> understand the meaning of the opaque data even if their functionality
> can be non-standard.

No, it does *not* require that at all.

We very careful referred to the *operators* of the software in the 
draft, not the implementors.

The intention is that software operators can define rules in their 
configuration files such that *they* determine which values have what 
meaning.    Just like how a BGP router can use BGP communities within 
routing policy maps.

In the load-balancer case, they might decide to use a few bits to select 
one of several RPZ feeds, or perhaps a view, without having to pass the 
client IP for the use a "source match" ACL to the backend.

They might decide to use another bit to indicate that the client is 
trusted such that the server doesn't need to apply RRL.

Granted this will need some form of representation in whatever 
configuration syntax is in use, but that would be implementation 
dependent.   The minimal implementation would just need to be able to 
test "tag & mask == value".

Ray