From jdfalk-lists@cybernothing.org Mon Aug 1 19:33:18 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220405E8004 for ; Mon, 1 Aug 2011 19:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z63wbtnvV1BW for ; Mon, 1 Aug 2011 19:33:08 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5521F8D0C for ; Mon, 1 Aug 2011 19:32:58 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p722WurM009451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 19:32:59 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p722WurM009451 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312252379; bh=4GXk3ODWFOmeDkhQ46kWt13uVqgYrUklP5vWI7DwZ MI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=X5sEdaJc79Jd MR/SyItYVZEMd0MtLK5m8bsbiNxYowuB5mxLObtvJl07Z46EwQtm8qtFKYtkIFBdR7n QzFZdUlhSvw5CemPr219nq+FaXY4eTpvmVvnvTTnKLFAkLGr2UJ3PJgXecdKEj+oXMO bePb4F8187zd3pf5lDaLeQAxY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Mon, 1 Aug 2011 19:32:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DBC6D86-E8D7-4062-99D1-FC1E1D60F652@cybernothing.org> References: To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] Drafting a new use-case: information dissemination ? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 02:33:19 -0000 On Jul 29, 2011, at 3:24 PM, Johan Pouwelse wrote: > At the 81th IETF BoF I've volunteered to contribute to the hopefully > soon-to-be WG REPUTE. Thank you! > This use case is focussed on collaborative and self-organising systems > where the users share resources freely. > We target the following four use case instances: > 1) open wifi base station - exchanging information between the > wireless and wired domain. > 2) Packet forwarding - Relaying packets in an Mobile Ad-hoc Network = (MANET) > 3) Caching proxy - Relaxing information for others in order to > enhance performance and privacy on the wired Internet > 4) file sharing - pooling storage capacity together in order to build > a vast archive of content >=20 > Commonality between the four instances is that without REPUTE there is = no mechanism to make an assessment of the trustworthiness of others. = Every participant in the above use case instances MUST use REPUTE to = determine if it should honour the request for resource usage. This looks like a perfect fit for REPUTE. I'd be curious to hear what = kind of vocabulary (or similar) you've developed thus far.... -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Mon Aug 1 23:03:56 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35E511E8088 for ; Mon, 1 Aug 2011 23:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.628 X-Spam-Level: X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzvAs2w+VOjN for ; Mon, 1 Aug 2011 23:03:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE3411E8075 for ; Mon, 1 Aug 2011 23:03:54 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 1 Aug 2011 23:04:02 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 1 Aug 2011 23:04:01 -0700 Thread-Topic: [domainrep] A sentence that confuses me Thread-Index: AcxK5yZ2hk1paTHrRPKtyWfbhKtDXgF8mYyA Message-ID: References: <20110725144616.GA1579@shinkuro.com> In-Reply-To: <20110725144616.GA1579@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] A sentence that confuses me X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:03:56 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Andrew Sullivan > Sent: Monday, July 25, 2011 7:46 AM > To: domainrep@ietf.org > Subject: [domainrep] A sentence that confuses me >=20 > In draft-kucherawy-reputation-query-dns-00, we have this: >=20 > In line with [DNS-EXPAND], the TXT resource record type is used for > this application. >=20 > But RFC 5507 says this: >=20 > We'll show how such a designer almost inevitably hits upon the idea > of just using a TXT Resource Record, why this is a bad thing, and why > a new Resource Record Type should be allocated instead. >=20 > How can these statements be reconciled? My tendency toward using TXT is from the last several years of email authen= tication work, where variously the SPF, Sender-ID, DomainKeys and DKIM prot= ocols and their various adjuncts all used TXT records to publish either key= s or policies. It's thus primarily there out of habit and not out of the i= dea that we have it right and the IAB got it wrong; I'd be fine with creati= ng a new RR type if that's the current wisdom, apart from the fact that it = will take some period of time for servers and resolvers both to begin suppo= rting it. This also presupposes that we get some buy-in from the community for puttin= g this data in the DNS rather than creating a new UDP-based protocol. I've= heard arguments from both sides of that fence. -MSK From msk@cloudmark.com Mon Aug 1 23:12:35 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7920D21F86DD for ; Mon, 1 Aug 2011 23:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fZo6iqEtfEd for ; Mon, 1 Aug 2011 23:12:32 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 54A4821F8CAA for ; Mon, 1 Aug 2011 23:12:32 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 1 Aug 2011 23:12:40 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 1 Aug 2011 23:12:39 -0700 Thread-Topic: When BoFs collide Thread-Index: AcxQ2y5Ph8HzzEaHQk6qYe5JicaXQQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF4E0EXCHC2corpclo_" MIME-Version: 1.0 Subject: [domainrep] When BoFs collide X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:12:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF4E0EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition to the REPUTE BoF in Quebec City (thanks to those of you who sh= owed up; the room was overflowing), reputation popped up in a couple of oth= er interesting areas. One of these was in the WEIRDS BoF, where the idea o= f starting work to replace WHOIS was considered. Specifically, security service providers (e.g., anti-spam companies and the= like) benefit from gathering some operational data about a domain or a net= work delegation from WHOIS. Information like which nameservers are in use,= to whom they are registered (for correlation, not for identification), reg= istration dates, etc. are all very useful in determining how likely or not = a particular source is to be abusive. These are valuable data points for r= eputation when evaluating either kind of registry object. But not only was that fairly obvious point made, but also there are rumoure= d to exist some registries, domain and network alike, that are (to put it p= olitely) somewhere below the desired standards of behaviour in terms of mak= ing usable data available via WHOIS, if they provide any at all (or even pr= ovide it truthfully). So not only is the reputation of the registry object= of interest, but so too is the reputation of the registry itself. Something to consider as this work develops. It's clear from the BoF discu= ssion that we probably want to limit our initial charter scope to be the em= ail domain space, but I believe we should continue with a framework that's = easily extensible into these other areas that several people have identifie= d as being potentially very interesting. -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF4E0EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In addition to t= he REPUTE BoF in Quebec City (thanks to those of you who showed up; the roo= m was overflowing), reputation popped up in a couple of other interesting a= reas.  One of these was in the WEIRDS BoF, where the idea of starting = work to replace WHOIS was considered.

 

Specifically, security service prov= iders (e.g., anti-spam companies and the like) benefit from gathering some = operational data about a domain or a network delegation from WHOIS.  I= nformation like which nameservers are in use, to whom they are registered (= for correlation, not for identification), registration dates, etc. are all = very useful in determining how likely or not a particular source is to be a= busive.  These are valuable data points for reputation when evaluating= either kind of registry object.


But= not only was that fairly obvious point made, but also there are rumoured t= o exist some registries, domain and network alike, that are (to put it poli= tely) somewhere below the desired standards of behaviour in terms of making= usable data available via WHOIS, if they provide any at all (or even provi= de it truthfully).  So not only is the reputation of the registry obje= ct of interest, but so too is the reputation of the registry itself.

 

Some= thing to consider as this work develops.  It’s clear from the Bo= F discussion that we probably want to limit our initial charter scope to be= the email domain space, but I believe we should continue with a framework = that’s easily extensible into these other areas that several people h= ave identified as being potentially very interesting.

 

-MSK

=
= --_000_F5833273385BB34F99288B3648C4F06F13512DF4E0EXCHC2corpclo_-- From msk@cloudmark.com Mon Aug 1 23:30:11 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF5421F8E81 for ; Mon, 1 Aug 2011 23:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.685 X-Spam-Level: X-Spam-Status: No, score=-103.685 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E52UAbwe6rDp for ; Mon, 1 Aug 2011 23:30:11 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4521F8E80 for ; Mon, 1 Aug 2011 23:30:11 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 1 Aug 2011 23:30:19 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 1 Aug 2011 23:30:18 -0700 Thread-Topic: Proposed charter, revised after BoF Thread-Index: AcxQ3aWRSBqDbOiOR9+ONjnljBoLng== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_" MIME-Version: 1.0 Subject: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:30:11 -0000 --_004_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_" --_000_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached is a revised charter based on the minutes Barry posted on Thursday= . Thanks to Barry for chairing the BoF and Jeff Hodges for taking notes. Please give it a once-over and let me know if you think it reflects the dis= cussion we had. Once there's agreement, I'll send it to the ADs for their = consideration. -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attached is a re= vised charter based on the minutes Barry posted on Thursday.  Thanks t= o Barry for chairing the BoF and Jeff Hodges for taking notes.

 

