Re: [ietf-dkim] A more fundamental SSP axiom

Dave Crocker <dhc@dcrocker.net> Wed, 02 August 2006 17:08 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KD6-0002Gu-Rg for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 13:08:44 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8KD5-00021L-FC for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 13:08:44 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k72H8WSg000973; Wed, 2 Aug 2006 10:08:33 -0700
Received: from [192.168.0.3] (adsl-68-122-118-34.dsl.pltn13.pacbell.net [68.122.118.34]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k72H8OIx000948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Wed, 2 Aug 2006 10:08:25 -0700
Message-ID: <44D0DBE8.6040205@dcrocker.net>
Date: Wed, 02 Aug 2006 10:07:52 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: IETF DKIM WG <ietf-dkim@mipassoc.org>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
References: <20060802163444.1D7815CC56D@mailout00.controlledmail.com>
In-Reply-To: <20060802163444.1D7815CC56D@mailout00.controlledmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Songbird: Clean, Clean
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a


Scott Kitterman wrote:
> On Wed, 02 Aug 2006 08:28:20 -0500 wayne <wayne@schlitt.net> wrote:
>> In <44D03872.5090601@dcrocker.net> Dave Crocker <dhc@dcrocker.net> writes:
>>> For this initial round of SSP, the wording of the Corollary probably 
> needs to be:
>>>     Information that is not widely viewed by receivers as essential 
> doesn't
>>>     belong in SSP.
>> I think this is very short sighted.  It is rare that a protocol gets
>> more than one or two revisions.  ...
>> I think it is very unlikely that we will get a chance to update DKIM
>> and have that update receive wide adoption.
>>
>> There certainly should be a cost/benefit analysis done.  If a feature
>> is costly to add and has little obvious benefit to both senders and
>> receivers, then, yeah, drop it.  ...
>>
> +1


1. The phrase "for the initial round" is explicitly stating that the goal is
near-term.  From one perspective, that is the very definition of short-sighted.
 In other words, that is exactly what I intended, although of course not with
the negative connotation of the latter term.

2. Statements about what works and doesn't work, for adoption of Internet
standards should come with some sort of empirical basis.  My own basis is that
every Internet protocol that has succeeded has begun with a modest list of
functions and has grown from there.  (Yes, I said every single one.)

3. A claim that we only ever get one or two versions of a protocol is
demonstrably false.  More importantly, it a) misses the model of incremental
extension that has been so successful for so many Internet protocols, and b)
seems to have a remarkably high correlation with the production of large,
complex, cumbersome protocols that get released late, never get fielded or never
work very well... (IMO)


Bottom Line:

     Although it is essential that a protocol specification be deployed only
after due deliberation, it is equally essential that it be concise, coherent and
compelling.

     In other words the market needs to understand it and needs to believe its
adoption is important... for the near term.

All of this argues strongly for the criterion I suggested.


d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html