Re: [iucg] Last Call: Modern Global Standards Paradigm

Eric Burger <eburger-l@standardstrack.com> Tue, 14 August 2012 02:26 UTC

Return-Path: <eburger-l@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A85F21F84C8 for <ietf@ietfa.amsl.com>; Mon, 13 Aug 2012 19:26:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+Cc7toAP+kF for <ietf@ietfa.amsl.com>; Mon, 13 Aug 2012 19:26:16 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1921F84A0 for <ietf@ietf.org>; Mon, 13 Aug 2012 19:26:16 -0700 (PDT)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:57416 helo=[192.168.15.138]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger-l@standardstrack.com>) id 1T16pZ-0005kx-DA for ietf@ietf.org; Mon, 13 Aug 2012 19:26:05 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [iucg] Last Call: Modern Global Standards Paradigm
From: Eric Burger <eburger-l@standardstrack.com>
In-Reply-To: <F2E0F8B862341F3DC407A2DA@JcK-HP8200.jck.com>
Date: Mon, 13 Aug 2012 22:26:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E521F97C-24C8-4D2E-9471-844FCD69212C@standardstrack.com>
References: <DF4B6630-8BD1-4BFF-B872-99619B06FCF2@ietf.org> <CAMm+Lwio8=EyW-=LZE8BA4=6N=H4f7a1Nycg25LxB920ceZ6JA@mail.gmail.com> <1117B161-0454-4570-96BF-4045E4DB62A8@standardstrack.com> <276B7D303A96E840D2F95107@JcK-HP8200.jck.com> <CAMm+LwjL=tnYrtmHkV+=+VeOCo+1PjAu+pW0LnUyHYhVX_pPZA@mail.gmail.com> <C01C22690CE178AF8C2E52F7@JcK-HP8200.jck.com> <20120813012310.9F01A21F861E@ietfa.amsl.com> <5028C4C8.40508@tana.it> <F2E0F8B862341F3DC407A2DA@JcK-HP8200.jck.com>
To: IETF list <ietf@ietf.org>
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 - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2012 02:26:17 -0000

+1. The ITU is not evil. It just is not the right place for Internet standards development. As John points out, there are potential uses of the ITU-T for good.

On Aug 13, 2012, at 10:50 AM, John C Klensin wrote:

> 
> 
> --On Monday, August 13, 2012 11:11 +0200 Alessandro Vesely
> <vesely@tana.it> wrote:
> 
>> ...
>> FWIW, I'd like to recall that several governments endorse IETF
>> protocols by establishing Internet based procedures for
>> official communications with the relevant PA, possibly giving
>> them legal standing.  Francesco Gennai presented a brief
>> review of such procedures[*] at the APPSAWG meeting in Paris.
>> At the time, John Klensin suggested that, while a more
>> in-depth review of existing practices would be appreciated,
>> the ITU is a more suitable body for the standardization of a
>> unified, compatible protocol for certified email, because of
>> those governmental involvements.
>> 
>> [*]
>> 
> http://www.ietf.org/proceedings/83/slides/slides-83-appsawg-1.pdf
> 
> Alessandro,
> 
> Please be a little careful about context, as your sequence of
> comments above could easily be misleading.  
> 
> For the very specific case of email certified by third parties,
> especially where there is a requirement for worldwide
> recognition (the topic of the talk and slides you cited), the
> biggest problem has, historically, been an administrative and
> policy one, not a technical standards issue.  We know how to
> digitally sign email in several different ways -- there is
> actually no shortage of standards.   While additional standards
> are certainly possible, more options in the absence of
> compelling need almost always reduces practical
> interoperability.  Perhaps the key question in the certified
> mail matter is who does the certifying and why anyone else
> should pay attention.  The thing that makes that question
> complicated was famously described by Jeff Schiller (I believe
> while he was still IETF Security AD) when he suggested that
> someone would need to be insane to issue general-purpose
> certificates that actually certified identity unless they were
> an entity able to invoke sovereign immunity, i.e., a government.
> 
> For certified email (or certified postal mail), your ability to
> rely on the certification in, e.g., legal matters ultimately
> depends on your government being willing to say something to you
> like "if you rely on this in the following ways, we will protect
> you from bad consequences if it wasn't reliable or accurate".
> If you want the same relationship with "foreign" mail, you still
> have to rely on your government's assertions since a foreign
> government can't do a thing for you if you get into trouble.
> That, in turn, requires treaties or some sort of bilateral
> agreements between the governments (for postal mail, some of
> that is built into the postal treaties).  
> 
> International organizations, particularly UN-based ones, can
> serve an important role in arranging such agreements and
> possibly even in being the repository organization for the
> treaties.  In the particular case of certified email, the ITU
> could reasonably play that role (although it seems to me that a
> very strong case could be made for having the UPU do it instead
> by building on existing foundations).
> 
> But that has nothing to do with the development of technical
> protocol standards.  Historical experience with development of
> technical standards by governmental/legislative bodies that then
> try to mandate their use has been almost universally poor and
> has often included ludicrous results.
> 
> A similar example arises with the spam problem.  There are many
> technical approaches to protecting the end user from spam
> (especially malicious spam) and for facilitating the efforts of
> mail delivery service providers and devices to apply those
> protective mechanisms.  Some of them justify technical standards
> that should be worked out in open forums that make their
> decisions on open and technical bases.  But, if one wants to
> prevent spam from imposing costs on intended recipients or third
> parties, that becomes largely a law-making and law enforcement
> problem, not a technical one.  If countries decide that they
> want to prevent spam from being sent, or to punish the senders,
> a certain amount of international cooperation (bilateral or
> multilaterial) is obviously going to be necessary.   As with the
> UPU and email certification, there might be better agencies or
> forums for discussion than the ITU or there might not.  But it
> isn't a technical protocol problem that the IETF is going to be
> able to solve or should even try to address, at least without a
> clear and actionable problem statement from those bodies.
> 
> I do believe that the ITU can, and should, serve a useful role
> in the modern world.  The discussion above (and some of the work
> of the Development and Radio Sectors) are good illustrations.
> But those cases have, as far as I can tell, nothing to do with
> the proposed statement, which is about the development and
> deployment of technical protocol standards.
> 
> regards,
>    john
>