Please giv= e it a once-over and let me know if you think it reflects the discussion we= had.  Once there’s agreement, I’ll send it to the ADs for= their consideration.

 <= /p>

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_-- --_004_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_ Content-Type: application/octet-stream; name="repute-charter" Content-Description: repute-charter Content-Disposition: attachment; filename="repute-charter"; size=6163; creation-date="Tue, 02 Aug 2011 06:30:01 GMT"; modification-date="Tue, 02 Aug 2011 06:27:30 GMT" Content-Transfer-Encoding: base64 V29ya2luZyBHcm91cCBOYW1lOgoJUmVwdXRhdGlvbiBTZXJ2aWNlcyAoUkVQVVRFKQoKSUVURiBB cmVhOgoJQXBwbGljYXRpb25zIEFyZWEKCkNoYWlyKHMpOgoJVEJECgpBcHBsaWNhdGlvbnMgQXJl YSBEaXJlY3RvcihzKToKCVBldGUgUmVzbmljayA8cHJlc25pY2tAcXVhbGNvbW0uY29tPgoJUGV0 ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJAc3RwZXRlci5pbT4KCkFwcGxpY2F0aW9ucyBBcmVhIEFk dmlzb3I6CglUQkQKCk1haWxpbmcgTGlzdHM6CglHZW5lcmFsIERpc2N1c3Npb246IHJlcHV0ZUBp ZXRmLm9yZwoJVG8gU3Vic2NyaWJlOgkgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yZXB1dGUKCUFyY2hpdmU6CSAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvcmVwdXRlLwoKRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoKCURldGVybWlu aW5nIHRoZSB0cnVzdHdvcnRoaW5lc3Mgb2YgY29udGVudCBvbiB0aGUgSW50ZXJuZXQgcmVtYWlu cyBhCgljaGFsbGVuZ2UsIGFuZCB0aGlzIHdlYWtuZXNzIGlzIGhlYXZpbHkgZXhwbG9pdGVkIGJ5 IGJhZCBhY3RvcnMuCglWYXJpb3VzIG1lY2hhbmlzbXMgaGF2ZSBiZWVuIGRldmVsb3BlZCBmb3Ig YXNzb2NpYXRpbmcgYSB2ZXJpZmllZAoJaWRlbnRpZmllciB3aXRoIGVtYWlsIGNvbnRlbnQsIHN1 Y2ggYXMgU1BGIChSRkM0NDA4KSBhbmQgREtJTQoJKFJGQzQ4NzEpLiAgSG93ZXZlciwgYW55b25l IGNhbiBjcmVhdGUgYW5kIGF0dGFjaCBzdWNoIGFuIGlkZW50aWZpZXIuCglXaGF0IGlzIGFsc28g cmVxdWlyZWQgaXMgYSBtZWFuaW5nZnVsIGFzc2Vzc21lbnQgb2YgdGhlCgl0cnVzdHdvcnRoaW5l c3Mgb2YgdGhlIGlkZW50aWZpZXIncyBvd25lci4gIFRoaXMgaW4gdHVybiBwZXJtaXRzCgltYWtp bmcgYSBtZWFuaW5nZnVsIGNob2ljZSBhYm91dCB3aGF0IHRvIGRvIHdpdGggdGhlIGFzc29jaWF0 ZWQKCWNvbnRlbnQuCgoJU3VjaCBhbiBhc3Nlc3NtZW50IHJlcXVpcmVzIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBpZGVudGlmaWVyIGFuZC9vcgoJdGhlIG93bmVyLiAgSW4gdGhlIGFnZ3JlZ2F0ZSwg c3VjaCBpbmZvcm1hdGlvbiBjYW4gYmUgY2FsbGVkCgkicmVwdXRhdGlvbiIuICBBIHNwZWNpZmlj IHJlcXVpcmVtZW50IGlzIGZvciBhIGNvbW1vbiBtZWNoYW5pc20gdG8KCXVzZSBpbiBxdWVyeWlu ZyByZXB1dGF0aW9uLXJlbGF0ZWQgZGF0YWJhc2VzLiAgVGhpcyB3b3JraW5nIGdyb3VwIHdpbGwK CWRldmVsb3Agc3BlY2lmaWNhdGlvbnMgZm9yIHN1Y2ggYSBjb21tb24gY2FwYWJpbGl0eS4KCglU aGUgYWR2ZW50IG9mIHRoZSByZXF1aXJlbWVudCBkZXNjcmliZWQgYWJvdmUgY3JlYXRlcyBhIG5l ZWQgdG8gaGF2ZQoJcmVwdXRhdGlvbiBkYXRhIHByb3ZpZGVycyBtYWtlIGF2YWlsYWJsZSB0byBj b25zdW1lcnMgZGF0YSBhYm91dAoJdGhlIG93bmVycyBvZiBpZGVudGlmaWVycy4gIEEgc3RhbmRh cmQgcHJvdG9jb2wgc3VpdGUgaXMgbmVlZGVkIHRvCglkZWZpbmUgdGhlIG1lY2hhbmlzbShzKSBh bmQgZm9ybWF0cyBmb3Igc3VjaCBkYXRhLgoKCVJlcHV0YXRpb24gaXMgYSBjb21wbGV4IHRvcGlj LCB0eXBpY2FsbHkgZXhwbG9yZWQgYWNjb3JkaW5nIHRvCgljb21wb25lbnRzIG9mIGluZm9ybWF0 aW9uIHRoYXQgYWRkIHZhbHVlIHRvIHRoZSBhc3Nlc3NtZW50LiAgQQoJZ2VuZXJhbCBkZWZpbml0 aW9uIG9mICJ2YWx1ZSIgaXMgbm90IHBvc3NpYmxlLCBzaW5jZSBpdCBpcyBkZXZlbG9wZWQKCWRp ZmZlcmVudGx5IGFjY29yZGluZyB0byBjb250ZXh0IGFuZCB0eXBlIG9mIGluZm9ybWF0aW9uLiAg SXQgd2lsbAoJYmUgbmVjZXNzYXJ5IGZvciBlYWNoIHJlcHV0YXRpb24gY29udGV4dCB0byBkZWZp bmUgd2hhdCB0aGF0IG1lYW5zLgoJSXQgY291bGQgc3BlY2lmeSB0aGUgcmVsaWFiaWxpdHkgb2Yg dGhhdCBpZGVudGlmaWVyJ3MgYXNzb2NpYXRpb24KCXdpdGggZ29vZCBvciBiYWQgY29udGVudDsg aXQgY291bGQgaW5kaWNhdGUgdGhhdCB0aGUgaWRlbnRpZmllcgoJYmVsb25ncyB0byBhIHJlc3Bl Y3RlZCBvcmdhbml6YXRpb24gb3Igb25lIGFib3V0IHdoaWNoIGxpdHRsZSBpcwoJa25vd24uCgoJ QW4gZXhpc3RpbmcsIHN0YW5kYXJkaXplZCByZXB1dGF0aW9uIHF1ZXJ5IG1lY2hhbmlzbSBpcwoJ Vm91Y2gtYnktUmVmZXJlbmNlIChSRkM1NTE4KSwgd2hpY2ggcHJvdmlkZXMgYSBzaW1wbGUgQm9v bGVhbgoJcmVzcG9uc2UgY29uY2VybmluZyB0aGUgYWNjZXB0YWJpbGl0eSBvZiBkaWZmZXJlbnQg dHlwZXMgb2YgbWFpbC4KCU90aGVyIGFwcGxpY2F0aW9uIHNwYWNlcyAtLSBzdWNoIGFzIFdlYiBp bnRlcmFjdGlvbnMgLS0gY291bGQKCWJlbmVmaXQgZnJvbSBjb21tb24gcmVwdXRhdGlvbiBxdWVy eSBtZWNoYW5pc21zLCBlc3BlY2lhbGx5IHRob3NlCglmb3Igd2hpY2ggcmVwbGllcyBuZWVkIHRv IGJlIG1vcmUgZWxhYm9yYXRlLgoKCVRoZSBtb3N0IG9idmlvdXMgaW5pdGlhbCB1c2UgY2FzZSBm b3IgcmVwdXRhdGlvbiBpcyBldmFsdWF0aW9uIG9mCglhIEROUyBkb21haW4gbmFtZSB0aGF0IGlz IGFzc29jaWF0ZWQgd2l0aCBjb250ZW50IGluIHRoZSBlbWFpbAoJc3BhY2UsIHdoZXJlIHRoZSBp ZGVudGlmaWVyIGlzIHZhbGlkYXRlZCB1c2luZyBhIHRlY2hub2xvZ3kgbGlrZQoJREtJTSBvciBT UEYuICBJbmJvdW5kIGVtYWlsIGZpbHRlcnMgdGhhdCBwZXJmb3JtIG1lc3NhZ2UKCWF1dGhlbnRp Y2F0aW9uIGNhbiBvYnRhaW4gdGhhdCBkb21haW4gbmFtZSBhbmQgdGhlbiBjb25zdWx0IGEKCXJl cHV0YXRpb24gc2VydmljZSBwcm92aWRlciB0byBtYWtlIGEgZGV0ZXJtaW5hdGlvbiAocGVyaGFw cyBhbHNvCgliYXNlZCBvbiBvdGhlciBmYWN0b3JzKSBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgY29u dGVudCBpcyBkZXNpcmFibGUKCWFuZCB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbiB3aXRoIHJlc3Bl Y3QgdG8gZGVsaXZlcnksIHJvdXRpbmcKCW9yIHJlamVjdGlvbi4KCQoJQW5vdGhlciBwb3NzaWJs ZSB1c2UgY2FzZSBpcyBpZGVudGl0eS1iYXNlZCBldmFsdWF0aW9uIG9mIHdlYgoJY29udGVudCB1 c2luZyB0ZWNobm9sb2dpZXMgc3VjaCBhcyBET1NFVEEgKHdvcmsgaW4gcHJvZ3Jlc3MpLgoJT3Ro ZXIgdXNlIGNhc2VzIGhhdmUgYmVlbiBzdWdnZXN0ZWQuCgoJVGhpcyB3b3JraW5nIGdyb3VwIHdp bGwgcHJvZHVjZSBhIHNldCBvZiBkb2N1bWVudHMgZGVmaW5pbmcgYW5kCglpbGx1c3RyYXRpbmcg dGhlIHJlcXVpcmVtZW50IGFuZCBkZWZpbmluZyBtZWNoYW5pc21zIHRvIHNhdHNpZnkgaXQuCglU d28gbWVjaGFuaXNtcyBhcmUgcHJvcG9zZWQ6CgoJKiBzaW1wbGUgLS0gYSByZXB1dGF0aW9uIGlz IGV4cHJlc3NlZCBpbiBhIHNpbXBsZSBtYW5uZXIgc3VjaCBhcwoJCWFuIGludGVnZXIKCgkqIGV4 dGVuZGVkIC0tIGEgcmVzcG9uc2UgY2FuIGNvbnRhaW4gbW9yZSBjb21wbGV4IGluZm9ybWF0aW9u CgkJdXNlZnVsIHRvIGFuIGFzc2Vzc29yCgoJVGhlIG1lY2hhbmlzbXMgd2lsbCBiZSBkZXNpZ25l ZCB0byBiZSBhcHBsaWNhdGlvbi1pbmRlcGVuZGVudCwgYW5kCglwb3J0YWJsZSBiZXR3ZWVuIHJl cHV0YXRpb24gcHJvdmlkZXJzLgoKCVRoZSBncm91cCB3aWxsIGFsc28gcHJvZHVjZSBzcGVjaWZp Y2F0aW9ucyBmb3IgcHJvdmlkaW5nIHNvdXJjZSBkYXRhCglpbnRvIHRvIGEgcmVwdXRhdGlvbiBz ZXJ2aWNlLgoKCVRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgZm9yIGl0cyBpbml0aWFsIGNo YXJ0ZXIgb25seSBvbiB0aGUKCXNwZWNpZmljIGFwcGxpY2F0aW9uIG9mIHJlcHV0YXRpb24gYWJv dXQgZG9tYWluIG5hbWVzIGZvdW5kIGluCgllbWFpbCBtZXNzYWdlcywgYXMgaXQgaXMgYmVsaWV2 ZWQgdGhlcmUgZXhpc3RzIHN1ZmZpY2llbnQgZXhwZXJpZW5jZQoJYW5kIGV4cGVydGlzZSBpbiB0 aGF0IGFyZWEuICBJZiBzdWNjZXNzZnVsLCB0aGUgZ3JvdXAgY2FuIHJlY2hhcnRlcgoJdG8gY292 ZXIgb3RoZXIgYXBwbGljYXRpb24gc3BhY2VzIHdoZXJlIGl0IGZlZWxzIGl0IGNhbiBhY2Nlc3MK CXN1ZmZpY2llbnQgZXhwZXJ0aXNlLgoKCVJlcHV0YXRpb24gc3lzdGVtcyBzdWNoIGFzIFJlYWx0 aW1lIEJsb2NrIExpc3RzIChSQkxzLCBSRkM1NzgyKQoJY2FuIGJlIHByb2JsZW1hdGljIHdoZW4g bm90IG9wZXJhdGVkIHByb3Blcmx5LiAgRm9yIGV4YW1wbGUsIGFuCglSQkwgdGhhdCBsaXN0cyBh IHNwZWNpZmljIHNvdXJjZSB3aXRob3V0IGp1c3RpZmljYXRpb24gY2FuIGRvIGhhcm0KCXRvIGEg bGVnaXRpbWF0ZSBidXNpbmVzcywgcHJvdm9raW5nIGRhbWFnZXMgYW5kIHBvc3NpYmxlIGxpdGln YXRpb24uCglUaGlzIGltcG9ydGFudCB0b3BpYyB3aWxsIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGlu IHRoZSBpbmZvcm1hdGlvbmFsCglwb3J0aW9ucyBvZiB0aGUgd29yayBwcm9kdWNlZCBoZXJlLCBp biB0ZXJtcyBvZiBhZHZpY2UgYm90aCB0bwoJcmVwdXRhdGlvbiBwcm92aWRlcnMgYW5kIHJlcHV0 YXRpb24gY29uc3VtZXJzLiAgVGhlIGlzc3VlcyBvZgoJZGF0YSB0cmFuc3BhcmVuY3kgYW5kIHJl ZHJlc3Mgd2lsbCBhbHNvIG5lZWQgdG8gYmUgZGlzY3Vzc2VkLgoKCUl0ZW1zIHRoYXQgYXJlIHNw ZWNpZmljYWxseSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgd29yazoKCgkqIFNwZWNpZmljIGFjdGlv bnMgdG8gYmUgdGFrZW4gaW4gcmVzcG9uc2UgdG8gYSByZXB1dGF0aW9uIHJlcGx5LgoJICBJdCBp cyB1cCB0byBhc3Nlc3NvcnMgKGkuZS4sIHRoZSBjb25zdW1lcnMgb2YgcmVwdXRhdGlvbiBkYXRh KQoJICB0byBkZXRlcm1pbmUgdGhpcy4gIE5vbi1ub3JtYXRpdmUgaWxsdXN0cmF0aW9ucywgaG93 ZXZlciwgY2FuCgkgIGJlIGluY2x1ZGVkIHRvIGRlbW9uc3RyYXRlIHBvc3NpYmxlIHVzZXMgb2Yg cmVwdXRhdGlvbiBkYXRhCgkgIGluIGEgcGFydGljdWxhciBjb250ZXh0LgoKCSogU2VsZWN0aW9u IG9mIHdoYXQgZGF0YSBtaWdodCBiZSB2YWxpZCBhcyB0aGUgc3ViamVjdCBvZiBhCgkgIHJlcHV0 YXRpb24gcXVlcnkuICBJdCBpcyB1cCB0byByZXB1dGF0aW9uIHNlcnZpY2UgcHJvdmlkZXJzIGFu ZAoJICBhc3Nlc3NvcnMgdG8gc2VsZWN0IHdoaWNoIHF1YWxpdGllcyBvZiBhIGJvZHkgb2YgZGF0 YSBtaWdodAoJICBiZSB1c2VmdWwgaW5wdXQgdG8gcmVwdXRhdGlvbiBldmFsdWF0aW9uLgoKR29h bHMgYW5kIE1pbGVzdG9uZXM6CgltbW0geXl5eToJSW5mb3JtYXRpb25hbCBkb2N1bWVudCwgZGVm aW5pbmcgdGhlIHByb2JsZW0gc3BhY2UKCQkJYW5kIHNvbHV0aW9uIG1vZGVsLCB0byB0aGUgSUVT RyBmb3IgcHVibGljYXRpb24uCgoJbW1tIHl5eXk6CVN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCwg ZGVmaW5pbmcgYSBuZXcgc3RydWN0dXJlCgkJCShlLmcuLCBhIG1lZGlhIHR5cGUpIGZvciByZWxh eWluZyByZXB1dGF0aW9uCgkJCWluZm9ybWF0aW9uLCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRp b24uCgoJbW1tIHl5eXk6CUluZm9ybWF0aW9uYWwgZG9jdW1lbnQsIGRlZmluaW5nIHRoZSB2b2Nh YnVsYXJ5CgkJCWZvciBwcm92aWRpbmcgcmVwdXRhdGlvbiBpbiB0aGUgZW1haWwgc3BoZXJlLCB0 byB0aGUKCQkJSUVTRyBmb3IgcHVibGljYXRpb24uCgoJbW1tIHl5eXk6ICAJU3RhbmRhcmRzIHRy YWNrIGRvY3VtZW50LCBkZWZpbmluZyB0aGUgc2ltcGxlCgkJCXF1ZXJ5IG1lY2hhbmlzbSwgdG8g dGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uLgoKCW1tbSB5eXl5OiAgCVN0YW5kYXJkcyB0cmFjayBk b2N1bWVudCwgZGVmaW5pbmcgdGhlIGV4dGVuZGVkCgkJCXF1ZXJ5IG1lY2hhbmlzbSwgdG8gdGhl IElFU0cgZm9yIHB1YmxpY2F0aW9uLgoKCW1tbSB5eXl5OiAgCVN0YW5kYXJkcyB0cmFjayBkb2N1 bWVudCwgZGVmaW5pbmcgbWVjaGFuaXNtcwoJCQlmb3Igc2VuZGluZyBkYXRhIHRvIHJlcHV0YXRp b24gcHJvdmlkZXJzLCB0byB0aGUKCQkJSUVTRyBmb3IgcHVibGljYXRpb24uCgoJbW1tIHl5eXk6 ICAJSW5mb3JtYXRpb25hbCBkb2N1bWVudCwgZGlzY3Vzc2luZyBpc3N1ZXMKCQkJb2YgZGF0YSB0 cmFuc3BhcmVuY3ksIHJlZHJlc3MsIG1ldGEtcmVwdXRhdGlvbgoJCQlhbmQgb3RoZXIgaW1wb3J0 YW50IG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zLCB0byB0aGUKCQkJSUVTRyBmb3IgcHVibGlj YXRpb24uCg== --_004_F5833273385BB34F99288B3648C4F06F13512DF4E1EXCHC2corpclo_-- From ietf-dkim@kitterman.com Tue Aug 2 06:28:25 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7EE21F8A56 for ; Tue, 2 Aug 2011 06:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[AWL=-2.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Junx9Uicv-0 for ; Tue, 2 Aug 2011 06:28:24 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id B759B21F8A23 for ; Tue, 2 Aug 2011 06:28:24 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id B22C638C178; Tue, 2 Aug 2011 09:28:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1312291713; bh=ocHRkvXi2FRdj6RuIaFI2PH7JQ9K7yVDmpoBgpUIt9U=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=qTcaxINCuDBk9KNGkFgGch1EX7dm9Cucdtuly2p4cT748YcJfZKg6hS4I7mlttx0w 1MG+5ekxV2zvUVjuQTfgf/TrJz1KunQMY4eXH2xAvW7IumBt27rgHemAXMxtBo2SOS 0WRuMHApaedNMnx9inyaGXaK/q8h63En7FzR1uyo= From: Scott Kitterman To: domainrep@ietf.org Date: Tue, 2 Aug 2011 09:28:30 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110725144616.GA1579@shinkuro.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108020928.30617.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] A sentence that confuses me X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:28:25 -0000 On Tuesday, August 02, 2011 02:04:01 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > > Behalf Of Andrew Sullivan Sent: Monday, July 25, 2011 7:46 AM > > To: domainrep@ietf.org > > Subject: [domainrep] A sentence that confuses me > > > > In draft-kucherawy-reputation-query-dns-00, we have this: > > In line with [DNS-EXPAND], the TXT resource record type is used for > > this application. > > > > But RFC 5507 says this: > > We'll show how such a designer almost inevitably hits upon the idea > > of just using a TXT Resource Record, why this is a bad thing, and why > > a new Resource Record Type should be allocated instead. > > > > How can these statements be reconciled? > > My tendency toward using TXT is from the last several years of email > authentication work, where variously the SPF, Sender-ID, DomainKeys and > DKIM protocols and their various adjuncts all used TXT records to publish > either keys or policies. It's thus primarily there out of habit and not > out of the idea that we have it right and the IAB got it wrong; I'd be > fine with creating a new RR type if that's the current wisdom, apart from > the fact that it will take some period of time for servers and resolvers > both to begin supporting it. > > This also presupposes that we get some buy-in from the community for > putting this data in the DNS rather than creating a new UDP-based > protocol. I've heard arguments from both sides of that fence. For SPF we got a new RR type (99) assigned because the DNS gurus of the day insisted it was essential. Despite being widely supported for many years in the relevant software and tools it has essentially zero deployment. This is because there is zero incentive to move from TXT to the dedicated RR. The choices were then (and as far as I know are now) either use TXT or put deployment into a several year wait state while DNS is upgraded everywhere. I don't see any technical point in pretending to use a new RR with TXT as a 'temporary' measure. The politics of the matter may prove to be different. Scott K From ajs@anvilwalrusden.com Tue Aug 2 07:14:33 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D2721F8781 for ; Tue, 2 Aug 2011 07:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzZWQlj6cttV for ; Tue, 2 Aug 2011 07:14:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A866321F8753 for ; Tue, 2 Aug 2011 07:14:31 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1D64A1ECB41C for ; Tue, 2 Aug 2011 14:14:40 +0000 (UTC) Date: Tue, 2 Aug 2011 10:14:33 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110802141433.GP22542@shinkuro.com> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108020928.30617.ietf-dkim@kitterman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [domainrep] More on TXT records (was: A sentence that confuses me) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:14:33 -0000 On Tue, Aug 02, 2011 at 09:28:30AM -0400, Scott Kitterman wrote: > For SPF we got a new RR type (99) assigned because the DNS gurus of the day > insisted it was essential. Despite being widely supported for many years in > the relevant software and tools it has essentially zero deployment. This is > because there is zero incentive to move from TXT to the dedicated RR. > > The choices were then (and as far as I know are now) either use TXT or put > deployment into a several year wait state while DNS is upgraded everywhere. I > don't see any technical point in pretending to use a new RR with TXT as a > 'temporary' measure. The politics of the matter may prove to be different. You do not need to upgrade DNS anywhere to support an unknown RRTYPE. How to handle unknown RRTYPEs in the DNS was standardized in 2003. Frankly, if you are using a DNS system that hasn't been upgraded since that era, you gots bigger problems than being able to handle something other than TXT. What is probably true is that the support tools need to be upgraded. I gather that there remain some client libraries that cannot handle unknown RRTYPEs, but I don't have a complete list or an understanding of how much pain they cause. Someone once suggested to me, in seriousness, that the gating library was VBA; if that's true, someone might want to explain to me how that could be a gating factor on an Internet protocol. Certainly my interlocutor at the time did not, but I was pretty sure he was confused. (Maybe he meant "VB"?) Suggestions for a list of such libraries would help. Remember that one of the biggest problems with TXT is the ease with which you can collide with others. Since there is no registry for how to handle the right hand side of a TXT record (and by definition, there cannot be), you are simply having to trust that nobody else will specify a format for the TXT record that is like enough to yours so as to cause your special-handling TXT records to become broken. The more people try to put a protocol inside TXT records, the more likely this eventuality becomes. Moreover, this needs to be part of your security considerations, particularly in a case like reputation where there will always be an incentive to try to cause the reputation system to break. A -- Andrew Sullivan ajs@anvilwalrusden.com From ietf-dkim@kitterman.com Tue Aug 2 07:44:24 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2E121F84F2 for ; Tue, 2 Aug 2011 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.255 X-Spam-Level: X-Spam-Status: No, score=-4.255 tagged_above=-999 required=5 tests=[AWL=-1.656, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcPG5ry6GKZO for ; Tue, 2 Aug 2011 07:44:24 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id E7C2111E8082 for ; Tue, 2 Aug 2011 07:44:23 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6CD2C38C178; Tue, 2 Aug 2011 10:44:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1312296272; bh=D7QAK8lxMH1zOc5Q+em3x7B5SzQ0f5mnfr/4Sd3kEAU=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=J5IlX7hsfwTAxAxFgQQ/k2ACcX9Yj1PBFBc/x3IOhJeHjsYQWajYl5JegFcVBZ6zj WR9ocsSYGWd54Ldyj+1+MCxfxIcWFJ51NryLxeOcepC6ihOH1qBxnb0MRr4AEYsiyk oxN1sAhiun/8CeGc8ROa8l05KvTwZIwGDQ/BCwXQ= From: Scott Kitterman To: domainrep@ietf.org Date: Tue, 2 Aug 2011 10:44:25 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> In-Reply-To: <20110802141433.GP22542@shinkuro.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108021044.28025.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] More on TXT records (was: A sentence that confuses me) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:44:24 -0000 On Tuesday, August 02, 2011 10:14:33 AM Andrew Sullivan wrote: > On Tue, Aug 02, 2011 at 09:28:30AM -0400, Scott Kitterman wrote: > > For SPF we got a new RR type (99) assigned because the DNS gurus of the > > day insisted it was essential. Despite being widely supported for many > > years in the relevant software and tools it has essentially zero > > deployment. This is because there is zero incentive to move from TXT to > > the dedicated RR. > > > > The choices were then (and as far as I know are now) either use TXT or > > put deployment into a several year wait state while DNS is upgraded > > everywhere. I don't see any technical point in pretending to use a new > > RR with TXT as a 'temporary' measure. The politics of the matter may > > prove to be different. > > You do not need to upgrade DNS anywhere to support an unknown RRTYPE. > How to handle unknown RRTYPEs in the DNS was standardized in 2003. > Frankly, if you are using a DNS system that hasn't been upgraded since > that era, you gots bigger problems than being able to handle something > other than TXT. > > What is probably true is that the support tools need to be upgraded. > I gather that there remain some client libraries that cannot handle > unknown RRTYPEs, but I don't have a complete list or an understanding > of how much pain they cause. Someone once suggested to me, in > seriousness, that the gating library was VBA; if that's true, someone > might want to explain to me how that could be a gating factor on an > Internet protocol. Certainly my interlocutor at the time did not, but > I was pretty sure he was confused. (Maybe he meant "VB"?) > Suggestions for a list of such libraries would help. > > Remember that one of the biggest problems with TXT is the ease with > which you can collide with others. Since there is no registry for how > to handle the right hand side of a TXT record (and by definition, > there cannot be), you are simply having to trust that nobody else will > specify a format for the TXT record that is like enough to yours so as > to cause your special-handling TXT records to become broken. The more > people try to put a protocol inside TXT records, the more likely this > eventuality becomes. Moreover, this needs to be part of your security > considerations, particularly in a case like reputation where there > will always be an incentive to try to cause the reputation system to > break. In 2006, when we were looking into this for SPF, there was a large vendor in the northwest of the USA that had a DNS product that would handle unknown RRs when they were loaded, but they had to be reloaded after every reboot as the configuration wasn't retained. Not being a user of this vendor's products, I've no idea if this is still the case. I agree with your other points. The measures used by DKIM/ADSP are a reasonable response to those limitations of TXT. Scott K From paul.hoffman@vpnc.org Tue Aug 2 07:57:21 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B891A21F874B for ; Tue, 2 Aug 2011 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z3ToNrrslD6 for ; Tue, 2 Aug 2011 07:57:21 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E872221F8749 for ; Tue, 2 Aug 2011 07:57:20 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72Ev8Ri012547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 07:57:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110802141433.GP22542@shinkuro.com> Date: Tue, 2 Aug 2011 07:57:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3274FD-C748-4374-84DF-70ADE7BC7957@vpnc.org> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1244.3) Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records (was: A sentence that confuses me) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:57:21 -0000 +1. There was a good argument five years ago to use TXT records for = unstructured responses. There are only weak arguments now for using them = for structured responses in completely new protocols. --Paul Hoffman= From dhc@dcrocker.net Tue Aug 2 08:06:16 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A9111E808A for ; Tue, 2 Aug 2011 08:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSEdwqQip3fl for ; Tue, 2 Aug 2011 08:06:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 24FF011E8083 for ; Tue, 2 Aug 2011 08:06:16 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p72F6HcG026293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 08:06:23 -0700 Message-ID: <4E381266.7070303@dcrocker.net> Date: Tue, 02 Aug 2011 08:06:14 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> In-Reply-To: <20110802141433.GP22542@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 02 Aug 2011 08:06:23 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:06:16 -0000 On 8/2/2011 7:14 AM, Andrew Sullivan wrote: > You do not need to upgrade DNS anywhere to support an unknown RRTYPE. That's been the claim for the last 15 years. It continues to be false, in practical terms. New RRs will be zero systems cost when the there is broad, end-to-end support, from client resolvers, through recursive servers, to authoritative servers, for new RRs, requiring nothing more the administrative effort of specifying the new record. That reality does not yet exist. What exists is partial support. In any event, the use of underscore-based subdomain naming renders the primary argument against TXT moot. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Tue Aug 2 08:33:53 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBD411E8082 for ; Tue, 2 Aug 2011 08:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.461 X-Spam-Level: X-Spam-Status: No, score=-110.461 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrcaStS1-pUV for ; Tue, 2 Aug 2011 08:33:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 755C011E8080 for ; Tue, 2 Aug 2011 08:33:52 -0700 (PDT) Received: (qmail 69682 invoked from network); 2 Aug 2011 15:34:01 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 15:34:01 -0000 Received: (qmail 97864 invoked from network); 2 Aug 2011 15:34:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 15:34:01 -0000 Date: 2 Aug 2011 15:33:39 -0000 Message-ID: <20110802153339.55165.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <4E381266.7070303@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:33:53 -0000 >> You do not need to upgrade DNS anywhere to support an unknown RRTYPE. > >That's been the claim for the last 15 years. It continues to be false, in >practical terms. Quite true. Even if DNS servers and caches all support arbitrary RRs, which may or may not be the case, there's vast amounts of provisioning software that doesn't support new RRs at all, or only as long strings of hex digits. Really, we understand why it would have been nice if it were easy to add and use new RRs. But it's not. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From paul.hoffman@vpnc.org Tue Aug 2 08:53:00 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2465721F8507 for ; Tue, 2 Aug 2011 08:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8ofnPZsS-m1 for ; Tue, 2 Aug 2011 08:52:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9C21F84ED for ; Tue, 2 Aug 2011 08:52:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72FqiG7015695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 08:52:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110802153339.55165.qmail@joyce.lan> Date: Tue, 2 Aug 2011 08:53:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FB0EE6E-DB16-4F72-81EC-EBD4B318A21E@vpnc.org> References: <20110802153339.55165.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1244.3) Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:53:00 -0000 We had this discussion five years ago, but it is probably worth having = it again now. On Aug 2, 2011, at 8:33 AM, John Levine wrote: >>> You do not need to upgrade DNS anywhere to support an unknown = RRTYPE. >>=20 >> That's been the claim for the last 15 years. It continues to be = false, in=20 >> practical terms. >=20 > Even if DNS servers and caches all support arbitrary RRs, Is there any evidence that any existing caches don't support arbitrary = RRtypes? > which may or may not be the case, there's vast amounts of provisioning > software that doesn't support new RRs at all, or only as long strings > of hex digits. Is that provisioning software used by anyone wanting to publish = reputation data? > Really, we understand why it would have been nice if it were easy to > add and use new RRs. But it's not. Who is "we" here? Some of "us" believe that things change over time. In = specific, some of "us" believe that *for this specific proposal*, if = someone publishing reputation data has a server that cannot be = configured to accept the data, there is a strong incentive to get a = server that does.=20 --Paul Hoffman From dfs@roaringpenguin.com Tue Aug 2 09:08:47 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C578E21F86EC for ; Tue, 2 Aug 2011 09:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNDuWbMLmusH for ; Tue, 2 Aug 2011 09:08:47 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id 0412521F84D3 for ; Tue, 2 Aug 2011 09:08:46 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p72G8nsH018068 for ; Tue, 2 Aug 2011 12:08:51 -0400 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p72G8jbH004460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 12:08:48 -0400 Date: Tue, 2 Aug 2011 12:08:45 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110802120845.5d729501@hydrogen.roaringpenguin.com> In-Reply-To: <9FB0EE6E-DB16-4F72-81EC-EBD4B318A21E@vpnc.org> References: <20110802153339.55165.qmail@joyce.lan> <9FB0EE6E-DB16-4F72-81EC-EBD4B318A21E@vpnc.org> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=3jcVvKWjnr0I elXBf5KBg5TFkco=; b=mc6yarUIKjlLcnuWSgSyMgrdjRnGKmHIjtQF5II3tlJk z0z30Cp4vSEo0ulhnggNYxHbrpBSZQv0IpO/z23hzO2n3GwmKIFco19SIZ6PVaQr ZhCeBcDISSqknrR0xDoy4MpCOxljbvOBRh1st2L+5Lk56IXez7QZvbhSwCiAw+k= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110802 / 01Ffs8OW6 Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:08:47 -0000 On Tue, 2 Aug 2011 08:53:03 -0700 Paul Hoffman wrote: > Who is "we" here? Some of "us" believe that things change over time. Yes, but some changes are better than others. I think this change: _repute.example.org 1h IN TXT "reputation-data-goes-here" is better than: exmple.org 1h IN REPUTE "reputation-data-goes-here" because it's less disruptive and equally good at avoiding clashes. I think multiplying RRs that are really TXT records is a bad idea. Multiplying domain prefixes like _repute is essentially free and virtually 100% guaranteed to work with all existing implementations. The only advantage to a specific RR is that the name server can, in theory, check its syntax and reject malformed records. But this obviously will require a software upgrade and may not be worthwhile since REPUTE records will probably not be human-generated. Regards, David. From johnl@iecc.com Tue Aug 2 09:13:39 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420DA21F8510 for ; Tue, 2 Aug 2011 09:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id par5YHqSWrQa for ; Tue, 2 Aug 2011 09:13:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF521F8509 for ; Tue, 2 Aug 2011 09:13:38 -0700 (PDT) Received: (qmail 75990 invoked from network); 2 Aug 2011 16:13:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=128d5.4e38223a.k1108; bh=tBZaHoaX7yhKVO0o+F6xWR3m4Nmbr0702jiff5HkzNk=; b=InNBBr+bb/w3EFC4XoOPcbSO2u5XztNFcBxcpdS376phKSJM/TwUER3liE3ZGNlMBhhXyzBrY250bS6ilsi9BAoPzlnq2KuERmAqF6W1A7G+9qVyYaaacXuypBGRd6jC3nlFjp5U9P3WmK+MGexYMmZyq5/wqnV2F85IE8NOzbU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Aug 2011 16:13:24 -0000 Date: 2 Aug 2011 12:13:45 -0400 Message-ID: From: "John R. Levine" To: "Paul Hoffman" In-Reply-To: <9FB0EE6E-DB16-4F72-81EC-EBD4B318A21E@vpnc.org> References: <20110802153339.55165.qmail@joyce.lan> <9FB0EE6E-DB16-4F72-81EC-EBD4B318A21E@vpnc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:13:39 -0000 >> Even if DNS servers and caches all support arbitrary RRs, > Is there any evidence that any existing caches don't support arbitrary > RRtypes? Caches are one of the few places that are reliably OK with arbitrary records. There are reasonably popular DNS servers like powerdns where the DNS data is stored in a database, and the server only supports specific record types. See http://doc.powerdns.com/types.html This isn't abandonware; it's reasonably well supported and handles DNSSEC. It's open source so you can hack in support for whatever you want, but it's a lot more work than just adding a few records to a database. There's also the question of what level of support there is in systems like .NET. That's not my favorite development environment, but there sure are a lot of people who use it. Or look at PHP, again, not my favorite language, but hugely popular for web applications. The lowest level DNS lookup function dns_get_record() has a list of known RR types, again, possible to update since it's open source, but not trivial. http://www.php.net/manual/en/function.dns-get-record.php >> there's vast amounts of provisioning software that doesn't support new >> RRs at all, or only as long strings of hex digits. > Is that provisioning software used by anyone wanting to publish > reputation data? Beats me. It is my strong impression that it's the way that the vast majority of domains have their DNS provisioned today, so if we claim it doesn't matter, we're saying whatever we design is only for a narrow range of specialists. Scott K. can probably tell you how painful it was to get it all to support TXT records so people could publish SPF. We in the DKIM community were lucky that the SPFers already had those arrows in their backs. R's, John From msk@cloudmark.com Tue Aug 2 09:48:44 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF04521F85BB for ; Tue, 2 Aug 2011 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XcpgiPpIDaM for ; Tue, 2 Aug 2011 09:48:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 677BE21F85B2 for ; Tue, 2 Aug 2011 09:48:44 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 2 Aug 2011 09:48:53 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 2 Aug 2011 09:48:52 -0700 Thread-Topic: [domainrep] More on TXT records (was: A sentence that confuses me) Thread-Index: AcxRHorD+6st2rLZQOeNZ5QEjXdb0AAFT4zQ Message-ID: References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> In-Reply-To: <20110802141433.GP22542@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] More on TXT records (was: A sentence that confuses me) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:48:45 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Andrew Sullivan > Sent: Tuesday, August 02, 2011 7:15 AM > To: domainrep@ietf.org > Subject: [domainrep] More on TXT records (was: A sentence that confuses m= e) >=20 > You do not need to upgrade DNS anywhere to support an unknown RRTYPE. > How to handle unknown RRTYPEs in the DNS was standardized in 2003. > Frankly, if you are using a DNS system that hasn't been upgraded since > that era, you gots bigger problems than being able to handle something > other than TXT. >=20 > What is probably true is that the support tools need to be upgraded. > I gather that there remain some client libraries that cannot handle > unknown RRTYPEs, but I don't have a complete list or an understanding > of how much pain they cause. Someone once suggested to me, in > seriousness, that the gating library was VBA; if that's true, someone > might want to explain to me how that could be a gating factor on an > Internet protocol. Certainly my interlocutor at the time did not, but > I was pretty sure he was confused. (Maybe he meant "VB"?) > Suggestions for a list of such libraries would help. I don't know of any limitation on the client side, having written lots of c= lient code by now. What I don't know about is the server side, having writ= ten no server code at all. How, for example, does one express binary data = in a BIND zone file? (There may be a way, but I've never seen it.) For this to be painless and usable out-of-the-box, both have to be possible= and relatively easy. From ajs@anvilwalrusden.com Tue Aug 2 10:36:42 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3606411E808F for ; Tue, 2 Aug 2011 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPbI2p6rsa9M for ; Tue, 2 Aug 2011 10:36:41 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BD56911E807B for ; Tue, 2 Aug 2011 10:36:41 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D636E1ECB41C; Tue, 2 Aug 2011 17:36:50 +0000 (UTC) Date: Tue, 2 Aug 2011 13:36:48 -0400 From: Andrew Sullivan To: dcrocker@bbiw.net Message-ID: <20110802173648.GV22542@shinkuro.com> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E381266.7070303@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:36:42 -0000 On Tue, Aug 02, 2011 at 08:06:14AM -0700, Dave CROCKER wrote: > New RRs will be zero systems cost when the there is broad, > end-to-end support, from client resolvers, through recursive > servers, to authoritative servers, for new RRs, requiring nothing > more the administrative effort of specifying the new record. So instead of addressing the distinction I was making in the mail I sent, which exactly acknowledged your point and asked for help in identifying the points of pain, you found it easier to point and laugh? Thanks. > In any event, the use of underscore-based subdomain naming renders > the primary argument against TXT moot. Given that we can't even get people to agree on how underscores are to be used (there's no registry, and there are two quite different use patterns and no reason to suppose there won't be another one tomorrow), I find it mighty hard to believe that the underscore "convention" is a big improvement. It's a one-at-a-time answer too. It just moves the pain around. A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Tue Aug 2 10:45:13 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1755411E80B3 for ; Tue, 2 Aug 2011 10:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.679 X-Spam-Level: X-Spam-Status: No, score=-103.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRPm4ITaloqc for ; Tue, 2 Aug 2011 10:45:12 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E4FDF11E8098 for ; Tue, 2 Aug 2011 10:45:09 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 2 Aug 2011 10:45:19 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 2 Aug 2011 10:45:18 -0700 Thread-Topic: [domainrep] More on TXT records Thread-Index: AcxROsVEd1N2ADE2RsmAAhhLPE4n3gAARvSA Message-ID: References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> In-Reply-To: <20110802173648.GV22542@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:45:13 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Andrew Sullivan > Sent: Tuesday, August 02, 2011 10:37 AM > To: dcrocker@bbiw.net > Cc: domainrep@ietf.org > Subject: Re: [domainrep] More on TXT records >=20 > Given that we can't even get people to agree on how underscores are to > be used (there's no registry, and there are two quite different use > patterns and no reason to suppose there won't be another one > tomorrow), I find it mighty hard to believe that the underscore > "convention" is a big improvement. It's a one-at-a-time answer too. > It just moves the pain around. I did see an effort to create such a registry. I don't know what happened = to it though. From peer2peer@gmail.com Tue Aug 2 11:44:02 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5121F873D for ; Tue, 2 Aug 2011 11:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBm2FwL18JlU for ; Tue, 2 Aug 2011 11:44:02 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4821F8736 for ; Tue, 2 Aug 2011 11:44:02 -0700 (PDT) Received: by gwb20 with SMTP id 20so41265gwb.31 for ; Tue, 02 Aug 2011 11:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=8nZpqIlgXwwFirr/VEgFavWNY94DtgzK3y4hkCgLsoQ=; b=EvfixOFXpyVwaAEeICMOEQRxOv3jeqRNN9anG1xdn/VQqYaWlh6zA1l/e0Ed8lww3/ OrFKDydMZmU2/OIl0Y1jf0D11aZkMBcnL1rd1kFWwhkEXN/+kShiYBJH7woO9VPysh6N Q7WvZ7BqEv2tZOYGwZLovwXoOAcnITvJfcZ94= MIME-Version: 1.0 Received: by 10.143.20.21 with SMTP id x21mr3802632wfi.39.1312310650436; Tue, 02 Aug 2011 11:44:10 -0700 (PDT) Received: by 10.142.80.16 with HTTP; Tue, 2 Aug 2011 11:44:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Aug 2011 20:44:10 +0200 Message-ID: From: Johan Pouwelse To: "domainrep@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:44:02 -0000 Nicely formulated charter. I'm very much in favour of a focussed charter. However, currently the charter is {overly} narrow. One of the key lessons of the BoF was in my estimation the strong, diverse and energetic interest. There is a thriving group of academics out there, like me, who would love to help. For instance, see the strong publication record here: http://scholar.google.com/scholar?q=3Dreputation+system Please don't cut them out of this community. An official IETF REPUTE charter would give them guidance+motivation for their work. May I propose reformulating like: The working group will focus initially only on the specific application of reputation about domain names found in email messages, as it is believed there exists sufficient experience and expertise in that area. If successful progress has been made, in the form of four accepted working group Standards track document= s we will take a limited step to generalise beyond domain names. The working group will cover at maximum two additional application spaces where it feels it can access to sufficient expertise and experience= . Or is this slightly wider scope not acceptable for Working Group acceptance process? -j On 2 August 2011 08:30, Murray S. Kucherawy wrote: > Attached is a revised charter based on the minutes Barry posted on > Thursday.=A0 Thanks to Barry for chairing the BoF and Jeff Hodges for tak= ing > notes. > > > > Please give it a once-over and let me know if you think it reflects the > discussion we had.=A0 Once there=92s agreement, I=92ll send it to the ADs= for > their consideration. > > > > -MSK > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > > From ajs@anvilwalrusden.com Tue Aug 2 11:50:11 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9BD21F85E3 for ; Tue, 2 Aug 2011 11:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTHUJmKVzDZx for ; Tue, 2 Aug 2011 11:50:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 44C0721F85CA for ; Tue, 2 Aug 2011 11:50:10 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 38E391ECB41C for ; Tue, 2 Aug 2011 18:50:18 +0000 (UTC) Date: Tue, 2 Aug 2011 14:50:11 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110802185011.GZ22542@shinkuro.com> References: <20110802153339.55165.qmail@joyce.lan> <9FB0EE6E-DB16-4F72-81EC-EBD4B318A21E@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:50:11 -0000 On Tue, Aug 02, 2011 at 12:13:45PM -0400, John R. Levine wrote: > There are reasonably popular DNS servers like powerdns where the DNS > data is stored in a database, and the server only supports specific > record types. See http://doc.powerdns.com/types.html This is an excellent example, actually, and a good point. PowerDNS is very widely used in the domain hosting environment (particularly, I understand, in Germany), so it might be a target of the repute work. > This isn't abandonware; it's reasonably well supported and handles > DNSSEC. On the other hand, the primary author resisted DNSSEC all the way, until there were people lined up to add the support. Then he did it. I suspect demand actually causes a response in that product, but it's not clear whether the cost would be worth it in this case. > There's also the question of what level of support there is in > systems like .NET. That's not my favorite development environment, > but there sure are a lot of people who use it. This was what I was asking about. Does .NET still not have that support? I thought I'd heard it did, but I don't know. > Or look at PHP, again, not my favorite language, but hugely popular > for web applications. The lowest level DNS lookup function > dns_get_record() has a list of known RR types, again, possible to > update since it's open source, but not trivial. This is another good example. On the other hand, perhaps adding support for unknown RRTYPEs would be a better thing to push for, instead of asking everyone in the world to add yet another bunch of special case handling for TXT records. > Beats me. It is my strong impression that it's the way that the > vast majority of domains have their DNS provisioned today, so if we > claim it doesn't matter, we're saying whatever we design is only for > a narrow range of specialists. Scott K. can probably tell you how > painful it was to get it all to support TXT records so people could > publish SPF. We in the DKIM community were lucky that the SPFers > already had those arrows in their backs. It's a bitter result that the effort was all to get people to add support for TXT records, which on their own don't actually solve the problem. This is not to denigrate the effort; it's just to note that we seem to have fought a battle for the wrong ground. To extend that military analogy, I'm not willing to die on this hill. If people really want to proceed with TXT records, they are free to do so given the well-established precedents. This seems to me, for the reasons I have outlined, to be a bad idea, but lots of people think my advice is wrong. However, I don't think the document undertaking to define this TXT record ought to cite something that says, "Don't use TXT records," as a reason why it is using a TXT record. That was the basis of my original question. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Aug 2 12:03:27 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17F1F0C49 for ; Tue, 2 Aug 2011 12:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jujtXYTGKPSt for ; Tue, 2 Aug 2011 12:03:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE021F0C43 for ; Tue, 2 Aug 2011 12:03:27 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2730B1ECB41C for ; Tue, 2 Aug 2011 19:03:37 +0000 (UTC) Date: Tue, 2 Aug 2011 15:03:31 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110802190330.GA22542@shinkuro.com> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:03:28 -0000 On Tue, Aug 02, 2011 at 10:45:18AM -0700, Murray S. Kucherawy wrote: > I did see an effort to create such a registry. I don't know what > happened to it though. There's been more than one such effort. The current one seems to be struggling from want of review. But even if we created a registry, there is no reason to suppose people won't use those names in ways we don't like. It is entirely outside of the traditions of DNS administration to try to constrain what domain name labels people use in their zones. A registry effectively tries to say, "Here are special purpose labels in the DNS," and the problem is that, having delegated the namespace to someone else, we're not going to be in a position to tell them what they're allowed to do in their zones. People could do anything the like with those names. That's a feature of DNS. If you want rules about whether the right hand side of the returned data is valid, you need an RRTYPE to enforce it. Now, one might say, "If you want to use this feature, you can't use that name for something else." I would agree. But that doesn't mean that the underscore label somehow makes the name safe. All the client software for repute (or any other TXT-using protocol) needs to be able to handle examples where the return data format doesn't conform to the standard, which means that instead of relying on your DNS library to do proper type checking, your application has to do it. Not the end of the world, but given my experience of in-application type checking (in the database application support world I sometimes live in), I can't say I am sanguine about robust interoperability over the long haul. A -- Andrew Sullivan ajs@anvilwalrusden.com From dfs@roaringpenguin.com Tue Aug 2 12:19:40 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4EE1F0C3A for ; Tue, 2 Aug 2011 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRv35l0b4xqH for ; Tue, 2 Aug 2011 12:19:39 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92E1F0C39 for ; Tue, 2 Aug 2011 12:19:39 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p72JJjQH018046 for ; Tue, 2 Aug 2011 15:19:47 -0400 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p72JJh7F005500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 15:19:45 -0400 Date: Tue, 2 Aug 2011 15:19:43 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110802151943.7eff0b3b@hydrogen.roaringpenguin.com> In-Reply-To: <20110802190330.GA22542@shinkuro.com> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <20110802190330.GA22542@shinkuro.com> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=BkeVPIUnnCp8 LfKrwN7gOxHGcJw=; b=fpIYx5AKxsx2pDBcxCJ8KebfCnltxalmFg+YBvw+s4jE EypO4Qx5H/IBRL/cLKUz6CgtNi/azWXiJj060h/M0s4FmH1/qh1Uuc6rR08LxSeN vLQbS4c+zds0ExBjtnJOxt4yyYrsX5v5vI65xM8OigihuDhdO++cw7LXTan1SbI= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110802 / 01FfvjK2w Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:19:40 -0000 On Tue, 2 Aug 2011 15:03:31 -0400 Andrew Sullivan wrote: > [...] which means that instead of relying on your DNS library to > do proper type checking, your application has to do it. But one of the strongest arguments for a new RR is that you can introduce it without any changes to DNS or resolver software. If you want your DNS library to do type-checking, that argument fails. I'm not saying a new RR is necessarily a bad thing, but it's not as easy to Just Implement as some people are saying. Regards, David. From johnl@iecc.com Tue Aug 2 12:33:08 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A621E1F0C39 for ; Tue, 2 Aug 2011 12:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvGQQuNvMHMF for ; Tue, 2 Aug 2011 12:33:08 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A3EAC11E80A1 for ; Tue, 2 Aug 2011 12:33:07 -0700 (PDT) Received: (qmail 22392 invoked from network); 2 Aug 2011 19:33:17 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 19:33:17 -0000 Received: (qmail 95072 invoked from network); 2 Aug 2011 19:33:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 19:33:16 -0000 Date: 2 Aug 2011 19:32:54 -0000 Message-ID: <20110802193254.20526.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <20110802151943.7eff0b3b@hydrogen.roaringpenguin.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:33:08 -0000 >But one of the strongest arguments for a new RR is that you can >introduce it without any changes to DNS or resolver software. If you >want your DNS library to do type-checking, that argument fails. On my list of Things to Do When I Get Back from the Jersey Shore* is a sketch of a DNS extension language so a computer could have a single list of extended DNS type definitions like it has a list of ports or of MIME types. Then DNS software could look at that to support new types, and you could add a new type by adding a line to the list. You couldn't do everything with it, e.g., I wouldn't try to do NSEC3 that way, but for the kind of stuff we're talking about that's a list of numbers, strings, names, and maybe bitmasks, it shouldn't be too hard. R's, John * - no, not that part, the much quieter next island south. Oy. From paul.hoffman@vpnc.org Tue Aug 2 12:42:49 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504D21F84DE for ; Tue, 2 Aug 2011 12:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3K2-NRqrK5n for ; Tue, 2 Aug 2011 12:42:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CE2F221F84D5 for ; Tue, 2 Aug 2011 12:42:48 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72JgcPi025931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Aug 2011 12:42:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <20110802193254.20526.qmail@joyce.lan> Date: Tue, 2 Aug 2011 12:42:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41D7CC11-8245-407B-90E8-B09958E1EC7F@vpnc.org> References: <20110802193254.20526.qmail@joyce.lan> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:42:50 -0000 On Aug 2, 2011, at 12:32 PM, John Levine wrote: >> But one of the strongest arguments for a new RR is that you can >> introduce it without any changes to DNS or resolver software. If you >> want your DNS library to do type-checking, that argument fails. >=20 > On my list of Things to Do When I Get Back from the Jersey Shore* is a > sketch of a DNS extension language so a computer could have a single > list of extended DNS type definitions like it has a list of ports or > of MIME types. Then DNS software could look at that to support new > types, and you could add a new type by adding a line to the list. You > couldn't do everything with it, e.g., I wouldn't try to do NSEC3 that > way, but for the kind of stuff we're talking about that's a list of > numbers, strings, names, and maybe bitmasks, it shouldn't be too hard. And I will offer to assist. I believe that I have probably not succeeded = in getting folks here to consider something other than TXT, but such a = tool would prevent this argument from happening five years from now. --Paul Hoffman From dfs@roaringpenguin.com Tue Aug 2 12:49:43 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06521F0C51 for ; Tue, 2 Aug 2011 12:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTo7SIdM7oqc for ; Tue, 2 Aug 2011 12:49:43 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id DA89C1F0C39 for ; Tue, 2 Aug 2011 12:49:42 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p72Jnnlr023386 for ; Tue, 2 Aug 2011 15:49:51 -0400 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p72Jnkxi003401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 15:49:49 -0400 Date: Tue, 2 Aug 2011 15:49:46 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110802154946.296c03ed@hydrogen.roaringpenguin.com> In-Reply-To: <20110802193254.20526.qmail@joyce.lan> References: <20110802151943.7eff0b3b@hydrogen.roaringpenguin.com> <20110802193254.20526.qmail@joyce.lan> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=XrEOSao8GFPI zjF8V1h4dkOJxaY=; b=Dskx1G3QOX7k3ROh/aPb/XTfTjVKImWOtE1dOS+yQDJQ 5Zo7aDuR6uiIVM9tAfW0ANY5GM6g4WwTtnypDqiRdLEU9LNyqlV4dUwitiV1lqSM g7xi/7EVMDjYomq8BzvyDcFN8Z3CA6Plbl37bKs22KD+z3L3immEKqvnSRPfJHw= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110802 / 01FfvNN3j Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:49:43 -0000 On 2 Aug 2011 19:32:54 -0000 "John Levine" wrote: > On my list of Things to Do When I Get Back from the Jersey Shore* is a > sketch of a DNS extension language so a computer could have a single > list of extended DNS type definitions like it has a list of ports or > of MIME types. Ah, so we will reinvent ASN.1 :) Actually, ASN.1 with PER might not be too bad. Regards, David. From ajs@anvilwalrusden.com Tue Aug 2 13:06:16 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97711E807F for ; Tue, 2 Aug 2011 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8F+o7mVXqFe for ; Tue, 2 Aug 2011 13:06:16 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E33EA21F85A3 for ; Tue, 2 Aug 2011 13:06:15 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8B86A1ECB41C for ; Tue, 2 Aug 2011 20:06:25 +0000 (UTC) Date: Tue, 2 Aug 2011 16:06:19 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110802200618.GE22542@shinkuro.com> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <20110802190330.GA22542@shinkuro.com> <20110802151943.7eff0b3b@hydrogen.roaringpenguin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110802151943.7eff0b3b@hydrogen.roaringpenguin.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:06:16 -0000 On Tue, Aug 02, 2011 at 03:19:43PM -0400, David F. Skoll wrote: > > [...] which means that instead of relying on your DNS library to > > do proper type checking, your application has to do it. > > But one of the strongest arguments for a new RR is that you can > introduce it without any changes to DNS or resolver software. If you > want your DNS library to do type-checking, that argument fails. That's not actually my argument. Unknown RRTYPE support is useful because _everyone else_ isn't a gating factor on your using the new RRTYPE. I think that it would be foolish to use an unknown RRTYPE directly in the application. The library that is talking directly to the DNS probably does want to know about the RRTYPE. Now, in early deployment that might be a special-purpose resolver library that you ship with the application to ensure it has support for the RRTYPE; at installation time, you check the system library to see whether it has the support you need and if not use your special-purpose one (and hope that this withers on the vine eventually). > I'm not saying a new RR is necessarily a bad thing, but it's not as > easy to Just Implement as some people are saying. I for one was not trying to suggest that. I was instead trying to suggest that it's not a simple no-brainer decision. A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Tue Aug 2 13:39:53 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4277011E808C for ; Tue, 2 Aug 2011 13:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.615 X-Spam-Level: X-Spam-Status: No, score=-6.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdDymq211lNK for ; Tue, 2 Aug 2011 13:39:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F611E8082 for ; Tue, 2 Aug 2011 13:39:52 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p72KdtKw001114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 13:40:01 -0700 Message-ID: <4E386099.8000804@dcrocker.net> Date: Tue, 02 Aug 2011 13:39:53 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> In-Reply-To: <20110802173648.GV22542@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 02 Aug 2011 13:40:01 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:39:53 -0000 Andrew, On 8/2/2011 10:36 AM, Andrew Sullivan wrote: > On Tue, Aug 02, 2011 at 08:06:14AM -0700, Dave CROCKER wrote: > >> New RRs will be zero systems cost when the there is broad, >> end-to-end support, from client resolvers, through recursive >> servers, to authoritative servers, for new RRs, requiring nothing >> more the administrative effort of specifying the new record. > > So instead of addressing the distinction I was making in the mail I > sent, which exactly acknowledged your point and asked for help in > identifying the points of pain, you found it easier to point and > laugh? Thanks. Please feel entirely assured that there is no laughter anywhere in the room. Tears, perhaps, but no laughter. There is nothing funny about years of having the core DNS community assert the demand that new RRs be used, but put no effort into making sure they are end-to-end viable. That assurance should be the responsibility of the folks controlling the DNS, not of folks trying to use it. As for addressing the distinction you made, please forgive my having jumped into the middle of things. I thought that my text was rather straightforward at implying new RRs are not currently viable, or at least, not easily viable. That was meant to address the distinction quite fundamentally. >> In any event, the use of underscore-based subdomain naming renders >> the primary argument against TXT moot. > > Given that we can't even get people to agree on how underscores are to > be used (there's no registry, and there are two quite different use > patterns and no reason to suppose there won't be another one > tomorrow), I find it mighty hard to believe that the underscore > "convention" is a big improvement. It's a one-at-a-time answer too. > It just moves the pain around. I suspect you are aware that I've been pressing rather forcefully to get the DNSEXT wg to consider the revised registry specification that I put forward at the end of March and have not even gotten an acknowledgement, nevermind discussion. This probably does not qualify as "can't even get people to agree" because that would imply conversation and there hasn't been any. At this point, I'm trying to discover an alternative path. Suggestions and assistance are eagerly sought... As for 'two different use patterns', that worthy of a separate thread and you've got my interest. On 8/2/2011 11:50 AM, Andrew Sullivan wrote: > This seems to me, for the > reasons I have outlined, to be a bad idea, but lots of people think my TXT with underscore is ugly, but is quite workable. It scale just fine. > advice is wrong. However, I don't think the document undertaking to > define this TXT record ought to cite something that says, "Don't use > TXT records," as a reason why it is using a TXT record. That was the > basis of my original question. Indeed it would be reasonable for the draft to note the problematic nature of the recommendation in the IAB paper... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Aug 2 14:01:05 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF021F8760 for ; Tue, 2 Aug 2011 14:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.672 X-Spam-Level: X-Spam-Status: No, score=-103.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCTRwvN5ooBb for ; Tue, 2 Aug 2011 14:01:04 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A965821F8757 for ; Tue, 2 Aug 2011 14:01:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 2 Aug 2011 14:01:14 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 2 Aug 2011 14:01:13 -0700 Thread-Topic: [domainrep] More on TXT records Thread-Index: AcxRTGQ2aJAKwj7WSZq/tQhL+gpG5AACsIHQ Message-ID: References: <20110802193254.20526.qmail@joyce.lan> <41D7CC11-8245-407B-90E8-B09958E1EC7F@vpnc.org> In-Reply-To: <41D7CC11-8245-407B-90E8-B09958E1EC7F@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:01:05 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Paul Hoffman > Sent: Tuesday, August 02, 2011 12:43 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] More on TXT records >=20 > And I will offer to assist. I believe that I have probably not > succeeded in getting folks here to consider something other than TXT, > but such a tool would prevent this argument from happening five years > from now. I'm comfortable with either approach, really. They each have their own ups= and downs. Though I think TXT is the path of least resistance, it also is= not problem-free. What about doing both, and letting the less-implemented one die? From ajs@anvilwalrusden.com Tue Aug 2 14:07:59 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855F011E80B7 for ; Tue, 2 Aug 2011 14:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quV0pVG50H4v for ; Tue, 2 Aug 2011 14:07:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0CABF11E80B6 for ; Tue, 2 Aug 2011 14:07:58 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C83041ECB41C for ; Tue, 2 Aug 2011 21:08:08 +0000 (UTC) Date: Tue, 2 Aug 2011 17:08:02 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110802210801.GL22542@shinkuro.com> References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <4E386099.8000804@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E386099.8000804@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:07:59 -0000 On Tue, Aug 02, 2011 at 01:39:53PM -0700, Dave CROCKER wrote: > As for addressing the distinction you made, please forgive my having > jumped into the middle of things. I thought that my text was > rather straightforward at implying new RRs are not currently viable, > or at least, not easily viable. That was meant to address the > distinction quite fundamentally. Nonsense. We had two problems in the DNS with new RRTYPEs. One was that the intermediate software all puked. The other was that we have support software that doesn't co-operate. I was arguing that the intermediate software mostly didn't do that any more, and acknowledging that there is a problem with other software. I was then asking for help in identifying where those problems are. To stamp your foot and say, "DNS weenies are saying this over and over again," doesn't help. > I suspect you are aware that I've been pressing rather forcefully to > get the DNSEXT wg to consider the revised registry specification ITYM DNSOP. If it were DNSEXT, I'd be aware of it, and I'd tell you you need to take it to DNSOP because there's no protocol change. > This probably does not qualify as "can't even get people to agree" > because that would imply conversation and there hasn't been any. Well, there was some. For instance, you presented a previous draft at a previous IETF meeting and did, ISTR, get some feedback from some guy I used to know. But it's true it would be nice to get more traction. But the other point I was trying to make -- that putting this in a registry still doesn't make this clean because it implies a restriction inside a name space that, formally, we don't control -- is still a problem. A -- Andrew Sullivan ajs@anvilwalrusden.com From R.E.Sonneveld@sonnection.nl Tue Aug 2 14:33:39 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E670C11E80C6 for ; Tue, 2 Aug 2011 14:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKiKWLoxJHZr for ; Tue, 2 Aug 2011 14:33:39 -0700 (PDT) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id DBB6211E80C5 for ; Tue, 2 Aug 2011 14:33:38 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LPB00A00L8B7000@hydrogen.mailtransaction.com>; Tue, 02 Aug 2011 23:33:47 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LPB000IIL8BAA00@hydrogen.mailtransaction.com>; Tue, 02 Aug 2011 23:33:47 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LPB0091NL8BK000@lion.sonnection.nl> for domainrep@ietf.org; Tue, 02 Aug 2011 23:33:47 +0200 (CEST) Message-id: <4E386E0C.2090802@sonnection.nl> Date: Tue, 02 Aug 2011 23:37:16 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 To: Andrew Sullivan References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <4E386099.8000804@dcrocker.net> <20110802210801.GL22542@shinkuro.com> In-reply-to: <20110802210801.GL22542@shinkuro.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1312320827; bh=WEG82vWkCXG1sUiAFtslQfRW+0yso8o1fsMTR2Cg4Y8=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=RM7wMsjOqSob1TA/lrQYu5FzGBaOx9gPZVyTmJ5UQ+AvJ6MUzzfVnO1fbxEaN4JLe FNm0BHd63RnOVR1X9DZmhCBbOZjBeUG6BhJn9m2PPZ2PqYn/ef4bA2gqHGeS9e4zyH 3LgpVKTUCUu8fpoZScJudDkiB2QfA0omDu7m4Vdg= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LPB00A00L8B7000 Cc: domainrep@ietf.org Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:33:40 -0000 On 8/2/11 11:08 PM, Andrew Sullivan wrote: > On Tue, Aug 02, 2011 at 01:39:53PM -0700, Dave CROCKER wrote: > >> As for addressing the distinction you made, please forgive my having >> jumped into the middle of things. I thought that my text was >> rather straightforward at implying new RRs are not currently viable, >> or at least, not easily viable. That was meant to address the >> distinction quite fundamentally. > Nonsense. We had two problems in the DNS with new RRTYPEs. One was > that the intermediate software all puked. The other was that we have > support software that doesn't co-operate. I was arguing that the > intermediate software mostly didn't do that any more, and > acknowledging that there is a problem with other software. I was then > asking for help in identifying where those problems are. To stamp > your foot and say, "DNS weenies are saying this over and over again," > doesn't help. > >> I suspect you are aware that I've been pressing rather forcefully to >> get the DNSEXT wg to consider the revised registry specification > ITYM DNSOP. If it were DNSEXT, I'd be aware of it, and I'd tell you > you need to take it to DNSOP because there's no protocol change. > >> This probably does not qualify as "can't even get people to agree" >> because that would imply conversation and there hasn't been any. > Well, there was some. For instance, you presented a previous draft at > a previous IETF meeting and did, ISTR, get some feedback from some guy > I used to know. But it's true it would be nice to get more traction. > > But the other point I was trying to make -- that putting this in a > registry still doesn't make this clean because it implies a > restriction inside a name space that, formally, we don't control -- is > still a problem. OK, folks. Can we first concentrate on the outline of all the work to be done and later on get into the details? Things that need our attention: - charter - who will work on what document(s) - milestones - how to discuss the various documents without getting a cacophony of voices, interfering opinions on 'n' topics etc. /rolf From msk@cloudmark.com Tue Aug 2 14:41:16 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1499111E80AE for ; Tue, 2 Aug 2011 14:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.671 X-Spam-Level: X-Spam-Status: No, score=-103.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voWSBFrrzfKx for ; Tue, 2 Aug 2011 14:41:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA5211E808F for ; Tue, 2 Aug 2011 14:41:15 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 2 Aug 2011 14:41:25 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 2 Aug 2011 14:41:25 -0700 Thread-Topic: First things first (was RE: [domainrep] More on TXT records) Thread-Index: AcxRW+mdjiv/ZvTuS6mg4/KmI9uQUAAABhZQ Message-ID: References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <4E386099.8000804@dcrocker.net> <20110802210801.GL22542@shinkuro.com> <4E386E0C.2090802@sonnection.nl> In-Reply-To: <4E386E0C.2090802@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [domainrep] First things first (was RE: More on TXT records) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:41:16 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Rolf E. Sonneveld > Sent: Tuesday, August 02, 2011 2:37 PM > To: Andrew Sullivan > Cc: domainrep@ietf.org > Subject: Re: [domainrep] More on TXT records >=20 > OK, folks. Can we first concentrate on the outline of all the work to be > done and later on get into the details? Things that need our attention: >=20 > - charter > - milestones Already out for review. Comments, please. > - who will work on what document(s) Nathaniel has said he'd like to keep the framework ("model") document. I'll volunteer to take the email vocabulary one ("vocab-identity"). I thin= k the other current vocabulary one ("vocab-email") should get a different a= uthor, or should be allowed to die. I'd also like to take a crack at the DNS or UDP one, whichever one we decid= e to keep. That leaves the HTTP query one and the media type registration looking for = new owners, plus any others we decide we need. Any takers? I suspect David Skoll is in for resurrecting the one he had about how reput= ation systems can receive feedback from data providers. He should confirm = that. And I'm up for reviewing and commenting on all of them. And I'll be doing = at least one of the implementations (an open source one) with my employer d= oing a commercial one. I have sent to the ADs already a list of about 20 people that volunteered, = either on the list, in the jabber room during the BoF, in the BoF or person= ally afterwards, to review and comment on documents and/or implement. > - how to discuss the various documents without getting a cacophony of > voices, interfering opinions on 'n' topics etc. That's for the co-chairs to do, whoever the ADs pick to do that. I think t= hat I need to step aside from that selection pool as I'm too immersed in th= e work to also be co-chairing. If anyone's keen to co-chair that hasn't already said so, let me know. I'v= e submitted a few names to the ADs already. -MSK From dfs@roaringpenguin.com Tue Aug 2 15:21:37 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3976911E80D1 for ; Tue, 2 Aug 2011 15:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BPGfK0DI2NI for ; Tue, 2 Aug 2011 15:21:36 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id 6E95F11E80CD for ; Tue, 2 Aug 2011 15:21:36 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p72MLiCm014483 for ; Tue, 2 Aug 2011 18:21:45 -0400 Received: from shishi.roaringpenguin.com (dfs@shishi.roaringpenguin.com [192.168.2.3]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p72MLga5030386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 18:21:44 -0400 Date: Tue, 2 Aug 2011 18:21:41 -0400 From: "David F. Skoll" To: "domainrep@ietf.org" Message-ID: <20110802182141.74b24a15@shishi.roaringpenguin.com> In-Reply-To: References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <4E386099.8000804@dcrocker.net> <20110802210801.GL22542@shinkuro.com> <4E386E0C.2090802@sonnection.nl> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=UeHDRxrNL1BM JjjFCR9xqsi8yto=; b=chwigHdC+RJHpYNgBBo4A8XoRwwzsMNHIxbam/ovrn93 9gLmzhjIdeBrBjDg07L/0J+8Tql0LyuLmT/Bdp0T4sWC5GkeM7ijVECQFRrxODUM 2WLJaBUELmT1uVCQEegXORHmOoeRyIevbXU2JnoY93t7EjIrKoYBYteNj3quGGU= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110802 / 01FfylI6g Subject: Re: [domainrep] First things first (was RE: More on TXT records) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:21:37 -0000 On Tue, 2 Aug 2011 14:41:25 -0700 "Murray S. Kucherawy" wrote: > I suspect David Skoll is in for resurrecting the one he had about how > reputation systems can receive feedback from data providers. He > should confirm that. Yes, confirmed. Regards, David. From johnl@iecc.com Tue Aug 2 15:52:27 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6900311E80E4 for ; Tue, 2 Aug 2011 15:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK6UglfDNnal for ; Tue, 2 Aug 2011 15:52:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1111E8095 for ; Tue, 2 Aug 2011 15:52:26 -0700 (PDT) Received: (qmail 23741 invoked from network); 2 Aug 2011 22:52:35 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 22:52:35 -0000 Received: (qmail 62229 invoked from network); 2 Aug 2011 22:52:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 22:52:35 -0000 Date: 2 Aug 2011 22:52:13 -0000 Message-ID: <20110802225213.74818.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:52:27 -0000 It's basically fine, but the bit about RBLs (which aren't even called RBLs any more) seems a bit out of touch. How about this as a replacement for the paragraph that starts "Reputation system such as ..." Reputation systems may publish reports that the subjects of the reports consider to be wrong, due to error, malice or a combination. The group will consider the feasibility and utility of systems to dispute or challenge information published by a reputation system. It will also consider the feasibility and utility of meta-reputation systems, to rate the accuracy and relability of reputation systems, and ways that reputation systems can operate transparently. I spscifically took out redress and lawsuits, since they are way outside the IETF's expertise. R's, John From johnl@iecc.com Tue Aug 2 15:54:38 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE46811E80C3 for ; Tue, 2 Aug 2011 15:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.546 X-Spam-Level: X-Spam-Status: No, score=-110.546 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i0c3v0QAdKP for ; Tue, 2 Aug 2011 15:54:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3488B11E8095 for ; Tue, 2 Aug 2011 15:54:38 -0700 (PDT) Received: (qmail 23766 invoked from network); 2 Aug 2011 22:54:48 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 22:54:48 -0000 Received: (qmail 62847 invoked from network); 2 Aug 2011 22:54:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 22:54:48 -0000 Date: 2 Aug 2011 22:54:25 -0000 Message-ID: <20110802225425.75438.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:54:38 -0000 > >What about doing both, and letting the less-implemented one die? Sure, but at this point it's functionally equivalent to just doing text. Ask SPF users how often they query for type 99 RR's. R's, John From johnl@iecc.com Tue Aug 2 15:55:17 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3A11E80C3 for ; Tue, 2 Aug 2011 15:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.57 X-Spam-Level: X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDCxF1FZQfXg for ; Tue, 2 Aug 2011 15:55:16 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0211E8095 for ; Tue, 2 Aug 2011 15:55:16 -0700 (PDT) Received: (qmail 23788 invoked from network); 2 Aug 2011 22:55:26 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 22:55:26 -0000 Received: (qmail 62932 invoked from network); 2 Aug 2011 22:55:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 22:55:26 -0000 Date: 2 Aug 2011 22:55:04 -0000 Message-ID: <20110802225504.75643.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <20110802154946.296c03ed@hydrogen.roaringpenguin.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:55:17 -0000 >Ah, so we will reinvent ASN.1 :) Actually, ASN.1 with PER might not be >too bad. Ewww. I was planning to stop at about 2% of the complexity of ASN.1. R's, John From msk@cloudmark.com Tue Aug 2 16:18:39 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0112C11E80F1 for ; Tue, 2 Aug 2011 16:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.67 X-Spam-Level: X-Spam-Status: No, score=-103.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATbPNGd0giFG for ; Tue, 2 Aug 2011 16:18:38 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4211E8095 for ; Tue, 2 Aug 2011 16:18:38 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 2 Aug 2011 16:18:48 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 2 Aug 2011 16:18:47 -0700 Thread-Topic: [domainrep] Proposed charter, revised after BoF Thread-Index: AcxRZt+pYPEAW+9aQ06G4hYy82+EYAAA6EjA Message-ID: References: <20110802225213.74818.qmail@joyce.lan> In-Reply-To: <20110802225213.74818.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:18:39 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQGllY2MuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDIsIDIwMTEgMzo1MiBQ TQ0KPiBUbzogZG9tYWlucmVwQGlldGYub3JnDQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+ IFN1YmplY3Q6IFJlOiBbZG9tYWlucmVwXSBQcm9wb3NlZCBjaGFydGVyLCByZXZpc2VkIGFmdGVy IEJvRg0KPiANCj4gSXQncyBiYXNpY2FsbHkgZmluZSwgYnV0IHRoZSBiaXQgYWJvdXQgUkJMcyAo d2hpY2ggYXJlbid0IGV2ZW4gY2FsbGVkDQo+IFJCTHMgYW55IG1vcmUpIHNlZW1zIGEgYml0IG91 dCBvZiB0b3VjaC4gIEhvdyBhYm91dCB0aGlzIGFzIGENCj4gcmVwbGFjZW1lbnQgZm9yIHRoZSBw YXJhZ3JhcGggdGhhdCBzdGFydHMgIlJlcHV0YXRpb24gc3lzdGVtIHN1Y2ggYXMNCj4gLi4uIg0K PiANCj4gICAgUmVwdXRhdGlvbiBzeXN0ZW1zIG1heSBwdWJsaXNoIHJlcG9ydHMgdGhhdCB0aGUg c3ViamVjdHMgb2YgdGhlDQo+ICAgIHJlcG9ydHMgY29uc2lkZXIgdG8gYmUgd3JvbmcsIGR1ZSB0 byBlcnJvciwgbWFsaWNlIG9yIGENCj4gICAgY29tYmluYXRpb24uICBUaGUgZ3JvdXAgd2lsbCBj b25zaWRlciB0aGUgZmVhc2liaWxpdHkgYW5kIHV0aWxpdHkNCj4gICAgb2Ygc3lzdGVtcyB0byBk aXNwdXRlIG9yIGNoYWxsZW5nZSBpbmZvcm1hdGlvbiBwdWJsaXNoZWQgYnkgYQ0KPiAgICByZXB1 dGF0aW9uIHN5c3RlbS4gIEl0IHdpbGwgYWxzbyBjb25zaWRlciB0aGUgZmVhc2liaWxpdHkgYW5k DQo+ICAgIHV0aWxpdHkgb2YgbWV0YS1yZXB1dGF0aW9uIHN5c3RlbXMsIHRvIHJhdGUgdGhlIGFj Y3VyYWN5IGFuZA0KPiAgICByZWxhYmlsaXR5IG9mIHJlcHV0YXRpb24gc3lzdGVtcywgYW5kIHdh eXMgdGhhdCByZXB1dGF0aW9uIHN5c3RlbXMNCj4gICAgY2FuIG9wZXJhdGUgdHJhbnNwYXJlbnRs eS4NCj4gDQo+IEkgc3BzY2lmaWNhbGx5IHRvb2sgb3V0IHJlZHJlc3MgYW5kIGxhd3N1aXRzLCBz aW5jZSB0aGV5IGFyZSB3YXkNCj4gb3V0c2lkZSB0aGUgSUVURidzIGV4cGVydGlzZS4NCg0KVGhh dCB3b3JrcyBmb3IgbWUuDQo= From jdfalk-lists@cybernothing.org Tue Aug 2 17:34:48 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A621F85A1 for ; Tue, 2 Aug 2011 17:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7gkEYewJB2C for ; Tue, 2 Aug 2011 17:34:47 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7A35E21F85A0 for ; Tue, 2 Aug 2011 17:34:47 -0700 (PDT) Received: from [192.168.11.41] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p730Ytbe028589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 17:34:57 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p730Ytbe028589 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312331697; bh=w6keCtP8OU3f3CgstF3WRFmO5CdNmPOGrgZTTzc72 tg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=YqArZcv5l3nO pJVgSDrmEGtzKZodJUHVY+FVVP/OEmsAvthExb1AXB4Dps6o5y6+FxRR9JJvtyeCRYg 3uSxCFAtAzq40r/6Y4WKlqr7GF7+g87PxMKzYZUzrUfP0Ka7KhNYN/cmfmF2bbob1RD rQj5MU1Ov2x75YB0Oa7ypQcrs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Tue, 2 Aug 2011 17:34:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110802225213.74818.qmail@joyce.lan> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:34:48 -0000 On Aug 2, 2011, at 4:18 PM, Murray S. Kucherawy wrote: >> It's basically fine, but the bit about RBLs (which aren't even called >> RBLs any more) seems a bit out of touch. How about this as a >> replacement for the paragraph that starts "Reputation system such as >> ..." [ . . . ] > That works for me. +1 More generally, I think we need to keep the initial charter tightly = focused. Johan is absolutely right about the vast and varied interest = in reputation in the academic community and elsewhere, but I'd be = concerned that leaving things loose would result in vast and varied = conversations which never actually result in work getting done. I'd be = in favor of adding one more vocabulary to this first charter, but we = should decide what it will be now rather than leaving it open. If other people want to work on additional vocabularies or extensions as = individual submissions, of course, that's fine. The WG can always = recharter to adopt any drafts which have sufficient interest and = momentum. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Tue Aug 2 20:37:35 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3811E811B for ; Tue, 2 Aug 2011 20:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.669 X-Spam-Level: X-Spam-Status: No, score=-103.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON7pNm2cZQJ6 for ; Tue, 2 Aug 2011 20:37:35 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4E11E8081 for ; Tue, 2 Aug 2011 20:37:35 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 2 Aug 2011 20:37:45 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 2 Aug 2011 20:37:44 -0700 Thread-Topic: [domainrep] Proposed charter, revised after BoF Thread-Index: AcxRdTGGsMOV8KT4SSKJUEvfX2hkdAAGVjzg Message-ID: References: <20110802225213.74818.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 03:37:35 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of J.D. Falk > Sent: Tuesday, August 02, 2011 5:35 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Proposed charter, revised after BoF >=20 > If other people want to work on additional vocabularies or extensions > as individual submissions, of course, that's fine. The WG can always > recharter to adopt any drafts which have sufficient interest and > momentum. The feeling I got in the room, especially from our AD, is that this is prob= ably the preferred path. People interested in spaces other than email doma= in names can certainly work to keep the framework and protocols extensible = as needed, but the first vocabulary/application the work supports will prob= ably need to be constrained. If that's wildly successful, I suspect much more latitude will be granted i= n a recharter. From msk@cloudmark.com Tue Aug 2 21:05:38 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5730F11E812D for ; Tue, 2 Aug 2011 21:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.669 X-Spam-Level: X-Spam-Status: No, score=-103.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwwTpxtcXDLR for ; Tue, 2 Aug 2011 21:05:37 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2711E8125 for ; Tue, 2 Aug 2011 21:05:37 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 2 Aug 2011 21:05:48 -0700 From: "Murray S. Kucherawy" To: Johan Pouwelse , "domainrep@ietf.org" Date: Tue, 2 Aug 2011 21:05:47 -0700 Thread-Topic: [domainrep] Drafting a new use-case: information dissemination ? Thread-Index: AcxOPmZD/awUTJF+TDqJupYMDXvexQDUtWrw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Drafting a new use-case: information dissemination ? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 04:05:38 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Johan Pouwelse > Sent: Friday, July 29, 2011 3:24 PM > To: domainrep@ietf.org > Subject: [domainrep] Drafting a new use-case: information dissemination? >=20 > Dear All, > At the 81th IETF BoF I've volunteered to contribute to the hopefully > soon-to-be WG REPUTE. Hi Johan, glad you were there! > Proposed use case: information dissemination > [...] This seems to me to be a reasonable use case. What you'd need to do, assum= ing the proposed framework, is to create a way to identify each of the four= use cases you listed so that they can be the subjects of a query. The tri= ck there is reliable identifiers; if you can't identify uniquely one of the= objects you've listed, the reputation can't be trusted because spoofing is= possible. For example, you listed an open WiFi base station. It's possible to bring = up a base station with any SSID you want, so that by itself isn't a reliabl= e identifier; you'd need something more. Maybe an SSID plus a MAC address = or something would work. People more expert at networking than me would ha= ve to weigh in here. So as long as you can come up with a secure way to identify any of the part= icipants you listed, this framework could be applied by creating one or mor= e vocabularies to describe them and express a reputation about them, like "= TRUSTED-BASE-STATION" or "TRUSTED-FORWARDER". Then it's just a matter of c= ollecting history of co-operation reports about each of them and condensing= those reports down into a score that can be reported using our framework. Thanks for the links to the two papers; I'll check them out soon. Glad to have you aboard! -MSK From vesely@tana.it Wed Aug 3 08:21:45 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A621F8B61 for ; Wed, 3 Aug 2011 08:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.674 X-Spam-Level: X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWzUqnNlbCEm for ; Wed, 3 Aug 2011 08:21:45 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C6BA021F886D for ; Wed, 3 Aug 2011 08:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312384916; bh=2AtvB2DMG+JWkN3gL/kMQVJlti6g372CQqt5pJ50crI=; l=550; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LGWkELTw0L9TQ0eJBiYdbH+k1y/+gDGROBcj6+PyTda8PeT013yZ7QElTWEtifO+j m59MORZ6HLaqRQG1VPrEFlnjJ9+K0pY79ukD6bOTxNvvGsxNpSyxbhlPmD/5WWI8I4 zdbnjqWxEGtUMu6YaaIbzxqvQ+O2Kt2xGv3/UL1Y= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 03 Aug 2011 17:21:56 +0200 id 00000000005DC042.000000004E396794.00002D59 Message-ID: <4E396794.1070202@tana.it> Date: Wed, 03 Aug 2011 17:21:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org References: <20110802225425.75438.qmail@joyce.lan> In-Reply-To: <20110802225425.75438.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:21:45 -0000 On 03/Aug/11 00:54, John Levine wrote: >> >>What about doing both, and letting the less-implemented one die? > > Sure, but at this point it's functionally equivalent to just doing > text. But with worse performance, see below. > Ask SPF users how often they query for type 99 RR's. At the risk of answering a rhetorical question, a compliant checker has to _always_ query the SPF RR, since that would take precedence over any TXT one. I'd be curious how a revised SPF could remove this particular arrow from its back... From ietf-dkim@kitterman.com Wed Aug 3 09:23:17 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B721F8A97 for ; Wed, 3 Aug 2011 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=-1.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmz3dW4gp1os for ; Wed, 3 Aug 2011 09:23:16 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEF121F8A70 for ; Wed, 3 Aug 2011 09:23:14 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id C2BCF38C131; Wed, 3 Aug 2011 12:23:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1312388606; bh=Hhr+JJjD8wHUxfFdujn/2efmvsHoo9r0ZO9+WcCDsf0=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=cl6C3H7dA93+BGDOwDu/F5qXq3A2X3RFAQKSw6lmGiaJhMDhfLHKd4fFmSZRnVb2v 8/Pk1bhthx9pZk0KHiMuSC1XTEbvVWgNIV61LUazCCnkqIM6MjHwgZPeUU0a77wZyP ITglv3GrOndA/DJkai8STg53nSnu5Xwzf26w8MQA= From: Scott Kitterman To: domainrep@ietf.org Date: Wed, 3 Aug 2011 12:23:24 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110802225425.75438.qmail@joyce.lan> <4E396794.1070202@tana.it> In-Reply-To: <4E396794.1070202@tana.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108031223.24665.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:23:17 -0000 On Wednesday, August 03, 2011 11:21:56 AM Alessandro Vesely wrote: > > Ask SPF users how often they query for type 99 RR's. > > At the risk of answering a rhetorical question, a compliant checker > has to always query the SPF RR, since that would take precedence > over any TXT one. I'd be curious how a revised SPF could remove this > particular arrow from its back... No. It doesn't. RFC 4408 para 4.4 says: "In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the name, querying for either RR type TXT, SPF, or both. If both SPF and TXT RRs are looked up, the queries MAY be done in parallel." Operators are perfectly free to waste resources querying for Type SPF or not. If you get both back, then the Type SPF takes precident, but there's not requirement to look for it. Scott K From peer2peer@gmail.com Mon Aug 8 07:57:28 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553E521F8B20 for ; Mon, 8 Aug 2011 07:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srTFarFT6JaW for ; Mon, 8 Aug 2011 07:57:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A073F21F8B0F for ; Mon, 8 Aug 2011 07:57:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so922449gyf.31 for ; Mon, 08 Aug 2011 07:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=bcVpjMg7BMjQsNC8h6lLtPGIW8XTZi3/v0U2O9mro44=; b=p4tAtk3WbChw2QzEXqeZsXMaSjs1ZefwHaqYkPHJxFmtHECP3m+F+CD09tAOS1cfPN jOrT+CdlrmrVbwzBZ31B6MIBrAfCpbvukbQEKq/A2AH2R1/tpltsyNizFNNlDHiDZqeS Hz3E+MopWwxSVFliIkOKVeyxYllJa+8NjA9Gs= MIME-Version: 1.0 Received: by 10.142.193.7 with SMTP id q7mr5973217wff.370.1312815469962; Mon, 08 Aug 2011 07:57:49 -0700 (PDT) Received: by 10.142.210.11 with HTTP; Mon, 8 Aug 2011 07:57:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Aug 2011 16:57:49 +0200 Message-ID: From: Johan Pouwelse To: "domainrep@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [domainrep] Drafting a new use-case: information dissemination ? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 14:57:28 -0000 On 3 August 2011 06:05, Murray S. Kucherawy wrote: > This seems to me to be a reasonable use case. What you'd need to do, ass= uming the proposed framework, is to create a way to identify each of the fo= ur use cases you listed so that they can be the subjects of a query. The t= rick there is reliable identifiers; if you can't identify uniquely one of t= he objects you've listed, the reputation can't be trusted because spoofing = is possible. > > For example, you listed an open WiFi base station. It's possible to brin= g up a base station with any SSID you want, so that by itself isn't a relia= ble identifier; you'd need something more. Maybe an SSID plus a MAC addres= s or something would work. People more expert at networking than me would = have to weigh in here. Yes, indeed reliable non-spoofable IDs are essential. For the REPUTE vision I would recommend the usage of "ECDSA and ECDH Public Keys". The length of the public key is short compared to RSA-like solutions. Usage with standard X.509 certificates is described here: http://www.ietf.org/rfc/rfc3279.txt Linking a public key to a base stations SSID is not obvious. SSIDs have a maximum length of 32 bytes. So that would be a partial hash of some sort. Is it deemed useful to subscribe a uniform non-spoofable ID for REPUTE ? -johan. On 3 August 2011 06:05, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On = Behalf Of Johan Pouwelse >> Sent: Friday, July 29, 2011 3:24 PM >> To: domainrep@ietf.org >> Subject: [domainrep] Drafting a new use-case: information dissemination? >> >> Dear All, >> At the 81th IETF BoF I've volunteered to contribute to the hopefully >> soon-to-be WG REPUTE. > > Hi Johan, glad you were there! > >> Proposed use case: information dissemination >> [...] > > This seems to me to be a reasonable use case. =A0What you'd need to do, a= ssuming the proposed framework, is to create a way to identify each of the = four use cases you listed so that they can be the subjects of a query. =A0T= he trick there is reliable identifiers; if you can't identify uniquely one = of the objects you've listed, the reputation can't be trusted because spoof= ing is possible. > > For example, you listed an open WiFi base station. =A0It's possible to br= ing up a base station with any SSID you want, so that by itself isn't a rel= iable identifier; you'd need something more. =A0Maybe an SSID plus a MAC ad= dress or something would work. =A0People more expert at networking than me = would have to weigh in here. > > So as long as you can come up with a secure way to identify any of the pa= rticipants you listed, this framework could be applied by creating one or m= ore vocabularies to describe them and express a reputation about them, like= "TRUSTED-BASE-STATION" or "TRUSTED-FORWARDER". =A0Then it's just a matter = of collecting history of co-operation reports about each of them and conden= sing those reports down into a score that can be reported using our framewo= rk. > > Thanks for the links to the two papers; I'll check them out soon. > > Glad to have you aboard! > > -MSK > > From nsb@guppylake.com Tue Aug 9 12:57:46 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A575E8014 for ; Tue, 9 Aug 2011 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibcGNSrPbEOE for ; Tue, 9 Aug 2011 12:57:46 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0019C5E8006 for ; Tue, 9 Aug 2011 12:57:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=cUVM4bDI3KGkaP0cbGGUjE8C+hL3ZlH22kr3UAFLHj7lpMkqUn1++HryVX8OBZth14eX0hBjcgPJTRV9oGWtwBS0HadehLtJNQKRJ0LqguE3lZmk0sjIq62IswgJzONq; Received: from 184-202-16-37.pools.spcsdns.net ([184.202.16.37] helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QqsR1-0003by-PI; Tue, 09 Aug 2011 15:57:56 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Tue, 9 Aug 2011 15:57:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Johan Pouwelse X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Drafting a new use-case: information dissemination ? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 19:57:47 -0000 On Aug 8, 2011, at 10:57 AM, Johan Pouwelse wrote: >> For example, you listed an open WiFi base station. It's possible to = bring up a base station with any SSID you want, so that by itself isn't = a reliable identifier; you'd need something more. Maybe an SSID plus a = MAC address or something would work. People more expert at networking = than me would have to weigh in here. >=20 > Yes, indeed reliable non-spoofable IDs are essential. Leaving aside the fact that nothing is completely non-spoofable, I don't = think SSID+MAC gets you very far. Some kind of vendor signature is = likely to be essential for any high level of reliability here.=20 But I like the basic idea/use-case! -- Nathaniel= From nsb@guppylake.com Tue Aug 9 13:14:15 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DB55E8005 for ; Tue, 9 Aug 2011 13:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-fjekxZaddq for ; Tue, 9 Aug 2011 13:14:14 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6DF21F8C68 for ; Tue, 9 Aug 2011 13:14:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=LuEdKhLSuYWXFvhz5ymBzSlXl2IwSWfXa47utjhM4tkDaFLDLhtfLfZNvGZ8T3e54uojrZuxTksWEvi8/TmT92HTi5BMLk5khqTfj5SE0d5dBMG+iYs10KYUDkN3TGOE; Received: from 184-202-16-37.pools.spcsdns.net ([184.202.16.37] helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QqshE-0005dk-Ah; Tue, 09 Aug 2011 16:14:41 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Tue, 9 Aug 2011 16:14:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> References: <20110802225213.74818.qmail@joyce.lan> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:14:15 -0000 I, too, am largely fine with the charter. However, in the spirit of = constructive nitpicking: General comment: I agree that we should be focused on the email domain = reputation use case, but I also agree with Johan that we shouldn't let = this focus make us miss the chance to do the general framework properly. = I would like to see us declare any use-cases other than domain = reputation to be out of scope, but also explicitly declare as in-scope a = secondary goal of structuring the protocol in such a way as to separate = the basic mechanism from the application/use-case/vocabulary. (See = "Proposed Addition" below.) Description of Working Group: > reputation data providers make available to consumers data about Consumers? Perhaps we mean users? illustrating the requirement and defining mechanisms to satsify = it. Typo: satisfy The working group will focus for its initial charter only on the s/only/primarily/ (because of the generalized syntax question) specific application of reputation about domain names found in email messages, as it is believed there exists sufficient = experience and expertise in that area. =20 Proposed Addition: "However, the WG will attempt to define the syntax = and mechanisms in such a way that other applications and vocabularies = can be developed without changes to the basic protocol." Goals and Milestones: mmm yyyy:=09 I disagree, I think we can be done by nnn zzzz. Seriously, do we have any idea what dates to shoot for? I would think = the first document or two could be ready for the Paris IETF in March, is = that unrealistically ambitious? -- Nathaniel From R.E.Sonneveld@sonnection.nl Tue Aug 9 13:17:01 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A749521F8A7B for ; Tue, 9 Aug 2011 13:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.041 X-Spam-Level: X-Spam-Status: No, score=-4.041 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUK9tkAmpkKK for ; Tue, 9 Aug 2011 13:17:01 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 99BBA21F8AED for ; Tue, 9 Aug 2011 13:17:00 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LPO00200GD50800@helium.mailtransaction.com>; Tue, 09 Aug 2011 22:17:29 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LPO00M20GD4TV00@helium.mailtransaction.com>; Tue, 09 Aug 2011 22:17:29 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xss9Rkl7HIrRcfgrgccWMw)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LPO00K0KGD4I300@lion.sonnection.nl> for domainrep@ietf.org; Tue, 09 Aug 2011 22:17:28 +0200 (CEST) Message-id: <4E4196AD.9060700@sonnection.nl> Date: Tue, 09 Aug 2011 22:21:01 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 To: "domainrep@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1312921049; bh=EE9fO2GCLPpnx0M04mEQWp4St1uAmdC85odg9XtsFe8=; h=MIME-version:Content-type:Message-id:Date:From:To:Subject; b=CB4lD2oZYx32MwZHtl5fkNvfr9kc8jLDpfAE3pTRfxkbfPopiSL3JIJTo5uXjJNBy JfdkVDOsKQxKWScJoMzWj7Fjt+wQDJMXRQikVrP9ZJV9WnOHAX9IDDcPXGlZiS306G nFYTnSWxVmqSU0X8YuopoQosCQg8o9tnPH+DGOuk= X-DKIM: OpenDKIM Filter v2.1.3 helium.mailtransaction.com 0LPO00200GD50800 Subject: [domainrep] Reputation information data which flows from a reputation client to a reputation provider X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:17:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_xss9Rkl7HIrRcfgrgccWMw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi, all, one of the milestones in the REPUTE charter is: mmm yyyy: Standards track document, defining mechanisms for sending data to reputation providers, to the IESG for publication. I suppose 'sending data to reputation providers' is the feedback mechanism discussed previously on this list? If so, I'd like this to be explicitly mentioned as 'sending feedback data'. So let's make this: mmm yyyy: Standards track document, defining mechanisms for sending feedback data to reputation providers, to the IESG for publication. The reason for making this more explicit, is that there can be multiple types of data that can/will be sent to reputation providers. The charter mentions query mechanisms for reputation clients to retrieve information from reputation providers, but in my view we should not restrict the reputation information flows to just 'queries' and 'feedback'. To give a few examples of other types of reputation information data flow: * at the end of the day there can and will be multiple reputation providers, some of them may want to exchange/interchange/share (part of) their reputation information with others * or it is possible a single provider of reputation has a mesh of reputation servers, which communicate with each other using a reputation protocol. This will not be restricted to one-way traffic, it will require a mechanism that supports reputation information flows in both directions. * another scenario can be, that reputation providers build reputations from data/information that will be provided by thousands or millions of clients, which need to be able to communicate a unit of reputation from client to reputation provider * as far as I know there are providers of RBLs/DNSBLs data which pushes complete DNS zones using zone transfers to customers. We will probably something equivalent for REPUTE, but not restricted to simple DNS zone transfers Or is this meant with the charter section?: "The group will also produce specifications for providing source data into to a reputation service." I suggest we spend some (more) words on this type of data flow and add and extra document on the milestone agenda: mmm yyyy: Standards track document, defining mechanisms for sending reputation data to reputation providers, to the IESG for publication. If there is consensus that such a document is in scope and that it should be part of the document output of this WG, I volunteer to work on this document. For the remainder of the charter: WFM. /rolf --Boundary_(ID_xss9Rkl7HIrRcfgrgccWMw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, all,

