
From nobody Wed Jun  5 07:36:44 2019
Return-Path: <Alexander_Brotman@comcast.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 56548120146 for <dbound@ietfa.amsl.com>; Wed,  5 Jun 2019 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 eUl3bUfsO-dl for <dbound@ietfa.amsl.com>; Wed,  5 Jun 2019 07:36:42 -0700 (PDT)
Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (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 1BB18120145 for <dbound@ietf.org>; Wed,  5 Jun 2019 07:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1559745378; x=2423658978; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JPvynseOhjYcLnikh8Gy0P2xCjeICPooB1/hF7C8aK4=; b=6GaPI/Ln3cumuI7pho8gKtylfUTrfMzZwUExY54WM7jK5YBlVqhn7C6vDEFPQaj/ mXthbb++5OMEnEWzyI2T1ABJJW1svpH5ELopd7SoV7MLOZclGwMge6X9vN9oifok NV1PfPemw5ddQbCfrojcYPM018b4935oBgSHovd9UHceg4eeoIYhZxg6CK725xh7 0KLE6NHOqa+f5nCsYeGWXAmRpwTcrWIpAKyTL3mrlPQw3cQk9U51+nz8tHDiIO+a 0uQnHXcFWhEDkgaKA/lwdhLWdglstrHlRAmvZDNAhOQP90YXKJCK+6djbTccjiEu err47dPO/9CDcbp7sTBk0A==;
X-AuditID: a2962c47-cebff70000021564-75-5cf7d362394c
Received: from COPDCEX18.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id D3.17.05476.263D7FC5; Wed,  5 Jun 2019 08:36:18 -0600 (MDT)
Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX18.cable.comcast.com (147.191.124.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 5 Jun 2019 08:36:26 -0600
Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1473.004; Wed, 5 Jun 2019 08:36:26 -0600
From: "Brotman, Alexander" <Alexander_Brotman@comcast.com>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: RDBD Questions 
Thread-Index: AdUbq/YfMyrF/wrcSlqq/9FGhGzr8A==
Date: Wed, 5 Jun 2019 14:36:26 +0000
Message-ID: <e90bf1c1071b4255841c6b99bd668cb8@COPDCEX19.cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWSUDRnsm7S5e8xBlde8ljsunyN3YHRY8mS n0wBjFENjDYlGUWpiSUuqWmpecWpdlwKGMAmKTUtvyjVNbEopzIoNSc1EbsykMqU1JzMstQi fazG6GM1J6GLKeP76j3sBR94K9pnfmdpYGzk7mLk4JAQMJHo/+bRxcjJISRwmEli+hqRLkYu IPsgo0Tvo9msEM4JRomd0z6xgVSxCVhJvP3fzgxiiwioS7xfdQ7MFhaQkLj2tokNIi4r0XXj IhOErSfxeNsjVhCbRUBF4kPfHEYQm1fAS2L1ioPsIDajgJjE91NrwOqZBcQlbj2ZD2ZLCAhI LNlznhnCFpV4+fgfK4RtILF16T4WiAfkJT7OhWrVkViwG+JMZgFtiWULXzNDrBKUODnzCQtE q7jE4SM7WCcwis5Csm0WkvZZSNpnIWlfwMiyipHX0MxIz9DUQM/ERM/ccBMjMOIXTdNx38H4 4XzsIUYBDkYlHt4vh77HCLEmlhVX5h5ilOBgVhLhTbz9JUaINyWxsiq1KD++qDQntfgQozQH i5I47+HD32KEBNITS1KzU1MLUotgskwcnFINjL7lufv5pvyv9lzkyh04q3fOdpdVWdMTO/Yl ej63XBC6VTF006YF+gunc21YZ/9Bi8vT6oLVRX8h69lrhMv1PuxX0/oqtMNSLfRm7orIXp89 ZVahfQ8udSjdk+znsIkzeJ3zsKF+25qjZkrfjz4tmhK4dVNbrvHHzh37IrsmH+ksOj5lUfw2 aSWW4oxEQy3mouJEAFf2klH0AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/oMNWuQrftEZd9Id0jrt8HxQnvrQ>
Subject: [dbound] RDBD Questions
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Jun 2019 14:36:43 -0000

Hello all,

Stephen and I were able to sit down and discuss the feedback that was recei=
ved during IETF and via the mailing list.  Based on that conversation, we'r=
e planning to make the following changes but would be happy to get any feed=
back before/as we do that.

1) A couple of people wanted a method for disavowing a relationship, i.e. m=
aking a negative assertion.  We believe we can achieve this by defining ano=
ther tag within the RDBD RR.
2) As part of adding negative assertions, we're proposing that we make it s=
o that any place where you might list a single name today, you could altern=
atively point to an HTTPS URL that points at a file containing a list of na=
mes.  When doing the negative assertion, this'd allow for an easier method =
to list numerous entries.
3) We'll explicitly document that the RDBD record type envisages multi-valu=
ed responses just to make it clear that both positive and negative records =
can be found at the same location.
4) We're not sure if there is a preference for the DNSSEC-style RR value we=
 used in the 01 draft, or for the DKIM-style value that was used in the 00 =
draft. (We will of course stick with a new RRTYPE and not go back to abusin=
g TXT:-) The end result is the same, but the format of the record value may=
 make more sense to some parties in one format or the other.  For the DKIM-=
style, this is a familiar format to many who have worked with SPF/DKIM/DMAR=
C records.  On the other hand, the DNSSEC-style might be more familiar to t=
hose managing the DNS systems. We've not yet decided which we prefer oursel=
ves, so feedback on this is most welcome.

Thank you again for your feedback.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

