Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state

Dave Crocker <dhc@dcrocker.net> Fri, 08 June 2012 05:09 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB6D11E80B2 for <apps-discuss@ietfa.amsl.com>; Thu, 7 Jun 2012 22:09:29 -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 i5jFFatcjQyP for <apps-discuss@ietfa.amsl.com>; Thu, 7 Jun 2012 22:09:28 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 877AD11E80CE for <apps-discuss@ietf.org>; Thu, 7 Jun 2012 22:09:28 -0700 (PDT)
Received: from [192.168.2.101] (e179037154.adsl.alicedsl.de [85.179.37.154]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5859O7M026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2012 22:09:26 -0700
Message-ID: <4FD188FF.1080201@dcrocker.net>
Date: Fri, 08 Jun 2012 07:09:19 +0200
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
References: <CAL0qLwY1DCP9RY7cykwrPi48A_1h_FJUXo5eRWkn3Rw=rFXpBw@mail.gmail.com> <CAC4RtVBuET9h-QHEtS=genmJnJ6bfKk=KD0bTJQvZJApAsY_ww@mail.gmail.com> <01OGEYVDDGU2000058@mauve.mrochek.com>
In-Reply-To: <01OGEYVDDGU2000058@mauve.mrochek.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]); Thu, 07 Jun 2012 22:09:28 -0700 (PDT)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2012 05:09:29 -0000

On 6/8/2012 4:19 AM, Ned Freed wrote:
> The problem here is that it's possible to think about MTA states in a lot of
> different ways, some of which don't map well if at all onto actual
> implementations. While the risk is low, I think expert review is needed to make
> sure things stay sane.

Ned,

You are of course right that one can get the choice(s) very wrong. And 
I've no trouble believe that some form of getting it wrong could have a 
toxic effect.  My question is what the actual damage of that is likely 
to be in the real world, /over time/.

That is, not just what is the likelihood that a site will use one of 
these potentially damaging values, but what is the likelihood that it 
will persist?

The world of MTA software developers is small enough to prompt me to 
believe that even if one of them gets this seriously wrong, a) it will 
get corrected quickly through natural forces, or b) they will have a 
plethora of other serious problems with their software and worrying 
about this one isn't worth the effort.

In contrast, Expert Review imposes quite an expensive /ongoing/ load on 
/us/, for every registration, nevermind on the folk who want to do the 
registering.

I see that as a very poor value proposition, especially in terms of 
community resources.  Which is why I favor FCFS.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net