one of the milestones in the REPUTE charter is:

    mmm yyyy:      Standards track document, defining mechanisms
            for sending data to reputation providers, to the
            IESG for publication.

I suppose 'sending data to reputation providers' is the feedback mechanism discussed previously on this list? If so, I'd like this to be explicitly mentioned as 'sending feedback data'. So let's make this:

    mmm yyyy:      Standards track document, defining mechanisms
            for sending feedback data to reputation providers, to the
            IESG for publication.

The reason for making this more explicit, is that there can be multiple types of data that can/will be sent to reputation providers. The charter mentions query mechanisms for reputation clients to retrieve information from reputation providers, but in my view we should not restrict the reputation information flows to just 'queries' and 'feedback'.

To give a few examples of other types of reputation information data flow:

  • at the end of the day there can and will be multiple reputation providers, some of them may want to exchange/interchange/share (part of) their reputation information with others
  • or it is possible a single provider of reputation has a mesh of reputation servers, which communicate with each other using a reputation protocol. This will not be restricted to one-way traffic, it will require a mechanism that supports reputation information flows in both directions.
  • another scenario can be, that reputation providers build reputations from data/information that will be provided by thousands or millions of clients, which need to be able to communicate a unit of reputation from client to reputation provider
  • as far as I know there are providers of RBLs/DNSBLs data which pushes complete DNS zones using zone transfers to customers. We will probably something equivalent for REPUTE, but not restricted to simple DNS zone transfers

