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

ALAIN AINA <aalain@trstech.net> Tue, 14 August 2012 12:22 UTC

Return-Path: <aalain@afribone.trstech.net>
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 EC0F021F8627 for <ietf@ietfa.amsl.com>; Tue, 14 Aug 2012 05:22:35 -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 NDMhcosIRYDr for <ietf@ietfa.amsl.com>; Tue, 14 Aug 2012 05:22:35 -0700 (PDT)
Received: from afribone.trstech.net (afribone.trstech.net [196.200.57.137]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1F21F8534 for <ietf@ietf.org>; Tue, 14 Aug 2012 05:22:34 -0700 (PDT)
Received: from [80.248.74.18] (helo=[192.168.3.5]) by afribone.trstech.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <aalain@afribone.trstech.net>) id 1T1G8j-0007aj-Cc for ietf@ietf.org; Tue, 14 Aug 2012 12:22:31 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: ALAIN AINA <aalain@trstech.net>
In-Reply-To: <E521F97C-24C8-4D2E-9471-844FCD69212C@standardstrack.com>
Date: Tue, 14 Aug 2012 16:21:58 +0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <755EBCEF-6064-4BEB-920F-0FBFB4592BBB@trstech.net>
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> <E521F97C-24C8-4D2E-9471-844FCD69212C@standardstrack.com>
To: IETF <ietf@ietf.org>
X-Mailer: Apple Mail (2.1084)
Sender: aalain@afribone.trstech.net
X-SA-Exim-Connect-IP: 80.248.74.18
X-SA-Exim-Mail-From: aalain@afribone.trstech.net
Subject: Re: [iucg] Last Call: Modern Global Standards Paradigm
X-SA-Exim-Version: 4.2.1 (built Thu, 21 Oct 2010 18:52:38 +0000)
X-SA-Exim-Scanned: Yes (on afribone.trstech.net)
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 12:22:36 -0000

I will say "there are potential uses of the  ITU for good".

--Alain

On Aug 14, 2012, at 6:26 AM, Eric Burger wrote:

> +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
>> 
>