Re: placing a dollar value on IETF IP.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: placing a dollar value on IETF IP.
On Oct 28, 2008, at 10:12 AM, John C Klensin wrote:
One could, of course, make many of the same observations about
replacing SMTP and/or today's Internet mail formats with some newlyFrom ietf-bounces at ietf.org Wed Oct 29 11:27:20 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 904DC28C3C5;
Wed, 29 Oct 2008 11:27:20 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7F55728C3BA
for <ietf at core3.amsl.com>; Wed, 29 Oct 2008 11:27:19 -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.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id qOX3Wa3MjVEV for <ietf at core3.amsl.com>;
Wed, 29 Oct 2008 11:27:18 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175])
by core3.amsl.com (Postfix) with ESMTP id 93FA128C3C5
for <ietf at ietf.org>; Wed, 29 Oct 2008 11:27:18 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so130532wfd.31
for <ietf at ietf.org>; Wed, 29 Oct 2008 11:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:cc:message-id:from:to
:in-reply-to:content-type:content-transfer-encoding:mime-version
:subject:date:references:x-mailer;
bh=LMSGyPCW4u74Ag/JP5mIhYMBPS3PECiw2gyKZfIp30U=;
b=km4G3u/G+PwQGgSI9faAQl1SxPHjmaYiukahEFojK868XgKs4gEoiWV6ps/2WJlcib
t+n4uc63CCLLzABESAnthqgg7tPJolAAoUrr2xLGbg8o6kaGxOygMoUwPBq3Um78Qb2d
SENjOuL8SblLJ5zIxkqSZXVmwAJ83zhxXY8Ho=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=cc:message-id:from:to:in-reply-to:content-type
:content-transfer-encoding:mime-version:subject:date:references
:x-mailer;
b=PxgTCM46kH/IWTdQl6wuDOhjiTUlXe5HCHkpcFLYGpVwna9y96ixdVTFvIuR4n2vTf
x5wXeoygYqN3s6gjnuupOM3RlyZbq2h9T5SndaDv7xVDm3G8zw0Nu3srKLI6WLpvAwmx
Fs+hG2Kplz31FtRtiV+n/9sekHeK+kBShNowE=
Received: by 10.142.44.11 with SMTP id r11mr327187wfr.59.1225304837622;
Wed, 29 Oct 2008 11:27:17 -0700 (PDT)
Received: from SJC-Office-NAT-220.mail-abuse.org
(SJC-Office-NAT-220.mail-abuse.org [168.61.10.220])
by mx.google.com with ESMTPS id 24sm444984wff.17.2008.10.29.11.27.15
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Wed, 29 Oct 2008 11:27:16 -0700 (PDT)
Message-Id: <6CF6ABD9-E6F9-4E0D-AA64-C2B898FFE871 at gmail.com>
From: Doug Otis <doug.mtview at gmail.com>
To: John C Klensin <john-ietf at jck.com>
In-Reply-To: <5A2081EFE709E9ABCC734983 at p3.int.jck.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: placing a dollar value on IETF IP.
Date: Wed, 29 Oct 2008 11:27:13 -0700
References: <00be01c935ed$14719880$6601a8c0 at tsg1>
<517bf110810240842m7076690fic47e8bcf36c324ee at mail.gmail.com>
<8c99930d0810251453q6c893a1ak6122b387a2112fea at mail.gmail.com>
<010f01c937ce$a9978540$6401a8c0 at tsg1>
<8c99930d0810280653n43818524t7fa94bc8c992ddbc at mail.gmail.com>
<2788466ED3E31C418E9ACC5C316615572FFAD7 at mou1wnexmb09.vcorp.ad.vrsn.com>
<5A2081EFE709E9ABCC734983 at p3.int.jck.com>
X-Mailer: Apple Mail (2.929.2)
Cc: tbray at textuality.com, IETF Discussion <ietf at ietf.org>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org
On Oct 28, 2008, at 10:12 AM, John C Klensin wrote:
One could, of course, make many of the same observations about
replacing SMTP and/or today's Internet mail formats with some newly-
inv-
invented and improved system, replacing HTTP with something more
elegantly designed based on what we know about computer systems
today, etc., as well as failure to harmonize residential supply
voltages around the world. Whether the problem is one of network
effects or the related one of the costs of replacing/ converting a
large installed base, the consequences are the same: mere
incremental technical superiority is almost never sufficient to
motivate an incompatible change.
Agreed. However, the issue is often not about compatibility, or
comparative adoption costs. Take an extension to DKIM as an example.
The proposed ADSP extension imposes an incompatible change to support
an Authentication-Results header which only identifies the From header
field as having been authenticated. An identical looking result can
be obtained when DKIM-ADSP is replaced with Sender-ID.
In the case of ADSP, a compliant DKIM signature MUST be on behalf of
the From header field, even when a different identity had been
authenticated when signing. In the case of Sender-ID, no email-
address is authenticated, and yet the appearance of an email-address
being authenticated is given. Neither DKIM-ADSP or Sender-ID offer
authenticated the email-addresses. It is harder to SELL a service
that adds a header that says "invalidation-results". Rather than
identifying an email-address as being INVALID with a moderate level of
assurance, this header indicates PASS under the guise of
authentication, but without there being either safe or reasonable
levels of assurance to make the assertion.
This clearly is not about compatibility or relative adoption costs.
These two approaches both represent incompatible changes where better
alternatives do not impose additional cost. Sender-ID's macro
expansion of DNS records can cause hundreds of subsequent DNS
transactions generated by recipients of spam, along with SMTP's
inability comply with Sender-ID's path registration methods. ADSP's
subversion of DKIM's "on-behalf-of" will no longer reflect what was
authenticated. Both Sender-ID and ADSP have the potential for
imposing significant future costs, incompatibilities, and damages.
The standardization process is being influenced by large providers
wanting to both blame shift and to overstate the offering of their
services which puts recipients at significant risk. Whenever an
email-address owner finds themselves blocked, it unfairly becomes
their fault for trusting a provider that never promised to
authenticate PRA or From email-addresses. IETF's role should be to
ensure dangerously misleading schemes are not endorsed, even when
desired by those working for influential parties within the IETF. A
judgement of merit should not be limited to technical excellence, but
should still include a consideration of the greater good. Perhaps
something similar to the Hippocratic oath to abstain from whatever is
deleterious and mischievous. Be the IETF and not the IVTF. : )
-Doug
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ented and improved system, replacing HTTP with something more
elegantly designed based on what we know about computer systems
today, etc., as well as failure to harmonize residential supply
voltages around the world. Whether the problem is one of network
effects or the related one of the costs of replacing/ converting a
large installed base, the consequences are the same: mere
incremental technical superiority is almost never sufficient to
motivate an incompatible change.
Agreed. However, the issue is often not about compatibility, or
comparative adoption costs. Take an extension to DKIM as an example.
The proposed ADSP extension imposes an incompatible change to support
an Authentication-Results header which only identifies the From header
field as having been authenticated. An identical looking result can
be obtained when DKIM-ADSP is replaced with Sender-ID.
In the case of ADSP, a compliant DKIM signature MUST be on behalf of
the From header field, even when a different identity had been
authenticated when signing. In the case of Sender-ID, no email-
address is authenticated, and yet the appearance of an email-address
being authenticated is given. Neither DKIM-ADSP or Sender-ID offer
authenticated the email-addresses. It is harder to SELL a service
that adds a header that says "invalidation-results". Rather than
identifying an email-address as being INVALID with a moderate level of
assurance, this header indicates PASS under the guise of
authentication, but without there being either safe or reasonable
levels of assurance to make the assertion.
This clearly is not about compatibility or relative adoption costs.
These two approaches both represent incompatible changes where better
alternatives do not impose additional cost. Sender-ID's macro
expansion of DNS records can cause hundreds of subsequent DNS
transactions generated by recipients of spam, along with SMTP's
inability comply with Sender-ID's path registration methods. ADSP's
subversion of DKIM's "on-behalf-of" will no longer reflect what was
authenticated. Both Sender-ID and ADSP have the potential for
imposing significant future costs, incompatibilities, and damages.
The standardization process is being influenced by large providers
wanting to both blame shift and to overstate the offering of their
services which puts recipients at significant risk. Whenever an
email-address owner finds themselves blocked, it unfairly becomes
their fault for trusting a provider that never promised to
authenticate PRA or From email-addresses. IETF's role should be to
ensure dangerously misleading schemes are not endorsed, even when
desired by those working for influential parties within the IETF. A
judgement of merit should not be limited to technical excellence, but
should still include a consideration of the greater good. Perhaps
something similar to the Hippocratic oath to abstain from whatever is
deleterious and mischievous. Be the IETF and not the IVTF. : )
-Doug
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