Or is this meant with the charter section?:

    "The group will also produce specifications for providing source data
    into to a reputation service."
 
I suggest we spend some (more) words on this type of data flow and add and extra document on the milestone agenda:

    mmm yyyy:      Standards track document, defining mechanisms
            for sending reputation data to reputation providers, to the
            IESG for publication.

If there is consensus that such a document is in scope and that it should be part of the document output of this WG, I volunteer to work on this document.

For the remainder of the charter: WFM.

/rolf
--Boundary_(ID_xss9Rkl7HIrRcfgrgccWMw)-- From msk@cloudmark.com Tue Aug 9 13:24:23 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C2F5E801D for ; Tue, 9 Aug 2011 13:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRjia7QX5pbD for ; Tue, 9 Aug 2011 13:24:23 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7528C5E8019 for ; Tue, 9 Aug 2011 13:24:23 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 9 Aug 2011 13:24:53 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 9 Aug 2011 13:24:51 -0700 Thread-Topic: [domainrep] Proposed charter, revised after BoF Thread-Index: AcxW0Pn3Uv87ieBUQhq5jMxRCG7V7QAASQGQ Message-ID: References: <20110802225213.74818.qmail@joyce.lan> <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> In-Reply-To: <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:24:24 -0000 > -----Original Message----- > From: Nathaniel Borenstein [mailto:nsb@guppylake.com] > Sent: Tuesday, August 09, 2011 1:15 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Proposed charter, revised after BoF >=20 > Description of Working Group: >=20 > > reputation data providers make available to consumers data about >=20 > Consumers? Perhaps we mean users? I used "consumers" there in the producer/consumer vein, but I'm fine with "= users" too. I'm fine with the rest of your proposed tweaks and additions. > Goals and Milestones: > mmm yyyy: >=20 > I disagree, I think we can be done by nnn zzzz. Right, sorry. Typo. > Seriously, do we have any idea what dates to shoot for? I would think > the first document or two could be ready for the Paris IETF in March, > is that unrealistically ambitious? -- Nathaniel Yep, I suspect so, given the absence of major objections to the framework o= r reputon drafts so far. Most of the back-and-forth has been about protoco= l definition. -MSK From msk@cloudmark.com Tue Aug 9 13:31:05 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0166E5E8023 for ; Tue, 9 Aug 2011 13:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89d04rosaOul for ; Tue, 9 Aug 2011 13:31:02 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6A27A5E8021 for ; Tue, 9 Aug 2011 13:31:02 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 9 Aug 2011 13:31:31 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 9 Aug 2011 13:31:30 -0700 Thread-Topic: [domainrep] Reputation information data which flows from a reputation client to a reputation provider Thread-Index: AcxW0WBi4iQ7sXIJQyC3Pui/qfLQJAAASpgQ Message-ID: References: <4E4196AD.9060700@sonnection.nl> In-Reply-To: <4E4196AD.9060700@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF663EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [domainrep] Reputation information data which flows from a reputation client to a reputation provider X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:31:05 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF663EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, My intent there was to constrain the charter to talk about how a single end= -point reports reputation data back to a server that aggregates it, such as= an end user clicking a "report spam" button that provokes a message back t= o the reputation server. This is partly because it's obviously something n= eeded, and partly because the work is already half done for us in the form = of what Mimedefang uses (plus some undocumented commercial versions of the = same thing, so there exists a body of knowledge about it). My feeling is that it would be fairly ambitious to talk about how reputatio= n data providers exchange data amongst themselves in a first go. The work = in the charter now, which focuses only on producer-consumer protocols and f= ormats, and maybe how events are reported into a reputation system, is a bi= g enough slice even though we've constrained the initial output to focus on= email domain reputation. That said, this is prime material for a potential re-charter after the init= ial work is done, along with a possible second application like reputation = about reputation providers, or reputation about WHOIS registries. We can s= ee what the working group has momentum for when that day comes. As for your milestone tweak (i.e., change "sending data" to "sending feedba= ck data"), it looks fine to me. Thanks, -MSK From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Beh= alf Of Rolf E. Sonneveld Sent: Tuesday, August 09, 2011 1:21 PM To: domainrep@ietf.org Subject: [domainrep] Reputation information data which flows from a reputat= ion client to a reputation provider Hi, all, one of the milestones in the REPUTE charter is: mmm yyyy: Standards track document, defining mechanisms for sending data to reputation providers, to the IESG for publication. I suppose 'sending data to reputation providers' is the feedback mechanism = discussed previously on this list? If so, I'd like this to be explicitly me= ntioned as 'sending feedback data'. So let's make this: mmm yyyy: Standards track document, defining mechanisms for sending feedback data to reputation providers, to the IESG for publication. The reason for making this more explicit, is that there can be multiple typ= es of data that can/will be sent to reputation providers. The charter menti= ons query mechanisms for reputation clients to retrieve information from re= putation providers, but in my view we should not restrict the reputation in= formation flows to just 'queries' and 'feedback'. To give a few examples of other types of reputation information data flow: * at the end of the day there can and will be multiple reputation provid= ers, some of them may want to exchange/interchange/share (part of) their re= putation information with others * or it is possible a single provider of reputation has a mesh of reputa= tion servers, which communicate with each other using a reputation protocol= . This will not be restricted to one-way traffic, it will require a mechani= sm that supports reputation information flows in both directions. * another scenario can be, that reputation providers build reputations f= rom data/information that will be provided by thousands or millions of clie= nts, which need to be able to communicate a unit of reputation from client = to reputation provider * as far as I know there are providers of RBLs/DNSBLs data which pushes = complete DNS zones using zone transfers to customers. We will probably some= thing equivalent for REPUTE, but not restricted to simple DNS zone transfer= s Or is this meant with the charter section?: "The group will also produce specifications for providing source data into to a reputation service." I suggest we spend some (more) words on this type of data flow and add and = extra document on the milestone agenda: mmm yyyy: Standards track document, defining mechanisms for sending reputation data to reputation providers, to the IESG for publication. If there is consensus that such a document is in scope and that it should b= e part of the document output of this WG, I volunteer to work on this docum= ent. For the remainder of the charter: WFM. /rolf --_000_F5833273385BB34F99288B3648C4F06F13512DF663EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Rolf,

 = ;

