Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Paul Wouters <paul@nohats.ca> Wed, 23 March 2016 21:47 UTC

Return-Path: <paul@nohats.ca>
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 C5E4412D688 for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2016 14:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 ARbl_3OMMiOB for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2016 14:47:39 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C11CF12D652 for <dnsop@ietf.org>; Wed, 23 Mar 2016 14:47:39 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qVjpc3q8pz3Q1; Wed, 23 Mar 2016 22:47:36 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bKm_lec73b1J; Wed, 23 Mar 2016 22:47:35 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 23 Mar 2016 22:47:35 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id AA5F3614CB60; Wed, 23 Mar 2016 17:47:33 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca AA5F3614CB60
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A907D10005AE; Wed, 23 Mar 2016 17:47:33 -0400 (EDT)
Date: Wed, 23 Mar 2016 17:47:33 -0400
From: Paul Wouters <paul@nohats.ca>
To: "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
In-Reply-To: <d47928f75e3e4e52a375429452a1ded8@mxph4chrw.fgremc.it>
Message-ID: <alpine.LFD.2.20.1603231745380.21525@bofh.nohats.ca>
References: <CAC=TB13r_7TPEcUeZqH6sxqKXHRn7TgFwLwdqjBxa57aqS1MZg@mail.gmail.com> <alpine.LSU.2.00.1603221140220.11434@hermes-2.csi.cam.ac.uk> <CAHPuVdVMMYny9d68fGeLPKUWZvEjD+Kk-in6eFrO=sND7bRtQw@mail.gmail.com> <CAC=TB11OrH1Myro+CCEMJWy67nYhDCrGWVhe+jM568o2CL7vEA@mail.gmail.com> <alpine.LSU.2.00.1603231024200.19314@hermes-2.csi.cam.ac.uk> <d47928f75e3e4e52a375429452a1ded8@mxph4chrw.fgremc.it>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/dPxR2DC8w9lEi1rRLAXBWsgX82w>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Subject: Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 23 Mar 2016 21:47:41 -0000

On Wed, 23 Mar 2016, Darcy Kevin (FCA) wrote:

> The more generalized form, of course, is for the client to provide a bitmap and/or an enumerated list, of the RRTYPEs it wishes to receive and/or not receive.
>
> One of the sticky problems to deal with, however, is how the server should respond if it implements some, but not all of the RRTYPEs requested (spike the whole transaction with a NOTIMP? return the ones it knows about and a pseudo-RR representing the ones it doesn't?)

That has been suggested in the past as well, but it seems it was not
liked eiter. We even already have the bitmap as it is used for NSEC3.

Since at the time I wanted it for "additional crypto" records, and
that seemed to have moved to SRV style prefix records, I didn't
try harder.

Paul