My intent there was to constr= ain the charter to talk about how a single end-point reports reputation dat= a back to a server that aggregates it, such as an end user clicking a ̶= 0;report spam” button that provokes a message back to the reputation = server.  This is partly because it’s obviously something needed,= and partly because the work is already half done for us in the form of wha= t Mimedefang uses (plus some undocumented commercial versions of the same t= hing, so there exists a body of knowledge about it).

<= p class=3DMsoNormal> 

My feeling is that it would be fairly ambitious to talk about how r= eputation data providers exchange data amongst themselves in a first go.&nb= sp; The work in the charter now, which focuses only on producer-consumer pr= otocols and formats, and maybe how events are reported into a reputation sy= stem, is a big enough slice even though we’ve constrained the initial= output to focus on email domain reputation.


That said, this is prime material for a potential r= e-charter after the initial work is done, along with a possible second appl= ication like reputation about reputation providers, or reputation about WHO= IS registries.  We can see what the working group has momentum for whe= n that day comes.

&nb= sp;

As for your milestone tweak= (i.e., change “sending data” to “sending feedback data&#= 8221;), it looks fine to me.

 

Thanks,

-MSK

 

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind= owtext'>From: domainrep-bounces@ietf.org [mailto:domain= rep-bounces@ietf.org] On Behalf Of Rolf E. Sonneveld
Sent:= Tuesday, August 09, 2011 1:21 PM
To: domainrep@ietf.org
Su= bject: [domainrep] Reputation information data which flows from a reput= ation client to a reputation provider

 

Hi, all,

one of the milestones in the REPUTE charter = is:

    mmm yyyy:      Standards = track document, defining mechanisms
       = ;     for sending data to reputation providers, to the
&n= bsp;           IESG for publication= .

I suppose 'sending data to reputation providers' is the feedback m= echanism discussed previously on this list? If so, I'd like this to be expl= icitly mentioned as 'sending feedback data'. So let's make this:

&nb= sp;   mmm yyyy:      Standards track document= , defining mechanisms
          =   for sending feedback data to reputation providers, to the
 &= nbsp;          IESG for publication.
=
The reason for making this more explicit, is that there can be multiple= types of data that can/will be sent to reputation providers. The charter m= entions query mechanisms for reputation clients to retrieve information fro= m reputation providers, but in my view we should not restrict the reputatio= n information flows to just 'queries' and 'feedback'.

To give a few = examples of other types of reputation information data flow:

=
  • at the end of the day there= can and will be multiple reputation providers, some of them may want to ex= change/interchange/share (part of) their reputation information with others=
  • or it is possible a single = provider of reputation has a mesh of reputation servers, which communicate = with each other using a reputation protocol. This will not be restricted to= one-way traffic, it will require a mechanism that supports reputation info= rmation flows in both directions.
  • another scenario can be, that reputation providers build reputations = from data/information that will be provided by thousands or millions of cli= ents, which need to be able to communicate a unit of reputation from client= to reputation provider
  • as f= ar as I know there are providers of RBLs/DNSBLs data which pushes complete = DNS zones using zone transfers to customers. We will probably something equ= ivalent for REPUTE, but not restricted to simple DNS zone transfers


Or is this meant with the charter sec= tion?:

    "The group will also produce specific= ations for providing source data
    into to a reputation= service."
 
I suggest we spend some (more) words on this = type of data flow and add and extra document on the milestone agenda:
    mmm yyyy:      Standards track doc= ument, defining mechanisms
         &= nbsp;  for sending reputation data to reputation providers, to the
=             IESG for publicati= on.

If there is consensus that such a document is in scope and that = it should be part of the document output of this WG, I volunteer to work on= this document.

For the remainder of the charter: WFM.

/rolf<= o:p>

= --_000_F5833273385BB34F99288B3648C4F06F13512DF663EXCHC2corpclo_-- From peer2peer@gmail.com Tue Aug 9 14:40:49 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561B311E80AD for ; Tue, 9 Aug 2011 14:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JewE8rj0ArzW for ; Tue, 9 Aug 2011 14:40:48 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C61AA11E808E for ; Tue, 9 Aug 2011 14:40:48 -0700 (PDT) Received: by pzk33 with SMTP id 33so1195929pzk.18 for ; Tue, 09 Aug 2011 14:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=/tCuBiTF4EfWF05/k5uRN8UtLQC65mpiADxgH3N8/6I=; b=tJvntiHtjzkf/mBI/b/26LV0qwN2NlJQ7euWtp6xD4RcVKaGtxEEaVthil8+N+L410 alYzdvjj3NmElP0VtH+LHhliGV2FeNVKcywraaIB19ixB/uZogrdjuNEN/abx+g0sMsz WHVL+20jxQ+yE9p6+Kr2QCwhdcX4Q2NcWvQpU= MIME-Version: 1.0 Received: by 10.143.26.40 with SMTP id d40mr7118237wfj.199.1312926078326; Tue, 09 Aug 2011 14:41:18 -0700 (PDT) Received: by 10.142.210.11 with HTTP; Tue, 9 Aug 2011 14:41:18 -0700 (PDT) In-Reply-To: <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> References: <20110802225213.74818.qmail@joyce.lan> <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> Date: Tue, 9 Aug 2011 23:41:18 +0200 Message-ID: From: Johan Pouwelse To: "domainrep@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:40:49 -0000 On 9 August 2011 22:14, Nathaniel Borenstein wrote: > Proposed Addition: "However, the WG will attempt to define the syntax and= mechanisms in such a way that other applications and vocabularies can be d= eveloped without changes to the basic protocol." Good idea. Who can object to apple pie and re-usable technology.. -johan On 9 August 2011 22:14, Nathaniel Borenstein wrote: > I, too, am largely fine with the charter. =A0However, in the spirit of co= nstructive nitpicking: > > General comment: =A0I agree that we should be focused on the email domain= reputation use case, but I also agree with Johan that we shouldn't let thi= s focus make us miss the chance to do the general framework properly. =A0I = would like to see us declare any use-cases other than domain reputation to = be out of scope, but also explicitly declare as in-scope a secondary goal o= f structuring the protocol in such a way as to separate the basic mechanism= from the application/use-case/vocabulary. =A0(See "Proposed Addition" belo= w.) > > Description of Working Group: > >> =A0 =A0 =A0 reputation data providers make available to consumers data a= bout > > Consumers? =A0Perhaps we mean users? > > =A0 =A0 =A0 =A0illustrating the requirement and defining mechanisms to sa= tsify it. > > Typo: satisfy > > =A0 =A0 =A0 =A0The working group will focus for its initial charter only = on the > > s/only/primarily/ =A0(because of the generalized syntax question) > > =A0 =A0 =A0 =A0specific application of reputation about domain names foun= d in > =A0 =A0 =A0 =A0email messages, as it is believed there exists sufficient = experience > =A0 =A0 =A0 =A0and expertise in that area. > > Proposed Addition: "However, the WG will attempt to define the syntax and= mechanisms in such a way that other applications and vocabularies can be d= eveloped without changes to the basic protocol." > > Goals and Milestones: > =A0 =A0 =A0 =A0mmm yyyy: > > I disagree, I think we can be done by nnn zzzz. > > Seriously, do we have any idea what dates to shoot for? =A0I would think = the first document or two could be ready for the Paris IETF in March, is th= at unrealistically ambitious? =A0-- Nathaniel > > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > From dotis@mail-abuse.org Tue Aug 9 15:45:11 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39921F8C5A for ; Tue, 9 Aug 2011 15:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.224 X-Spam-Level: X-Spam-Status: No, score=-104.224 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VjqI2rffHvn for ; Tue, 9 Aug 2011 15:45:03 -0700 (PDT) Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0560D21F8C58 for ; Tue, 9 Aug 2011 15:45:03 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id 042506E0139 for ; Tue, 9 Aug 2011 22:45:31 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 78373A9443B for ; Tue, 9 Aug 2011 22:45:31 +0000 (UTC) Message-ID: <4E41B88B.9050500@mail-abuse.org> Date: Tue, 09 Aug 2011 15:45:31 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20110725144616.GA1579@shinkuro.com> <201108020928.30617.ietf-dkim@kitterman.com> <20110802141433.GP22542@shinkuro.com> <4E381266.7070303@dcrocker.net> <20110802173648.GV22542@shinkuro.com> <4E386099.8000804@dcrocker.net> <20110802210801.GL22542@shinkuro.com> In-Reply-To: <20110802210801.GL22542@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] More on TXT records X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 22:45:11 -0000 On 8/2/11 2:08 PM, Andrew Sullivan wrote: > On Tue, Aug 02, 2011 at 01:39:53PM -0700, Dave CROCKER wrote: > >> As for addressing the distinction you made, please forgive my having >> jumped into the middle of things. I thought that my text was >> rather straightforward at implying new RRs are not currently viable, >> or at least, not easily viable. That was meant to address the >> distinction quite fundamentally. > Nonsense. We had two problems in the DNS with new RRTYPEs. One was > that the intermediate software all puked. The other was that we have > support software that doesn't co-operate. I was arguing that the > intermediate software mostly didn't do that any more, and > acknowledging that there is a problem with other software. I was then > asking for help in identifying where those problems are. To stamp > your foot and say, "DNS weenies are saying this over and over again," > doesn't help. Why balk at defining plugins that support the typical provider's user consoles? >> I suspect you are aware that I've been pressing rather forcefully to >> get the DNSEXT wg to consider the revised registry specification > ITYM DNSOP. If it were DNSEXT, I'd be aware of it, and I'd tell you > you need to take it to DNSOP because there's no protocol change.\ Agreed. It is not accurate to describe the issue as representing a protocol limitation. >> This probably does not qualify as "can't even get people to agree" >> because that would imply conversation and there hasn't been any. > Well, there was some. For instance, you presented a previous draft at > a previous IETF meeting and did, ISTR, get some feedback from some guy > I used to know. But it's true it would be nice to get more traction. Far greater attention must be paid to network amplification from recipient UDP requests that are chained to obtain HTTP pages worth of information. At least HTTP runs over TCP. Is such a resulting DDoS of innocent bystanders a DNS protocol issue or would this be due to using the wrong protocol? > But the other point I was trying to make -- that putting this in a > registry still doesn't make this clean because it implies a > restriction inside a name space that, formally, we don't control -- is > still a problem. Well said. -Doug From R.E.Sonneveld@sonnection.nl Wed Aug 10 01:21:13 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9769A21F87C3 for ; Wed, 10 Aug 2011 01:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.072 X-Spam-Level: X-Spam-Status: No, score=-4.072 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvfCaUAXgV5E for ; Wed, 10 Aug 2011 01:21:08 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 3A38521F8784 for ; Wed, 10 Aug 2011 01:21:08 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LPP00G00DW0J100@helium.mailtransaction.com>; Wed, 10 Aug 2011 10:21:36 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LPP00M1SDVZSO00@helium.mailtransaction.com>; Wed, 10 Aug 2011 10:21:36 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_kDCHBDoxbqotp/voZigF2A)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LPP00K2PDVZI300@lion.sonnection.nl> for domainrep@ietf.org; Wed, 10 Aug 2011 10:21:35 +0200 (CEST) Message-id: <4E424064.3080505@sonnection.nl> Date: Wed, 10 Aug 2011 10:25:08 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 To: "Murray S. Kucherawy" References: <4E4196AD.9060700@sonnection.nl> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1312964496; bh=5hwm++rrdPqibLZr3cKYm+Xax8leBC3Jmm5X92X3hZc=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=BZwSxHjCgeSf9zPpz1LDoGcs08lNKKk9XI3u8tRZnlnkDIxkn1qMK2igqcfz2IihK bl8g16mQiOtVRbQseN47tzFMZkJj3b+kAM/1WDeuiVKyjkJPuOaL+zSrmXP4OBcGeV 5+SSR7APO9eJboD+G3tNbPlFe3b62LYhlvdxzYJU= X-DKIM: OpenDKIM Filter v2.1.3 helium.mailtransaction.com 0LPP00G00DW0J100 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Reputation information data which flows from a reputation client to a reputation provider X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 08:21:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_kDCHBDoxbqotp/voZigF2A) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi, Murray, On 8/9/11 10:31 PM, Murray S. Kucherawy wrote: > > My intent there was to constrain the charter to talk about how a > single end-point reports reputation data back to a server that > aggregates it, such as an end user clicking a "report spam" button > that provokes a message back to the reputation server. > OK. I suggest we'd add this text to that paragraph, in order to make it more clear, like: The group will also produce specifications on reporting reputation data from (a) single end-point(s) to a server, that aggregates it[, for example when an end user clicks on a 'report spam' button that provokes a message back to the reputation server]. The 'for example...' may not fit for a charter document, hence I put it in square brackets. > This is partly because it's obviously something needed, and partly > because the work is already half done for us in the form of what > Mimedefang uses (plus some undocumented commercial versions of the > same thing, so there exists a body of knowledge about it). > > My feeling is that it would be fairly ambitious to talk about how > reputation data providers exchange data amongst themselves in a first go. > The internal data exchange of reputation providers is not my primary concern, indeed. My primary concern was that we should not limit the reputation model to be a model where there's only one-way traffic from provider to consumer. > The work in the charter now, which focuses only on producer-consumer > protocols and formats, and maybe how events are reported into a > reputation system, is a big enough slice even though we've constrained > the initial output to focus on email domain reputation. > Given the 'nature' of reputation, it sure will prove to be a big enough slice ;-) > > That said, this is prime material for a potential re-charter after the > initial work is done, along with a possible second application like > reputation about reputation providers, or reputation about WHOIS > registries. We can see what the working group has momentum for when > that day comes. > Agreed. /rolf --Boundary_(ID_kDCHBDoxbqotp/voZigF2A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, Murray,

On 8/9/11 10:31 PM, Murray S. Kucherawy wrote:

My intent there was to constrain the charter to talk about how a single end-point reports reputation data back to a server that aggregates it, such as an end user clicking a “report spam” button that provokes a message back to the reputation server. 


OK. I suggest we'd add this text to that paragraph, in order to make it more clear, like:

The group will also produce specifications on reporting reputation data from (a) single end-point(s) to a server, that aggregates it[, for example when an end user clicks on a 'report spam' button that provokes a message back to the reputation server].

The 'for example...' may not fit for a charter document, hence I put it in square brackets.

This is partly because it’s obviously something needed, and partly because the work is already half done for us in the form of what Mimedefang uses (plus some undocumented commercial versions of the same thing, so there exists a body of knowledge about it).

 

My feeling is that it would be fairly ambitious to talk about how reputation data providers exchange data amongst themselves in a first go. 


The internal data exchange of reputation providers is not my primary concern, indeed. My primary concern was that we should not limit the reputation model to be a model where there's only one-way traffic from provider to consumer.

The work in the charter now, which focuses only on producer-consumer protocols and formats, and maybe how events are reported into a reputation system, is a big enough slice even though we’ve constrained the initial output to focus on email domain reputation.


Given the 'nature' of reputation, it sure will prove to be a big enough slice ;-)


That said, this is prime material for a potential re-charter after the initial work is done, along with a possible second application like reputation about reputation providers, or reputation about WHOIS registries.  We can see what the working group has momentum for when that day comes.


Agreed.

/rolf
--Boundary_(ID_kDCHBDoxbqotp/voZigF2A)-- From sm@resistor.net Wed Aug 10 21:57:40 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82AA21F877D for ; Wed, 10 Aug 2011 21:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbw-eoqayYVS for ; Wed, 10 Aug 2011 21:57:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E393B21F876F for ; Wed, 10 Aug 2011 21:57:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p7B4w6te000565 for ; Wed, 10 Aug 2011 21:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313038691; bh=AuY/W7WwlHAodlxjWYtbTsvbNPg/YUuBLL2vKMnas4c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=zlHoNB5zPKhpBtixKzr7Ql4Hu2w8iPA+X9dooYdM05woCy86D18OV9S3bYvfLCZ/1 LPsF8VKZE5/vPD3G87KUvpmLK4hoDi0vEwjnYPXObnSl58T5OhyXISgJdz1R6sHAYz xRi+8dy4hy55M5f6kxmA9x5t2oMsGFcRf3Jkwc10= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313038691; bh=AuY/W7WwlHAodlxjWYtbTsvbNPg/YUuBLL2vKMnas4c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=R6P+9Ox6V2U7NcIEsR9Hm6Z5Xo4ym32+kwqby3mnci6FY5kRh4Hv57cCXGpMZ82fN yz3MQ2tSUsJNymZI5PXqXBupV9MS0QQ1p/qknOwKBSpQDbbHDjZT1w68nEDzW8YLAW UHjsuFoQZKZP+K5oWmtJR4HXUMpVtlmm2co7jnv0= Message-Id: <6.2.5.6.2.20110810213613.0b685fc0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 10 Aug 2011 21:55:34 -0700 To: domainrep@ietf.org From: SM In-Reply-To: References: <20110802225213.74818.qmail@joyce.lan> <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 04:57:40 -0000 Hello, Nitting about the proposed charter: "However, anyone can create and attach such an identifier." I suggest "However, anyone can assign such an identifier." as there is no attachment for RFC4408. BTW, would the work also cover RFC 4406? Regards, -sm From msk@cloudmark.com Wed Aug 10 22:08:23 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBE221F888A for ; Wed, 10 Aug 2011 22:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N25rApS-k-88 for ; Wed, 10 Aug 2011 22:08:23 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9421F8880 for ; Wed, 10 Aug 2011 22:08:23 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 10 Aug 2011 22:08:55 -0700 From: "Murray S. Kucherawy" To: SM , "domainrep@ietf.org" Date: Wed, 10 Aug 2011 22:08:54 -0700 Thread-Topic: [domainrep] Proposed charter, revised after BoF Thread-Index: AcxX41K5l6CCvGZ4TQGsAj5NJEVW+AAASRFw Message-ID: References: <20110802225213.74818.qmail@joyce.lan> <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> <6.2.5.6.2.20110810213613.0b685fc0@resistor.net> In-Reply-To: <6.2.5.6.2.20110810213613.0b685fc0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 05:08:23 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of SM > Sent: Wednesday, August 10, 2011 9:56 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Proposed charter, revised after BoF >=20 > Hello, >=20 > Nitting about the proposed charter: >=20 > "However, anyone can create and attach such an identifier." >=20 > I suggest "However, anyone can assign such an identifier." as there > is no attachment for RFC4408. How about: Determining the trustworthiness of content on the Internet remains = a challenge, and this weakness is heavily exploited by bad actors. Various mechanisms have been developed for associating a verified identifier with email content, such as SPF (RFC4408) and DKIM (RFC4871). However, legitimate and illegitimate users alike can take advantage of these schemes. What is also required is a meaningful assessment of the trustworthiness of the identifier's owner. This in turn permits making a meaningful choice about what to do with the associated content. > BTW, would the work also cover RFC 4406? With this rewording, yes. It's only omitted because it's not in anywhere n= ear as widespread use as those two are, but RFC4406 certainly is included a= s a possible email authentication protocol. -MSK From msk@cloudmark.com Wed Aug 10 22:16:01 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9621F8A30 for ; Wed, 10 Aug 2011 22:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lEXX47W1Tux for ; Wed, 10 Aug 2011 22:16:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A0EB221F8A1A for ; Wed, 10 Aug 2011 22:15:54 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 10 Aug 2011 22:16:27 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 10 Aug 2011 22:16:26 -0700 Thread-Topic: [domainrep] Proposed charter, revised after BoF Thread-Index: AcxW0Pn3Uv87ieBUQhq5jMxRCG7V7QBFHQQw Message-ID: References: <20110802225213.74818.qmail@joyce.lan> <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> In-Reply-To: <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 05:16:01 -0000 > -----Original Message----- > From: Nathaniel Borenstein [mailto:nsb@guppylake.com] > Sent: Tuesday, August 09, 2011 1:15 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Proposed charter, revised after BoF >=20 > Proposed Addition: "However, the WG will attempt to define the syntax > and mechanisms in such a way that other applications and vocabularies > can be developed without changes to the basic protocol." How's this? The working group will focus for its initial charter on an extensible framework of syntax and mechanisms for reputation servic= es, and primarily on the specific application of reputation about domai= n names found in email messages, as it is believed there exists sufficient experience and expertise in that area. The framework wi= ll allow other applications and vocabularies to be developed without changes to the basic protocol. Then, if successful, the group can re-charter to cover other application spaces where it feels it can access sufficient expertise. > Seriously, do we have any idea what dates to shoot for? I would think > the first document or two could be ready for the Paris IETF in March, > is that unrealistically ambitious? -- Nathaniel I think so, yes. I'll post an updated charter with this week's feedback an= d some milestone guesstimates shortly. From msk@cloudmark.com Wed Aug 10 22:20:28 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0555621F8A64 for ; Wed, 10 Aug 2011 22:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.088 X-Spam-Level: X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-IJDpSafIuL for ; Wed, 10 Aug 2011 22:20:27 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 605C021F8A35 for ; Wed, 10 Aug 2011 22:20:27 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 10 Aug 2011 22:21:00 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 10 Aug 2011 22:20:59 -0700 Thread-Topic: Updated proposed charter Thread-Index: AcxX5nS9eVo5IJMVRmSthuyGhaPeMw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF6C3EXCHC2corpclo_" MIME-Version: 1.0 Subject: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 05:20:28 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF6C3EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've updated the proposed charter at http://www.blackops.org/~msk/domainrep= /repute-charter.txt to take into account this week's feedback, including so= me milestones that I think we could hit given the current interest. Please= review it and let me know if I've missed anything. -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF6C3EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve updat= ed the proposed charter at http://www.blackops.org/~msk/domainrep/repute-charter= .txt to take into account this week’s feedback, including some mi= lestones that I think we could hit given the current interest.  Please= review it and let me know if I’ve missed anything.

 

-MSK=

= --_000_F5833273385BB34F99288B3648C4F06F13512DF6C3EXCHC2corpclo_-- From R.E.Sonneveld@sonnection.nl Thu Aug 11 01:44:56 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1DC21F8AE6 for ; Thu, 11 Aug 2011 01:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTtfB3dz2oW2 for ; Thu, 11 Aug 2011 01:44:54 -0700 (PDT) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id AACC721F8B0D for ; Thu, 11 Aug 2011 01:44:49 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LPR009006FEHH00@hydrogen.mailtransaction.com>; Thu, 11 Aug 2011 10:45:22 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LPR00D0X9NLUR00@hydrogen.mailtransaction.com>; Thu, 11 Aug 2011 10:45:22 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6GZVSsq+2/Mbp/lrpJu6OA)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LPR0032T9NLGB00@lion.sonnection.nl> for domainrep@ietf.org; Thu, 11 Aug 2011 10:45:21 +0200 (CEST) Message-id: <4E439778.4060906@sonnection.nl> Date: Thu, 11 Aug 2011 10:48:56 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 To: "Murray S. Kucherawy" References: In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1313052322; bh=Wf0vc1SxMdC36uFanxygtqT+SYvuoxXNd1Jy21cGiZM=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=NZ1LeytbuYP9j8ca8e23qWE/K/nYM7fBCjJYxoWdEvYHVyeqoOPHw8R36wzrlyGGv HkX9xtBK2yQmwf8bF2E/rqik+W55K/k5rJJOoCI0enbEfP3dg98pu/hKhXeQE/bcoh gyvVpeeuwylx2hA0yTjJijolk7RtzhA/+bjOZAiM= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LPR009006FEHH00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 08:44:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6GZVSsq+2/Mbp/lrpJu6OA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi, On 8/11/11 7:20 AM, Murray S. Kucherawy wrote: > > I've updated the proposed charter at > http://www.blackops.org/~msk/domainrep/repute-charter.txt > to take > into account this week's feedback, including some milestones that I > think we could hit given the current interest. Please review it and > let me know if I've missed anything. > here's my review of the latest charter: [...] "reputation". A specific requirement is for a common mechanism to use in querying reputation-related databases. s/databases/repositories The word 'databases' associates (IMHO) too much with database technologies and products, which we want to stay away from. [...] The group will also produce specifications for reporting reputation data from end-points (usually end users, such as someone clicking a "report spam" button in response to unwanted email, or a "thumbs-up" button in an online rating system) to reputation data aggregators for use in computing updated reputations. Excellent rephrased! [...] reputation providers and reputation consumers. The issues of data transparency and redress will also need to be discussed. Add: privacy (i.e. "The issues of data transparancy, privacy and redress...". Apart from this, the charter looks fine to me. /rolf --Boundary_(ID_6GZVSsq+2/Mbp/lrpJu6OA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi,

On 8/11/11 7:20 AM, Murray S. Kucherawy wrote:

I’ve updated the proposed charter at http://www.blackops.org/~msk/domainrep/repute-charter.txt to take into account this week’s feedback, including some milestones that I think we could hit given the current interest.  Please review it and let me know if I’ve missed anything.


here's my review of the latest charter:

[...]	"reputation".  A specific requirement is for a common mechanism to
	use in querying reputation-related databases.

s/databases/repositories

The word 'databases' associates (IMHO) too much with database technologies and products, which we want to stay away from.

[...]

	The group will also produce specifications for reporting reputation
	data from end-points (usually end users, such as someone clicking
	a "report spam" button in response to unwanted email, or a
	"thumbs-up" button in an online rating system) to reputation
	data aggregators for use in computing updated reputations.

Excellent rephrased!

[...]

	reputation providers and reputation consumers.  The issues of
	data transparency and redress will also need to be discussed.

Add: privacy (i.e. "The issues of data transparancy, privacy and redress...".

Apart from this, the charter looks fine to me.

/rolf
--Boundary_(ID_6GZVSsq+2/Mbp/lrpJu6OA)-- From sm@resistor.net Thu Aug 11 03:20:05 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205BD21F8AFE for ; Thu, 11 Aug 2011 03:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5AB1dyp81Gw for ; Thu, 11 Aug 2011 03:20:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FE221F8AF4 for ; Thu, 11 Aug 2011 03:20:00 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p7BAKQTx028787; Thu, 11 Aug 2011 03:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313058032; bh=7KUKI3BVgjhCwjnqDNGVQdjKzKs6ff/M1AJV9id6/zg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=S1Fx/zwmRRQqYFTSNjTBepkpPsXPJPOLy3J5OjFGAEf30YmVd7vB2gltrFHfGIsec n5vkwFlSe537KOqCn9nlAWPLk1/IfAyV+Z/AaEk7OKwCCuovRgdFwFFLehkrufHb1r CtoV3x3U4g53DLKbFJpNqomIXeXySaIZZFMRym1U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313058032; bh=7KUKI3BVgjhCwjnqDNGVQdjKzKs6ff/M1AJV9id6/zg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GmrkevqB8E0EazrjSoiENda6JEULU0uBbUX/cqRMSL0IobDCs9jiplRCjFIdkexXy C2AFlzVPZnZcbQ2tcw6qmArAaNZ2Py/ebTmfC+zKTYEy9a+6QyExx5RLIUA8KV/sB5 m/YDJzvl1rkO6SzpBMazUSBtwe7sHgPfZbAZBCmg= Message-Id: <6.2.5.6.2.20110811031841.090ca468@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Aug 2011 03:19:25 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <20110802225213.74818.qmail@joyce.lan> <7E359B03-F740-4E98-B0BD-DD8A659C610F@guppylake.com> <6.2.5.6.2.20110810213613.0b685fc0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] Proposed charter, revised after BoF X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 10:20:05 -0000 Hi Murray, At 22:08 10-08-2011, Murray S. Kucherawy wrote: >How about: > > Determining the trustworthiness of content on the Internet remains a > challenge, and this weakness is heavily exploited by bad actors. > Various mechanisms have been developed for associating a verified > identifier with email content, such as SPF (RFC4408) and DKIM > (RFC4871). However, legitimate and illegitimate users alike can > take advantage of these schemes. What is also required is a > meaningful assessment of the trustworthiness of the identifier's > owner. This in turn permits making a meaningful choice about what > to do with the associated content. That looks fine. >With this rewording, yes. It's only omitted because it's not in >anywhere near as widespread use as those two are, but RFC4406 >certainly is included as a possible email authentication protocol. Ok. Regards, -sm From ajs@anvilwalrusden.com Thu Aug 11 05:53:08 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AB621F85AE for ; Thu, 11 Aug 2011 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-EPqitKmbJG for ; Thu, 11 Aug 2011 05:53:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AA50C21F85AA for ; Thu, 11 Aug 2011 05:53:07 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4881A1ECB41D for ; Thu, 11 Aug 2011 12:53:42 +0000 (UTC) Date: Thu, 11 Aug 2011 08:53:39 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110811125339.GB95640@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:53:08 -0000 I read this version of the charter, and I think it is a good basis for work. I confess I find the milestones a little optimistic given my observations of how long things actually take in the IETF, but since every charter seems to display that effect (and since I have no better suggestions), I don't object. A On Wed, Aug 10, 2011 at 10:20:59PM -0700, Murray S. Kucherawy wrote: > I've updated the proposed charter at http://www.blackops.org/~msk/domainrep/repute-charter.txt to take into account this week's feedback, including some milestones that I think we could hit given the current interest. Please review it and let me know if I've missed anything. > > -MSK > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep -- Andrew Sullivan ajs@crankycanuck.ca From johnl@iecc.com Thu Aug 11 09:12:48 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8B621F8C11 for ; Thu, 11 Aug 2011 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbefjIe8zeUq for ; Thu, 11 Aug 2011 09:12:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 661BD21F8C0C for ; Thu, 11 Aug 2011 09:12:47 -0700 (PDT) Received: (qmail 67312 invoked from network); 11 Aug 2011 16:13:21 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 11 Aug 2011 16:13:21 -0000 Received: (qmail 3540 invoked from network); 11 Aug 2011 16:13:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Aug 2011 16:13:20 -0000 Date: 11 Aug 2011 16:12:58 -0000 Message-ID: <20110811161258.93829.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:12:48 -0000 >I've updated the proposed charter at >http://www.blackops.org/~msk/domainrep/repute-charter.txt to take into Seems basically fine. Please change Reputation systems such as Realtime Block Lists (RBLs, RFC5782) to Reputation systems such as DNS Blacklists and Whitelists (DNSBLs and DNSWLs, RFC5782) DNSBL is the standard term now, RBL is Trend's trademark, and doesn't describe what they are, anyway. Many of them make no attempt to be realtime, e.g., the Spamahaus PBL which lists IP ranges whose owners have a policy of no direct outgoing mail. R's, John From msk@cloudmark.com Thu Aug 11 10:47:09 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B079F21F8AA8 for ; Thu, 11 Aug 2011 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Pig7axva9lj for ; Thu, 11 Aug 2011 10:47:09 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 972BE21F8A4B for ; Thu, 11 Aug 2011 10:47:08 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 11 Aug 2011 10:47:43 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 11 Aug 2011 10:47:42 -0700 Thread-Topic: [domainrep] Updated proposed charter Thread-Index: AcxYQZtKp8fwiQx9Sse0/t3kMLt0FAADSBCg Message-ID: References: <20110811161258.93829.qmail@joyce.lan> In-Reply-To: <20110811161258.93829.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:47:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQGllY2MuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDk6MTMg QU0NCj4gVG86IGRvbWFpbnJlcEBpZXRmLm9yZw0KPiBDYzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0K PiBTdWJqZWN0OiBSZTogW2RvbWFpbnJlcF0gVXBkYXRlZCBwcm9wb3NlZCBjaGFydGVyDQo+IA0K PiA+SSd2ZSB1cGRhdGVkIHRoZSBwcm9wb3NlZCBjaGFydGVyIGF0DQo+ID5odHRwOi8vd3d3LmJs YWNrb3BzLm9yZy9+bXNrL2RvbWFpbnJlcC9yZXB1dGUtY2hhcnRlci50eHQgdG8gdGFrZSBpbnRv DQo+IA0KPiBTZWVtcyBiYXNpY2FsbHkgZmluZS4gIFBsZWFzZSBjaGFuZ2UNCj4gDQo+IAlSZXB1 dGF0aW9uIHN5c3RlbXMgc3VjaCBhcyBSZWFsdGltZSBCbG9jayBMaXN0cyAoUkJMcywgUkZDNTc4 MikNCj4gDQo+IHRvDQo+IA0KPiAJUmVwdXRhdGlvbiBzeXN0ZW1zIHN1Y2ggYXMgRE5TIEJsYWNr bGlzdHMgYW5kIFdoaXRlbGlzdHMNCj4gCShETlNCTHMgYW5kIEROU1dMcywgUkZDNTc4MikNCj4g DQo+IEROU0JMIGlzIHRoZSBzdGFuZGFyZCB0ZXJtIG5vdywgUkJMIGlzIFRyZW5kJ3MgdHJhZGVt YXJrLCBhbmQgZG9lc24ndA0KPiBkZXNjcmliZSB3aGF0IHRoZXkgYXJlLCBhbnl3YXkuICBNYW55 IG9mIHRoZW0gbWFrZSBubyBhdHRlbXB0IHRvIGJlDQo+IHJlYWx0aW1lLCBlLmcuLCB0aGUgU3Bh bWFoYXVzIFBCTCB3aGljaCBsaXN0cyBJUCByYW5nZXMgd2hvc2Ugb3duZXJzDQo+IGhhdmUgYSBw b2xpY3kgb2Ygbm8gZGlyZWN0IG91dGdvaW5nIG1haWwuDQoNCkRvbmUsIGFuZCBhbHNvIGZvbGRl ZCBpbiBSb2xmJ3MgZmVlZGJhY2suDQoNCi1NU0sNCg== From jdfalk-lists@cybernothing.org Thu Aug 11 13:14:48 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2769421F8658 for ; Thu, 11 Aug 2011 13:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c7-ct0ni+8j for ; Thu, 11 Aug 2011 13:14:47 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 570F321F85B8 for ; Thu, 11 Aug 2011 13:14:47 -0700 (PDT) Received: from [10.9.8.135] ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7BKFJCc008037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Aug 2011 13:15:21 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p7BKFJCc008037 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1313093721; bh=5CiUT0B4rtIwIyVGtw+UKFfpWIc3n4dPTup1HtoBk pE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Y55hMqkkekh5 TwLAN7Dp66oFROAnovrZK6bZstiSCYcFNVTg4d6zu3RqUabTZgYa3ZqRCV9QgZKWhqc vpS433gosy1pH+8Sbd/WLivCEikkmzWlqzlWUcuoC4/OJI+s37FKxdzq/cjdCCzkICm XDaMRF2jNCbPcdcduUH2XSV9Q= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110811125339.GB95640@shinkuro.com> Date: Thu, 11 Aug 2011 13:15:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110811125339.GB95640@shinkuro.com> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:14:48 -0000 On Aug 11, 2011, at 5:53 AM, Andrew Sullivan wrote: > I read this version of the charter, and I think it is a good basis for > work. I confess I find the milestones a little optimistic given my > observations of how long things actually take in the IETF, but since > every charter seems to display that effect (and since I have no better > suggestions), I don't object. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From dhc@dcrocker.net Fri Aug 12 11:26:17 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3211E8088 for ; Fri, 12 Aug 2011 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pMZ3XyKqU36 for ; Fri, 12 Aug 2011 11:26:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DC40411E8087 for ; Fri, 12 Aug 2011 11:26:16 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CIQn8B023744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 11:26:54 -0700 Message-ID: <4E457068.7060209@dcrocker.net> Date: Fri, 12 Aug 2011 11:26:48 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20110811125339.GB95640@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Aug 2011 11:26:54 -0700 (PDT) Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:26:17 -0000 ( With some hope of posting this to the correct list this time... ) Based on: I have some questions about the current draft of the charter. For the moment, I'm merely trying to get a better understanding of what is intended: > Determining the trustworthiness of content on the Internet remains a What is meant by "trustworthiness of content"? Two examples are that it might mean that it really was created by the purported author. Or it might mean that its contents are "valid" (which might invite some discussion about "validity", of course.) There are other possibilities. > (RFC4871). However, legitimate and illegitimate users alike can What is an "illegitimate user"? > take advantage of these schemes. What is also required is a > meaningful assessment of the trustworthiness of the identifier's > owner. This in turn permits making a meaningful choice about what > to do with the associated content. Is the work of the group intended to cover "what to do with the associated content"? > The advent of the requirement described above creates a need to have > reputation data providers make available to consumers data about Does "consumers" mean end-users, operators of receiving services, or some other group? If it means end-users, how are they expected to employ this information within the current context of the tools end-users have? > An existing, standardized reputation query mechanism is > Vouch-by-Reference (RFC5518), which provides a simple Boolean > response concerning the acceptability of different types of mail. > Other application spaces -- such as Web interactions -- could > benefit from common reputation query mechanisms, especially those > for which replies need to be more elaborate. Given the existence of VBR, why is an additional reputation query mechanism needed? What will be different in the the mechanism and why is the difference important? Perhaps the new mechanism will be identical to VBR, but merely will have the meaning of the response be more general than just email? > This working group will produce a set of documents defining and > illustrating the requirement and defining mechanisms to satisfy it. > Two mechanisms are proposed: > > * simple -- a reputation is expressed in a simple manner such as > an integer > > * extended -- a response can contain more complex information > useful to an assessor Who is going to use each of these mechanisms and why? Are they participating in the discussions so far? Have they expressed interest in implementing the output of the working group? > > The mechanisms will be designed to be application-independent, and > portable between reputation providers. For this topic, what does 'application-independent' mean? What does portable between providers mean? > The group will also produce specifications for reporting reputation > data from end-points (usually end users, such as someone clicking > a "report spam" button in response to unwanted email, or a > "thumbs-up" button in an online rating system) to reputation > data aggregators for use in computing updated reputations. Reporting to whom? What will be the basis for choosing among the different possible and existing models for reporting spam? The language appears to equate reporting by end-users with some other forms of reporting. Is there really a basis for conflating these? > Reputation systems such as Realtime Block Lists (RBLs, RFC5782) > can be problematic when not operated properly. For example, an > RBL that lists a specific source without justification can do harm By 'source' I assume the meaning is of an listed problem domain, rather than the source of the report that the domain is a problem? > to a legitimate business, provoking damages and possible litigation. > This important topic will need to be discussed in the informational > portions of the work produced here, in terms of advice both to What is meant by "informational portions of the work"? What output does that refer to? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Fri Aug 12 11:45:03 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5CB21F8548 for ; Fri, 12 Aug 2011 11:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YHCsVc5g7gL for ; Fri, 12 Aug 2011 11:45:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A556221F8561 for ; Fri, 12 Aug 2011 11:44:51 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 12 Aug 2011 11:45:29 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 12 Aug 2011 11:45:28 -0700 Thread-Topic: [domainrep] Updated proposed charter Thread-Index: AcxZHW74Q4pzoLR8RNCfpjefPkcuSwAAGPxA Message-ID: References: <20110811125339.GB95640@shinkuro.com> <4E457068.7060209@dcrocker.net> In-Reply-To: <4E457068.7060209@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:45:03 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Dave CROCKER > Sent: Friday, August 12, 2011 11:27 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Updated proposed charter >=20 > > Determining the trustworthiness of content on the Internet remai= ns a >=20 > What is meant by "trustworthiness of content"? >=20 > Two examples are that it might mean that it really was created by the pur= ported > author. Or it might mean that its contents are "valid" (which might invi= te some > discussion about "validity", of course.) There are other possibilities. That first sentence makes a very general problem statement. It could inclu= de either or both of those things. > > (RFC4871). However, legitimate and illegitimate users alike can >=20 > What is an "illegitimate user"? Changed to "good and bad actors alike". > > take advantage of these schemes. What is also required is a > > meaningful assessment of the trustworthiness of the identifier's > > owner. This in turn permits making a meaningful choice about what > > to do with the associated content. >=20 > Is the work of the group intended to cover "what to do with the > associated content"? Specifically, no (that is, I don't believe we should say reputation result = X means spam folder, reputation result Y means bounce, reputation result Z = means deliver). The point is to make that information available to someone= that wants it in some standardized way. > > The advent of the requirement described above creates a need to have > > reputation data providers make available to consumers data about >=20 > Does "consumers" mean end-users, operators of receiving services, or > some other group? Either of those. Any client that wishes to acquire and make use of that in= formation. > If it means end-users, how are they expected to employ this information > within the current context of the tools end-users have? An MUA could conceivably make reputation queries just like an MTA or MDA co= uld. > > An existing, standardized reputation query mechanism is > > Vouch-by-Reference (RFC5518), which provides a simple Boolean > > response concerning the acceptability of different types of mail. > > Other application spaces -- such as Web interactions -- could > > benefit from common reputation query mechanisms, especially those > > for which replies need to be more elaborate. >=20 > Given the existence of VBR, why is an additional reputation query mechani= sm > needed? What will be different in the the mechanism and why is the > difference important? Specifically, the proposed system is not Boolean in nature. In the propose= d framework, it is possible to make an expression of scale in terms of an a= ssertion, and confidence in that assertion. > Perhaps the new mechanism will be identical to VBR, but merely will have = the > meaning of the response be more general than just email? It's more flexible than VBR in the sense that it can be applied to more tha= n just that one application, and also in that assertions are scalar. > > This working group will produce a set of documents defining and > > illustrating the requirement and defining mechanisms to satisfy it. > > Two mechanisms are proposed: > > > > * simple -- a reputation is expressed in a simple manner such as > > an integer > > > > * extended -- a response can contain more complex information > > useful to an assessor >=20 > Who is going to use each of these mechanisms and why? Are they participa= ting in > the discussions so far? Have they expressed interest in implementing the= output > of the working group? People tracking the list should feel free to answer on their own behalves. = I know about two implementations of servers, one will use the "simple" met= hod and one will use "extended", and of two client implementations, one of = which will implement "simple" and one of which will implement both. > > The mechanisms will be designed to be application-independent, and > > portable between reputation providers. >=20 > For this topic, what does 'application-independent' mean? The framework for doing reputation work in general will work the same way f= or different applications (email identity reputation, web identity reputati= on, reputation about reputation servers, reputation about domain registrars= , etc.). > What does portable between providers mean? This was discussed in the BoF. If you're using a reputation service provid= er for evaluating domain names in an email message, you should ideally be a= ble to switch to a different service provider without changing the interpre= tation of the answers on your side. > > The group will also produce specifications for reporting reputation > > data from end-points (usually end users, such as someone clicking > > a "report spam" button in response to unwanted email, or a > > "thumbs-up" button in an online rating system) to reputation > > data aggregators for use in computing updated reputations. >=20 > Reporting to whom? As it says, "to reputation data aggregators". > What will be the basis for choosing among the different possible and exis= ting > models for reporting spam? >=20 > The language appears to equate reporting by end-users with some other for= ms of > reporting. Is there really a basis for conflating these? The idea is to specify the protocol that is invoked when one clicks a "Repo= rt Spam" button, or equivalent, to report that user action back to a reputa= tion service provider to enrich its data set about the sender of that messa= ge. > > Reputation systems such as Realtime Block Lists (RBLs, RFC5782) > > can be problematic when not operated properly. For example, an > > RBL that lists a specific source without justification can do harm >=20 > By 'source' I assume the meaning is of an listed problem domain, rather t= han the > source of the report that the domain is a problem? In the case of RBLs, the source is an IP address. In the case of a reputat= ion service that refers to domain names in email, the "source" would be the= domain name, determined in some defined way (e.g. DKIM signing domain). > > to a legitimate business, provoking damages and possible litigation. > > This important topic will need to be discussed in the informational > > portions of the work produced here, in terms of advice both to >=20 > What is meant by "informational portions of the work"? What output does = that > refer to? Non-normative portions of the base specifications, and/or an informational = document that talks about BCP of either being a producer or consumer of rep= utation information. -MSK From nsb@guppylake.com Fri Aug 12 12:25:32 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF785E8008 for ; Fri, 12 Aug 2011 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSmkBHA7wwCM for ; Fri, 12 Aug 2011 12:25:31 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id CA68D5E8007 for ; Fri, 12 Aug 2011 12:25:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=oSz9++Zad6+YZAZ8zGmXUbCqVQqowHtf5gxOUJ7shVCfl1GVotA7DJUqpJmDywrlBMlPgM1fUFS02d6yoBDnf5Lo3k/VC6qe77K1Mz9/QwA/o9eezvHkZHjEdA2FWMQg; Received: from [108.98.177.27] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrxMu-00031J-2n for domainrep@ietf.org; Fri, 12 Aug 2011 15:26:09 -0400 From: Nathaniel Borenstein Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-98--137485917 Date: Fri, 12 Aug 2011 15:26:03 -0400 In-Reply-To: <20110811125339.GB95640@shinkuro.com> To: domainrep@ietf.org References: <20110811125339.GB95640@shinkuro.com> Message-Id: <68A3FAF5-D67C-4291-AEEE-4B60D015A71C@guppylake.com> X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:25:32 -0000 --Apple-Mail-98--137485917 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 11, 2011, at 8:53 AM, Andrew Sullivan wrote: > I confess I find the milestones a little optimistic given my > observations of how long things actually take in the IETF, but since > every charter seems to display that effect (and since I have no better > suggestions), I don't object. I fear the target dates almost have to be unrealistic to motivate people = to actually work. Also, a nit: I wonder if "feedback" is the right term in the 6th = deliverable. Is an unsolicited opinion feedback? If not, and if we = want the possibility of sending unsolicited opinions, perhaps = "evaluation" is a better choice? But this is way down in the nits. I'm very happy with the charter as it = stands. -- Nathaniel= --Apple-Mail-98--137485917 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
 I = confess I find the milestones a little optimistic given = my
observations of how long things actually take in the IETF, but = since
every charter seems to display that effect (and since I have no = better
suggestions), I don't = object.

But this is way down in the nits. =  I'm very happy with the charter as it stands.  -- = Nathaniel
= --Apple-Mail-98--137485917-- From sm@resistor.net Fri Aug 12 12:37:14 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13321F8853 for ; Fri, 12 Aug 2011 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0hJEu9INHvN for ; Fri, 12 Aug 2011 12:37:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F2D21F8834 for ; Fri, 12 Aug 2011 12:37:11 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7CJbAI6000145; Fri, 12 Aug 2011 12:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313177859; bh=VYtrSKHuCYBA6KOddv6MJB4S/vGOV5ZPv1iTO+elcOE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=FTdICDGBjRTpjyQjLBDHk16xRi4rwzzBT0Eb4HxMY7gEdcLwnr0ZhCMMIwjATR7gc cAesinO04uSBG0LwV65s0AQZAcrLTSaPfBGcUFS1VhYR00Q5uE2D8tTksl30wfDpbZ 6JKRwKupDpo8pWIrmduG4lFOsCbaXmuZs6uTbZbw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313177859; bh=VYtrSKHuCYBA6KOddv6MJB4S/vGOV5ZPv1iTO+elcOE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=jVPFXcf0VMvTBE8YXJ2bYb96CTNcDQrSjddCnkMvR9nWsV4mkUIZIU2sgywctew+D yA0SmlZlog2QYEVeanCkxb4oXdqQRa1Fjx3rg0qvt4p7XWKsQPPuBWZB/CZuFdtZZ5 0gXJWoOhSPTGpJNcl/gYCN3HD5QpqgCnpR5QWn4M= Message-Id: <6.2.5.6.2.20110812114006.0b0cc218@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Aug 2011 12:29:09 -0700 To: dcrocker@bbiw.net From: SM In-Reply-To: <4E457068.7060209@dcrocker.net> References: <20110811125339.GB95640@shinkuro.com> <4E457068.7060209@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:37:14 -0000 Hi Dave, At 11:26 12-08-2011, Dave CROCKER wrote: >Based on: > > > > >I have some questions about the current draft of the charter. For >the moment, I'm merely trying to get a better understanding of what >is intended: > > > > Determining the trustworthiness of content on the Internet remains a > >What is meant by "trustworthiness of content"? >Two examples are that it might mean that it really was created by >the purported author. Or it might mean that its contents are >"valid" (which might invite some discussion about "validity", of >course.) There are other possibilities. What is being done is assessing information (the proposed charter uses the word "content"). Reputation, for lack of a better metric, is used to assign a trust value. I avoided "validity" for the reason you mentioned above. For what it is worth, you can determine the authenticity of the identifiers attached to this message, i.e. are they valid. That information isn't useful unless you can trust it. You might use a reputation value to determine the trust value. Regards, -sm From dhc@dcrocker.net Fri Aug 12 12:38:42 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39CD5E800A for ; Fri, 12 Aug 2011 12:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2ZLs+GU7FKw for ; Fri, 12 Aug 2011 12:38:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 13A215E8006 for ; Fri, 12 Aug 2011 12:38:42 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CJdE0H025119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 12:39:19 -0700 Message-ID: <4E458161.40505@dcrocker.net> Date: Fri, 12 Aug 2011 12:39:13 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20110811125339.GB95640@shinkuro.com> <68A3FAF5-D67C-4291-AEEE-4B60D015A71C@guppylake.com> In-Reply-To: <68A3FAF5-D67C-4291-AEEE-4B60D015A71C@guppylake.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Aug 2011 12:39:20 -0700 (PDT) Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:38:42 -0000 On 8/12/2011 12:26 PM, Nathaniel Borenstein wrote: > On Aug 11, 2011, at 8:53 AM, Andrew Sullivan wrote: > >> I confess I find the milestones a little optimistic given my >> observations of how long things actually take in the IETF, but since >> every charter seems to display that effect (and since I have no better >> suggestions), I don't object. > > I fear the target dates almost have to be unrealistic to motivate people to > actually work. Since there is no history of short wg charter milestones having that effect and no history of much enforcement of milestones, the actual effect of overly aggressive milestones is to establish unrealistic expectations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jdfalk-lists@cybernothing.org Fri Aug 12 13:56:51 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8600111E80A7 for ; Fri, 12 Aug 2011 13:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbm7AG--vV2B for ; Fri, 12 Aug 2011 13:56:50 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 26A0511E80A6 for ; Fri, 12 Aug 2011 13:56:43 -0700 (PDT) Received: from [192.168.11.39] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7CKvHld027593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 12 Aug 2011 13:57:19 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p7CKvHld027593 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1313182640; bh=KQfgAbvDVTLjg2GpToL2y8MkEKdLHDwl6CN/bEm5/ vQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=fE3Gm/CnIiEo xebL3kJ7oQ+ue3KKKDZZEPmZJVdeMRYUNEhQFWsr1C3lmmviONv8pFnOzfmNI5zDdbn Rlq67ehh1+aEcbg7AXHjOq/hbwX7ZF3wrQMqFfIiiryV+Q6hGhr5vPSFDGVIspALilm ZedHm4uw12KBuFhujqpwpB8Mg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Fri, 12 Aug 2011 13:57:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110811125339.GB95640@shinkuro.com> <4E457068.7060209@dcrocker.net> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 20:56:51 -0000 On Aug 12, 2011, at 11:45 AM, Murray S. Kucherawy wrote: >>> take advantage of these schemes. What is also required is a >>> meaningful assessment of the trustworthiness of the identifier's >>> owner. This in turn permits making a meaningful choice about = what >>> to do with the associated content. >>=20 >> Is the work of the group intended to cover "what to do with the >> associated content"? >=20 > Specifically, no (that is, I don't believe we should say reputation = result X means spam folder, reputation result Y means bounce, reputation = result Z means deliver). The point is to make that information = available to someone that wants it in some standardized way. Thinking ahead...a Reputation Provider MAY make recommendations = regarding the eventual disposition of an item, but such recommendations = are outside of the scope of this work. I'm not sure if that needs to be = in the charter. >>> The advent of the requirement described above creates a need to = have >>> reputation data providers make available to consumers data about >>=20 >> Does "consumers" mean end-users, operators of receiving services, or >> some other group? >=20 > Either of those. Any client that wishes to acquire and make use of = that information. I doubt end users will make use of REPUTE directly, but their software = agents could. Should we define "consumers" broadly as "software agents = capable of receiving and processing REPUTE messages"? >>> Reputation systems such as Realtime Block Lists (RBLs, RFC5782) >>> can be problematic when not operated properly. For example, an >>> RBL that lists a specific source without justification can do = harm >>=20 >> By 'source' I assume the meaning is of an listed problem domain, = rather than the >> source of the report that the domain is a problem? >=20 > In the case of RBLs, the source is an IP address. In the case of a = reputation service that refers to domain names in email, the "source" = would be the domain name, determined in some defined way (e.g. DKIM = signing domain). Perhaps "identifier" or "source identifier" instead? -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From nsb@guppylake.com Sat Aug 13 07:54:17 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABACA21F86F6 for ; Sat, 13 Aug 2011 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EItJ8vCP3wRB for ; Sat, 13 Aug 2011 07:54:16 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7695E21F86F4 for ; Sat, 13 Aug 2011 07:54:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=EOiggehKz7ttr2mUXrcGgfCqbSc2PRMu6VkH6Ki7qcMCK5hCbbkgzVEX03lOoKKW9tA/hmNJnLfN5/ypXGBxNUvpzK6iS7C6RqcmhyHFGsXyhnzeqeOlsGL151Xtbaac; Received: from [108.99.249.185] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QsFbx-0006iI-2M; Sat, 13 Aug 2011 10:54:53 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-119--67358877 From: Nathaniel Borenstein In-Reply-To: <4E458161.40505@dcrocker.net> Date: Sat, 13 Aug 2011 10:54:50 -0400 Message-Id: <72384228-7219-4EE0-A867-BBF426B00BDD@guppylake.com> References: <20110811125339.GB95640@shinkuro.com> <68A3FAF5-D67C-4291-AEEE-4B60D015A71C@guppylake.com> <4E458161.40505@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: domainrep@ietf.org Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 14:54:17 -0000 --Apple-Mail-119--67358877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 12, 2011, at 3:39 PM, Dave CROCKER wrote: >> I fear the target dates almost have to be unrealistic to motivate = people to >> actually work. >=20 > Since there is no history of short wg charter milestones having that = effect and no history of much enforcement of milestones, the actual = effect of overly aggressive milestones is to establish unrealistic = expectations. As one whose expectations for timing are nearly always unrealistic, I'll = defer to anyone who believes they know how to make them realistic. I'm = just observing the way people tend to put things off until a deadline is = approaching.= --Apple-Mail-119--67358877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I fear the target dates almost have to = be unrealistic to motivate people to
actually work.

Since there is no = history of short wg charter milestones having that effect and no history = of much enforcement of milestones, the actual effect of overly = aggressive milestones is to establish unrealistic = expectations.

As one whose = expectations for timing are nearly always unrealistic, I'll defer to = anyone who believes they know how to make them realistic.  I'm just = observing the way people tend to put things off until a deadline is = approaching.
= --Apple-Mail-119--67358877-- From paul.hoffman@vpnc.org Fri Aug 12 08:09:31 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7DE21F8A4D for ; Fri, 12 Aug 2011 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTzjRa2VUq8U for ; Fri, 12 Aug 2011 08:09:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B18E221F8A35 for ; Fri, 12 Aug 2011 08:09:27 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7CF9fks067498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Aug 2011 08:09:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Aug 2011 08:10:04 -0700 Message-Id: <1013AA4B-AAD0-428F-8ED1-496F08475321@vpnc.org> To: domainrep@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Mailman-Approved-At: Sun, 14 Aug 2011 08:32:24 -0700 Subject: [domainrep] Support latest proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:09:31 -0000 I have read the charter proposed on 2011-08-10 and think it would be a = useful WG in the IETF. --Paul Hoffman From vesely@tana.it Mon Aug 15 01:34:03 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6421F89B8 for ; Mon, 15 Aug 2011 01:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw24O69iYn89 for ; Mon, 15 Aug 2011 01:34:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D447221F8AEA for ; Mon, 15 Aug 2011 01:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1313397284; bh=SdyHNoieCwPIUOsc1stWZY8NxXz9RvZKWpwCQpWiFlU=; l=3059; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jaYG759IS+viqt0M4OPpBkcBvLrSymy4qiK2gAPCkHDjwqkiZdQdX1VuPyXQHbv7Q P17b9xCeXMV5bIK0Wqd/2r52/549XvuFmERqH6EKOqd06wKwjHz/a5MumVYBC7joGt DKgZMgcNpnJUSu5twes+XB4X7QX/yBMlrLT61Mn8= Received: from [109.115.141.115] ([109.115.141.115]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 15 Aug 2011 10:34:43 +0200 id 00000000005DC042.000000004E48DA23.00006A29 Message-ID: <4E48DA14.5090901@tana.it> Date: Mon, 15 Aug 2011 10:34:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: domainrep@ietf.org References: <20110811125339.GB95640@shinkuro.com> <4E457068.7060209@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 08:34:04 -0000 On 12.08.2011 20:45, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Dave CROCKER >> Given the existence of VBR, why is an additional reputation query >> mechanism needed? What will be different in the the mechanism and why >> is the difference important? > > Specifically, the proposed system is not Boolean in nature. In the > proposed framework, it is possible to make an expression of scale in terms > of an assertion, and confidence in that assertion. This difference doesn't seem to be advantageous to consumers. In fact, I never saw lists of messages sorted by spam-score. Consumers would probably prefer a few discrete values (obtainable using thresholds.) It must be a matter of necessity to do continuous values. >> > The group will also produce specifications for reporting reputation >> > data from end-points (usually end users, such as someone clicking >> > a "report spam" button in response to unwanted email, or a >> > "thumbs-up" button in an online rating system) to reputation >> > data aggregators for use in computing updated reputations. >> >> Reporting to whom? > > As it says, "to reputation data aggregators". Yes, the last bullet of out-of-scope items explains that aggregated data is crunched so as to obtain reputation values. Although the algorithms are specifically out of scope, it is their nature that determines the continuous nature of the output. Data aggregation is the most striking feature, not found in VBR. The very definition of reputation, in the second paragraph of the charter text, is given using the term "aggregate". However, the paragraph that explains it, quoted above, comes far below. Its position and its wording seem to diminish the importance of data aggregation, as if it were an optional component. How ambiguous, considering its specification comes right after the problem definition, in Goals and Milestones. In case aggregation is to be considered a requisite of a reputation system, I suggest to merge that paragraph with the second paragraph. For example: Such an assessment requires to gather and process information about the identifier and/or the owner, which we call raw data. In the aggregate, such data can be called "reputation". The working group will produce specifications for both data-exchange sides of the processing, that is * a common mechanism to use in querying reputation-related repositories, so as to bring reputation data to "consumers"; and * reporting raw data from end-points (usually end users, such as someone clicking a "report spam" button in response to unwanted email, or a "thumbs-up" button in an online rating system) to "aggregators". Actually, I'm not 100% happy with the second bullet. I'd move the parenthesized text down, after the focus for the initial charter on email messages. I'm not sure whether the WG is willing to tackle the problem of receiving and vetting abuse reports. Aggregators are clearly an abstraction conceived to insulate abuse reporting. jm2c From jdfalk-lists@cybernothing.org Mon Aug 15 10:54:51 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A838421F8CA6 for ; Mon, 15 Aug 2011 10:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy7C58JTPGsb for ; Mon, 15 Aug 2011 10:54:51 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id DD1AE21F8CA7 for ; Mon, 15 Aug 2011 10:54:50 -0700 (PDT) Received: from [192.168.1.2] (66-87-5-202.pools.spcsdns.net [66.87.5.202]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7FHtU2E010062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Aug 2011 10:55:35 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p7FHtU2E010062 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1313430936; bh=NnzYnoxytUmNCzxcOlR6L6nTxFyYXVEUw+Bvaqmn8 T4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=REN6nETNqHT8 B+dUytxnsxz0WT2qof4GyqiWrdsKePOSCDZfhClE9OZG5BG26fUZu46jV2W76gko2x4 uBoL1jrZdgF6Y7fD+TBz1lGTAgj0OGtsKli+zkSfQizMt66ufd/jZw+j/uy6s09MqX0 UnjOqrOw2SCOr746MawgzxXyk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <4E48DA14.5090901@tana.it> Date: Mon, 15 Aug 2011 12:55:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110811125339.GB95640@shinkuro.com> <4E457068.7060209@dcrocker.net> <4E48DA14.5090901@tana.it> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:54:51 -0000 On Aug 15, 2011, at 3:34 AM, Alessandro Vesely wrote: > On 12.08.2011 20:45, Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Dave CROCKER >>> Given the existence of VBR, why is an additional reputation query >>> mechanism needed? What will be different in the the mechanism and = why >>> is the difference important? >>=20 >> Specifically, the proposed system is not Boolean in nature. In the >> proposed framework, it is possible to make an expression of scale in = terms >> of an assertion, and confidence in that assertion. >=20 > This difference doesn't seem to be advantageous to consumers. In = fact, I > never saw lists of messages sorted by spam-score. Consumers would = probably > prefer a few discrete values (obtainable using thresholds.) This hasn't been our experience with the Sender Score (senderscore.org.) = There are some consumers of the data (big mailbox providers) who place = different rate limits on senders depending on their score, and they like = being able to set their own thresholds. http://www.returnpath.net/blog/received/2011/07/rate-limiting/ -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Mon Aug 15 10:58:54 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DF021F8C9D for ; Mon, 15 Aug 2011 10:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNoHhBOeFCTi for ; Mon, 15 Aug 2011 10:58:54 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3E63C21F8C95 for ; Mon, 15 Aug 2011 10:58:54 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 15 Aug 2011 10:59:36 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 15 Aug 2011 10:59:34 -0700 Thread-Topic: [domainrep] Updated proposed charter Thread-Index: AcxbJjNXhNl/WFmDR1G7FuzTAg1lHQAThHkw Message-ID: References: <20110811125339.GB95640@shinkuro.com> <4E457068.7060209@dcrocker.net> <4E48DA14.5090901@tana.it> In-Reply-To: <4E48DA14.5090901@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:58:55 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Alessandro Vesely > Sent: Monday, August 15, 2011 1:34 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Updated proposed charter >=20 > This difference doesn't seem to be advantageous to consumers. In fact, I > never saw lists of messages sorted by spam-score. Consumers would probab= ly > prefer a few discrete values (obtainable using thresholds.) It must be a > matter of necessity to do continuous values. This seems to fly in the face of the experience provided by Spamassassin, a= nd it's wildly popular. It definitely offers a score and allows users to d= efine the limit above which something is spam. > Data aggregation is the most striking feature, not found in VBR. The ver= y > definition of reputation, in the second paragraph of the charter text, is > given using the term "aggregate". However, the paragraph that explains i= t, > quoted above, comes far below. Its position and its wording seem to dimi= nish > the importance of data aggregation, as if it were an optional component. = How > ambiguous, considering its specification comes right after the problem > definition, in Goals and Milestones. There's no intention to diminish its importance, but it is only one piece o= f the puzzle. The charter has a lot of other context and background to del= iver, as will the ultimate suite of documents this WG would produce. That said, there will certainly be lots of systems that have proprietary fe= edback mechanisms. Thus, I think there's currently a lot less demand to sp= ecify this piece than there is the query/response portion. That may be why= it's less dominant. As for vetting the reports, I think that's a matter for Security Considerat= ions and not of protocol. But certainly if/when we do tackle the reporting= portion of this work, it'll have to be covered. From dotis@mail-abuse.org Mon Aug 15 14:51:57 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D774411E80C4 for ; Mon, 15 Aug 2011 14:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.155 X-Spam-Level: X-Spam-Status: No, score=-104.155 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSLn3h4sVr57 for ; Mon, 15 Aug 2011 14:51:56 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id 80AD711E80C0 for ; Mon, 15 Aug 2011 14:51:56 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id 3DB9A30810D for ; Mon, 15 Aug 2011 21:52:41 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id BDEA8A9443B for ; Mon, 15 Aug 2011 21:52:41 +0000 (UTC) Message-ID: <4E499528.1000309@mail-abuse.org> Date: Mon, 15 Aug 2011 14:52:40 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: domainrep Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [domainrep] Reputation basis of Charter flawed. X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:51:58 -0000 The charter attempts to establish reputation schemes based on flawed methodologies. a) SPF may not identify sender domains within shared IP addresses. b) SPF may invite amplification attacks. c) DKIM may not identify intended message recipients. d) DKIM may not prevent a spoofed header from being applied against a reputation assertion. SPF domain reputations are problematic. ---- 1) It is common for multiple domains to share a common address. 2) A domain used to reference an "authorized" address within an exchange is undefined. 3) Enforcement is problematic because a domain reference might be extracted from- a) HELO/EHLO b) return-path c) PRA (From, Sender, Resent-*) 4) SPF macro libraries expand email-address local-parts and permit dangerous network amplifications against innocent third-parties that may not even be present within an attacking message. DKIM domain reputations are problematic. ---- 1) DKIM may not confirm intended recipients. 2) DKIM permits pre-pended header fields where asserting good a reputation could prove hazardous. Sending commercial/bulk email to recipients that never expressed a desire to receive them is often the basis used to describe an act of spamming. Since DKIM permits replay by design, a malefactor could utilize this weakness to damage reputations based upon valid DKIM signatures. Several have also expressed a desire to aggregate reputation based upon disparate methods. Such aggregation further reduces any clarity regarding why a particular reputation has been asserted, and whether the actors involved were controlled by the assessed domain. Unless SPF is limited exclusively to that of the EHLO domain and DKIM confirms the intended recipient, these two methodologies can not be safely used. Imposing such restrictions would permit a class of spam that could not affect the reputation of a domain. For domain reputation to work effectively and safely with email, there must be a safe method available to authenticate the SMTP transmitter. To deal with the growing use of LSN, a cryptographic technique as enabled by DANE would be ideal. The charter should remove references to flawed SPF and DKIM methodologies for establishing reputations. Refer instead to as yet an undefined method. -Doug From msk@cloudmark.com Mon Aug 15 15:03:12 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40D21F8CDF for ; Mon, 15 Aug 2011 15:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.06 X-Spam-Level: X-Spam-Status: No, score=-103.06 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcZXzBPDqsmv for ; Mon, 15 Aug 2011 15:03:11 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id C848821F8BF0 for ; Mon, 15 Aug 2011 15:03:11 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 15 Aug 2011 15:03:58 -0700 From: "Murray S. Kucherawy" To: domainrep Date: Mon, 15 Aug 2011 15:03:57 -0700 Thread-Topic: [domainrep] Reputation basis of Charter flawed. Thread-Index: Acxbla77qiA3N91eQ5uMz5C6cC/QjAAACj1g Message-ID: References: <4E499528.1000309@mail-abuse.org> In-Reply-To: <4E499528.1000309@mail-abuse.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Reputation basis of Charter flawed. X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 22:03:12 -0000 References to DKIM and SPF are merely examples that create the need being a= ddressed here. The general framework is one that can support developing re= putation with any identifier that can be reliably established using whateve= r method people find useful. I think including them as use cases is actually a good idea. Their respect= ive security considerations are already well-documented, and would of cours= e be necessary review for anyone implementing a reputation system based upo= n them. -MSK From dhc@dcrocker.net Tue Aug 16 07:00:21 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5021F8AFA for ; Tue, 16 Aug 2011 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOOtHbbXGS6f for ; Tue, 16 Aug 2011 07:00:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1005B21F8AD3 for ; Tue, 16 Aug 2011 07:00:21 -0700 (PDT) Received: from [192.168.1.158] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7GE13Xh019981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Aug 2011 07:01:08 -0700 Message-ID: <4E4A7817.20607@dcrocker.net> Date: Tue, 16 Aug 2011 07:00:55 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E499528.1000309@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 16 Aug 2011 07:01:09 -0700 (PDT) Subject: Re: [domainrep] Reputation basis of Charter flawed. X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:00:22 -0000 On 8/15/2011 3:03 PM, Murray S. Kucherawy wrote: > References to DKIM and SPF are merely examples that create the need being > addressed here. +1 An essential point about this new work is that it /starts/ with a "verified domain name" without having to worry about any of the details that made the domain name be verified. How the verification is obtained is out of scope for this group. That is, SPF and DKIM really are just examples of how to produce verification. If someone has criticisms of the verification process, they need to pursue them in a venue that discusses domain name verification. Domainrep has nothing to do with domain name verification, anymore than a TCP design group has anything to do with IP design. Hence, discussion of SPF or DKIM is out of scope for this group. > The general framework is one that can support developing reputation with any > identifier that can be reliably established using whatever method people find > useful. To be precise, I believe it's "domain name identifier" rather than "any identifier", for this group. > I think including them as use cases is actually a good idea. +1. It permits designing at a systems level and with an anchor in the real world of likely uses. > Their > respective security considerations are already well-documented, For this group, that doesn't matter. It's out of scope. The way to keep an out of scope topic out of scope is to avoid /any/ discussion of it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rbbarclay@gmail.com Tue Aug 16 07:48:01 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4205E21F8A95 for ; Tue, 16 Aug 2011 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPU36uDR+fdQ for ; Tue, 16 Aug 2011 07:48:00 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5821F8B48 for ; Tue, 16 Aug 2011 07:48:00 -0700 (PDT) Received: by iye1 with SMTP id 1so9217442iye.27 for ; Tue, 16 Aug 2011 07:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LnBzM4iQeD81l1O3TdPHQeRTfezAimJlG/h90p2H3Qg=; b=V+YE4l844OxcB25T73hTw2VapQtWhbJlxZU9bb6OPHLazX7AMC2HtoEX6JC04MW6Hd zwjBG3P7xeySaBJMRbzAjlWFFzYYQNdi9SQ5KUH2WxxVZiDeB5CHIZIbaMmk+H/No6+X x+ky/Et9fam4rjX4eSRkUVxOAhNq2RzfsRVhY= MIME-Version: 1.0 Received: by 10.231.42.133 with SMTP id s5mr10995492ibe.34.1313506128230; Tue, 16 Aug 2011 07:48:48 -0700 (PDT) Received: by 10.231.32.13 with HTTP; Tue, 16 Aug 2011 07:48:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 08:48:47 -0600 Message-ID: From: Robert Barclay To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=00151774187a2ef76804aaa07a89 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Updated proposed charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:48:01 -0000 --00151774187a2ef76804aaa07a89 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Murray, Thanks for this, and sorry for being a little late to the game here. I thin= k this charter makes sense to me. The only piece of it I question a little is the work to provide feedback to reputation providers. I think this may be a topic that could be a huge sinkhole and isn't required for the query mechanism itself to be useful. Given the wide variety of types of data that might go into calculating a reputation and the number of different potential sources of that informatio= n if we discuss it at all I think it makes more sense to focus time on the query mechanisms and the informational document. Those are big enough chunk= s of work. Robert On Wed, Aug 10, 2011 at 11:20 PM, Murray S. Kucherawy wr= ote: > I=92ve updated the proposed charter at > http://www.blackops.org/~msk/domainrep/repute-charter.txt to take into > account this week=92s feedback, including some milestones that I think we > could hit given the current interest. Please review it and let me know i= f > I=92ve missed anything.**** > > ** ** > > -MSK**** > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > > --00151774187a2ef76804aaa07a89 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Murray,
Thanks for this, and sorry for being a little late to the game = here. I think this charter makes sense to me. The only piece of it I questi= on a little is the work to provide feedback to reputation providers. I thin= k this may be a topic that could be a huge sinkhole and isn't required = for the query mechanism itself to be useful.=A0
Given the wide variety of types of data that might go into calculating= a reputation and the number of different potential sources of that informa= tion if we discuss it at all I think it makes more sense to focus time on t= he query mechanisms and the informational document. Those are big enough ch= unks of work.

Robert

On Wed, Aug 10= , 2011 at 11:20 PM, Murray S. Kucherawy <msk@cloudmark.com> wrote:

I=92ve updated the proposed charter at http://www.blackops= .org/~msk/domainrep/repute-charter.txt to take into account this week= =92s feedback, including some milestones that I think we could hit given th= e current interest.=A0 Please review it and let me know if I=92ve missed an= ything.

=A0

-MSK


______________= _________________________________
domainrep mailing list
domainrep@ietf.org
https://www.ietf.org/mailman/listinfo/domainrep


--00151774187a2ef76804aaa07a89-- From dotis@mail-abuse.org Tue Aug 16 11:54:40 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7F221F8BB9 for ; Tue, 16 Aug 2011 11:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.073 X-Spam-Level: X-Spam-Status: No, score=-104.073 tagged_above=-999 required=5 tests=[AWL=-1.474, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HBdg3spMwvC for ; Tue, 16 Aug 2011 11:54:39 -0700 (PDT) Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A921F8BB7 for ; Tue, 16 Aug 2011 11:54:39 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id 0177A6E0163 for ; Tue, 16 Aug 2011 18:55:27 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 4A31BA9443B for ; Tue, 16 Aug 2011 18:55:27 +0000 (UTC) Message-ID: <4E4ABD1C.9030501@mail-abuse.org> Date: Tue, 16 Aug 2011 11:55:24 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E499528.1000309@mail-abuse.org> <4E4A7817.20607@dcrocker.net> In-Reply-To: <4E4A7817.20607@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Reputation basis of Charter flawed. X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 18:54:41 -0000 On 8/16/11 7:00 AM, Dave CROCKER wrote: > > > On 8/15/2011 3:03 PM, Murray S. Kucherawy wrote: >> References to DKIM and SPF are merely examples that create the need >> being >> addressed here. > > +1 > > An essential point about this new work is that it /starts/ with a > "verified domain name" without having to worry about any of the > details that made the domain name be verified. How the verification > is obtained is out of scope for this group. > > That is, SPF and DKIM really are just examples of how to produce > verification. > > If someone has criticisms of the verification process, they need to > pursue them in a venue that discusses domain name verification. > Domainrep has nothing to do with domain name verification, anymore > than a TCP design group has anything to do with IP design. > > Hence, discussion of SPF or DKIM is out of scope for this group. > > >> The general framework is one that can support developing reputation >> with any > > identifier that can be reliably established using whatever method > people find > > useful. > > To be precise, I believe it's "domain name identifier" rather than > "any identifier", for this group. > > >> I think including them as use cases is actually a good idea. > > +1. It permits designing at a systems level and with an anchor in the > real world of likely uses. > >> Their >> respective security considerations are already well-documented, > > For this group, that doesn't matter. It's out of scope. > > The way to keep an out of scope topic out of scope is to avoid /any/ > discussion of it. Using SPF or DKIM as examples of domain verification within the repute charter indirectly endorses the methods as suitable for use with a reputation scheme. These methods DO NOT verify a domain as controlling destination or the act of sending a message. Hardly a basis for reputations even as an example! When the suitability of a protocol is out-of-scope, a request to have the protocols removed from the charter is appropriate. Only large entities with the might of volume are safe from abuses permitted by these two schemes. Support issues represent a significant cost related to offering reputation. Aggregation will not avoid accountability. One should hope the resulting reputation service is suitable for both small and large entities. -Doug From msk@cloudmark.com Tue Aug 30 22:30:50 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A921F8ADC for ; Tue, 30 Aug 2011 22:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIO6qNEMoPtW for ; Tue, 30 Aug 2011 22:30:49 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4C21F8ACC for ; Tue, 30 Aug 2011 22:30:46 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 30 Aug 2011 22:32:15 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 30 Aug 2011 22:32:14 -0700 Thread-Topic: Charter adjustments Thread-Index: Acxnn1b0tDUGfuclRPu/ZtxAbur5XA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 05:30:50 -0000 After some review by our sponsoring AD, I've made a few tweaks in the propo= sed charter. Please provide any comments you may have, even if it's just a= "looks good", preferably sooner rather than later. They are pretty minor,= but having such feedback on the record will help move things along. The full updated charter is still available at http://www.blackops.org/~msk= /domainrep/repute-charter.txt; the diffs are below. Absent any major problems, we should be on an IESG telechat and the main IE= TF mailing list fairly soon. -MSK --- repute-charter 2011/08/14 02:52:38 1.16 +++ repute-charter 2011/08/29 22:05:44 @@ -74,16 +74,19 @@ =20 This working group will produce a set of documents defining and illustrating the requirement and defining mechanisms to satisfy it. - Two mechanisms are proposed: + Two mechanisms are on the table: =20 * simple -- a reputation is expressed in a simple manner such as - an integer + an integer, provided via TXT records in the DNS + (see draft-kucherawy-reputation-query-dns) =20 * extended -- a response can contain more complex information - useful to an assessor + useful to an assessor, provided via an XML reply over HTTP + (see draft-kucherawy-reputation-query-http) =20 The mechanisms will be designed to be application-independent, and - portable between reputation providers. + portable between reputation providers. The working group will + consider these and may develop both or decide only one is needed. =20 The group will also produce specifications for reporting reputation data from end-points (usually end users, such as someone clicking @@ -128= ,6 +131,14 @@ compute reputations. These are part of a back-end system, usually proprietary, and not appropriate for specification as part of a query/reply framework and protocol. + + The initial draft set: + draft-kucherawy-reputation-model + draft-kucherawy-reputation-media-type + draft-kucherawy-reputation-query-http + draft-kucherawy-reputation-query-dns + draft-kucherawy-reputation-query-udp + draft-kucherawy-reputation-vocab-identity =20 Goals and Milestones: Mar 2012: Informational document, defining the problem space From R.E.Sonneveld@sonnection.nl Wed Aug 31 01:23:12 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD36021F8B39 for ; Wed, 31 Aug 2011 01:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxGXN5vguOCP for ; Wed, 31 Aug 2011 01:23:11 -0700 (PDT) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id D82DB21F8B02 for ; Wed, 31 Aug 2011 01:23:10 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LQS00I009UFFF00@hydrogen.mailtransaction.com>; Wed, 31 Aug 2011 10:24:35 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LQS0064JA0Z4C00@hydrogen.mailtransaction.com>; Wed, 31 Aug 2011 10:24:35 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LQS00M4SA0Z2200@lion.sonnection.nl> for domainrep@ietf.org; Wed, 31 Aug 2011 10:24:35 +0200 (CEST) Message-id: <4E5DF0A9.1070404@sonnection.nl> Date: Wed, 31 Aug 2011 10:28:25 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 To: "Murray S. Kucherawy" References: In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1314779075; bh=zCESJaow9Ms1sM+L8yI0xuDk7hLPNs2WsNRHQSU4vlc=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=H1Pp7hEkoCIziid66FCFho6RIedbbgPOLOtJpD7nTXWDlCMDidACuaFeM6dkMhngx HydMcdWYwKDyBfUDlRJYyZ2vJo2nrrpcxil1fTpy+OQTpGm4VqcuMR32283ccGImyw t6qvL4WV+Epjnxfegu2GWsyTPJ0vAAYCYy0jcZrk= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LQS00I009UFFF00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:23:12 -0000 Hi, Murray, On 8/31/11 7:32 AM, Murray S. Kucherawy wrote: > After some review by our sponsoring AD, I've made a few tweaks in the proposed charter. Please provide any comments you may have, even if it's just a "looks good", preferably sooner rather than later. They are pretty minor, but having such feedback on the record will help move things along. > > The full updated charter is still available at http://www.blackops.org/~msk/domainrep/repute-charter.txt; the diffs are below. > > Absent any major problems, we should be on an IESG telechat and the main IETF mailing list fairly soon. > > -MSK > > > --- repute-charter 2011/08/14 02:52:38 1.16 > +++ repute-charter 2011/08/29 22:05:44 > @@ -74,16 +74,19 @@ > > This working group will produce a set of documents defining and > illustrating the requirement and defining mechanisms to satisfy it. > - Two mechanisms are proposed: > + Two mechanisms are on the table: > > * simple -- a reputation is expressed in a simple manner such as > - an integer > + an integer, provided via TXT records in the DNS > + (see draft-kucherawy-reputation-query-dns) Does the 'such as' exclude alternative simple mechanisms which do not work via TXT records in DNS? Or is 'provided via TXT records in the DNS' just given as an example? On other words, does 'such as' relate to only 'an integer' or to the entire phrase? > > * extended -- a response can contain more complex information > - useful to an assessor > + useful to an assessor, provided via an XML reply over HTTP > + (see draft-kucherawy-reputation-query-http) Same question as above: does this limit in-charter discussions to the mechanism described in the draft document? > > The mechanisms will be designed to be application-independent, and > - portable between reputation providers. > + portable between reputation providers. The working group will > + consider these and may develop both or decide only one is needed. Hmm, IMHO retrieval mechanisms (simple vs extended) and types of reputation data (simple vs complex) are mixed up here. If I remember correctly we discussed the 'application independence' and 'portability' in the context of the reputation data, not the (retrieval) mechanism. The portability of the reputation data is important as this data can be interchanged between reputation providers and consumers can use different reputation sources and may want to compare or aggregate reputation scores. The portability and application independency of the retrieval mechanism doesn't need to be mentioned here, as it is implicit to the creation of a standards track RFC. All in all, I'm not convinced the new charter text is an improvement over the old one. /rolf From peer2peer@gmail.com Wed Aug 31 03:12:04 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C893921F8B00 for ; Wed, 31 Aug 2011 03:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhdwnF3ZXC9L for ; Wed, 31 Aug 2011 03:12:04 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEF2D21F86B1 for ; Wed, 31 Aug 2011 03:12:03 -0700 (PDT) Received: by gxk19 with SMTP id 19so502992gxk.31 for ; Wed, 31 Aug 2011 03:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=22U3jUMBB9VlXTquljBjOx4zOBIK5/4SNRXqi+Scb0M=; b=ASd9SRHnJENmBwDW4YvkLLyH2UCvc2l7fTou+R/2FzbbL3NOxerryQGYTsLhNDEgP8 JnrEqpNnUw5PvJ6VOPQbW+ESXdKlR209Y1zMgsZsYX7hOII1Ux8gOkYpw5j9tToQ9NR4 y8Dc1IuG7847JeuYWJfzC+KD8onRIng6A41ws= MIME-Version: 1.0 Received: by 10.142.172.12 with SMTP id u12mr58493wfe.10.1314785611278; Wed, 31 Aug 2011 03:13:31 -0700 (PDT) Received: by 10.143.44.17 with HTTP; Wed, 31 Aug 2011 03:13:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Aug 2011 12:13:31 +0200 Message-ID: From: Johan Pouwelse To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 10:12:04 -0000 "looks good" -johan. On 31/08/2011, Murray S. Kucherawy wrote: > After some review by our sponsoring AD, I've made a few tweaks in the > proposed charter. Please provide any comments you may have, even if it's > just a "looks good", preferably sooner rather than later. They are pretty > minor, but having such feedback on the record will help move things along. > > The full updated charter is still available at > http://www.blackops.org/~msk/domainrep/repute-charter.txt; the diffs are > below. > > Absent any major problems, we should be on an IESG telechat and the main > IETF mailing list fairly soon. > > -MSK > > > --- repute-charter 2011/08/14 02:52:38 1.16 > +++ repute-charter 2011/08/29 22:05:44 > @@ -74,16 +74,19 @@ > > This working group will produce a set of documents defining and > illustrating the requirement and defining mechanisms to satisfy it. > - Two mechanisms are proposed: > + Two mechanisms are on the table: > > * simple -- a reputation is expressed in a simple manner such as > - an integer > + an integer, provided via TXT records in the DNS > + (see draft-kucherawy-reputation-query-dns) > > * extended -- a response can contain more complex information > - useful to an assessor > + useful to an assessor, provided via an XML reply over HTTP > + (see draft-kucherawy-reputation-query-http) > > The mechanisms will be designed to be application-independent, and > - portable between reputation providers. > + portable between reputation providers. The working group will > + consider these and may develop both or decide only one is needed. > > The group will also produce specifications for reporting reputation > data from end-points (usually end users, such as someone clicking @@ > -128,6 +131,14 @@ > compute reputations. These are part of a back-end system, usually > proprietary, and not appropriate for specification as part of > a query/reply framework and protocol. > + > + The initial draft set: > + draft-kucherawy-reputation-model > + draft-kucherawy-reputation-media-type > + draft-kucherawy-reputation-query-http > + draft-kucherawy-reputation-query-dns > + draft-kucherawy-reputation-query-udp > + draft-kucherawy-reputation-vocab-identity > > Goals and Milestones: > Mar 2012: Informational document, defining the problem space > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > From ajs@anvilwalrusden.com Wed Aug 31 04:58:44 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A7921F8ABE for ; Wed, 31 Aug 2011 04:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PekKsAvR7t2D for ; Wed, 31 Aug 2011 04:58:43 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07321F8ABC for ; Wed, 31 Aug 2011 04:58:43 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 123231ECB41C for ; Wed, 31 Aug 2011 12:00:13 +0000 (UTC) Date: Wed, 31 Aug 2011 08:00:14 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110831120013.GC99123@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 11:58:44 -0000 On Tue, Aug 30, 2011 at 10:32:14PM -0700, Murray S. Kucherawy wrote: > After some review by our sponsoring AD, I've made a few tweaks in the proposed charter. Please provide any comments you may have, even if it's just a "looks good", preferably sooner rather than later. They are pretty minor, but having such feedback on the record will help move things along. > I'm fine with this, although this change > - Two mechanisms are proposed: > + Two mechanisms are on the table: seems to me to be in the wrong direction. I increasingly hate the hoary phrase "on the table". A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Aug 31 06:58:34 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7100921F8B9D for ; Wed, 31 Aug 2011 06:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3YP294DccJQ for ; Wed, 31 Aug 2011 06:58:33 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id C0FCA21F8B6F for ; Wed, 31 Aug 2011 06:58:33 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 31 Aug 2011 07:00:03 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 31 Aug 2011 07:00:02 -0700 Thread-Topic: [domainrep] Charter adjustments Thread-Index: Acxnt22v6/9lgjLJSyy2uMrOo5J/eAALjBIA Message-ID: References: <4E5DF0A9.1070404@sonnection.nl> In-Reply-To: <4E5DF0A9.1070404@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:58:34 -0000 > -----Original Message----- > From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] > Sent: Wednesday, August 31, 2011 1:28 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Charter adjustments >=20 > Does the 'such as' exclude alternative simple mechanisms which do not > work via TXT records in DNS? Or is 'provided via TXT records in the DNS' > just given as an example? On other words, does 'such as' relate to only > 'an integer' or to the entire phrase? It indicates a starting point for discussion. The use of DNS TXT records t= o relay data is controversial and I expect we'll have that debate, but it's= a convenient place to begin. > > * extended -- a response can contain more complex information > > - useful to an assessor > > + useful to an assessor, provided via an XML reply over HTTP > > + (see draft-kucherawy-reputation-query-http) >=20 > Same question as above: does this limit in-charter discussions to the > mechanism described in the draft document? Same answer; it's a good starting point. The debate here doesn't seem to b= e over HTTP, but rather over JSON vs. XML. But, of course, HTTP could also= be debated. > Hmm, IMHO retrieval mechanisms (simple vs extended) and types of > reputation data (simple vs complex) are mixed up here. If I remember > correctly we discussed the 'application independence' and 'portability' > in the context of the reputation data, not the (retrieval) mechanism. We discussed both. The former goes in the "model" and "media-type" documen= ts; the latter goes in the two protocol specifications. > All in all, I'm not convinced the new charter text is an improvement > over the old one. I'm curious as to why, since this is text you previously approved: http://www.ietf.org/mail-archive/web/domainrep/current/msg00418.html The only real change is that the initial examples of "simple" and "extended= " are given explicitly, rather than only in the drafts that have already be= en posted. From R.E.Sonneveld@sonnection.nl Wed Aug 31 08:37:42 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53E21F8B70 for ; Wed, 31 Aug 2011 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.915 X-Spam-Level: X-Spam-Status: No, score=-3.915 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6DzQky236e6 for ; Wed, 31 Aug 2011 08:37:41 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 86FD921F8B67 for ; Wed, 31 Aug 2011 08:37:41 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LQS00000U58C500@helium.mailtransaction.com>; Wed, 31 Aug 2011 17:39:08 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LQS004KJU583G00@helium.mailtransaction.com>; Wed, 31 Aug 2011 17:39:08 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LQS0061LU580C00@lion.sonnection.nl> for domainrep@ietf.org; Wed, 31 Aug 2011 17:39:08 +0200 (CEST) Message-id: <4E5E5682.5090505@sonnection.nl> Date: Wed, 31 Aug 2011 17:42:58 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 To: "Murray S. Kucherawy" References: <4E5DF0A9.1070404@sonnection.nl> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1314805148; bh=eHs3Lmyj8LUj5/mmzaKy/FNOt6wWXN7ImZIXi73Unyw=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=dKa5UZNaZrTVSJohIH11xiOi45zLss2vWb+gz38NtMjlq3XizA4iIRabmgqpKad+8 mY9LbYLODgasumDoa4mWhFF5O1DOBXFS4Q7/OBETwBL2H5pC+jqXb2DB2RT53UJ+3E spXJDHsJnK7NTtbzfLOs3NIjGOOMi0ln1rjEGJqo= X-DKIM: OpenDKIM Filter v2.1.3 helium.mailtransaction.com 0LQS00000U58C500 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:37:42 -0000 On 8/31/11 4:00 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] >> Sent: Wednesday, August 31, 2011 1:28 AM >> To: Murray S. Kucherawy >> Cc: domainrep@ietf.org >> Subject: Re: [domainrep] Charter adjustments >> >> Does the 'such as' exclude alternative simple mechanisms which do not >> work via TXT records in DNS? Or is 'provided via TXT records in the DNS' >> just given as an example? On other words, does 'such as' relate to only >> 'an integer' or to the entire phrase? > It indicates a starting point for discussion. The use of DNS TXT records to relay data is controversial and I expect we'll have that debate, but it's a convenient place to begin. I agree it's a convenient place to begin, but I really fail to see the added value in the context of a charter document. If we want to keep it, may I suggest to slightly change it, to make more explicit that these are mere examples, nothing more: Old text: * simple -- a reputation is expressed in a simple manner such as an integer, provided via TXT records in the DNS (see draft-kucherawy-reputation-query-dns) * extended -- a response can contain more complex information useful to an assessor, provided via an XML reply over HTTP (see draft-kucherawy-reputation-query-http) New text: * simple -- a reputation is expressed in a simple manner, such as an integer provided via TXT records in the DNS (see draft-kucherawy-reputation-query-dns) * extended -- a response can contain more complex information useful to an assessor which, for example, can be provided via an XML reply over HTTP (see draft-kucherawy-reputation-query-http) >>> * extended -- a response can contain more complex information >>> - useful to an assessor >>> + useful to an assessor, provided via an XML reply over HTTP >>> + (see draft-kucherawy-reputation-query-http) >> Same question as above: does this limit in-charter discussions to the >> mechanism described in the draft document? > Same answer; it's a good starting point. The debate here doesn't seem to be over HTTP, but rather over JSON vs. XML. But, of course, HTTP could also be debated. > >> Hmm, IMHO retrieval mechanisms (simple vs extended) and types of >> reputation data (simple vs complex) are mixed up here. If I remember >> correctly we discussed the 'application independence' and 'portability' >> in the context of the reputation data, not the (retrieval) mechanism. > We discussed both. The former goes in the "model" and "media-type" documents; the latter goes in the two protocol specifications. What you say here is entirely correct. But that doesn't mean the charter isn't still mixing up the two interpretations of the word 'mechanism'. [Granted, I approved the old text, so I presumably didn't notice it when I read the original charter text.] Suggestion: Old text: Two mechanisms are on the table: [...] The mechanisms will be designed to be application-independent, and portable between reputation providers. The working group will consider these and may develop both or decide only one is needed. New text: Two combinations of mechanism and reputation data type are on the table: [...] The combinations of mechanism and reputation data type will be designed to be application-independent, and portable between reputation providers. The working group will consider these and may develop both or decide only one is needed. /rolf From johnl@iecc.com Wed Aug 31 08:59:23 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D941F21F8CDF for ; Wed, 31 Aug 2011 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.139 X-Spam-Level: X-Spam-Status: No, score=-111.139 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+ny4sLoo4XD for ; Wed, 31 Aug 2011 08:59:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF521F8CDE for ; Wed, 31 Aug 2011 08:59:23 -0700 (PDT) Received: (qmail 57049 invoked from network); 31 Aug 2011 16:00:52 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 31 Aug 2011 16:00:52 -0000 Received: (qmail 36398 invoked from network); 31 Aug 2011 16:00:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 Aug 2011 16:00:52 -0000 Date: 31 Aug 2011 16:00:30 -0000 Message-ID: <20110831160030.40398.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <20110831120013.GC99123@shinkuro.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:59:24 -0000 >seems to me to be in the wrong direction. I increasingly hate the >hoary phrase "on the table". It's also confusing. In the US, a motion that is tabled is set aside and will probably never be seen again. In the UK and Canada, a motion that is tabled is taken up for active debate. I'm happy with "proposed" or "under consideration", or any similar furniture-free non-metaphorical term. I'm also OK with the TXT and XML-HTTP examples, given that they're examples. It seems easier than "a query mechanism intended to be sufficiently lightweight to be implemented as a single UDP round trip with possible intermediate caches", and "a query mechanism using a hierarchical naming scheme and returning a potentially large response containing tagged data in an agreed format." R's, John From msk@cloudmark.com Wed Aug 31 10:52:05 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC021F8E3A for ; Wed, 31 Aug 2011 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.525 X-Spam-Level: X-Spam-Status: No, score=-103.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQBJAfM7UAAZ for ; Wed, 31 Aug 2011 10:52:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2400521F8E38 for ; Wed, 31 Aug 2011 10:52:05 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 31 Aug 2011 10:53:36 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 31 Aug 2011 10:53:35 -0700 Thread-Topic: [domainrep] Charter adjustments Thread-Index: Acxn9y5KtFxHLG5aRnS1CepEPWY6LwAD6wtA Message-ID: References: <20110831120013.GC99123@shinkuro.com> <20110831160030.40398.qmail@joyce.lan> In-Reply-To: <20110831160030.40398.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:52:05 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of John Levine > Sent: Wednesday, August 31, 2011 9:01 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Charter adjustments >=20 > >seems to me to be in the wrong direction. I increasingly hate the > >hoary phrase "on the table". >=20 > It's also confusing. In the US, a motion that is tabled is set aside > and will probably never be seen again. In the UK and Canada, a motion > that is tabled is taken up for active debate. >=20 > I'm happy with "proposed" or "under consideration", or any similar > furniture-free non-metaphorical term. OK, I've gone back to "under consideration". From msk@cloudmark.com Wed Aug 31 11:06:53 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9DC21F8DF1 for ; Wed, 31 Aug 2011 11:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4YoX54NfCwB for ; Wed, 31 Aug 2011 11:06:51 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 26DEB21F8DD1 for ; Wed, 31 Aug 2011 11:06:51 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 31 Aug 2011 11:08:21 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 31 Aug 2011 11:08:21 -0700 Thread-Topic: [domainrep] Charter adjustments Thread-Index: Acxn9CIaRw85rB1USLqWlM9WJMXtpQAFA9sQ Message-ID: References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> In-Reply-To: <4E5E5682.5090505@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:06:53 -0000 > -----Original Message----- > From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] > Sent: Wednesday, August 31, 2011 8:43 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Charter adjustments >=20 > I agree it's a convenient place to begin, but I really fail to see the > added value in the context of a charter document. Charter documents, and BoFs, have to describe the starting point accurately= . That's why this stuff is in there. > If we want to keep it, may I suggest to slightly change it, to make > more > explicit that these are mere examples, nothing more: >=20 > Old text: >=20 > * simple -- a reputation is expressed in a simple manner such as > an integer, provided via TXT records in the DNS > (see draft-kucherawy-reputation-query-dns) >=20 > * extended -- a response can contain more complex information > useful to an assessor, provided via an XML reply over HTTP > (see draft-kucherawy-reputation-query-http) >=20 >=20 > New text: >=20 > * simple -- a reputation is expressed in a simple manner, such as > an integer provided via TXT records in the DNS > (see draft-kucherawy-reputation-query-dns) >=20 > * extended -- a response can contain more complex information > useful to an assessor which, for example, can be provided via an XML re= ply over HTTP > (see draft-kucherawy-reputation-query-http) That's such a minor change that I've made it. I see what you're trying to = convey but I don't think it's a very big deal at this point. > What you say here is entirely correct. But that doesn't mean the charter > isn't still mixing up the two interpretations of the word 'mechanism'. >=20 > [Granted, I approved the old text, so I presumably didn't notice it when > I read the original charter text.] >=20 > Suggestion: >=20 > Old text: >=20 > Two mechanisms are on the table: >=20 > [...] >=20 > The mechanisms will be designed to be application-independent, and > portable between reputation providers. The working group will > consider these and may develop both or decide only one is needed. >=20 > New text: >=20 > Two combinations of mechanism and reputation data type are on the table: >=20 > [...] >=20 > The combinations of mechanism and reputation data type will be designed > to be application-independent, and portable between reputation providers= . > The working group will consider these and may develop both or decide onl= y > one is needed. This conflates some important things. Portability is irrelevant to mechani= sm, for example; it has to do with the choice of the expressed reputation (= and is thus part of the vocabulary), not the protocol by which it's deliver= ed. I prefer the current text. Is there other feedback? From R.E.Sonneveld@sonnection.nl Wed Aug 31 15:11:28 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAA721F8DE4 for ; Wed, 31 Aug 2011 15:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.883 X-Spam-Level: X-Spam-Status: No, score=-3.883 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHEtd1TWY7ox for ; Wed, 31 Aug 2011 15:11:28 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id C754821F8DDF for ; Wed, 31 Aug 2011 15:11:27 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LQT00H00CDL5Q00@helium.mailtransaction.com>; Thu, 01 Sep 2011 00:12:58 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LQT00F0VCDL0D00@helium.mailtransaction.com>; Thu, 01 Sep 2011 00:12:57 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LQT0062VCDL0C00@lion.sonnection.nl> for domainrep@ietf.org; Thu, 01 Sep 2011 00:12:57 +0200 (CEST) Message-id: <4E5EB2CF.5090300@sonnection.nl> Date: Thu, 01 Sep 2011 00:16:47 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 To: "Murray S. Kucherawy" References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1314828778; bh=G/kStpgb9sUh/9ZgS9w5Pj5djW37jO8JpM0/VbAxe2Q=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=NBmrMg//x3gWPn9ZuYFGXWPIevywANazztrW09S+VDvU/GmfxmD5Z/mjmejNPhrre b9KkhqdWgb0Z8Gwfadnbm0rWBJsyDQJjCKDWyMHSdTsyp4orh1gkDgLlv6DbYwXiHS yfXMMtl0F9O6OwcdgjnpCE5OGI+6yftQZ9eRLPqI= X-DKIM: OpenDKIM Filter v2.1.3 helium.mailtransaction.com 0LQT00H00CDL5Q00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 22:11:28 -0000 On 8/31/11 8:08 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] >> Sent: Wednesday, August 31, 2011 8:43 AM >> To: Murray S. Kucherawy >> Cc: domainrep@ietf.org >> Subject: Re: [domainrep] Charter adjustments >> >> I agree it's a convenient place to begin, but I really fail to see the >> added value in the context of a charter document. > Charter documents, and BoFs, have to describe the starting point accurately. That's why this stuff is in there. > >> If we want to keep it, may I suggest to slightly change it, to make >> more >> explicit that these are mere examples, nothing more: >> >> Old text: >> >> * simple -- a reputation is expressed in a simple manner such as >> an integer, provided via TXT records in the DNS >> (see draft-kucherawy-reputation-query-dns) >> >> * extended -- a response can contain more complex information >> useful to an assessor, provided via an XML reply over HTTP >> (see draft-kucherawy-reputation-query-http) >> >> >> New text: >> >> * simple -- a reputation is expressed in a simple manner, such as >> an integer provided via TXT records in the DNS >> (see draft-kucherawy-reputation-query-dns) >> >> * extended -- a response can contain more complex information >> useful to an assessor which, for example, can be provided via an XML reply over HTTP >> (see draft-kucherawy-reputation-query-http) > That's such a minor change that I've made it. I see what you're trying to convey but I don't think it's a very big deal at this point. > >> What you say here is entirely correct. But that doesn't mean the charter >> isn't still mixing up the two interpretations of the word 'mechanism'. >> >> [Granted, I approved the old text, so I presumably didn't notice it when >> I read the original charter text.] >> >> Suggestion: >> >> Old text: >> >> Two mechanisms are on the table: >> >> [...] >> >> The mechanisms will be designed to be application-independent, and >> portable between reputation providers. The working group will >> consider these and may develop both or decide only one is needed. >> >> New text: >> >> Two combinations of mechanism and reputation data type are on the table: >> >> [...] >> >> The combinations of mechanism and reputation data type will be designed >> to be application-independent, and portable between reputation providers. >> The working group will consider these and may develop both or decide only >> one is needed. > This conflates some important things. Portability is irrelevant to mechanism, for example; it has to do with the choice of the expressed reputation (and is thus part of the vocabulary), not the protocol by which it's delivered. > > I prefer the current text. The current text reads "The mechanisms will [...], and portable between reputation providers". In your answer to my mail you write: "Portability is irrelevant to mechanism". Ergo? /rolf From dotis@mail-abuse.org Wed Aug 31 16:29:20 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594BA21F8DAD for ; Wed, 31 Aug 2011 16:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgfVx5v4lgiF for ; Wed, 31 Aug 2011 16:29:19 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05F21F8DA8 for ; Wed, 31 Aug 2011 16:29:18 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id 8FB2C308105 for ; Wed, 31 Aug 2011 23:30:48 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 21560A9443B for ; Wed, 31 Aug 2011 23:30:49 +0000 (UTC) Message-ID: <4E5EC428.3010109@mail-abuse.org> Date: Wed, 31 Aug 2011 16:30:48 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> <4E5EB2CF.5090300@sonnection.nl> In-Reply-To: <4E5EB2CF.5090300@sonnection.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 23:29:20 -0000 On 8/31/11 3:16 PM, Rolf E. Sonneveld wrote: > On 8/31/11 8:08 PM, Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] >>> Sent: Wednesday, August 31, 2011 8:43 AM >>> To: Murray S. Kucherawy >>> Cc: domainrep@ietf.org >>> Subject: Re: [domainrep] Charter adjustments >>> >>> I agree it's a convenient place to begin, but I really fail to see the >>> added value in the context of a charter document. >> Charter documents, and BoFs, have to describe the starting point >> accurately. That's why this stuff is in there. >> >>> If we want to keep it, may I suggest to slightly change it, to make >>> more >>> explicit that these are mere examples, nothing more: >>> >>> Old text: >>> >>> * simple -- a reputation is expressed in a simple manner such as >>> an integer, provided via TXT records in the DNS >>> (see draft-kucherawy-reputation-query-dns) >>> >>> * extended -- a response can contain more complex information >>> useful to an assessor, provided via an XML reply over HTTP >>> (see draft-kucherawy-reputation-query-http) >>> >>> >>> New text: >>> >>> * simple -- a reputation is expressed in a simple manner, such as >>> an integer provided via TXT records in the DNS >>> (see draft-kucherawy-reputation-query-dns) >>> >>> * extended -- a response can contain more complex information >>> useful to an assessor which, for example, can be provided >>> via an XML reply over HTTP >>> (see draft-kucherawy-reputation-query-http) >> That's such a minor change that I've made it. I see what you're >> trying to convey but I don't think it's a very big deal at this point. >> >>> What you say here is entirely correct. But that doesn't mean the >>> charter >>> isn't still mixing up the two interpretations of the word 'mechanism'. >>> >>> [Granted, I approved the old text, so I presumably didn't notice it >>> when >>> I read the original charter text.] >>> >>> Suggestion: >>> >>> Old text: >>> >>> Two mechanisms are on the table: >>> >>> [...] >>> >>> The mechanisms will be designed to be application-independent, and >>> portable between reputation providers. The working group will >>> consider these and may develop both or decide only one is needed. >>> >>> New text: >>> >>> Two combinations of mechanism and reputation data type are on >>> the table: >>> >>> [...] >>> >>> The combinations of mechanism and reputation data type will be >>> designed >>> to be application-independent, and portable between reputation >>> providers. >>> The working group will consider these and may develop both or >>> decide only >>> one is needed. >> This conflates some important things. Portability is irrelevant to >> mechanism, for example; it has to do with the choice of the expressed >> reputation (and is thus part of the vocabulary), not the protocol by >> which it's delivered. >> >> I prefer the current text. > > The current text reads "The mechanisms will [...], and portable > between reputation providers". In your answer to my mail you write: > "Portability is irrelevant to mechanism". Ergo? The path to hell is paved with good intentions. Why establish potentially detrimental mechanisms based on abstract methods using flawed examples? When an underlying identity mechanism might harm networks or incorrectly identify responsible actors, any such scheme should be dissuaded. Aggregation of poorly considered mechanisms will not mitigate possible harm, but will eliminate possible redress. This effort will not establish the desired outcome. It is unwise to assume the outcome of such a system is not affected by inherent weaknesses. Examples given in this charter illustrate very poor judgement with respect to identify mechanisms that are open to abuse. -Doug From msk@cloudmark.com Wed Aug 31 16:33:26 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055F121F8DE8 for ; Wed, 31 Aug 2011 16:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yw6eGFdF6nn for ; Wed, 31 Aug 2011 16:33:25 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 949E621F8DE4 for ; Wed, 31 Aug 2011 16:33:25 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 31 Aug 2011 16:34:57 -0700 From: "Murray S. Kucherawy" To: "Rolf E. Sonneveld" Date: Wed, 31 Aug 2011 16:34:55 -0700 Thread-Topic: [domainrep] Charter adjustments Thread-Index: AcxoKyZziRYcDknQT+OsmL7Buu5gQAAC1Gwg Message-ID: References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> <4E5EB2CF.5090300@sonnection.nl> In-Reply-To: <4E5EB2CF.5090300@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 23:33:26 -0000 > -----Original Message----- > From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] > Sent: Wednesday, August 31, 2011 3:17 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Charter adjustments >=20 > The current text reads "The mechanisms will [...], and portable between > reputation providers". In your answer to my mail you write: "Portability > is irrelevant to mechanism". Ergo? I think I see what you're getting at now. How's this: Both the syntactical and semantic aspects of these mechanisms will = be designed to be application-independent, and portable between reputation providers. The working group will consider these and may develop both or decide only one is needed.