From nobody Tue Jul 1 04:31:48 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE441A0069; Tue, 1 Jul 2014 04:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHUOuqpeL76O; Tue, 1 Jul 2014 04:31:38 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1171A0049; Tue, 1 Jul 2014 04:31:34 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s61BVWSD014809; Tue, 1 Jul 2014 12:31:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s61BVViE014803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Jul 2014 12:31:31 +0100 From: "Adrian Farrel" To: , , Date: Tue, 1 Jul 2014 12:31:27 +0100 Message-ID: <059b01cf9520$000e4120$002ac360$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+VH/4Hn5+9+xKfQ4i6x6LNtwECwg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20790.006 X-TM-AS-Result: No--1.434-10.0-31-10 X-imss-scan-details: No--1.434-10.0-31-10 X-TMASE-MatchedRID: F//CmDt69uSQBxlKj0umu6gJdIabkq8Lh8Ytn75ClDOsIMnczyxe539M UW3noMgm9PpTwwvqom+Rk6XtYogiarQ/aqQZTRfK0C1sQRfQzEHEQdG7H66TyHEqm8QYBtMOYmq yWB9nZ34xJfjyPmYWsGa4pFM07EFRipnufb7tBUIl4nVYwIRGQa1+3JijYrAOMqmhG/M0o4/0MH wzu2JowH/sHqJVh3aulExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/FFdyg1owudO8WBN-_eK4cNS288s Cc: iesg@ietf.org Subject: [Internetgovtech] NTIA/IANA transition coordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 11:31:39 -0000 The IESG (minus any ADs who have put their names in as candidates) has completed its selection of two IETF representatives to the ICANN consultative process on the transition of IANA from NTIA stewardship. Alissa Cooper and Jari Arkko have been selected. The IESG thanks everyone who put their names forward for their time and their willingness to serve. Thanks, Adrian Farrel (for the IESG) From nobody Tue Jul 1 11:01:20 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A91B284E for ; Tue, 1 Jul 2014 11:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0aKAoTqD4Fo for ; Tue, 1 Jul 2014 11:01:14 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1C41B283E for ; Tue, 1 Jul 2014 11:01:14 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E8BEB8A031; Tue, 1 Jul 2014 18:01:12 +0000 (UTC) Date: Tue, 1 Jul 2014 14:01:08 -0400 From: Andrew Sullivan To: ianatransition@icann.org, ianaplan@ietf.org, internetgovtech@iab.org Message-ID: <20140701180108.GA51920@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0pQw15tvsjT24usM-wF_5EmCtQE Subject: [Internetgovtech] NTIA/IANA transition co-ordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:01:16 -0000 Dear colleagues, As part of the NTIA/IANA transition, the IAB is to select two people to serve as members of the co-ordination group. The IAB (less those whose names were under consideration for appointment) deliberated, and hereby appoints Russ Housley and Lynn St. Amour. Russ is an IAB member and Chair of the IAB, and is a member of the IAB's IANA Evolution program. Lynn continued as a member of the IAB's IANA Evolution program after stepping down recently as CEO of ISOC. We thank both Russ and Lynn for being willing to serve, and thank others who were willing to be considered. The appointments have been communicated to ICANN in its role as convenor of the process. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 1 11:13:15 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68A51B286A for ; Tue, 1 Jul 2014 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pkLIaN9-dhE for ; Tue, 1 Jul 2014 11:12:57 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DC91B2888 for ; Tue, 1 Jul 2014 11:12:54 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so8111473qaq.10 for ; Tue, 01 Jul 2014 11:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g2LICjVoErxYrTVLo8EZQ9Ka2DL5R9bS7qoDSjmEFUE=; b=suf6q4Wc2jIPfCiBKJOjDbkCw7kcYRBhVMCX8zFjCG0Udv+TMUCqqpg7lOY/raXnW2 Z26FHJB0sZQ7dMpLrr3RDa+0Otqlu+ICk2d6YJG6yjd3fqM+8h/VluE3c2JfG5xmCIW3 7F0VBbeVycTWqVz1gN8MHBbpMRXhCP7xNtdzv3OAKQaDeOuoFVyvSC5F2VQUyJ2z3bPZ 9fAvwxSyk/roKiOodH8+s2EnGyuirVy8/IhSyA6b8KM0GNMQYHTZZMGvT/AqdNdqPysa a+O/b5UoInNDy94hJJpsw3ydKs7imc58717w8r/OOvWL0V42f0vioabntF+BErIMcIwo PT4g== MIME-Version: 1.0 X-Received: by 10.140.94.225 with SMTP id g88mr69550011qge.101.1404238373435; Tue, 01 Jul 2014 11:12:53 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Tue, 1 Jul 2014 11:12:53 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Tue, 1 Jul 2014 11:12:53 -0700 (PDT) In-Reply-To: <20140701180108.GA51920@mx1.yitter.info> References: <20140701180108.GA51920@mx1.yitter.info> Date: Tue, 1 Jul 2014 19:12:53 +0100 Message-ID: From: Seun Ojedeji To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a113a7f166dbd9d04fd25b9c5 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/rcsjme1jEs9-sdbR-TrOMCwEiu4 Cc: ianaplan@ietf.org, internetgovtech@iab.org, ianatransition@icann.org Subject: Re: [Internetgovtech] NTIA/IANA transition co-ordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:12:58 -0000 --001a113a7f166dbd9d04fd25b9c5 Content-Type: text/plain; charset=UTF-8 Thanks for the information. Your message and the one received earlier today just triggered a thought; is there really a major difference between IAB and IETF. However as I think about it, the TOR of the group perhaps brings comfort. Cheers! sent from Google nexus 4 kindly excuse brevity and typos. On 1 Jul 2014 19:01, "Andrew Sullivan" wrote: > Dear colleagues, > > As part of the NTIA/IANA transition, the IAB is to select two people > to serve as members of the co-ordination group. The IAB (less those > whose names were under consideration for appointment) deliberated, and > hereby appoints Russ Housley and Lynn St. Amour. > > Russ is an IAB member and Chair of the IAB, and is a member of the > IAB's IANA Evolution program. Lynn continued as a member of the IAB's > IANA Evolution program after stepping down recently as CEO of ISOC. > > We thank both Russ and Lynn for being willing to serve, and thank > others who were willing to be considered. > > The appointments have been communicated to ICANN in its role as > convenor of the process. > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > --001a113a7f166dbd9d04fd25b9c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for the information. Your message and the one receive= d earlier today just triggered a thought; is there really a major differenc= e between IAB and IETF.
However as I think about it, the TOR of the group perhaps brings comfort.

Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.

On 1 Jul 2014 19:01, "Andrew Sullivan"= <ajs@anvilwalrusden.com&g= t; wrote:
Dear colleagues,

As part of the NTIA/IANA transition, the IAB is to select two people
to serve as members of the co-ordination group. =C2=A0The IAB (less those whose names were under consideration for appointment) deliberated, and
hereby appoints Russ Housley and Lynn St. Amour.

Russ is an IAB member and Chair of the IAB, and is a member of the
IAB's IANA Evolution program. =C2=A0Lynn continued as a member of the I= AB's
IANA Evolution program after stepping down recently as CEO of ISOC.

We thank both Russ and Lynn for being willing to serve, and thank
others who were willing to be considered.

The appointments have been communicated to ICANN in its role as
convenor of the process.

Best regards,

Andrew

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech
--001a113a7f166dbd9d04fd25b9c5-- From nobody Tue Jul 1 11:28:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE181A0549 for ; Tue, 1 Jul 2014 08:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWGEotO7L50j for ; Tue, 1 Jul 2014 08:40:20 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A131A0370 for ; Tue, 1 Jul 2014 08:40:19 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id p9so6936739lbv.26 for ; Tue, 01 Jul 2014 08:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DtEFWANQ38co5a+Cvd8do7hzVqzqGTkDjcd8ATbgvV0=; b=GbjXsAafm9GTI5cEXsZ5OQ8+BBiT6WSm43/aM14oHy+ovsS2khnMNxWj4QRsMoRVEa ZgC1PjbEUqbNIsVUpcDhs/jex6FVL2vSMChvMzM1KclZCGgUOoDmtlF1tkB1PARH6CNY CvpO1zCXyfM/09lj/NUmJXBfaXOBzoGfVhQ9LtJp9ViLAjnuYjD2DrhZwc6z7SUUf0ud 8jIpozoSkXFxQgfW4h3SiZ/oSf51Xm4bOP4ML5GeYpPk5DMrKq7m8upQjUBZGEvQUbSQ rIe0C8+hAlwckhtZ32TgpQJIN89AFFKoJb9EX1uWvNWRvjMHwNqSQXO+KYYPq/O/h8mG /B4A== MIME-Version: 1.0 X-Received: by 10.152.19.229 with SMTP id i5mr2382774lae.60.1404229217960; Tue, 01 Jul 2014 08:40:17 -0700 (PDT) Received: by 10.114.245.229 with HTTP; Tue, 1 Jul 2014 08:40:17 -0700 (PDT) In-Reply-To: <059b01cf9520$000e4120$002ac360$@olddog.co.uk> References: <059b01cf9520$000e4120$002ac360$@olddog.co.uk> Date: Tue, 1 Jul 2014 18:40:17 +0300 Message-ID: From: Richard Omolo To: adrian@olddog.co.uk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/i4tx_73XANkS1LizjXRDHWuSBCE X-Mailman-Approved-At: Tue, 01 Jul 2014 11:28:15 -0700 Cc: ianaplan@ietf.org, internetgovtech@iab.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [Internetgovtech] NTIA/IANA transition coordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 15:40:21 -0000 Hi Thanks for the good initiative. I am late but I would have like to be actively be in the team. Congrats. Richard Omolo Bondo City, Kenya On 7/1/14, Adrian Farrel wrote: > The IESG (minus any ADs who have put their names in as candidates) has > completed > its selection of two IETF representatives to the ICANN consultative process > on > the transition of IANA from NTIA stewardship. > > Alissa Cooper and Jari Arkko have been selected. > > The IESG thanks everyone who put their names forward for their time and > their > willingness to serve. > > Thanks, > Adrian Farrel (for the IESG) > > From nobody Tue Jul 1 11:28:21 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7E91A03BD for ; Tue, 1 Jul 2014 11:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jq4AeZ7pqaY for ; Tue, 1 Jul 2014 11:05:02 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22F71A03C3 for ; Tue, 1 Jul 2014 11:05:01 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db12so9897003veb.7 for ; Tue, 01 Jul 2014 11:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2bR5jm55hiR3UvGy3E5/j8DJLd5OHHxJ9e4wfcPFD/8=; b=GdrXoI2bcVvo2QHtndykG6WqQ0dCnSV+zV7ThwFIyJETq1Q1D+YUJTi23E1FQ994Yx kHa+kLK1+MQWWsVQrKaK/vxfS0niOeKfHZp/V+XIrx0r2HYf8QCIaJy31c7KHy7r3ezv ii68mt+Ga5mIYwkHi6moZT96TIEK+EqMMHIPVpUhMSmOxOJpTqFDdI4VNPXdTE3o2UmH nBugeROAPGNbLwLRjF/rE8jQJ+p/1Wm/ps8jfWvbTqH4XLgyIzd1+PUijOZJhpOU5z5D uO//beGB/9ReYfvijsQJLdy9+60e/DmSlnaWZxyCfBjisyQkymvW5o0xiX+Y7htvssoB KZKA== MIME-Version: 1.0 X-Received: by 10.58.186.172 with SMTP id fl12mr1834498vec.39.1404237900661; Tue, 01 Jul 2014 11:05:00 -0700 (PDT) Received: by 10.58.49.164 with HTTP; Tue, 1 Jul 2014 11:05:00 -0700 (PDT) In-Reply-To: <20140701180108.GA51920@mx1.yitter.info> References: <20140701180108.GA51920@mx1.yitter.info> Date: Tue, 1 Jul 2014 19:05:00 +0100 Message-ID: From: Sivasubramanian M To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b6dc4fc3fcb5f04fd259d92 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8AOswf-ik33zwq52_OVO2sphxFU X-Mailman-Approved-At: Tue, 01 Jul 2014 11:28:15 -0700 Cc: ianaplan@ietf.org, internetgovtech@iab.org, "ianatransition@icann.org" Subject: Re: [Internetgovtech] [IANAtransition] NTIA/IANA transition co-ordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:05:11 -0000 --047d7b6dc4fc3fcb5f04fd259d92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BCongratulations to Russ Housley and Lynn St.Amour. This is good fo= r IANA. =E2=80=8B Sivasubramanian M On Tue, Jul 1, 2014 at 7:01 PM, Andrew Sullivan wrote: > Dear colleagues, > > As part of the NTIA/IANA transition, the IAB is to select two people > to serve as members of the co-ordination group. The IAB (less those > whose names were under consideration for appointment) deliberated, and > hereby appoints Russ Housley and Lynn St. Amour. > > Russ is an IAB member and Chair of the IAB, and is a member of the > IAB's IANA Evolution program. Lynn continued as a member of the IAB's > IANA Evolution program after stepping down recently as CEO of ISOC. > > We thank both Russ and Lynn for being willing to serve, and thank > others who were willing to be considered. > > The appointments have been communicated to ICANN in its role as > convenor of the process. > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > ianatransition mailing list > ianatransition@icann.org > https://mm.icann.org/mailman/listinfo/ianatransition > --047d7b6dc4fc3fcb5f04fd259d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BCongratulations to= Russ Housley and Lynn St.Amour. This is good for IANA. =E2=80=8B



On Tue, Jul 1, 2014 at 7:01 PM, Andrew S= ullivan <ajs@anvilwalrusden.com> wrote:
Dear colleagues,

As part of the NTIA/IANA transition, the IAB is to select two people
to serve as members of the co-ordination group. =C2=A0The IAB (less those whose names were under consideration for appointment) deliberated, and
hereby appoints Russ Housley and Lynn St. Amour.

Russ is an IAB member and Chair of the IAB, and is a member of the
IAB's IANA Evolution program. =C2=A0Lynn continued as a member of the I= AB's
IANA Evolution program after stepping down recently as CEO of ISOC.

We thank both Russ and Lynn for being willing to serve, and thank
others who were willing to be considered.

The appointments have been communicated to ICANN in its role as
convenor of the process.

Best regards,

Andrew

--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
ianatransition mailing list
ianatransition@icann.org https://mm.icann.org/mailman/listinfo/ianatransition

--047d7b6dc4fc3fcb5f04fd259d92-- From nobody Tue Jul 1 20:11:38 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5381A03EE for ; Tue, 1 Jul 2014 20:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmgFi0pWjE71 for ; Tue, 1 Jul 2014 20:11:32 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 460C21A03C7 for ; Tue, 1 Jul 2014 20:11:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 523CB1E5E90; Tue, 1 Jul 2014 20:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rzZu1PAwezP; Tue, 1 Jul 2014 20:11:22 -0700 (PDT) Received: from [192.168.7.160] (ip-64-134-71-47.public.wayport.net [64.134.71.47]) by c8a.amsl.com (Postfix) with ESMTPSA id CEAE11E5E8E; Tue, 1 Jul 2014 20:11:21 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: IETF Chair Date: Tue, 1 Jul 2014 23:11:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> To: ietf-announce@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/p92IDPtOjy_67TJdTZghNPU2nIM Cc: internetgovtech@iab.org, IETF discussion list Subject: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internetgovtech@iab.org List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 03:11:34 -0000 Last week, some of us visited the ICANN meeting (at the Hilton London = Metropole!). Here are a few reflections from a session that I moderated = together with Patrik F=E4ltstr=F6m on this topic: = http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardship= / Jari Arkko IETF Chair From nobody Tue Jul 1 23:05:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56C41B28D0 for ; Tue, 1 Jul 2014 23:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeV6-rbWtTQ7 for ; Tue, 1 Jul 2014 23:05:30 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12241B28D1 for ; Tue, 1 Jul 2014 23:05:30 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id q108so4258259qgd.6 for ; Tue, 01 Jul 2014 23:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fJQyI8b71eD8GYVGPHJ9cUsYA8Vm6Y9cOGpU6w72mb4=; b=Apo9sHjDeb98uIXwdfw1Acc1AeH2D7JB02GZi/y4/6bjtpfVmLF2x/nPFMfUsyTiAd yZ+j/hPpLAY0/OmrsseNgi/zYuIopG8d6MIjXVXt0LKdQlNXt1mTaP4zF5tYITTtPyi5 O9ueDtWtlCETrWjIrQKcQjJsjJ+Y5SIXkcYEnZ4HSopRfS6DeB4gSn096FsM8xJ+stF8 42UMM3ppL3yHshowVtkAatigiDxxiEthxUiBGSPaoyhxAkt+aqwAd6VXQCnJgEDH0n28 vbvlElP8RNGaV/OVWqcL1gvpOlQKE0sNq/DspPNK27sEytFUsCspnn1bqAm9OR7TKSkv Dlyg== MIME-Version: 1.0 X-Received: by 10.140.81.16 with SMTP id e16mr74227727qgd.110.1404281128924; Tue, 01 Jul 2014 23:05:28 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Tue, 1 Jul 2014 23:05:28 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Tue, 1 Jul 2014 23:05:28 -0700 (PDT) In-Reply-To: References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> Date: Wed, 2 Jul 2014 07:05:28 +0100 Message-ID: From: Seun Ojedeji To: internetgovtech@iab.org Content-Type: multipart/alternative; boundary=001a11c119e2dabfbd04fd2fad89 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/B_2viOw6cQvvTXCiPaL3oUhz6cY Cc: IETF discussion list , ietf-announce@ietf.org Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 06:05:31 -0000 --001a11c119e2dabfbd04fd2fad89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the share Jari, it was good that the bullet point 1 item in the summary achieved consensus ;) Cheers! sent from Google nexus 4 kindly excuse brevity and typos. On 2 Jul 2014 04:12, "IETF Chair" wrote: Last week, some of us visited the ICANN meeting (at the Hilton London Metropole!). Here are a few reflections from a session that I moderated together with Patrik F=C3=A4ltstr=C3=B6m on this topic: http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardship/ Jari Arkko IETF Chair _______________________________________________ Internetgovtech mailing list Internetgovtech@iab.org https://www.iab.org/mailman/listinfo/internetgovtech --001a11c119e2dabfbd04fd2fad89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for the share Jari, it was good that the bullet point= 1 item in the summary achieved consensus ;)

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.

On 2 Jul 2014 04:12, "IETF Chair" <= chair@ietf.org> wrote:
Last week, some of us visited the ICANN meeting (at the Hilton London Metro= pole!). Here are a few reflections from a session that I moderated together= with Patrik F=C3=A4ltstr=C3=B6m on this topic:

http://www.ietf.org/blog/2014/07/icann-and-t= ransition-of-ntias-stewardship/

Jari Arkko
IETF Chair

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech
--001a11c119e2dabfbd04fd2fad89-- From nobody Wed Jul 2 03:19:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81FD1A000D for ; Wed, 2 Jul 2014 03:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57bWMrrcHQ3f for ; Wed, 2 Jul 2014 03:19:50 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC1D1B28E7 for ; Wed, 2 Jul 2014 03:19:50 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so9748015qcv.10 for ; Wed, 02 Jul 2014 03:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JfyQ4XKQ/8jiw9fm5bD2U7EENmBh1gl3BGZwAKYedoI=; b=TjB8DX0k7sjZWMmENcc+3PIpCKXMdpebxTa0Ah6UpKkZ4Tfad3wSwGbqAYwJIGG3tP 7tO87/EPSZ6wAs5/NrpVsyCPRomjS+XS/UzK7SU7mvRSjebVFMn7E3mqmGJ9Kh7MtU3g LBKp5ou8g4Qp8qviun7yVmhd7kbbAbNdKdk+8QbJHNqj1WQD0zSYGv4pWByAYTNaf+53 HIHHpACbjGNpiP95K7gHBFqOdFYcA+EWjPIhhxKRprT2b1BefYCE7hkmKc5IdJuL6IjH vOE7/EnRBYlT8pr2gbsbYFBlN9wiYekkZVFtplmGW2CaYi+P5DC84NlTlzzRArdUhNh6 1xgQ== X-Received: by 10.224.88.69 with SMTP id z5mr41879404qal.14.1404296389391; Wed, 02 Jul 2014 03:19:49 -0700 (PDT) Received: from ?IPv6:2601:6:3a80:77e:3510:f2c1:198d:394c? ([2601:6:3a80:77e:3510:f2c1:198d:394c]) by mx.google.com with ESMTPSA id i8sm7595331qge.12.2014.07.02.03.19.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 03:19:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC6304EE-B6F1-41EF-8805-3027F752351C" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: Date: Wed, 2 Jul 2014 06:19:48 -0400 Message-Id: References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> To: Seun Ojedeji X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jDBfiIzAGBK_ZZUOyjk1J4O93eI Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 10:19:51 -0000 --Apple-Mail=_BC6304EE-B6F1-41EF-8805-3027F752351C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 (no hats) The best part was the hum. Seriously, the session was well-done, not least for demonstrating some = of the working methods the IETF uses that one hopes the coordination = group will adopt as well.=20 The problem to be solved is relatively narrow for the IETF, but the = coordination group has a slightly separate task as well. Their task = amounts to coordinating the inputs of multiple design teams on multiple = components, some of which have to interoperate without unacceptable side = effects, for a coherent plan to be formed. Mostly those interoperation = mechanisms are in place but not all.=20 The IETF/IAB participants' experience is going to be useful in keeping = the effort on course. Thanks to those who've stepped up. Suzanne On Jul 2, 2014, at 2:05 AM, Seun Ojedeji wrote: > Thanks for the share Jari, it was good that the bullet point 1 item in = the summary achieved consensus ;) >=20 > Cheers! >=20 > sent from Google nexus 4 > kindly excuse brevity and typos. >=20 > On 2 Jul 2014 04:12, "IETF Chair" wrote: > Last week, some of us visited the ICANN meeting (at the Hilton London = Metropole!). Here are a few reflections from a session that I moderated = together with Patrik F=E4ltstr=F6m on this topic: >=20 > = http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardship= / >=20 > Jari Arkko > IETF Chair >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --Apple-Mail=_BC6304EE-B6F1-41EF-8805-3027F752351C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 (no = hats)

The best part was the = hum.

Seriously, the session was well-done, not least = for demonstrating some of the working methods the IETF uses that one = hopes the coordination group will adopt as = well. 

The problem to be solved is = relatively narrow for the IETF, but the coordination group has a = slightly separate task as well.  Their task amounts to coordinating = the inputs of multiple design teams on multiple components, some of = which have to interoperate without unacceptable side effects, for a = coherent plan to be formed. Mostly those interoperation mechanisms are = in place but not all. 

The IETF/IAB = participants' experience is going to be useful in keeping the effort on = course. Thanks to those who've stepped = up.


Suzanne

On Jul 2, 2014, at 2:05 AM, Seun Ojedeji <seun.ojedeji@gmail.com> = wrote:

Thanks for the share Jari, it was good that = the bullet point 1 item in the summary achieved consensus ;)

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.

On 2 Jul 2014 04:12, "IETF Chair" <chair@ietf.org> wrote:
Last week, some of us visited the ICANN meeting (at the Hilton London = Metropole!). Here are a few reflections from a session that I moderated = together with Patrik F=E4ltstr=F6m on this topic:

http://www.ietf.org/blog/2014/07/icann-and-transition-of= -ntias-stewardship/

Jari Arkko
IETF Chair

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
= https://www.iab.org/mailman/listinfo/internetgovtech=
_______________________________________________
Internetgovtech = mailing list
Internetgovtech@iab.org
htt= ps://www.iab.org/mailman/listinfo/internetgovtech
= --Apple-Mail=_BC6304EE-B6F1-41EF-8805-3027F752351C-- From nobody Wed Jul 2 05:24:15 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE9B1A0091 for ; Wed, 2 Jul 2014 05:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.631 X-Spam-Level: ** X-Spam-Status: No, score=2.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE3GvbUZjMer for ; Wed, 2 Jul 2014 05:24:11 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3357D1A008C for ; Wed, 2 Jul 2014 05:24:11 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:3152 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1X2Ja6-0003Wd-8d for internetgovtech@iab.org; Wed, 02 Jul 2014 05:24:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Jul 2014 14:06:24 +0200 To: internetgovtech@iab.org From: JFC Morfin In-Reply-To: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/5ZeMvMEoSwQalVHaXwIZj_VhMs4 Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 12:24:12 -0000 On 05:11 02/07/2014, IETF Chair said: >Last week, some of us visited the ICANN meeting (at the Hilton >London Metropole!). Here are a few reflections from a session that I >moderated together with Patrik Fältström on this topic: > >http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardship/ Jari, You write "A big part of this work rests on the individual communities (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA functions customers. Our session discussed expectations both for the communities and the community's expectations of the Coordination Group moving forward." This sounds reasonable. However, it delimitates the work to IANA functions ***customers*** (as contributors) and does not includes IANA functions ***users*** (who also use other comparable functions). Does this means that in your opinion neither the global (RFC 6852) nor the IUse (at this stage an I_D should be produced to document that concept) communities are involved? I like Pete RFC 7282 but it underlines the separation and differences between IETF, IUse and governance. It is based upon the credo: "We believe in: rough consensus and running code.". I do not disagree with it IRT the IETF mission of documentation (remember my ban was ***voted*** by the IESG). However, it may conflict with what IUCG calls "leaving mode" and RFC 6852 "the economics of global markets, fueled by technological advancements, drive global deployment of standards ***regardless*** of their formal status" i.e. what works is good, even if it was more or less opposed by rough consensus (ex. NATs) An IAB/IETF rough consensus will always be second to global market economy (along RFC 6852), i.e. the ecosystem final emergence. Because the ecosystem: - is larger than the sum of all the RFC 6852's "global communities" and all the users' internet footings. - has a real architecture which is more than the sum of the RFCs. IMHO there is only one way to take this into account if we try to stay consistant with IEN 48, the whole scientific, political, philosophic, economic "locality issue", and avoid a SOC (self-ordering criticality): it is to try to keep clearly differentiating global (IETF) and local (IUse) visions while making converge. - At this stage we tried a compromise with IUsers (IUCG@IETF) within the IETF. May be my fault, but this is not enough. It is a possibly good liaison/repository if some joined and help. However it cannot foster a true cooperation between two different but complementary planes, with one being managed by the 30 years old IETF and the other still being hardly identified. - My current experience is slow: it is to embody the local level into a real VGN (virtual glocal network: the networks of the network of networks; the local user footing in the internet): my village: as an "intelligent village on the information roads". The purpose to be copied by, and mesh with, other real life villages, business, trades, at fringe to fringe layer six and above, while solidly respecting and enhancing layer seven. As "glocal users" (the term "end user" is an architectural error when you read IEN 48) we need to have a contingency plan by September 2015 in case ICANN does not scale to our needs (up to now, it does not want to care). One of our problem is the ICANN and IANA of the other systems we (may) use in our real digital glocality. The IETF promotes its technology for its internet RFC 6852 global community. This is logic. ICANN documents and supports its US VGN. Fair enough/ How does the IETF proposes us and where does it document our relation with the other global communities it claims to be a benefit for humanity, and interface/integrate their technologies? Suzanne, I am sorry, you are right: >The problem to be solved is relatively narrow for the IETF, but it is very ***deep***. How does the IETF mesh with other digital technologies (that may use TCP/IP, at least in part - cf. IEN 48 second motivation) of which we feel it blocks their innovation, the same as we feel that ICANN blocks the innovative open use of the IETF technology (e.g. DNS)? If the IETF succeeds there, it may save the ICANN's day in providing them other good and adequate rules/examples to govern complex networking. This was plan in 1978 but we are no more in 1978 and we have to get real. Best jfc From nobody Wed Jul 2 07:14:56 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF401A0146 for ; Wed, 2 Jul 2014 07:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IbHZai31l3H for ; Wed, 2 Jul 2014 07:14:43 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B841A0126 for ; Wed, 2 Jul 2014 07:14:36 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id j5so4707792qga.37 for ; Wed, 02 Jul 2014 07:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kjrHamhCWVSdjNu5IVW1N1Blj7HMKsBFPe4iDMtLzcM=; b=wiSHGhb7oTtdb3DMwonSY2ylVYHObJgaxi+wm1tnlU3WOoBym4qkCJ//EwsQPjLKOx sL/UvVgb8yQq8vMEs5vuwrGr7LRIhYnK2xSRTIVKFLBzQiBr3RbIe6jHmzpQp3D9c3IJ Pdx1mqSP//5FeoViLFFfQXig1do4QnqZnW37sSwGbjPo/200p3RP/zPpURtmlOOWbz8Z AIZwaGlfucjtKC7BLhsr+D59jlxMCLVwt5Lm7f7gFDS3DyR34gvt9MhsFwJ8xD1DXQH5 IXaQJC7pzWoPrg8GjlV/8LCFyPny7ex6pWQoreSm4H/n1G54D2CrxR04OPB6nmvxn+QD 0/xA== MIME-Version: 1.0 X-Received: by 10.224.137.135 with SMTP id w7mr84125897qat.52.1404310475694; Wed, 02 Jul 2014 07:14:35 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 2 Jul 2014 07:14:35 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 2 Jul 2014 07:14:35 -0700 (PDT) In-Reply-To: <20140702122415.0EDE41A0091@ietfa.amsl.com> References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> <20140702122415.0EDE41A0091@ietfa.amsl.com> Date: Wed, 2 Jul 2014 15:14:35 +0100 Message-ID: From: Seun Ojedeji To: JFC Morfin Content-Type: multipart/alternative; boundary=001a11c2eb340ee77b04fd36832f Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ocXNdVmRVSDLmirA1CchDp6Zo5s Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:14:45 -0000 --001a11c2eb340ee77b04fd36832f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable sent from Google nexus 4 kindly excuse brevity and typos. On 2 Jul 2014 13:24, "JFC Morfin" wrote: > > On 05:11 02/07/2014, IETF Chair said: >> >> Last week, some of us visited the ICANN meeting (at the Hilton London Metropole!). Here are a few reflections from a session that I moderated together with Patrik F=C3=A4ltstr=C3=B6m on this topic: >> >> http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardship/ > > > Jari, > > You write "A big part of this work rests on the individual communities (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA functions customers. Our session discussed expectations both for the communities and the community's expectations of the Coordination Group moving forward." > > This sounds reasonable. However, it delimitates the work to IANA functions ***customers*** (as contributors) and does not includes IANA functions ***users*** (who also use other comparable functions). > Maybe the term "customer" may not be all that encompassing so yes using the word "user" could be more general enough. Nevertheless I think it does not remove the fact that users are part of the process. Users for instance could engage thorough the atlarge or even as an individual since it's an open process. the other part points to the statement above. Regards --001a11c2eb340ee77b04fd36832f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

sent from Google nexus 4
kindly excuse brevity and typos.
On 2 Jul 2014 13:24, "JFC Morfin" <jefsey@jefsey.com> wrote:
>
> On 05:11 02/07/2014, IETF Chair said:
>>
>> Last week, some of us visited the ICANN meeting (at the Hilton Lon= don Metropole!). Here are a few reflections from a session that I moderated= together with Patrik F=C3=A4ltstr=C3=B6m on this topic:
>>
>> http://www.ietf.org/blog/2014/07/icann-and-transition= -of-ntias-stewardship/
>
>
> Jari,
>
> You write "A big part of this work rests on the individual commun= ities (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA func= tions customers. Our session discussed expectations both for the communitie= s and the community's expectations of the Coordination Group moving for= ward."
>
> This sounds reasonable. However, it delimitates the work to IANA funct= ions ***customers*** (as contributors) and does not includes IANA functions= ***users*** (who also use other comparable functions).
>
Maybe the term "customer" may not be all that encompassing so yes= using the word "user" could be more general enough. Nevertheless= I think it does not remove the fact that users are part of the process. Us= ers for instance could engage thorough the atlarge or even as an individual= since it's an open process.

<snip> the other part points to the=C2=A0 statement ab= ove.

Regards

--001a11c2eb340ee77b04fd36832f-- From nobody Wed Jul 2 07:29:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7A1A019A; Wed, 2 Jul 2014 07:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9BVG--9yF0F; Wed, 2 Jul 2014 07:29:03 -0700 (PDT) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2406A1A0240; Wed, 2 Jul 2014 07:29:03 -0700 (PDT) Received: from isoc-rem-mbp2227.home ([96.237.230.184]) by p3plsmtpa06-10.prod.phx3.secureserver.net with id MSUz1o0053zMm3C01SV0g1; Wed, 02 Jul 2014 07:29:02 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Lynn St.Amour" In-Reply-To: <20140701180108.GA51920@mx1.yitter.info> Date: Wed, 2 Jul 2014 10:28:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49918635-D566-4311-A621-4F16EB341B61@LStAmour.org> References: <20140701180108.GA51920@mx1.yitter.info> To: Andrew Sullivan , IAB IAB X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/uJYdK8r9RlPve0Pm1g2NaeUbMnE Cc: ianaplan@ietf.org, internetgovtech@iab.org, ianatransition@icann.org Subject: Re: [Internetgovtech] NTIA/IANA transition co-ordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:29:05 -0000 Thank you Andrew and thank you to the IAB, This is a very important undertaking, and I take this responsibility = seriously. I look forward to working closely with all of you, as well = as with the other appointees. In particular, Jari, Russ, and Alissa - = a very, very strong team. In the interest of transparency, I am not being remunerated for this = effort, although I will be accepting travel support through the ICANN = travel policy in place to support this committee.=20 Please let me know if you need a more formal declaration or something to = post.=20 Best regards, Lynn On Jul 1, 2014, at 2:01 PM, Andrew Sullivan = wrote: > Dear colleagues, >=20 > As part of the NTIA/IANA transition, the IAB is to select two people > to serve as members of the co-ordination group. The IAB (less those > whose names were under consideration for appointment) deliberated, and > hereby appoints Russ Housley and Lynn St. Amour. >=20 > Russ is an IAB member and Chair of the IAB, and is a member of the > IAB's IANA Evolution program. Lynn continued as a member of the IAB's > IANA Evolution program after stepping down recently as CEO of ISOC. >=20 > We thank both Russ and Lynn for being willing to serve, and thank > others who were willing to be considered. >=20 > The appointments have been communicated to ICANN in its role as > convenor of the process. >=20 > Best regards, >=20 > Andrew >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Wed Jul 2 08:48:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE651B2981 for ; Wed, 2 Jul 2014 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSjGQKaS6aHG for ; Wed, 2 Jul 2014 08:48:03 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA181B2980 for ; Wed, 2 Jul 2014 08:48:03 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q107so4885825qgd.27 for ; Wed, 02 Jul 2014 08:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ryvqsfW8NFL4WBLkRIiKGskKfhR9hTNhLJL1hrRzP/I=; b=W716RH4ro4LO+QcCFWXWig1ulMFGOm9ffWifJ1Nqg5Adz6nOB7ZX9PSYYpFsgs65QJ VBvzGvzW3lEHc+oWYvNnOXH5jfsNK0bt+i7lT3M12RWK7G/NhKzsk1UqMm5sDi8NX8Zl JpU7T/4kfqhXQr1Dgw7fgPvUOVOtgPZBPCyjAX2ZynGUDrdO4q6rH5Z3EZjyTzhl57oe hGmr5eQuSRQPU/SZjh2EPmVDzol5pzUE21Nv1qPfCupDGlJD+qvSCXXm2A5L8vzBVWme aO6m8THaYFbIheJfUlalb9g3z6eYI5D77E48Nv25RHYG+LuXEBhNqURf1900HTIzQ9LO ISxQ== MIME-Version: 1.0 X-Received: by 10.229.191.135 with SMTP id dm7mr81801430qcb.9.1404316082021; Wed, 02 Jul 2014 08:48:02 -0700 (PDT) Sender: jefsey@gmail.com Received: by 10.140.25.169 with HTTP; Wed, 2 Jul 2014 08:48:01 -0700 (PDT) Date: Wed, 2 Jul 2014 17:48:01 +0200 X-Google-Sender-Auth: pglx6rYyXR3q3rcInzjRQPvJUkY Message-ID: From: JFC Morfin To: Seun Ojedeji Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/i6TWiQ5LKoX82pnHs20boreWxoQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:48:04 -0000 Dear Seun, the term "customers" is correct. The IETF is a contractual customer of the IANA to store and distribute their data to the users we are. I am not a customer of the IANA. However, I can integrate the IANA data into the Super-IANA I maintain for my VGN members together with other CLASSes and technologies data (as ICANN can contractually do it). I am not particularly interested in the US ICANN VGN governance. What I expect from the IETF as the being the technical source of the common documentation is that it documents the technical support of my technical needs irt. ICANN and non-ICANN propositions, including how to set and operate my owns. Otherwise, it means that I must become an SDO myself. In that case nothing guaranties there will be no conflict since I do not adhere to the RFC 6852 paradigm for the reason that RFC 6852 does not include any conflict resolution procedure and common guidance referent. The main problem is that I am a good will IUser. The Stats who voted against RFC 6852 and the NTIA at the WCIT (1) may be less cooperative, (2) may become my own law [e.g. France/ICANN opposition over ".vin/.wine" which is a pure IANA issue, or Merkel-Hollande project of an NSA secure euronet VGN], (3) may be more attractive in areas of my VGN concerns and needs. jfc 2014-07-02 16:14 GMT+02:00 Seun Ojedeji : > sent from Google nexus 4 > kindly excuse brevity and typos. > On 2 Jul 2014 13:24, "JFC Morfin" wrote: >> >> On 05:11 02/07/2014, IETF Chair said: >>> >>> Last week, some of us visited the ICANN meeting (at the Hilton London >>> Metropole!). Here are a few reflections from a session that I moderated >>> together with Patrik F=C3=A4ltstr=C3=B6m on this topic: >>> >>> >>> http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewards= hip/ >> >> >> Jari, >> >> You write "A big part of this work rests on the individual communities >> (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA functio= ns >> customers. Our session discussed expectations both for the communities a= nd >> the community's expectations of the Coordination Group moving forward." >> >> This sounds reasonable. However, it delimitates the work to IANA functio= ns >> ***customers*** (as contributors) and does not includes IANA functions >> ***users*** (who also use other comparable functions). >> > Maybe the term "customer" may not be all that encompassing so yes using t= he > word "user" could be more general enough. Nevertheless I think it does no= t > remove the fact that users are part of the process. Users for instance co= uld > engage thorough the atlarge or even as an individual since it's an open > process. > > the other part points to the statement above. > > Regards From nobody Wed Jul 2 12:21:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9461B281A for ; Wed, 2 Jul 2014 12:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFB74o1gfjLP for ; Wed, 2 Jul 2014 12:21:54 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CA91A04C8 for ; Wed, 2 Jul 2014 12:21:53 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so9243127qac.7 for ; Wed, 02 Jul 2014 12:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S518clRqYLi1jnbikWRWnMe6BSma3m5wE9CdcNRFi5Y=; b=eJAMgSXy3YzK2Xk7GI1CJzm2D1Q/dwjrWHf21tIBxnSZZp+BxkjYuG7G5t1A80y3hc svZpH95LJw0PWbQlxt8MX++k/pq+WzHgxqqSw4Ygt2PQRHTSlHwtAHHAa8y/A8PfxvoB rXGwFS/ec1uSd8S1vdloOztWvOpeSnZL5B2x4ISmx8zawIPCKTiH9GzYC/Ea94O8yw3J CvRWfOtXMMUz49mor5LPEBCoWw1DDgVvHsz3frZtlMDMskQMxAxRFKiOX+JPsjYz5rnl BaRB69wm6zRmZEEeV2CbYvmZH04ZfgwYuIMop/6h1+J/2H010Bfwwfq+yb120AHUnyii g7cA== MIME-Version: 1.0 X-Received: by 10.224.130.5 with SMTP id q5mr27488826qas.72.1404328912957; Wed, 02 Jul 2014 12:21:52 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 2 Jul 2014 12:21:52 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 2 Jul 2014 12:21:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jul 2014 20:21:52 +0100 Message-ID: From: Seun Ojedeji To: JFC Morfin Content-Type: multipart/alternative; boundary=001a11c2c45201357804fd3ace9a Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Xbw7jJiZfjWybcybEyme3hIQiWU Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 19:21:56 -0000 --001a11c2c45201357804fd3ace9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello JFC, Okay I fell for that, thought we were discussing participation in IANA oversight transition process. All the best. Cheers! sent from Google nexus 4 kindly excuse brevity and typos. On 2 Jul 2014 16:48, "JFC Morfin" wrote: > Dear Seun, > > the term "customers" is correct. The IETF is a contractual customer of > the IANA to store and distribute their data to the users we are. I am > not a customer of the IANA. However, I can integrate the IANA data > into the Super-IANA I maintain for my VGN members together with other > CLASSes and technologies data (as ICANN can contractually do it). > > I am not particularly interested in the US ICANN VGN governance. What > I expect from the IETF as the being the technical source of the common > documentation is that it documents the technical support of my > technical needs irt. ICANN and non-ICANN propositions, including how > to set and operate my owns. Otherwise, it means that I must become an > SDO myself. In that case nothing guaranties there will be no conflict > since I do not adhere to the RFC 6852 paradigm for the reason that RFC > 6852 does not include any conflict resolution procedure and common > guidance referent. > > The main problem is that I am a good will IUser. The Stats who voted > against RFC 6852 and the NTIA at the WCIT (1) may be less cooperative, > (2) may become my own law [e.g. France/ICANN opposition over > ".vin/.wine" which is a pure IANA issue, or Merkel-Hollande project of > an NSA secure euronet VGN], (3) may be more attractive in areas of my > VGN concerns and needs. > > jfc > > 2014-07-02 16:14 GMT+02:00 Seun Ojedeji : > > sent from Google nexus 4 > > kindly excuse brevity and typos. > > On 2 Jul 2014 13:24, "JFC Morfin" wrote: > >> > >> On 05:11 02/07/2014, IETF Chair said: > >>> > >>> Last week, some of us visited the ICANN meeting (at the Hilton London > >>> Metropole!). Here are a few reflections from a session that I moderat= ed > >>> together with Patrik F=C3=A4ltstr=C3=B6m on this topic: > >>> > >>> > >>> > http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardshi= p/ > >> > >> > >> Jari, > >> > >> You write "A big part of this work rests on the individual communities > >> (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA > functions > >> customers. Our session discussed expectations both for the communities > and > >> the community's expectations of the Coordination Group moving forward.= " > >> > >> This sounds reasonable. However, it delimitates the work to IANA > functions > >> ***customers*** (as contributors) and does not includes IANA functions > >> ***users*** (who also use other comparable functions). > >> > > Maybe the term "customer" may not be all that encompassing so yes using > the > > word "user" could be more general enough. Nevertheless I think it does > not > > remove the fact that users are part of the process. Users for instance > could > > engage thorough the atlarge or even as an individual since it's an open > > process. > > > > the other part points to the statement above. > > > > Regards > --001a11c2c45201357804fd3ace9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello JFC,

Okay I fell for that, thought we were discussing participati= on in IANA oversight transition process.

All the best.

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.

On 2 Jul 2014 16:48, "JFC Morfin" <= jefsey@jefsey.com> wrote:
Dear Seun,

the term "customers" is correct. The IETF is a contractual custom= er of
the IANA to store and distribute their data to the users we are. I am
not a customer of the IANA. However, I can integrate the IANA data
into the Super-IANA I maintain for my VGN members together with other
CLASSes and technologies data (as ICANN can contractually do it).

I am not particularly interested in the US ICANN VGN governance. What
I expect from the IETF as the being the technical source of the common
documentation is that it documents the technical support of my
technical needs irt. ICANN and non-ICANN propositions, including how
to set and operate my owns. Otherwise, it means that I must become an
SDO myself. In that case nothing guaranties there will be no conflict
since I do not adhere to the RFC 6852 paradigm for the reason that RFC
6852 does not include any conflict resolution procedure and common
guidance referent.

The main problem is that I am a good will IUser. The Stats who voted
against RFC 6852 and the NTIA at the WCIT (1) may be less cooperative,
(2) may become my own law [e.g. France/ICANN opposition over
".vin/.wine" which is a pure IANA issue, or Merkel-Hollande proje= ct of
an NSA secure euronet VGN], (3) may be more attractive in areas of my
VGN concerns and needs.

jfc

2014-07-02 16:14 GMT+02:00 Seun Ojedeji <seun.ojedeji@gmail.com>:
> sent from Google nexus 4
> kindly excuse brevity and typos.
> On 2 Jul 2014 13:24, "JFC Morfin" <jefsey@jefsey.com> wrote:
>>
>> On 05:11 02/07/2014, IETF Chair said:
>>>
>>> Last week, some of us visited the ICANN meeting (at the Hilton= London
>>> Metropole!). Here are a few reflections from a session that I = moderated
>>> together with Patrik F=C3=A4ltstr=C3=B6m on this topic:
>>>
>>>
>>> http://www.ietf.org/blog/2014/0= 7/icann-and-transition-of-ntias-stewardship/
>>
>>
>> Jari,
>>
>> You write "A big part of this work rests on the individual co= mmunities
>> (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA f= unctions
>> customers. Our session discussed expectations both for the communi= ties and
>> the community's expectations of the Coordination Group moving = forward."
>>
>> This sounds reasonable. However, it delimitates the work to IANA f= unctions
>> ***customers*** (as contributors) and does not includes IANA funct= ions
>> ***users*** (who also use other comparable functions).
>>
> Maybe the term "customer" may not be all that encompassing s= o yes using the
> word "user" could be more general enough. Nevertheless I thi= nk it does not
> remove the fact that users are part of the process. Users for instance= could
> engage thorough the atlarge or even as an individual since it's an= open
> process.
>
> <snip> the other part points to the =C2=A0statement above.
>
> Regards
--001a11c2c45201357804fd3ace9a-- From nobody Wed Jul 2 16:20:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325731A0AC1 for ; Wed, 2 Jul 2014 16:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWh2BFYLeLYb for ; Wed, 2 Jul 2014 16:20:26 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12CC1A0AA2 for ; Wed, 2 Jul 2014 16:20:25 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::b89b:6394:5849:df5c]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0387.000; Thu, 3 Jul 2014 00:20:23 +0100 From: Michele Neylon - Blacknight To: "internetgovtech@iab.org" , "ietf-announce@ietf.org" Thread-Topic: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship Thread-Index: AQHPlaN/KSpzqetDG0Kae1OMuv0xtZuNbMUw Date: Wed, 2 Jul 2014 23:20:22 +0000 Message-ID: References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> In-Reply-To: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0p_jU8EzO2CJ9a5N0abgQxlquow Cc: IETF discussion list Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 23:20:29 -0000 Jari I was sitting down the back during that session and thought it was excellen= t. There was a nice balance between people on the stage and interaction fro= m the floor.=20 Great work by yourself and Patrik. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: Internetgovtech [mailto:internetgovtech-bounces@iab.org] On Behalf Of= IETF Chair Sent: Wednesday, July 2, 2014 4:11 AM To: ietf-announce@ietf.org Cc: internetgovtech@iab.org; IETF discussion list Subject: [Internetgovtech] ICANN discussions on the transition of NTIA's st= ewardship Last week, some of us visited the ICANN meeting (at the Hilton London Metro= pole!). Here are a few reflections from a session that I moderated together= with Patrik F=E4ltstr=F6m on this topic: http://www.ietf.org/blog/2014/07/icann-and-transition-of-ntias-stewardship/ Jari Arkko IETF Chair _______________________________________________ Internetgovtech mailing list Internetgovtech@iab.org https://www.iab.org/mailman/listinfo/internetgovtech From nobody Thu Jul 3 02:42:43 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B11B280C; Thu, 3 Jul 2014 02:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiYKDHQCja5V; Thu, 3 Jul 2014 02:42:39 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6148A1A0AB1; Thu, 3 Jul 2014 02:42:39 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:42927 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1X2dXJ-0003c5-2g; Thu, 03 Jul 2014 02:42:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Jul 2014 11:39:59 +0200 To: IAB IAB From: JFC Morfin In-Reply-To: <49918635-D566-4311-A621-4F16EB341B61@LStAmour.org> References: <20140701180108.GA51920@mx1.yitter.info> <49918635-D566-4311-A621-4F16EB341B61@LStAmour.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/72BmAluwEEh2fasHJJGgHqCEFqY Cc: ianaplan@ietf.org, internetgovtech@iab.org, ianatransition@icann.org, "iucg@ietf.org" Subject: Re: [Internetgovtech] NTIA/IANA transition co-ordination group X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 09:42:40 -0000 At 16:28 02/07/2014, Lynn St.Amour wrote: > > Russ is an IAB member and Chair of the IAB, and is a member of the > > IAB's IANA Evolution program. Lynn continued as a member of the IAB's > > IANA Evolution program after stepping down recently as CEO of ISOC. These appointments are certainly an extremely wise choice in regard to an homogenous and efficient representation of the I*stablishment. The points now to clarify for them seem to be: 1. the consideration given to the IUsership as either a partner, a collateral or:and an acknowledged contingency planner. 2. ditto for the OpenStand signatorees, endorsers and supporters and ITU 3. the intent of every State and user to transition key Internet domain name functions to the global multistakeholder community. Also, when I consider http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ I see references made to "protocol numbers and Internet numbering resources", but the term "address" is missing. Have the appointees a clear understanding of what technically the NTIA is: - actually transfering when "the U.S. Commerce Department's National Telecommunications and Information Administration (NTIA) [] announces its intent to transition key Internet domain name functions to the global multistakeholder community" - considering as the "global multistakeholder community". Are each and every one included on an equal footing? Are those ones I*organizations and States, Provider, IUser, people? Is this the WSIS and Sao Paulo people centered information society? The whole humanity? Its whole digital ecosystem. I believe that before discussing the stakes one should first agree upon the words being used to describe them. JFC Morfin From nobody Thu Jul 3 09:10:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3831B28E2 for ; Thu, 3 Jul 2014 09:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LawuCFwsQNsL for ; Thu, 3 Jul 2014 09:09:58 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED2F1B2810 for ; Thu, 3 Jul 2014 09:09:58 -0700 (PDT) Received: from [192.168.1.3] (m90-141-145-21.cust.tele2.se [90.141.145.21]) by mail.frobbit.se (Postfix) with ESMTPSA id C69B01FD2E; Thu, 3 Jul 2014 18:09:55 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_9CCEB472-27E6-4A0C-9793-7B50C8A906B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 3 Jul 2014 18:09:52 +0200 Message-Id: References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> To: Michele Neylon - Blacknight X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/TDZ6rsbYWXm7Teo6W-RIlHniJBE Cc: "internetgovtech@iab.org" , IETF discussion list , "ietf-announce@ietf.org" Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:10:00 -0000 --Apple-Mail=_9CCEB472-27E6-4A0C-9793-7B50C8A906B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 3 jul 2014, at 01:20, Michele Neylon - Blacknight = wrote: > I was sitting down the back during that session and thought it was = excellent. There was a nice balance between people on the stage and = interaction from the floor.=20 >=20 > Great work by yourself and Patrik. Thanks! Patrik --Apple-Mail=_9CCEB472-27E6-4A0C-9793-7B50C8A906B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTtYBQrMabGguI180RAo0tAJ4q6PITGqnE3uRC/Mi4O/quGB+f8gCdGzwL Yd2N89Ys69uvmlgAoamOU0o= =HqZX -----END PGP SIGNATURE----- --Apple-Mail=_9CCEB472-27E6-4A0C-9793-7B50C8A906B6-- From nobody Thu Jul 3 09:21:58 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A101B2954 for ; Thu, 3 Jul 2014 09:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrAsRmusaDyd for ; Thu, 3 Jul 2014 09:21:44 -0700 (PDT) Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [212.110.188.53]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955F91B2904 for ; Thu, 3 Jul 2014 09:21:44 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=firsthand.net; b=aproi4cVwCy1hQfB8CidZVeL8UzFZP2bi/bEMeEE0AkSpH8nFwFIvowzkZpQG44QEdlyeNh/1aOF3xY56unantU4Yc5W2Ym2SioRf9EJ0SheabfZjjG0/++1kJlsql5c; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from orionlocal.local (host-2-96-89-86.as13285.net [2.96.89.86]) by bmtwo.vm.bytemark.co.uk (Postfix) with ESMTPSA id 0F035E0102; Thu, 3 Jul 2014 17:21:42 +0100 (BST) Message-ID: <53B58312.7010608@firsthand.net> Date: Thu, 03 Jul 2014 17:21:38 +0100 From: Christian de Larrinaga User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <196BA88C-1FB1-4077-B6E5-02B4AC75C991@ietf.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5398EAF405AC22EC44B3B1BE" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/5PAhPS_OCSgHV3x5YxMjF5HRdHo Cc: "internetgovtech@iab.org" , Michele Neylon - Blacknight , "ietf-announce@ietf.org" , IETF discussion list Subject: Re: [Internetgovtech] ICANN discussions on the transition of NTIA's stewardship X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cdel@firsthand.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:21:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5398EAF405AC22EC44B3B1BE Content-Type: multipart/alternative; boundary="------------040200090209010806070208" This is a multi-part message in MIME format. --------------040200090209010806070208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you and Jari, Alissa and the others for pitching in. It was really effective and impressive. The comments have been most positive across the board. Well done! Christian Patrik F=C3=A4ltstr=C3=B6m wrote: > On 3 jul 2014, at 01:20, Michele Neylon - Blacknight wrote: > >> I was sitting down the back during that session and thought it was exc= ellent. There was a nice balance between people on the stage and interact= ion from the floor.=20 >> >> Great work by yourself and Patrik. > > Thanks! > > Patrik > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --=20 Christian de Larrinaga FBCS, CITP, MCMA ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel@firsthand.net ------------------------- --------------040200090209010806070208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
Thank you= =20 and Jari, Alissa and the others for pitching in. It was really effective and impressive. The comments have been most positive across the board.=20 Well done!=C2=A0 Christian

Patrik F=C3=A4ltstr=C3=B6m wrote= :
On 3 jul 2014, at 01:20, Michele Neylon - Blacknight &l=
t;michele@blacknight.com> wrote:


I was sitting down the bac=
k during that session and thought it was excellent. There was a nice bala=
nce between people on the stage and interaction from the floor.=20

Great work by yourself and Patrik.


Thanks!

   Patrik


_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovt=
ech

--
Christian de=20 Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand -------------------------
+44 7989 386778
= cdel@firsthand.net
-------------------------
--------------040200090209010806070208-- --------------enig5398EAF405AC22EC44B3B1BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTtYMTAAoJEO8NEF3l27Yr1FYH/A0qo4ILDUveF1MhHSml1JyN sodewmR0lfl0y7dqz+XL638/pdvAgISu6h0U4Xa3bTJhi5jaPnjhQsiP0K1V/pU1 ZtreLIfQ/thz53Yyt/QRduAijhLwoBEjAXEQqdgu9yFrWUOYrMsLj1bU/fo0yeUa +NZCBfgGz8rDHsxNhn8VMamh0AC/NyPxghlzI3ZxmfRueU1hCXuOnmjBRsQR1Bg8 u8KewlAevf79/v051pDJHq1aDmCRfQKM5K4RW/wefHzubGVDEHBLPc/sekCn8AfT yuCYAHEO2YX8GAoh5RUcMi2JwlQD8/KQEzXa2yEXZcl1G8r2ew9I1htlNKgUUso= =6okG -----END PGP SIGNATURE----- --------------enig5398EAF405AC22EC44B3B1BE-- From nobody Tue Jul 8 15:50:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6F1A0175 for ; Tue, 8 Jul 2014 15:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u--IjnA9tRGX for ; Tue, 8 Jul 2014 15:50:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3B1A016C for ; Tue, 8 Jul 2014 15:50:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s68MocTf027409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2014 15:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404859852; x=1404946252; bh=wAzYSA/MIJ0qNWetajsYfzNndzmbgZ6jIkzCwLZaluY=; h=Date:To:From:Subject; b=4eIsxRcC/9zTCadQJNRKS76Eo68Ig0mO1NoPSBP8Ux+ivNIZMSVeZ0JXgZzEw5rT7 WkdoPsxLJk036rmB7AlkfXydiMV2W69SyBsNJyBqCxkdJA777SxIX4e+q660Ge4wyX yUIwgxY9W5WDVafyDlADkgYB3IgVTetp+gxfb66Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404859852; x=1404946252; i=@elandsys.com; bh=wAzYSA/MIJ0qNWetajsYfzNndzmbgZ6jIkzCwLZaluY=; h=Date:To:From:Subject; b=RSjMXXoMVj2QuOkrcdanJ/gtkPGtlCgfov9SpjsHRB3GTIfQhIwmljjVDSOCwydWE B62zMJQlAUJPMSXzaSkiZe/24a7P1i/qlmA93Zt8pAptR9ic191H6FBU88MmLwWBDp PVW5WKs6pN3kiMN8o1qmw/CYo7qzou5QZEwSYNJY= Message-Id: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Jul 2014 15:01:48 -0700 To: internetgovtech@iab.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Gk-7tJ970xl7Oz8Fo0mDEI9cJnY Subject: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 22:50:55 -0000 Hello, There is a message at http://mm.icann.org/pipermail/ianatransition/2014/001160.html from "ICANN staff". It looks like nobody from ICANN took responsibility for the decision to transition the IANA Transition discussion to the web. It is odd to see that in a message which mentions transparency. Here are some of ICANN conditions to participation: "ICANN has the right (though not the obligation) to, in ICANN Forum's sole discretion (i) refuse or remove any content that, in ICANN Forum's reasonable opinion, violates any ICANN policy or procedure or is in any way harmful or objectionable, or (ii) terminate or deny access to and use of the Website to any individual or entity for any reason, in ICANN's sole discretion." I note the "sole discretion" in the above. "Adhere to ICANN's conflict of interest policies" There isn't any information about those policies. "Conduct themselves in accordance with ICANN policies." There isn't any information about those policies. "Protect the organization's assets and ensure their efficient and effective use." The participant has to protect ICANN's assets. In simple terms participants should work towards ensuring ICANN's interest. The last entity that attempted a transition of discussions to the web found out that it was a failure. It looks like ICANN staff has not learned anything from that. Regards, S. Moonesamy From nobody Wed Jul 9 05:55:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128931A03B3 for ; Wed, 9 Jul 2014 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DphSP65maTK for ; Wed, 9 Jul 2014 05:55:08 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B171A03A4 for ; Wed, 9 Jul 2014 05:55:07 -0700 (PDT) Received: from BK-EXCHMBX01.blacknight.local ([fe80::a9c8:c46:8f4d:f8c8]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0387.000; Wed, 9 Jul 2014 13:55:05 +0100 From: Michele Neylon - Blacknight To: S Moonesamy , "internetgovtech@iab.org" Thread-Topic: [Internetgovtech] Transition to the web Thread-Index: AQHPmv80mWX06CRoGkmcaNx79uM1/puXs5yQ Date: Wed, 9 Jul 2014 12:55:05 +0000 Message-ID: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> In-Reply-To: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a01:a8:ff01:0:cabc:c8ff:fea6:ee0b] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/R7Jc1cfMNXG5a4bLvW90PijyaJ8 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:55:11 -0000 There's a lot of content, including a discussion forum, over on https://www= .icann.org/stewardship As for the policies you mentioned, all of those policies are published on t= he ICANN website If you're having issues locating them I'm sure someone can point you to the= m Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59=A0 9183072 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland=A0 Company No.: 370845 -----Original Message----- From: Internetgovtech [mailto:internetgovtech-bounces@iab.org] On Behalf Of= S Moonesamy Sent: Tuesday, July 08, 2014 11:02 PM To: internetgovtech@iab.org Subject: [Internetgovtech] Transition to the web Hello, There is a message at http://mm.icann.org/pipermail/ianatransition/2014/001160.html from "ICANN s= taff". It looks like nobody from ICANN took responsibility for the decisio= n to transition the IANA Transition discussion to the web. It is odd to se= e that in a message which mentions transparency. Here are some of ICANN conditions to participation: "ICANN has the right (though not the obligation) to, in ICANN Forum's so= le discretion (i) refuse or remove any content that, in ICANN Forum's reasonable opinion, violates any ICANN policy or procedure or is in any way harmful or objectionable, or (ii) terminate or deny access to and use of the Website to any individual or entity for any reason, in ICANN's sole discretion." I note the "sole discretion" in the above. "Adhere to ICANN's conflict of interest policies" There isn't any information about those policies. "Conduct themselves in accordance with ICANN policies." There isn't any information about those policies. "Protect the organization's assets and ensure their efficient and effect= ive use." The participant has to protect ICANN's assets. In simple terms participant= s should work towards ensuring ICANN's interest. The last entity that attempted a transition of discussions to the web found= out that it was a failure. It looks like ICANN staff has not learned anyt= hing from that. Regards, S. Moonesamy _______________________________________________ Internetgovtech mailing list Internetgovtech@iab.org https://www.iab.org/mailman/listinfo/internetgovtech From nobody Wed Jul 9 08:25:41 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20D31A0AF2 for ; Wed, 9 Jul 2014 08:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Poc8m8K4MDxU for ; Wed, 9 Jul 2014 08:25:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA29A1A0AF1 for ; Wed, 9 Jul 2014 08:25:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.136.216]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s69FPCma020411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 08:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404919524; x=1405005924; bh=liOg4jGqa9ZrDTkO8sO/cuoZZDqADRlvHwwvQ7AE5wY=; h=Date:To:From:Subject:In-Reply-To:References; b=ftL3Xs0EGm8eH3iotQH/cwXQj6Gd3awcX58Jx1i1UKXW94B1/H+NR96dCdaGL2zJw r2ilDoqpYBSnOSmIdiBo4sK6rjj/bpD46urtUENijs0kvbtn4qut78QRr1LmoKN9A2 +Vw1LuXTBAJXzm7To67DXGnbcGgvdwguvIOoQ3lo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404919524; x=1405005924; i=@elandsys.com; bh=liOg4jGqa9ZrDTkO8sO/cuoZZDqADRlvHwwvQ7AE5wY=; h=Date:To:From:Subject:In-Reply-To:References; b=YA1RLTwD4ZDcF4+acLSMQSumJ4h30Hr6wbw59hwFEJXP3y9WQDZEF0E9P1US7BjfM /kyTwg/y+TPbqlIPemy9qaNARoPO+T65LzcXq3KizyhIf2YXObJb8672K+WqjzpNr5 9tTTvgt9TQ+CuuliCUDV/rZ6qiBUGrsqUegwuELg= Message-Id: <6.2.5.6.2.20140709074402.0cc445d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 09 Jul 2014 08:00:14 -0700 To: Michele Neylon - Blacknight , internetgovtech@iab.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/W2xh0rxb5OQ7c8aDjnaYg8rPIU4 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:25:40 -0000 Hi Michele, At 05:55 09-07-2014, Michele Neylon - Blacknight wrote: >There's a lot of content, including a discussion forum, over on >https://www.icann.org/stewardship There is a statement from the Advisor to the President on Global Strategy on that web page. I'll quote part of it: "we must first be sure that we all agree on the initial process" I'll wait for the IETF representatives to ask IETF participants whether they agree. >If you're having issues locating them I'm sure someone can point you to them I did have issues locating these policies. Regards, S. Moonesamy From nobody Wed Jul 9 09:17:00 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079D31A0425 for ; Wed, 9 Jul 2014 09:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4gqoBWmWGVR for ; Wed, 9 Jul 2014 09:16:57 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3171A040B for ; Wed, 9 Jul 2014 09:16:56 -0700 (PDT) Received: from mx1.yitter.info (c-76-118-173-172.hsd1.nh.comcast.net [76.118.173.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 51FE18A031 for ; Wed, 9 Jul 2014 16:16:55 +0000 (UTC) Date: Wed, 9 Jul 2014 12:16:53 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140709161653.GM59034@mx1.yitter.info> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9BOhKsjlI74ZxvW_q-Zj3t6QE_A Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:16:58 -0000 On Wed, Jul 09, 2014 at 12:55:05PM +0000, Michele Neylon - Blacknight wrote: > There's a lot of content, including a discussion forum, over on https://www.icann.org/stewardship Yes, and it's all ridiculous. That site (or "microsite", as it's been styled) both attempts to impose ICANN policies on the global discussion about all IANA and pretends to be a single discussion point for the entire transition. But as we heard in London at the ICANN meeting's session on the IANA transition, the way this should really be pursued is by working on the separate parts of the IANA function inside the concerned communities. So, we don't actually need a single site, or list, or anything to discuss the overall IANA transition. The co-ordination group is there to solve that problem. But if we did need such a site, it could not possibly come under ICANN's terms of service, which include a rule that one has to protect ICANN's assets. Were this not an IETF list (so we don't really have a reason to discuss the names-IANA issue), I'd suggest that ICANN should repurpose its microsite to facilitate the discussion in the names community. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 9 09:18:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948AE1A0331 for ; Wed, 9 Jul 2014 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CUxDcwsgUFx for ; Wed, 9 Jul 2014 09:18:09 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2BF1A0067 for ; Wed, 9 Jul 2014 09:18:09 -0700 (PDT) Received: from mx1.yitter.info (c-76-118-173-172.hsd1.nh.comcast.net [76.118.173.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3C98A8A031 for ; Wed, 9 Jul 2014 16:18:08 +0000 (UTC) Date: Wed, 9 Jul 2014 12:18:06 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140709161806.GN59034@mx1.yitter.info> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140709161653.GM59034@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/EjSyLptDgSp5gy2DSKbyOdlDkck Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:18:09 -0000 On Wed, Jul 09, 2014 at 12:16:53PM -0400, Andrew Sullivan wrote: > Were this not an IETF list Err, I meant "IAB" list. Many apologies. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 9 09:56:51 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB401A0104 for ; Wed, 9 Jul 2014 09:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Roo6l4Jz0veo for ; Wed, 9 Jul 2014 09:56:48 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7F41A001C for ; Wed, 9 Jul 2014 09:56:47 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X4v7H-000K9x-D0; Wed, 09 Jul 2014 12:53:11 -0400 Date: Wed, 09 Jul 2014 12:56:38 -0400 From: John C Klensin To: Andrew Sullivan , internetgovtech@iab.org Message-ID: <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> In-Reply-To: <20140709161653.GM59034@mx1.yitter.info> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/NEY1012ESHN8qq10odYlG35MxHk Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:56:49 -0000 --On Wednesday, July 09, 2014 12:16 -0400 Andrew Sullivan wrote: >... > Were this not an IAB list (so we don't really have a reason to > discuss the names-IANA issue), I'd suggest that ICANN should > repurpose its microsite to facilitate the discussion in the > names community. (above corrected) It would still be inappropriate for it to require adherence to ICANN policies --notably preservation of ICANN assets and giving priority to ICANN's best interests-- by the users or in discussions on that site. At a very high level, I think that is one of the key issues in the discussion. From my point of view, the criteria for a successful conclusion is one that best serves the long-term interests of the Internet and its users (I hope those are the same). Various people among ICANN leadership and staff seem to keep slipping into assertions about ICANN's own best interests ("assets" included). If that is just a slip or an unintentional application of an inappropriately-general rule, I think it is worth correcting because it is by no means proven that what is good for ICANN is good for the Internet. If it is more than that, then, IMO, it is really important that we resist moves in the direction of substituting "best interests of ICANN" for "best interests of the Internet" as a criterion, must less a constraint on discussions. john From nobody Wed Jul 9 10:14:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CFF1A0104 for ; Wed, 9 Jul 2014 10:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQX0khjBaWBF for ; Wed, 9 Jul 2014 10:14:04 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B851A0048 for ; Wed, 9 Jul 2014 10:14:04 -0700 (PDT) Received: from mx1.yitter.info (c-76-118-173-172.hsd1.nh.comcast.net [76.118.173.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1368C8A035 for ; Wed, 9 Jul 2014 17:14:03 +0000 (UTC) Date: Wed, 9 Jul 2014 13:14:01 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140709171401.GB2935@mx1.yitter.info> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/m4UIJ_gHadmHenGJbgNdW8LYFuw Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:14:05 -0000 On Wed, Jul 09, 2014 at 12:56:38PM -0400, John C Klensin wrote: > > It would still be inappropriate for it to require adherence to > ICANN policies --notably preservation of ICANN assets and giving > priority to ICANN's best interests-- by the users or in > discussions on that site. Well, perhaps, but I'm not sure this list is the right place to have an opinion about that. I recognize the difficulty, however, of attempting to express that to ICANN given that the terms of service of the site presumably to be used for such communication might be unacceptable. But I'm not sure this list is the right place to try to tell ICANN how it ought to run its process for figuring out the names-relevant transition of the IANA function. There _is_ an interesting wrinkle directly related to the IETF (and perhaps indirectly to the IAB), however. That is, the IETF maintains an independent registry of special-use names. These also need to be registered with IANA, but maybe not in the DNS. Clearly, that list and the root zone mustn't be in conflict. It's hard to see how to make this point to ICANN if one is uncomfortable with the terms under which ICANN is operating its community process. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 9 10:46:34 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35E31B278E for ; Wed, 9 Jul 2014 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G-mCIEmHibO for ; Wed, 9 Jul 2014 10:46:31 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F7A1A0AE8 for ; Wed, 9 Jul 2014 10:46:31 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so2772027qcy.28 for ; Wed, 09 Jul 2014 10:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NjXAifwiK+TmveogJ/Z+qMSiU4p7VSud6TN1mACmtA0=; b=ozXP+TtbROHKUq3cxnudwc0nf8BqZ/LXXMiqKAkWmVdO8FjnUr9UkeoNxn2dASKXcO Yr7LzhMc86/UdbxGxilcRQPLgkG8FZ3WUdIL0BadsQl09tQdstCg2v7LbaRE1mDOz1qC TDjIWpMwjvbcMgOqxjpvbKxAqCQ6nwgD5ktYTb6p0yNJrplM857GKYH9uyUAMGlTKKHr GaLZl9UCyS8ojaBY8fyc9OnmDC/y2eqzWd3TFHMfU226fC3jBVwCTOjSD+jX8PsyB/tJ Ox2bbJh9m13VuynAFeXzL344y/K8M+t2ziC/pfbXKirPLKV4cp/dYG4nH53tbYDlFM9I Kfjw== MIME-Version: 1.0 X-Received: by 10.224.137.135 with SMTP id w7mr71727670qat.52.1404927990405; Wed, 09 Jul 2014 10:46:30 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 9 Jul 2014 10:46:30 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 9 Jul 2014 10:46:30 -0700 (PDT) In-Reply-To: <20140709161653.GM59034@mx1.yitter.info> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> Date: Wed, 9 Jul 2014 18:46:30 +0100 Message-ID: From: Seun Ojedeji To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2eb34cda54704fdc64991 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/nWLOsBJBNCJwqrkG-MZyA_TzPYM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:46:33 -0000 --001a11c2eb34cda54704fdc64991 Content-Type: text/plain; charset=UTF-8 It is just so unfortunate the way ICANN is "acting" up. Even if ICANN needed a forum (which I open-mindedly reviewed as I thought it's okay to have options) I don't see any motive to shutdown the mailing list...unless it is an attempt to discourage a broader discussion of the subject matter. One would expect that ICANN will allow the coordination team do it's job and not interfere! More so the forum is not even independent of ICANN content/usage policies as Andrew rightly observed. It is my hope that the coordination team will do the needful. Regards sent from Google nexus 4 kindly excuse brevity and typos. On 9 Jul 2014 17:17, "Andrew Sullivan" wrote: > On Wed, Jul 09, 2014 at 12:55:05PM +0000, Michele Neylon - Blacknight > wrote: > > There's a lot of content, including a discussion forum, over on > https://www.icann.org/stewardship > > Yes, and it's all ridiculous. That site (or "microsite", as it's been > styled) both attempts to impose ICANN policies on the global > discussion about all IANA and pretends to be a single discussion point > for the entire transition. But as we heard in London at the ICANN > meeting's session on the IANA transition, the way this should really > be pursued is by working on the separate parts of the IANA function > inside the concerned communities. > > So, we don't actually need a single site, or list, or anything to > discuss the overall IANA transition. The co-ordination group is there > to solve that problem. But if we did need such a site, it could not > possibly come under ICANN's terms of service, which include a rule > that one has to protect ICANN's assets. > > Were this not an IETF list (so we don't really have a reason to > discuss the names-IANA issue), I'd suggest that ICANN should repurpose > its microsite to facilitate the discussion in the names community. > > Best regards, > > A > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > --001a11c2eb34cda54704fdc64991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It is just so unfortunate the way ICANN is "acting"= ; up. Even if ICANN needed a forum (which I open-mindedly reviewed as I tho= ught it's okay to have options) I don't see any motive to shutdown = the mailing list...unless it is an attempt to discourage a broader discussi= on of the subject matter.
One would expect that ICANN will allow the coordination team do it's jo= b and not interfere!
More so the forum is not even independent of ICANN content/usage policies a= s Andrew rightly observed. It is my hope that the coordination team will do= the needful.

Regards

sent from Google nexus 4
kindly excuse brevity and typos.

On 9 Jul 2014 17:17, "Andrew Sullivan"= <ajs@anvilwalrusden.com&g= t; wrote:
On Wed, Jul 09, 2014 at 12:55:05PM +0000, Michele Neylon - Blacknight wrote= :
> There's a lot of content, including a discussion forum, over on https://www.i= cann.org/stewardship

Yes, and it's all ridiculous. =C2=A0That site (or "microsite"= , as it's been
styled) both attempts to impose ICANN policies on the global
discussion about all IANA and pretends to be a single discussion point
for the entire transition. =C2=A0But as we heard in London at the ICANN
meeting's session on the IANA transition, the way this should really be pursued is by working on the separate parts of the IANA function
inside the concerned communities.

So, we don't actually need a single site, or list, or anything to
discuss the overall IANA transition. =C2=A0The co-ordination group is there=
to solve that problem. =C2=A0But if we did need such a site, it could not possibly come under ICANN's terms of service, which include a rule
that one has to protect ICANN's assets.

Were this not an IETF list (so we don't really have a reason to
discuss the names-IANA issue), I'd suggest that ICANN should repurpose<= br> its microsite to facilitate the discussion in the names community.

Best regards,

A


--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech
--001a11c2eb34cda54704fdc64991-- From nobody Wed Jul 9 11:04:52 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB271A0373 for ; Wed, 9 Jul 2014 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqeDENXcQn9u for ; Wed, 9 Jul 2014 11:04:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 109361A0340 for ; Wed, 9 Jul 2014 11:04:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4109BBDCF; Wed, 9 Jul 2014 19:04:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFs_Ox3f2U3v; Wed, 9 Jul 2014 19:04:48 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.20.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 347F2BDCA; Wed, 9 Jul 2014 19:04:48 +0100 (IST) Message-ID: <53BD843F.1070304@cs.tcd.ie> Date: Wed, 09 Jul 2014 19:04:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrew Sullivan , internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> In-Reply-To: <20140709171401.GB2935@mx1.yitter.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/AP6vWGxEFrn7On4GaJnfQjAeOTM Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 18:04:51 -0000 On 09/07/14 18:14, Andrew Sullivan wrote: > But I'm not sure this list is the right place to try to > tell ICANN how it ought to run its process for figuring out the > names-relevant transition of the IANA function. I agree. Which makes it even more of a shame that icann seem block-headedly intent on shuttering the mailing list where that discussion would be appropriate. S. From nobody Wed Jul 9 11:07:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7B1A0340 for ; Wed, 9 Jul 2014 11:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX7KmL5mC9gU for ; Wed, 9 Jul 2014 11:07:02 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4217D1A038F for ; Wed, 9 Jul 2014 11:07:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 91184CC0D0 for ; Wed, 9 Jul 2014 14:07:01 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i4kF4B9GtnkF for ; Wed, 9 Jul 2014 14:06:52 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id C0830CC0D4 for ; Wed, 9 Jul 2014 14:06:52 -0400 (EDT) Message-ID: <53BD84BB.7000002@meetinghouse.net> Date: Wed, 09 Jul 2014 14:06:51 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> In-Reply-To: <53BD843F.1070304@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Md78qUqQefy807KU5gWIgSew4mM Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 18:07:06 -0000 Stephen Farrell wrote: > > On 09/07/14 18:14, Andrew Sullivan wrote: >> But I'm not sure this list is the right place to try to >> tell ICANN how it ought to run its process for figuring out the >> names-relevant transition of the IANA function. > I agree. Which makes it even more of a shame that icann > seem block-headedly intent on shuttering the mailing list > where that discussion would be appropriate. > > Kind of sums up in a sentence all the reasons that ICANN needs continued oversight. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Wed Jul 9 12:18:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987F21A0BE8 for ; Wed, 9 Jul 2014 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TyvTmmBr_NV for ; Wed, 9 Jul 2014 12:18:04 -0700 (PDT) Received: from p3plsmtpa11-05.prod.phx3.secureserver.net (p3plsmtpa11-05.prod.phx3.secureserver.net [68.178.252.106]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7A1A03D4 for ; Wed, 9 Jul 2014 12:18:04 -0700 (PDT) Received: from isoc-rem-mbp2227.home ([96.237.230.184]) by p3plsmtpa11-05.prod.phx3.secureserver.net with id QKJ21o00G3zMm3C01KJ3FZ; Wed, 09 Jul 2014 12:18:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Lynn St.Amour" In-Reply-To: <20140709171401.GB2935@mx1.yitter.info> Date: Wed, 9 Jul 2014 15:18:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> To: "internetgovtech@iab.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZXc1j4jc3GbVQLyYNZ5Yohju0jY Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:18:06 -0000 In thinking about how to turn this around, what if a few key people (say = IETF and IAB Chairs) were to write to Fadi and some of his key advisors = and suggest they reconsider their recent actions given how counter this = is to so many principles. ICANN senior staff may just not be aware of = this. And, maybe the CG should have a statement of "what good looks like" or = of what one should reasonably expect from these processes. This is = where the IETF and IAB can help - you have far more experience with = these types of community and consensus processes than any other group. Lynn On Jul 9, 2014, at 1:14 PM, Andrew Sullivan = wrote: > But I'm not sure this list is the right place to try to > tell ICANN how it ought to run its process for figuring out the > names-relevant transition of the IANA function. >=20 From nobody Wed Jul 9 12:24:13 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E441A040D for ; Wed, 9 Jul 2014 12:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw5tMi5JEhQV for ; Wed, 9 Jul 2014 12:24:10 -0700 (PDT) Received: from www.schiefner.de (www.schiefner.de [193.175.80.188]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D1B1A03D1 for ; Wed, 9 Jul 2014 12:24:10 -0700 (PDT) Received: from brln-4d0c0eb2.pool.mediaways.net ([77.12.14.178] helo=[192.168.220.73]) by www.schiefner.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X4xTM-0005pO-Al; Wed, 09 Jul 2014 21:24:08 +0200 Message-ID: <53BD96CD.3030402@schiefner.de> Date: Wed, 09 Jul 2014 21:23:57 +0200 From: Carsten Schiefner User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Lynn St.Amour" , "internetgovtech@iab.org" References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YxsS8WMcdQL5vY_RqaE7GTOc5bY Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:24:12 -0000 Hi Lynn, On 09.07.2014 21:18, Lynn St.Amour wrote: > In thinking about how to turn this around, what if a few key people > (say IETF and IAB Chairs) were to write to Fadi and some of his key > advisors and suggest they reconsider their recent actions given how > counter this is to so many principles. ICANN senior staff may just > not be aware of this. that indeed might be the case - that's why I'd support your take on this. It however puts another question on the table: how "senior" @ ICANN one does need to be to be or become aware of it *before* actually taking action as we have seen? Best, -C. From nobody Wed Jul 9 12:43:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F4E1A0421 for ; Wed, 9 Jul 2014 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQtOA4L_PQZN for ; Wed, 9 Jul 2014 12:43:26 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B921A041F for ; Wed, 9 Jul 2014 12:43:26 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so8218568vcb.30 for ; Wed, 09 Jul 2014 12:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xh0mdB/qaeLzM8Xn4ecbwbkVWVXcGzE96W/pBbvjes4=; b=gUARkSGOG5f85kQFuLbndgFtUWM0nRefYeyvChzA+sCveHdayVCYgAPW0dSBvH/GtR 8e80iKl7KdaGmmghR/PNbOOlkW4TnSkOVK5dCHV/y0To5H/2mRLfXEizGhoP0IJqM/ea VshwsxZhissPx+CUsvacn3Gi9wlYiALHyZ0THDB/TvtZVTiSSDD6mMH1FTAGxb4ieAN9 jDk3eIn8xfMkyFYkixK2SyQiYTueBUdb0k5eZRpopcqDAfuGrs2Na9Jn3qtCBRMFN4Om Rdmm5B5XuapjvnAK4BcEQ5wGHDnhGkVJRkshgL0KMu5xw2H601rQrxVBUzDLTXP1nVK+ e0cg== MIME-Version: 1.0 X-Received: by 10.220.44.20 with SMTP id y20mr2056867vce.60.1404935005242; Wed, 09 Jul 2014 12:43:25 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 9 Jul 2014 12:43:25 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Wed, 9 Jul 2014 12:43:25 -0700 (PDT) In-Reply-To: <53BD96CD.3030402@schiefner.de> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD96CD.3030402@schiefner.de> Date: Wed, 9 Jul 2014 20:43:25 +0100 Message-ID: From: Seun Ojedeji To: Carsten Schiefner Content-Type: multipart/alternative; boundary=047d7b3a98d0eb8e5604fdc7eb22 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/qpsI2apUxfaivGdlXaZpih0K-wA Cc: "Lynn St.Amour" , internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:43:28 -0000 --047d7b3a98d0eb8e5604fdc7eb22 Content-Type: text/plain; charset=UTF-8 sent from Google nexus 4 kindly excuse brevity and typos. On 9 Jul 2014 20:24, "Carsten Schiefner" wrote: > > Hi Lynn, > > > On 09.07.2014 21:18, Lynn St.Amour wrote: >> >> In thinking about how to turn this around, what if a few key people >> (say IETF and IAB Chairs) were to write to Fadi and some of his key >> advisors and suggest they reconsider their recent actions given how >> counter this is to so many principles. ICANN senior staff may just >> not be aware of this. > > > that indeed might be the case - that's why I'd support your take on this. > Although I doubt this could be the reason because I won't expect such decision to be taken by junior ICANN staff as those would just be implementers. Also there are quite senior ICANN folks on that list which should remove the doubt of their awareness. Nevertheless, one could reason with your assumption for benefit of doubt. > It however puts another question on the table: how "senior" @ ICANN one does need to be to be or become aware of it *before* actually taking action as we have seen? > More like don't be senior if you want to be aware ;)... lol Cheers! > Best, > > -C. > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --047d7b3a98d0eb8e5604fdc7eb22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

sent from Google nexus 4
kindly excuse brevity and typos.
On 9 Jul 2014 20:24, "Carsten Schiefner" <carsten@schiefner.de> wrote:
>
> Hi Lynn,
>
>
> On 09.07.2014 21:18, Lynn St.Amour wrote:
>>
>> In thinking about how to turn this around, what if a few key peopl= e
>> (say IETF and IAB Chairs) were to write to Fadi and some of his ke= y
>> advisors and suggest they reconsider their recent actions given ho= w
>> counter this is to so many principles. =C2=A0ICANN senior staff ma= y just
>> not be aware of this.
>
>
> that indeed might be the case - that's why I'd support your ta= ke on this.
>
Although I doubt this could be the reason because I won't expect such d= ecision to be taken by junior ICANN staff as those would just be implemente= rs. Also there are quite senior ICANN folks on that list which should remov= e the doubt of their awareness. Nevertheless, one could reason with your as= sumption for benefit of doubt.

> It however puts another question on the table: how &quo= t;senior" @ ICANN one does need to be to be or become aware of it *bef= ore* actually taking action as we have seen?
>
More like don't be senior if you want to be aware ;)... lol

Cheers!
> Best,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -C.
>
>
> _______________________________________________
> Internetgovtech mailing list
> Internetgovtech@iab.org=
> https= ://www.iab.org/mailman/listinfo/internetgovtech

--047d7b3a98d0eb8e5604fdc7eb22-- From nobody Wed Jul 9 12:45:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B49C1A045D for ; Wed, 9 Jul 2014 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6gask7RuXKD for ; Wed, 9 Jul 2014 12:45:13 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217931A0452 for ; Wed, 9 Jul 2014 12:45:12 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so5288464lbj.41 for ; Wed, 09 Jul 2014 12:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0jbR6uRhKTNW+20v9LOryeGdQ6FU82EU7yXFcAyo4fM=; b=lLkerJ0PXp+jvnzB/J8KccAS3TU601kcntmsyelWzxFVVLNEqQDd+Pu0ekJJfW9VIM lUz2w07P/kFFMTsupaEPqbUZFjZE0ed8Dme61vXbM+GL8Alb3v0a5kpnGFwsHA1nSINO YEogn/MPjdTKIAj3/X4aLBX2WHm2YwEb71ZrXA3b6brA9V9YBgog4m6hFAhNKfm7FOc0 gWJwfb+0jALKeKhM6pcNsXSdrbStWjLZkuTKIqAqBdTqWomUTUapQVYy4vbHPnliZaHx FcyQZhlf/ZTgvp+jNNodmeJaUFTsgzG6OEIOaLufidywmRJ+8I7EU0XxQ1/TTm3i3TVB +rcA== MIME-Version: 1.0 X-Received: by 10.112.134.40 with SMTP id ph8mr15434701lbb.34.1404935111130; Wed, 09 Jul 2014 12:45:11 -0700 (PDT) Received: by 10.112.171.129 with HTTP; Wed, 9 Jul 2014 12:45:11 -0700 (PDT) In-Reply-To: <53BD96CD.3030402@schiefner.de> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD96CD.3030402@schiefner.de> Date: Wed, 9 Jul 2014 16:45:11 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: Carsten Schiefner Content-Type: multipart/alternative; boundary=047d7b3a7eac3b457704fdc7f2c9 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HbTNwSCqRc_tK4YA9l4385hvwgs Cc: "Lynn St.Amour" , "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:45:17 -0000 --047d7b3a7eac3b457704fdc7f2c9 Content-Type: text/plain; charset=UTF-8 It'd be quite worrying if ICANN is becoming an organisation where middle management are who actually make these important decisions without proper oversight. Several examples come to mind, none of them good. I support Lynn's idea. regards -Carlos On Wed, Jul 9, 2014 at 4:23 PM, Carsten Schiefner wrote: > Hi Lynn, > > > On 09.07.2014 21:18, Lynn St.Amour wrote: > >> In thinking about how to turn this around, what if a few key people >> (say IETF and IAB Chairs) were to write to Fadi and some of his key >> advisors and suggest they reconsider their recent actions given how >> counter this is to so many principles. ICANN senior staff may just >> not be aware of this. >> > > that indeed might be the case - that's why I'd support your take on this. > > It however puts another question on the table: how "senior" @ ICANN one > does need to be to be or become aware of it *before* actually taking action > as we have seen? > > Best, > > -C. > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --047d7b3a7eac3b457704fdc7f2c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It'd be quite worrying if ICANN is becoming an organis= ation where middle management are who actually make these important decisio= ns without proper oversight. Several examples come to mind, none of them go= od.

I support Lynn's idea.

regards<= /div>

-Carlos

=
On Wed, Jul 9, 2014 at 4:23 PM, Carsten Schi= efner <carsten@schiefner.de> wrote:
Hi Lynn,


On 09.07.2014 21:18, Lynn St.Amour wrote:
In thinking about how to turn this around, what if a few key people
(say IETF and IAB Chairs) were to write to Fadi and some of his key
advisors and suggest they reconsider their recent actions given how
counter this is to so many principles. =C2=A0ICANN senior staff may just not be aware of this.

that indeed might be the case - that's why I'd support your take on= this.

It however puts another question on the table: how "senior" @ ICA= NN one does need to be to be or become aware of it *before* actually taking= action as we have seen?

Best,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -C.


_______________________________________________
Internetgovtech mailing list
Internetgovtec= h@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech



--
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--047d7b3a7eac3b457704fdc7f2c9-- From nobody Wed Jul 9 13:39:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD721AD6B0 for ; Wed, 9 Jul 2014 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TmTG9NVhMb2 for ; Wed, 9 Jul 2014 13:38:59 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F111ACAD6 for ; Wed, 9 Jul 2014 13:38:59 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so9694993pac.5 for ; Wed, 09 Jul 2014 13:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=O94oNuvJizuv78iLOxLGa01sVW2rouyzYtYU1PJZJbw=; b=xRMG8nOyFz3/5lIVulqxosjRDngHUWga6Lg7DJHmPTH0ttLja/oVsG44MJxOUNVur3 4vUxQHT4PCe70NxlP9WyPgsZBymruYZ7N0TBvpE3ly5BAzTQr8RNc4L3IGTJFrnz/Rl1 4aF3ZLOlbUUJTLWkDS1izkykn3Cprpdsl2A2EFwao/aK4qbWDgh+8OyitmxpVjvFZjpx LsIvCo4Xg68J1hr3BPt7/bgI19tvXAvhWC0nGOJxvAygpiOcbP4qESMGW1yxUsZ5ZLsg UPN2xGPxgWpxEBRcbdd27vzcsaLZvmUl0dLKgLDtPhpNZBr3JsXVUAv0ZUceSPOA/Zif R23g== X-Received: by 10.66.66.140 with SMTP id f12mr42847853pat.78.1404938338889; Wed, 09 Jul 2014 13:38:58 -0700 (PDT) Received: from [192.168.178.23] (158.197.69.111.dynamic.snap.net.nz. [111.69.197.158]) by mx.google.com with ESMTPSA id pp2sm29635539pdb.59.2014.07.09.13.38.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 13:38:58 -0700 (PDT) Message-ID: <53BDA867.7090701@gmail.com> Date: Thu, 10 Jul 2014 08:39:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miles Fidelman References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> In-Reply-To: <53BD84BB.7000002@meetinghouse.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/xCcHt3F5tPTpuAUO3d3dsMmS4v0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:39:01 -0000 On 10/07/2014 06:06, Miles Fidelman wrote: > Stephen Farrell wrote: >> >> On 09/07/14 18:14, Andrew Sullivan wrote: >>> But I'm not sure this list is the right place to try to >>> tell ICANN how it ought to run its process for figuring out the >>> names-relevant transition of the IANA function. >> I agree. Which makes it even more of a shame that icann >> seem block-headedly intent on shuttering the mailing list >> where that discussion would be appropriate. >> >> > Kind of sums up in a sentence all the reasons that ICANN needs continued > oversight. Yes. I am very disillusioned by this. I agree with Lynn's suggestion about triggering some high-level messages about this, but it suggests that a watchdog with teeth is needed (and I'm not at all convinced that NTIA has teeth in practice). "Teeth" generally means having the power to fire people. Brian From nobody Wed Jul 9 13:40:39 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D981AD6B0 for ; Wed, 9 Jul 2014 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVxEvDuvS-jm for ; Wed, 9 Jul 2014 13:40:33 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id ED2ED1A0421 for ; Wed, 9 Jul 2014 13:40:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 6B8D5CC0E5 for ; Wed, 9 Jul 2014 16:40:30 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QNCWdNaeLuqW for ; Wed, 9 Jul 2014 16:40:21 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 3468BCC113 for ; Wed, 9 Jul 2014 16:40:21 -0400 (EDT) Message-ID: <53BDA8B3.8050709@meetinghouse.net> Date: Wed, 09 Jul 2014 16:40:19 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> In-Reply-To: <53BDA867.7090701@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/bIRL1Tc7QAqfE4LWIngaVv6xe08 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:40:35 -0000 Brian E Carpenter wrote: > On 10/07/2014 06:06, Miles Fidelman wrote: >> Stephen Farrell wrote: >>> On 09/07/14 18:14, Andrew Sullivan wrote: >>>> But I'm not sure this list is the right place to try to >>>> tell ICANN how it ought to run its process for figuring out the >>>> names-relevant transition of the IANA function. >>> I agree. Which makes it even more of a shame that icann >>> seem block-headedly intent on shuttering the mailing list >>> where that discussion would be appropriate. >>> >>> >> Kind of sums up in a sentence all the reasons that ICANN needs continued >> oversight. > Yes. I am very disillusioned by this. I agree with Lynn's suggestion > about triggering some high-level messages about this, but it suggests > that a watchdog with teeth is needed (and I'm not at all convinced that > NTIA has teeth in practice). "Teeth" generally means having the power > to fire people. > Or to chop funding. Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Thu Jul 10 02:43:24 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5661B27EF for ; Thu, 10 Jul 2014 02:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHDv7sn6_TVk for ; Thu, 10 Jul 2014 02:43:19 -0700 (PDT) Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [IPv6:2001:41c8:1:6062::d46e:bc35]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738651B27FE for ; Thu, 10 Jul 2014 02:43:19 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=firsthand.net; b=DwHLzZMcUTnHs+983aZCV7lMEN/e/r/iBcJHL0XqtTAcK7tk80vE+gOWOJmqhGrxeWR1NEN5yAmRXgJRaTyDKu3qlIsx39A72gxv3T1U/ejCkHLjrsnTveW+kopzIJIW; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from orionlocal.local (host-78-147-2-204.as13285.net [78.147.2.204]) by bmtwo.vm.bytemark.co.uk (Postfix) with ESMTPSA id 6D022E0102; Thu, 10 Jul 2014 10:43:16 +0100 (BST) Message-ID: <53BE602F.7020108@firsthand.net> Date: Thu, 10 Jul 2014 10:43:11 +0100 From: Christian de Larrinaga User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Brian E Carpenter References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> In-Reply-To: <53BDA867.7090701@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7968E588BED512C1AD9EAE1A" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pAzuF-fe07EZlS6nZlQcMhbGfR8 Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cdel@firsthand.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 09:43:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7968E588BED512C1AD9EAE1A Content-Type: multipart/alternative; boundary="------------010108030005040603030307" This is a multi-part message in MIME format. --------------010108030005040603030307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian The problem is not use of website or email it is that ICANN is going well beyond the remit that the US Government set it to facilitate a global dialogue to establish a post US governmental top down role. ICANN has a vested interest in the outcome. It is not a neutral party. It's conduct so far has determined the topics, the mechanisms, the committees, the dialogue within those groups, the representation, and now the communications tools all under its own direct management control.= This is not facilitation it is a blatant attempt to own the entire issue from top to bottom. The key response from IETF is some fraternal frankness that expresses with clarity our requirements for Registry operations in future. US.gov has spoken now IETF needs to fill any policy void left for those resources IETF is responsible for. Christian Brian E Carpenter wrote: > On 10/07/2014 06:06, Miles Fidelman wrote: >> Stephen Farrell wrote: >>> On 09/07/14 18:14, Andrew Sullivan wrote: >>>> But I'm not sure this list is the right place to try to >>>> tell ICANN how it ought to run its process for figuring out the >>>> names-relevant transition of the IANA function. >>> I agree. Which makes it even more of a shame that icann >>> seem block-headedly intent on shuttering the mailing list >>> where that discussion would be appropriate. >>> >>> >> Kind of sums up in a sentence all the reasons that ICANN needs continu= ed >> oversight. > > Yes. I am very disillusioned by this. I agree with Lynn's suggestion > about triggering some high-level messages about this, but it suggests > that a watchdog with teeth is needed (and I'm not at all convinced that= > NTIA has teeth in practice). "Teeth" generally means having the power > to fire people. > > Brian > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --=20 Christian de Larrinaga FBCS, CITP, MCMA ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel@firsthand.net ------------------------- --------------010108030005040603030307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
Brian
The problem is not use of website or email it is that ICANN is going well=20 beyond the remit that the US Government set it to facilitate a global=20 dialogue to establish a post US governmental top down role.

ICANN= has a vested interest in the outcome. It is not a neutral party. It's=20 conduct so far has determined the topics, the mechanisms, the=20 committees, the dialogue within those groups, the representation, and=20 now the communications tools all under its own direct management=20 control.

This is not facilitation it is a blatant attempt to own the entire issue from top to bottom.

The key response from IETF is some fraternal frankness that expresses with clarity our=20 requirements for Registry operations in future.=C2=A0 US.gov has spoken n= ow=20 IETF needs to fill any policy void left for those resources IETF is=20 responsible for.



Christian



Brian E=20 Carpenter wrote:
On 10/07/2014 06:06, Miles Fidelman wrote:

Stephen Farrell wrote:

On 09/07/14 18:14, Andrew =
Sullivan wrote:

But I'm not sure this list=
 is the right place to try to
tell ICANN how it ought to run its process for figuring out the
names-relevant transition of the IANA function.

I agree. Which makes it even more of a =
shame that icann
seem block-headedly intent on shuttering the mailing list
where that discussion would be appropriate.



Kind of sums up in a sentence all the r=
easons that ICANN needs continued
oversight.


Yes. I am very disillusioned by this. I agree with Lynn's suggestion
about triggering some high-level messages about this, but it suggests
that a watchdog with teeth is needed (and I'm not at all convinced that
NTIA has teeth in practice). "Teeth" generally means having the power
to fire people.

    Brian

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovt=
ech

--
Christian de=20 Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand -------------------------
+44 7989 386778
= cdel@firsthand.net
-------------------------
--------------010108030005040603030307-- --------------enig7968E588BED512C1AD9EAE1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTvmAwAAoJEO8NEF3l27YrQf4H/R0ukw6p5sqiJeGgtB7/Y9bF S80ak5gekAzlWhPW7AuLfYqELP45Kn5xqYCCLThFiKXgq3Rj2h4So3Tn9eWuMlkg pf2OLZW4YK2oH4yo1yO/0ggPtUuTWw1iqIOO3uXJA4bXLUMhNUX6dBva2xmfwbEI /dFoYYiLmACRp3THkQ48yKlnRhMuUzi8cg6SY69/ObjFZ1NXjgY70B1yXZcj4apM 8v3XohADYVdQUYdh9HcahI4gfGG0YgiFfxXRXBb4/1AoMiBNSRoVCbGQVm8vv9KT RX4y6W4nv/jkp7CeGAHfrt89nq8m04CAdAuJHswZLERQkOYo/a8lOPYLIUK0ZjA= =zVPE -----END PGP SIGNATURE----- --------------enig7968E588BED512C1AD9EAE1A-- From nobody Thu Jul 10 02:49:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9681B2825 for ; Thu, 10 Jul 2014 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL4MCMHJP_pe for ; Thu, 10 Jul 2014 02:49:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C401B27E6 for ; Thu, 10 Jul 2014 02:49:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.136.216]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6A9n0qR003147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 02:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404985753; x=1405072153; bh=iwAp4wLVL5U1ThGLpRNIXTsCFWbSSAZfoFK7Ij8/zBk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pzaACSlGs4jbnp5IxNF1DTe0FtXltkDPRH217b4HXz+n3oGqfQNjuGyc4pZlkXkEF wzj+FdemK0maFklMOYOB0dPXFoNjWOojLxMOqSFVo9JB+dOWs4AAbJvmlKtd4W2y2y voPJv71jxCGn+aX+DL0+qUdlnu8dIRpcPz0/CRa4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404985753; x=1405072153; i=@elandsys.com; bh=iwAp4wLVL5U1ThGLpRNIXTsCFWbSSAZfoFK7Ij8/zBk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LCzRquy8KYSHnVMyoW9/avO/1/neVMCehcq0u7IrrPhOUo6gm2oaBcqvokIOwH4LO Jh2B1lZijyYUoVolua8fyGHrGc8z+m7fjWBLV+H2Z6A7A7Aet+6Xrw3XvkklFfyMC6 +F22N1RKorQ89klfPQmU/xOzFdPQP/pto+vwIznw= Message-Id: <6.2.5.6.2.20140710010338.0cde2480@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Jul 2014 02:27:20 -0700 To: Alissa Cooper , Jari Arkko From: S Moonesamy In-Reply-To: <53BDA8B3.8050709@meetinghouse.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BDA8B3.8050709@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Oift7nsfpyU5KcleydhOEGtliGw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 09:49:17 -0000 Hi Alissa, Jari, I am writing to you as you are the representatives of the IETF in the matter of the IANA Transition. One of the conditions required for participation in the IANA Transition discussions is that the person must protect ICANN assets. That decision has been taken by ICANN staff [1][2]. I find it extremely difficult to accept that condition. I am curious about whether you agreed to that condition. Regards, S. Moonesamy 1. http://mm.icann.org/pipermail/ianatransition/2014/001111.html 2. http://mm.icann.org/pipermail/ianatransition/2014/001160.html From nobody Thu Jul 10 02:57:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECB81B27E6 for ; Thu, 10 Jul 2014 02:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdIhXN4H8BIq for ; Thu, 10 Jul 2014 02:57:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A69B31B2825 for ; Thu, 10 Jul 2014 02:57:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BB1C0BDFE; Thu, 10 Jul 2014 10:57:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3j04DGirqIV; Thu, 10 Jul 2014 10:57:24 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.20.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 69F6DBDCF; Thu, 10 Jul 2014 10:57:24 +0100 (IST) Message-ID: <53BE6384.5030504@cs.tcd.ie> Date: Thu, 10 Jul 2014 10:57:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cdel@firsthand.net, Brian E Carpenter References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> In-Reply-To: <53BE602F.7020108@firsthand.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Vv6_cyl0usT5PFgILSzhCcQkmEY Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 09:57:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/07/14 10:43, Christian de Larrinaga wrote: > The key response from IETF is some fraternal frankness that > expresses with clarity our requirements for Registry operations in > future. Possibly that. But I also liked what Lynn said - one of the things that I think I've seen learned by some IETF leadership is when to put up your hands and say "ok, we were wrong, the community don't like , here's what we'll do in future," that usually in response to the community rightly beating up some AD on ietf@ietf.org:-) I don't think the IESG or IAB are perfect in that respect, but when the community has (rough) consensus on a thing then that position does win I think. I think a note to Fadi or whoever within icann saying that its time that icann did the equivalent could be useful. (Though I find it hard to believe icann don't have someone watching this list, or their own, and they should've just figured out the above earlier.) S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTvmOEAAoJEC88hzaAX42iFckH/jnuROIgiMTmD0IAIcOHcVB9 sb+CRwDwNS3Ud6b68MB7+LDRUjmsh56jqwAVuerCyxGhUFwE7NE7n0L8QLg0V8Is XrnGj1cr/9AGBw28dbvusrKZJdYgzjRCu68Ax8ykHcTgxn5p3ErTPfBclejpoEEd cEsJPcH7xayQ34/Mdx4v8XhSPDzOr7qHCdKCLzOZI0hX4ph6DSqeZ4mvVyqvWDeo uk79f7o3gfAWv1W0FMDMoaTXd0luI+rLBFWp8ZeBrqrUHrqj1nXN+1waSMqKmqce 1yTZt5g+A2zixeSfC/rsTTY9wjBGG787aDeNjwGI4p4lAwhEqzzNMvptx3OSm/g= =Dcqy -----END PGP SIGNATURE----- From nobody Thu Jul 10 03:24:29 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151AB1B285F for ; Thu, 10 Jul 2014 03:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b-hV96jvYDa for ; Thu, 10 Jul 2014 03:24:27 -0700 (PDT) Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [212.110.188.53]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F051B285E for ; Thu, 10 Jul 2014 03:24:26 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=firsthand.net; b=MImeCeZxJOQAgU0BKdLr7eZdsq1JBl+hZySWBi70OtbMf4PX45bT+nJ1aPQWWv5uiSY/xRLsaLe30PlGCikL9PEXzvEPG2hUUxFDeYJ7+AcqIPy8SEaLPug4dibdIaBl; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from orionlocal.local (host-78-147-2-204.as13285.net [78.147.2.204]) by bmtwo.vm.bytemark.co.uk (Postfix) with ESMTPSA id 87E51E0102; Thu, 10 Jul 2014 11:24:23 +0100 (BST) Message-ID: <53BE69D2.9070509@firsthand.net> Date: Thu, 10 Jul 2014 11:24:18 +0100 From: Christian de Larrinaga User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Stephen Farrell References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> In-Reply-To: <53BE6384.5030504@cs.tcd.ie> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig548C5127725BE30795B4A788" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/S1FhvaIMeTBXc9wMGAHvbXIVkcA Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cdel@firsthand.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:24:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig548C5127725BE30795B4A788 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ICANN has an opportunity to row back of course. I'm not discounting Lynn's suggestion. However the intent of my point is that IETF is in danger of delegating its own responsibilities by allowing the debates to be framed to protect the interests of, and be owned and implemented by another institution that is itself a vested interested party. That is ICANN. So there is quite a bit of back peddling needed. Taking the initiative here is also important. IETF has responsibility to establish process and requirements for any future contract it directly makes without US Gov intercession with a registry operator (whether that is at IANA/ ICANN or anywhere) Brian talks about "oversight with teeth". That is looking increasingly unlikely. The alternative is undersight with teeth and that is where IETF and other bottom up communities can develop. C Stephen Farrell wrote: > > > On 10/07/14 10:43, Christian de Larrinaga wrote: > > The key response from IETF is some fraternal frankness that > > expresses with clarity our requirements for Registry operations in > > future. > > Possibly that. But I also liked what Lynn said - one of the things > that I think I've seen learned by some IETF leadership is when to > put up your hands and say "ok, we were wrong, the community don't > like , here's what we'll do in future," that usually in response > to the community rightly beating up some AD on ietf@ietf.org:-) > I don't think the IESG or IAB are perfect in that respect, but when > the community has (rough) consensus on a thing then that position > does win I think. > > I think a note to Fadi or whoever within icann saying that its > time that icann did the equivalent could be useful. (Though I find > it hard to believe icann don't have someone watching this list, or > their own, and they should've just figured out the above earlier.) > > S. --=20 Christian de Larrinaga FBCS, CITP, MCMA ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel@firsthand.net ------------------------- --------------enig548C5127725BE30795B4A788 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTvmnTAAoJEO8NEF3l27YrFWIH/3M7ywRFvGvEGhMJLw+8hDPk okIeBe5ZEvyK80YBcwaNiA4pl+qzOABFf0OYv7o98fnCj/ktv4vc9QCbe2By0AqY uNx/7+NISJX60lzvYvNqFYJ9IUyS5kWzOF11GzR1EH0Oli7fhocZmnz3xY/3bPoZ BiAT04BInb6YAufr2HaOtuYFQTKW8WQthNZRouHsUWLTLoZPMuB1zRWmTHgPbkTT u9IBGl75oXchIiBdRk/1rL3GAv6gmIjB7I5xLfwmuOVn3ZEJvCnGpeUE2OWtay8u 09yUrrb1ZzEiulk4WZhEa5S0pHpEjjaDItftBckEkvYPQl3E/fHkp6YN2sE/CDA= =X6JX -----END PGP SIGNATURE----- --------------enig548C5127725BE30795B4A788-- From nobody Thu Jul 10 04:24:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC701B288D for ; Thu, 10 Jul 2014 04:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIOCKJJALOnv for ; Thu, 10 Jul 2014 04:24:55 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1061B288C for ; Thu, 10 Jul 2014 04:24:55 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6ABOrQ0004391 for ; Thu, 10 Jul 2014 07:24:53 -0400 Received: (qmail 32242 invoked by uid 0); 10 Jul 2014 11:24:53 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 10 Jul 2014 11:24:53 -0000 Message-ID: <53BE77FB.5080705@acm.org> Date: Thu, 10 Jul 2014 07:24:43 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> In-Reply-To: <53BE6384.5030504@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140710-0, 07/10/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/2uoz0QhX8mKa4CRboVxqJ5urEtk Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:24:56 -0000 On 10-Jul-14 05:57, Stephen Farrell wrote: > I think a note to Fadi or whoever within icann saying that its > time that icann did the equivalent could be useful. (Though I find > it hard to believe icann don't have someone watching this list, or > their own, and they should've just figured out the above earlier.) I am sure they do. It may just not matter to the ones who are reading - after all these sorts of issues will be the purview of the Coordination Group. Or they may be reporting back to their bosses, who don't assign the highest priority to this issue. When you come right down to it, there is no aspect of this transition that someone somewhere isn't complaining about. They have to be doing triage on problem issues. At ICANN, as long as the Board is happy, there is little we can do to change staff's direction. Perhaps the IETF Liaison to the Board is a path you can use to communicate your feelings. BTW, I think I may have lost the thread on this. The thing we are upset about is a mailing list? If someone closed a list you all were interested it, could someone just reopen another list somewhere else? I strikes me that there is no shortage of lists on this stuff. I seem to be reading email on the IANA transition and ICANN accountability on nearly a dozen of them. But as I said, I may have lost the thread on this conversation. avri From nobody Thu Jul 10 04:48:05 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0454F1B2890 for ; Thu, 10 Jul 2014 04:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIHYwGurmrvN for ; Thu, 10 Jul 2014 04:48:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA381A03FF for ; Thu, 10 Jul 2014 04:48:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F7A8BE17; Thu, 10 Jul 2014 12:48:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDsY-lt4WtEM; Thu, 10 Jul 2014 12:47:59 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.20.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4754DBE08; Thu, 10 Jul 2014 12:47:59 +0100 (IST) Message-ID: <53BE7D6F.3040503@cs.tcd.ie> Date: Thu, 10 Jul 2014 12:47:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Avri Doria , internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> In-Reply-To: <53BE77FB.5080705@acm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/XXcQuTpgHWjTNCh7q0smJrvGBJM Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:48:03 -0000 Hiya, On 10/07/14 12:24, Avri Doria wrote: > > BTW, I think I may have lost the thread on this. The thing we are upset > about is a mailing list? Well s/upset/unhappy about/ and yes this is about the ianatransition@icann.org list. But its really now more about the ham-fistedness of icann in how and why they are closing that than the list content itself. (Though the list did have content but I'm told the "microsite" doesn't really, and there's the issue with inheriting icann rules for the microsite thing as well I suppose so I'll not bother finding out if the microsite thing has any content.) S. > If someone closed a list you all were > interested it, could someone just reopen another list somewhere else? I > strikes me that there is no shortage of lists on this stuff. I seem to > be reading email on the IANA transition and ICANN accountability on > nearly a dozen of them. > > But as I said, I may have lost the thread on this conversation. From nobody Thu Jul 10 04:51:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA631B2897 for ; Thu, 10 Jul 2014 04:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ntfo2k5WVTsE for ; Thu, 10 Jul 2014 04:51:44 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08B31A03FF for ; Thu, 10 Jul 2014 04:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5863; q=dns/txt; s=iport; t=1404993118; x=1406202718; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=tD5rqZyuBDe7Lo8RUftkRiiekNU7En/lvC5LBhHjMnY=; b=Tyn58KD4xi6txP+5HKTmDGRVCmt1rVYO64RJ1+5d2cTgJMcoCQ/w4oqM VCCybzNiwt8hu6FX5VPDGnXvfrNXCfq96kPhuZBxS5MJJcuJDKpi13PnQ xsNp5E6foYRc5mZhAlx6nOA2MuCoOXCRwaaOIoT7DlA2tuaVQ+x7/lPc5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAO99vlOtJssW/2dsb2JhbABZhynDfwGBIXWEAwEBAQMBI0sQCwshIQICDwJGBgEMCAEBEAWIIQiuV5kgF45iEQFXgneBTAEElmaEGocPjQaDRTuBOg X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208,217";a="103035571" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 10 Jul 2014 11:51:34 +0000 Received: from [10.61.165.48] ([10.61.165.48]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6ABpK8q020726; Thu, 10 Jul 2014 11:51:20 GMT Message-ID: <53BE7E38.30502@cisco.com> Date: Thu, 10 Jul 2014 13:51:20 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Lynn St.Amour" , "internetgovtech@iab.org" , Avri Doria References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010109010307070603060804" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YaJu2Oz4vtp8CI3EOE4s7nNqd-4 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:51:46 -0000 This is a multi-part message in MIME format. --------------010109010307070603060804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Lynn, Thanks for your note. > In thinking about how to turn this around, what if a few key people (say IETF and IAB Chairs) were to write to Fadi and some of his key advisors and suggest they reconsider their recent actions given how counter this is to so many principles. ICANN senior staff may just not be aware of this. I do think it would be good for the IETF and IAB chairs to say something. You're exactly right that we don't know what level this decision was made at. And it's been executed. What I'm concerned about (in response to Avri really) is two things: first, that the decision was made by someone unknown to us, absent any discussion, that caught many by surprise; and second that the result requires acceptance of terms that ICANN ought not impose. As to what communication vehicles exist, it also seems to me that staff jumped the gun and should have left this matter to the CG. A change of charter seems in order, but that gets us to your next point. > > And, maybe the CG should have a statement of "what good looks like" or of what one should reasonably expect from these processes. This is where the IETF and IAB can help - you have far more experience with these types of community and consensus processes than any other group. These are just some thoughts... The NTIA has set the yard stick for broad community consensus. To measure that I would hope that the CG goes back to its communities. Measuring the aggregate proposal through other yard sticks will be hard. For one, it takes a long time to develop those procedures. As you say, the IETF's are perhaps the most mature, and we've spent about half my life developing them. Therefore, one ground rule could be that any mailing list that the CG uses will NOT be used as a measure of consensus, that such measures will happen elsewhere. That means that the list would be informative, but not have normative value. To reinforce the point, when it becomes clear that a matter should rest with a particular body (say the RIRs for addresses) that the discussion should move there and not continue. Additionally, I would suggest that participants be reminded that their contributions to any list should be measured by the weight of their ideas and not the volume of their email. By the way, on *this* list I would hope people would observe this rule. Eliot --------------010109010307070603060804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Lynn,

Thanks for your note.

In thinking about how to turn this around, what if a few key people (say IETF and IAB Chairs) were to write to Fadi and some of his key advisors and suggest they reconsider their recent actions given how counter this is to so many principles.  ICANN senior staff may just not be aware of this.

I do think it would be good for the IETF and IAB chairs to say something.  You're exactly right that we don't know what level this decision was made at.  And it's been executed.  What I'm concerned about (in response to Avri really)  is two things: first, that the decision was made by someone unknown to us, absent any discussion, that caught many by surprise; and second that the result requires acceptance of terms that ICANN ought not impose.  As to what communication vehicles exist, it also seems to me that staff jumped the gun and should have left this matter to the CG.  A change of charter seems in order, but that gets us to your next point.


And, maybe the CG should have a statement of "what good looks like" or of what one should reasonably expect from these processes.  This is where the IETF and IAB can help - you have far more experience with these types of community and consensus processes than any other group.

These are just some thoughts...

The NTIA has set the yard stick for broad community consensus.  To measure that I would hope that the CG goes back to its communities.  Measuring the aggregate proposal through other yard sticks will be hard.  For one, it takes a long time to develop those procedures.  As you say, the IETF's are perhaps the most mature, and we've spent about half my life developing them.  Therefore, one ground rule could be that any mailing list that the CG uses will NOT be used as a measure of consensus, that such measures will happen elsewhere.  That means that the list would be informative, but not have normative value.  To reinforce the point, when it becomes clear that a matter should rest with a particular body (say the RIRs for addresses) that the discussion should move there and not continue.

Additionally, I would suggest that participants be reminded that their contributions to any list should be measured by the weight of their ideas and not the volume of their email.  By the way, on this list I would hope people would observe this rule.

Eliot

--------------010109010307070603060804-- From nobody Thu Jul 10 05:14:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1DA1A0407 for ; Thu, 10 Jul 2014 05:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6njEMSQ5reCJ for ; Thu, 10 Jul 2014 05:13:52 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id 809031B28A2 for ; Thu, 10 Jul 2014 05:13:52 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6ACDohR012972 for ; Thu, 10 Jul 2014 08:13:50 -0400 Received: (qmail 31586 invoked by uid 0); 10 Jul 2014 12:13:50 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 10 Jul 2014 12:13:50 -0000 Message-ID: <53BE8374.7090101@acm.org> Date: Thu, 10 Jul 2014 08:13:40 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <53BE7D6F.3040503@cs.tcd.ie> In-Reply-To: <53BE7D6F.3040503@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140710-0, 07/10/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ntfY2KRspcgMIbbMwPBs-vGDGvg Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:13:59 -0000 On 10-Jul-14 07:47, Stephen Farrell wrote: > But its really now more > about the ham-fistedness of icann in how and why they > are closing that than the list content itself. Ah, I am sure the ham-fistedness complaint line is quite long. Probably just need to wait in the queue. avri From nobody Thu Jul 10 05:20:55 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47291B2888 for ; Thu, 10 Jul 2014 05:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4EqdnjVDumJ for ; Thu, 10 Jul 2014 05:20:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 246441A04AC for ; Thu, 10 Jul 2014 05:20:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 873E9BE16; Thu, 10 Jul 2014 13:20:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3pQstotz0so; Thu, 10 Jul 2014 13:20:47 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.20.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7A204BE08; Thu, 10 Jul 2014 13:20:47 +0100 (IST) Message-ID: <53BE851F.1090803@cs.tcd.ie> Date: Thu, 10 Jul 2014 13:20:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Avri Doria , internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <53BE7D6F.3040503@cs.tcd.ie> <53BE8374.7090101@acm.org> In-Reply-To: <53BE8374.7090101@acm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/t8U9I4bHmXr1iHGdnpcCXXH_XtA Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:20:53 -0000 On 10/07/14 13:13, Avri Doria wrote: > > On 10-Jul-14 07:47, Stephen Farrell wrote: >> > But its really now more >> > about the ham-fistedness of icann in how and why they >> > are closing that than the list content itself. > > Ah, I am sure the ham-fistedness complaint line is quite long. Probably > just need to wait in the queue. Or not. For a case like this where we're running an open process that kind of error needs to be openly beaten up on IMO. I think fixing it only via a quiet word in the ear is actually less desirable And anyway, I've no history myself with icann, so I'm coming to their ineptitude fresh enough to whine a bit;-) S. From nobody Thu Jul 10 06:03:02 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF61B28E7 for ; Thu, 10 Jul 2014 06:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Acu0gtfLdxPP for ; Thu, 10 Jul 2014 06:02:46 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EB71B28D2 for ; Thu, 10 Jul 2014 06:02:46 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X5DwH-000N3i-LS; Thu, 10 Jul 2014 08:59:05 -0400 Date: Thu, 10 Jul 2014 09:02:35 -0400 From: John C Klensin To: Stephen Farrell , Avri Doria , internetgovtech@iab.org Message-ID: <8AC511E5FFAA7DF2E5777A31@JcK-HP8200.jck.com> In-Reply-To: <53BE851F.1090803@cs.tcd.ie> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <53BE7D6F.3040503@cs.tcd.ie> <53BE8374.7090101@acm.org> <53BE851F.1090803@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/GEDPiHEilpTvBBDqhyIZtjeXXl0 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:02:57 -0000 --On Thursday, July 10, 2014 13:20 +0100 Stephen Farrell wrote: > > > On 10/07/14 13:13, Avri Doria wrote: >> >> On 10-Jul-14 07:47, Stephen Farrell wrote: >>> > But its really now more >>> > about the ham-fistedness of icann in how and why they >>> > are closing that than the list content itself. >> >> Ah, I am sure the ham-fistedness complaint line is quite >> long. Probably just need to wait in the queue. > > Or not. For a case like this where we're running an open > process that kind of error needs to be openly beaten up > on IMO. I think fixing it only via a quiet word in the ear > is actually less desirable Usually, I would agree. But --deliberately stating this as a hypothetical and without commenting on or trying to extrapolate from prior ICANN behavior -- suppose you had an organization with a long history of reacting to public criticism with defensiveness, denial, stonewalling, coverups, or what, in some cultures, would be called "fancy footwork". Even if there were less of a pattern but some tendencies toward reactions of that type, someone observing the problem would be faced with a tactical choice between a pair of goals: * If the main goal was the get the problem fixed, pointing out the problem quietly would probably have better odds of success. * If the main goal was to hold the organization's feet to the fire with the hope that similar situations would be avoided in the future but little expectation of getting the present one fixed (at least without loss of a lot of time and the shedding of real or virtual blood), then making a public stink would probably be the better choice. And this sort of thing and the need to consider the possibility of reactions other than "yes, that is a problem, let's get it fixed" is why many people in our community prefer working with emotionless computers and networks to dealing with humans. :-( best, john From nobody Thu Jul 10 06:29:34 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE281A0535 for ; Thu, 10 Jul 2014 06:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXYLoalj-kM5 for ; Thu, 10 Jul 2014 06:29:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE641B28F0 for ; Thu, 10 Jul 2014 06:29:28 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB242.namprd06.prod.outlook.com (10.242.191.142) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 13:29:25 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.41]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.214]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 13:29:25 +0000 From: Dan York To: Avri Doria Thread-Topic: [Internetgovtech] Transition to the web Thread-Index: AQHPmv8wihHRc8gERUWDMbx2tUdK4ZuXtAOAgAA4YoCAAAsbAIAABNyAgAAOL4CAAACUgIAAKoaAgADbFoCAAAP4AIAAGGaAgAAi1YA= Date: Thu, 10 Jul 2014 13:29:24 +0000 Message-ID: <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> In-Reply-To: <53BE77FB.5080705@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [74.75.92.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(164054003)(24454002)(189002)(199002)(15454003)(21056001)(99396002)(80022001)(16236675004)(76176999)(77096002)(54356999)(106356001)(110136001)(50986999)(93886003)(107046002)(307094003)(83322001)(99286002)(86362001)(106116001)(95666004)(2656002)(87936001)(81342001)(92566001)(92726001)(66066001)(31966008)(15975445006)(79102001)(33656002)(64706001)(4396001)(101416001)(20776003)(19580405001)(83716003)(15202345003)(36756003)(19580395003)(81542001)(85852003)(46102001)(105586002)(83072002)(74502001)(82746002)(76482001)(85306003)(77982001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB242; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_25D6CC36C17D46139F4EF9CC3C6714B6isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/X7wJ27VfC9rMFc9th-cHZNMnXAQ Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:29:31 -0000 --_000_25D6CC36C17D46139F4EF9CC3C6714B6isocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I find myself agreeing with Avri a bit here that I'm not entirely clear on = what the issue is... On Jul 10, 2014, at 7:24 AM, Avri Doria > wrote: BTW, I think I may have lost the thread on this. The thing we are upset about is a mailing list? I get that ICANN shut down the ianatransition@icann.org mailing list and asked everyone to move to a web discussion f= orum: http://mm.icann.org/pipermail/ianatransition/2014/001160.html I get that they did this without a whole lot of public notice and without m= uch discussion. I further understand that when you go to that web discuss= ion forum at: http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47 you are agreeing by participating to abide by their Standards of Behavior[1= ], Privacy Policy[2], and Terms of Service[3]: [1] https://www.icann.org/resources/pages/expected-standards-2012-05-15-en [2] https://www.icann.org/resources/pages/privacy-2012-12-21-en [3] https://www.icann.org/resources/pages/tos-2014-06-13-en I've scanned through all three and they all seem to be the typical kinds of= documents you see associated with discussion forums and online sites. Qui= te frankly, I'm glad to see they have these documents posted because it pro= vides a framework that can be used to deal with trolls and other people who= are being abusive. >From some comments here on the list I gather there is a concern about one b= ullet item in the Standards of Behavior [1]: =95 Protect the organization=92s assets and ensure their efficient and effe= ctive use. Which I personally took as "don't DDoS the website or otherwise do bad thin= gs to ICANN's infrastructure", but I gather others are perhaps interpreting= as thinking of IANA as an ICANN "asset" and thereby biasing the discussion= . Is that the primary concern here? If so, could we perhaps suggest to ICA= NN some clarifying language for this "Standards of Behavior" document to ad= dress the concerns? Perhaps they would be fine making modifications to the= document. Additionally, would it not be reasonable to assume that if these documents = apply to an ICANN-hosted web discussion forum they would *ALSO* apply to an= ICANN-hosted mailing list? Perhaps that was never explicitly stated in t= he sign-up page for the mailing list, but I could see a message from "ICANN= staff" going out to the mailing list stating something along these lines. = Many or most of us have probably been on lists where this is done from time= to time by the list admins. It seems to me to be a reasonable expectation= . If people are still unhappy with all three of these documents then perhaps,= as Avri noted, discussions should take place on some of the other lists an= d forums that are out there on this issue. Or am I missing something else here? Thanks, Dan --_000_25D6CC36C17D46139F4EF9CC3C6714B6isocorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I find myself agreeing with Avri a bit here that I'm not entirely clear on = what the issue is...

On Jul 10, 2014, at 7:24 AM, Avri Doria <avri@acm.org>
 wrote:

BTW, I think I may have lost the thread on this. =  The thing we are upset
about is a mailing list?  

I get that ICANN shut down the ianatransition@icann.org mailing list and asked everyone to move t= o a web discussion forum:


I get that they did this without a whole lot of public notice and with= out much discussion.   I further understand that when you go to that w= eb discussion forum at:


you are agreeing by participating to abide by their Standards of Behav= ior[1], Privacy Policy[2], and Terms of Service[3]:

[2] https://www.icann.org/resources/pages/privacy-2012-12-21-en<= /div>

I've scanned through all three and they all seem to be the typical kin= ds of documents you see associated with discussion forums and online sites.=  Quite frankly, I'm glad to see they have these documents posted beca= use it provides a framework that can be used to deal with trolls and other people who are being abusive.

From some comments here on the list I gather there is a concern about = one bullet item in the Standards of Behavior [1]:

=95= Protect the organization=92s assets and ensure their efficient and ef= fective use.

Which I personally took as "don't DDoS the website or otherwise d= o bad things to ICANN's infrastructure", but I gather others are perha= ps interpreting as thinking of IANA as an ICANN "asset" and there= by biasing the discussion.

Is that the primary concern here?    If so, could we perhaps= suggest to ICANN some clarifying language for this "Standards of Beha= vior" document to address the concerns?  Perhaps they would be fi= ne making modifications to the document.

Additionally, would it not be reasonable to assume that if these docum= ents apply to an ICANN-hosted web discussion forum they would *ALSO* apply = to an ICANN-hosted mailing list?   Perhaps that was never explicitly s= tated in the sign-up page for the mailing list, but I could see a message from "ICANN staff" going out to = the mailing list stating something along these lines. Many or most of us ha= ve probably been on lists where this is done from time to time by the list = admins.  It seems to me to be a reasonable expectation.

If people are still unhappy with all three of these documents then per= haps, as Avri noted, discussions should take place on some of the other lis= ts and forums that are out there on this issue.

Or am I missing something else here?

Thanks,
Dan






--_000_25D6CC36C17D46139F4EF9CC3C6714B6isocorg_-- From nobody Thu Jul 10 06:44:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8F1B2906 for ; Thu, 10 Jul 2014 06:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmNXbSShBh5H for ; Thu, 10 Jul 2014 06:44:19 -0700 (PDT) Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id 35F7D1B28FF for ; Thu, 10 Jul 2014 06:44:19 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) (authenticated bits=0) by hans.rg.net (8.14.9/8.14.7) with ESMTP id s6ADiG5m069743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jul 2014 13:44:16 GMT (envelope-from llynch@civil-tongue.net) Date: Thu, 10 Jul 2014 06:44:16 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Dan York In-Reply-To: <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> Message-ID: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; boundary="===============7862086802903934368==" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/qrlaU9qYE4hGAGYZrstrGiVklXY Cc: "internetgovtech@iab.org" , Avri Doria Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:44:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============7862086802903934368== Content-Type: TEXT/Plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 10 Jul 2014, Dan York wrote: > I find myself agreeing with Avri a bit here that I'm not entirely clear > on what the issue is... Dan - For me this is about inclusion by default (the push of email to each user with the opening for response in your own time) vs the need to constantly check in on a coversation (the pull of on line forums with the requirement to fit yourself into the correct thread). The flow of a list works better for me and it's easy enough to state norms for participstion when the conversation drifts. I'd prefer to opt for tacit inclusion - you lose folks with every gate you put in the path. typing in alpine on a free bsd server... -Lucy > On Jul 10, 2014, at 7:24 AM, Avri Doria > > wrote: > > BTW, I think I may have lost the thread on this. The thing we are upset > about is a mailing list? > > I get that ICANN shut down the ianatransition@icann.org mailing list and asked everyone to move to a web discussion forum: > > http://mm.icann.org/pipermail/ianatransition/2014/001160.html > > I get that they did this without a whole lot of public notice and without much discussion. I further understand that when you go to that web discussion forum at: > > http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47 > > you are agreeing by participating to abide by their Standards of Behavior[1], Privacy Policy[2], and Terms of Service[3]: > > [1] https://www.icann.org/resources/pages/expected-standards-2012-05-15-en > [2] https://www.icann.org/resources/pages/privacy-2012-12-21-en > [3] https://www.icann.org/resources/pages/tos-2014-06-13-en > > I've scanned through all three and they all seem to be the typical kinds of documents you see associated with discussion forums and online sites. Quite frankly, I'm glad to see they have these documents posted because it provides a framework that can be used to deal with trolls and other people who are being abusive. > >> From some comments here on the list I gather there is a concern about one bullet item in the Standards of Behavior [1]: > > • Protect the organization’s assets and ensure their efficient and effective use. > > Which I personally took as "don't DDoS the website or otherwise do bad things to ICANN's infrastructure", but I gather others are perhaps interpreting as thinking of IANA as an ICANN "asset" and thereby biasing the discussion. > > Is that the primary concern here? If so, could we perhaps suggest to ICANN some clarifying language for this "Standards of Behavior" document to address the concerns? Perhaps they would be fine making modifications to the document. > > Additionally, would it not be reasonable to assume that if these documents apply to an ICANN-hosted web discussion forum they would *ALSO* apply to an ICANN-hosted mailing list? Perhaps that was never explicitly stated in the sign-up page for the mailing list, but I could see a message from "ICANN staff" going out to the mailing list stating something along these lines. Many or most of us have probably been on lists where this is done from time to time by the list admins. It seems to me to be a reasonable expectation. > > If people are still unhappy with all three of these documents then perhaps, as Avri noted, discussions should take place on some of the other lists and forums that are out there on this issue. > > Or am I missing something else here? > > Thanks, > Dan > > > > > > > --===============7862086802903934368== Content-Type: TEXT/PLAIN; charset=us-ascii Content-ID: Content-Description: Content-Disposition: inline _______________________________________________ Internetgovtech mailing list Internetgovtech@iab.org https://www.iab.org/mailman/listinfo/internetgovtech --===============7862086802903934368==-- From nobody Thu Jul 10 06:48:46 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FA41B28F1 for ; Thu, 10 Jul 2014 06:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5xyNqARvuLr for ; Thu, 10 Jul 2014 06:48:41 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7881A0502 for ; Thu, 10 Jul 2014 06:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5549; q=dns/txt; s=iport; t=1405000104; x=1406209704; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7eXwNoNywTLe7eDGct8MuEdiTmIXkGbgTBLNRL7R3ik=; b=dLwJQFzDJ666RskLVs05jy29W0eTvfmdkW4NeSVfklI3sNBUATV3X0gw rnGpLOJElvg6n0Z2tkNuqcH1XmLphRdOEFQUFr+YkjucKVoMlBj2haeeY p3BMCkabO3M9q0KHQWCgTUGnoJdSuwdiSX5zaHp/zTvKWYLzCIAzQgAqQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEACSZvlOtJssW/2dsb2JhbABZg2CDSbw9h0IBgSF1hAMBAQEDASNLCgEFCwsYCRYIAwICCQMCAQIBNBEGAQwBBQIBAYg2CA2uV5kdF49EBgGCd4FMAQSbAIcPjQaDRTsv X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208,217";a="107127525" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 10 Jul 2014 13:48:21 +0000 Received: from [10.61.207.181] ([10.61.207.181]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6ADmc0g030913; Thu, 10 Jul 2014 13:48:38 GMT Message-ID: <53BE99B6.3030604@cisco.com> Date: Thu, 10 Jul 2014 15:48:38 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dan York , Avri Doria References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> In-Reply-To: <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040505020008080805010801" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pVO8jsnifz02p93v5mnJijkbnx4 Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:48:43 -0000 This is a multi-part message in MIME format. --------------040505020008080805010801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dan, On 7/10/14, 3:29 PM, Dan York wrote: > I find myself agreeing with Avri a bit here that I'm not entirely > clear on what the issue is... > > On Jul 10, 2014, at 7:24 AM, Avri Doria > > wrote: > >> BTW, I think I may have lost the thread on this. The thing we are upset >> about is a mailing list? > > I get that ICANN shut down the ianatransition@icann.org > mailing list and asked everyone to > move to a web discussion forum: > > http://mm.icann.org/pipermail/ianatransition/2014/001160.html > > I get that they did this without a whole lot of public notice and > without much discussion. s/much/*any*/ > I further understand that when you go to that web discussion forum at: > > http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47 > > you are agreeing by participating to abide by their Standards of > Behavior[1], Privacy Policy[2], and Terms of Service[3]: > > [1] https://www.icann.org/resources/pages/expected-standards-2012-05-15-en > [2] https://www.icann.org/resources/pages/privacy-2012-12-21-en > [3] https://www.icann.org/resources/pages/tos-2014-06-13-en > > I've scanned through all three and they all seem to be the typical > kinds of documents you see associated with discussion forums and > online sites. It's [1]. The top of that list is a doozy. See Andrew's note at http://mm.icann.org/pipermail/ianatransition/2014/001134.html. He was quite specific as to his concerns that I share. Eliot --------------040505020008080805010801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dan,

On 7/10/14, 3:29 PM, Dan York wrote:
I find myself agreeing with Avri a bit here that I'm not entirely clear on what the issue is...

On Jul 10, 2014, at 7:24 AM, Avri Doria <avri@acm.org>
 wrote:

BTW, I think I may have lost the thread on this.  The thing we are upset
about is a mailing list?  

I get that ICANN shut down the ianatransition@icann.org mailing list and asked everyone to move to a web discussion forum:


I get that they did this without a whole lot of public notice and without much discussion.  

s/much/any/


I further understand that when you go to that web discussion forum at:


you are agreeing by participating to abide by their Standards of Behavior[1], Privacy Policy[2], and Terms of Service[3]:


I've scanned through all three and they all seem to be the typical kinds of documents you see associated with discussion forums and online sites. 

It's [1].  The top of that list is a doozy.  See Andrew's note at http://mm.icann.org/pipermail/ianatransition/2014/001134.html.  He was quite specific as to his concerns that I share.

Eliot
--------------040505020008080805010801-- From nobody Thu Jul 10 06:53:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BFE1B28F1 for ; Thu, 10 Jul 2014 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOQoXYQ48Dz6 for ; Thu, 10 Jul 2014 06:53:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBF4C1A05CB for ; Thu, 10 Jul 2014 06:53:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E797BE08; Thu, 10 Jul 2014 14:53:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpEiynILuCsw; Thu, 10 Jul 2014 14:53:10 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.20.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BEDA7BDFE; Thu, 10 Jul 2014 14:53:10 +0100 (IST) Message-ID: <53BE9AC6.8080103@cs.tcd.ie> Date: Thu, 10 Jul 2014 14:53:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eliot Lear , Dan York , Avri Doria References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <53BE99B6.3030604@cisco.com> In-Reply-To: <53BE99B6.3030604@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/j8szcT-lBenJZ9gKamAY5qMpZOc Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:53:14 -0000 On 10/07/14 14:48, Eliot Lear wrote: >> > >> > http://mm.icann.org/pipermail/ianatransition/2014/001160.html >> > >> > I get that they did this without a whole lot of public notice and >> > without much discussion. > s/much/*any*/ Right. And using a pseudonymous sender for those mails, which is not ideal from an accountability perspective. And ignoring a thread similar to this one on that list both at the time of the initial posting and this week. Basically, they screwed this up mightily and still are showing no recognition of that. S. From nobody Thu Jul 10 07:30:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841091A083D for ; Thu, 10 Jul 2014 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTzbDNcmqsJF for ; Thu, 10 Jul 2014 07:30:45 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9264C1A07A1 for ; Thu, 10 Jul 2014 07:30:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id F0A4DCC09C for ; Thu, 10 Jul 2014 10:30:44 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O4jxtGtXEyU5 for ; Thu, 10 Jul 2014 10:30:36 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 3E7A4CC0A4 for ; Thu, 10 Jul 2014 10:30:36 -0400 (EDT) Message-ID: <53BEA38B.7040402@meetinghouse.net> Date: Thu, 10 Jul 2014 10:30:35 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: "internetgovtech@iab.org" References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <53BE99B6.3030604@cisco.com> <53BE9AC6.8080103@cs.tcd.ie> In-Reply-To: <53BE9AC6.8080103@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/zuh9OalZ9KKAgiNTrMU3fWSLMFQ Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:30:46 -0000 It occurs to me that, a few messages back, Lynn St.Amour wrote: > In thinking about how to turn this around, what if a few key people > (say IETF and IAB Chairs) were to write to Fadi and some of his key > advisors and suggest they reconsider their recent actions given how > counter this is to so many principles. > > ICANN senior staff may just not be aware of this. And, maybe the CG > should have a statement of "what good looks like" or of what one > should reasonably expect from these processes. This is where the IETF > and IAB can help - you have far more experience with these types of > community and consensus processes than any other group. I kind of wonder if, by now, some folks HAVE written to Fadi. If not, perhaps the question becomes why not? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Thu Jul 10 07:30:58 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4C51A0347 for ; Thu, 10 Jul 2014 07:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm8H9XYGiaDD for ; Thu, 10 Jul 2014 07:30:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFA81B290A for ; Thu, 10 Jul 2014 07:30:52 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB241.namprd06.prod.outlook.com (10.242.191.148) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 14:30:49 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.41]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.214]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 14:30:49 +0000 From: Dan York To: Eliot Lear Thread-Topic: [Internetgovtech] Transition to the web Thread-Index: AQHPmv8wihHRc8gERUWDMbx2tUdK4ZuXtAOAgAA4YoCAAAsbAIAABNyAgAAOL4CAAACUgIAAKoaAgADbFoCAAAP4AIAAGGaAgAAi1YCAAAVgAIAAC8CA Date: Thu, 10 Jul 2014 14:30:47 +0000 Message-ID: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <53BE99B6.3030604@cisco.com> In-Reply-To: <53BE99B6.3030604@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [74.75.92.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(164054003)(189002)(24454002)(36756003)(86362001)(106116001)(16236675004)(83322001)(85852003)(81342001)(64706001)(81542001)(74502001)(66066001)(92726001)(19580395003)(106356001)(2656002)(31966008)(77096002)(95666004)(107046002)(92566001)(110136001)(20776003)(93886003)(83072002)(21056001)(99396002)(4396001)(33656002)(85306003)(99286002)(76176999)(76482001)(82746002)(50986999)(80022001)(77982001)(15975445006)(54356999)(87936001)(79102001)(15202345003)(19580405001)(83716003)(105586002)(46102001)(101416001)(104396001)(437434002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB241; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_FA0F27D5506048D19F214938662F803Aisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RICWIaIDfRTgXWFzGSOAwK8zvFc Cc: "internetgovtech@iab.org" , Avri Doria Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:30:56 -0000 --_000_FA0F27D5506048D19F214938662F803Aisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eliot, On Jul 10, 2014, at 9:48 AM, Eliot Lear > wrote: I've scanned through all three and they all seem to be the typical kinds of= documents you see associated with discussion forums and online sites. It's [1]. The top of that list is a doozy. See Andrew's note at http://mm= .icann.org/pipermail/ianatransition/2014/001134.html. He was quite specifi= c as to his concerns that I share. Ah, gotcha. That message from Andrew is VERY helpful. He went through the= Standards of Behavior with a finer attention to detail than I did and I do= understand and agree with his concerns. Thank you for clarifying the issue and also for the indication that there w= as no real discussion about this transition on the email lists. I guess the larger question I still have is whether it is reasonable to ass= ume that an ICANN-hosted mailing list would operate under the same SoB and = ToS as the online forum. To me I think it probably *is*, although that may= not have been explicitly stated in any list communication or pages. The other question is: what do people want as an outcome? 1. Do we want ICANN to reinstate the ianatransition email list? 2. Do we want ICANN to change its Standards of Behavior to address the conc= erns raised by Andrew and others? 3. Do we want to as a group move the discussion to some other non-ICANN for= um and try to encourage people to go there? 4. Do we want "someone" from ICANN to say that they didn't handle this tran= sition terribly well? (but then what?) Or is there something else people want? What is the action we want to see = coming out of this discussion? Thanks, Dan --_000_FA0F27D5506048D19F214938662F803Aisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Eliot,

On Jul 10, 2014, at 9:48 AM, Eliot Lear <lear@cisco.com>
 wrote:

I've scanned through all three and they all seem to be the typical kin= ds of documents you see associated with discussion forums and online sites.=  

It's [1].  The top of that list is a doozy.  See Andrew's note at= http://mm.icann.org/pipermail/ianatransition/2014/001134.html.  He= was quite specific as to his concerns that I share.

Ah, gotcha.  That message from Andrew is VERY helpful.  He w= ent through the Standards of Behavior with a finer attention to detail than= I did and I do understand and agree with his concerns.

Thank you for clarifying the issue and also for the indication that th= ere was no real discussion about this transition on the email lists.

I guess the larger question I still have is whether it is reasonable t= o assume that an ICANN-hosted mailing list would operate under the same SoB= and ToS as the online forum.  To me I think it probably *is*, althoug= h that may not have been explicitly stated in any list communication or pages.

The other question is: what do people want as an outcome?

1. Do we want ICANN to reinstate the ianatransition email list?

2. Do we want ICANN to change its Standards of Behavior to address the= concerns raised by Andrew and others?

3. Do we want to as a group move the discussion to some other non-ICAN= N forum and try to encourage people to go there?

4. Do we want "someone" from ICANN to say that they didn't h= andle this transition terribly well?  (but then what?)

Or is there something else people want?  What is the action we wa= nt to see coming out of this discussion?

Thanks,
Dan
--_000_FA0F27D5506048D19F214938662F803Aisocorg_-- From nobody Thu Jul 10 07:41:00 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3F1A0A83 for ; Thu, 10 Jul 2014 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFoEETgceTbz for ; Thu, 10 Jul 2014 07:40:53 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id E661A1A07AB for ; Thu, 10 Jul 2014 07:40:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 7176CCC0A7 for ; Thu, 10 Jul 2014 10:40:52 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AiWQxvgHEBFu for ; Thu, 10 Jul 2014 10:40:43 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 2D9F5CC0A4 for ; Thu, 10 Jul 2014 10:40:42 -0400 (EDT) Message-ID: <53BEA5EA.1060703@meetinghouse.net> Date: Thu, 10 Jul 2014 10:40:42 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: "internetgovtech@iab.org" References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <53BE99B6.3030604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/g3b9zJGu9sqfPX6twep1QVcW2BA Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:40:53 -0000 Dan York wrote: > I guess the larger question I still have is whether it is reasonable > to assume that an ICANN-hosted mailing list would operate under the > same SoB and ToS as the online forum. To me I think it probably *is*, > although that may not have been explicitly stated in any list > communication or pages. > > The other question is: what do people want as an outcome? > > 1. Do we want ICANN to reinstate the ianatransition email list? yes > > 2. Do we want ICANN to change its Standards of Behavior to address the > concerns raised by Andrew and others? > > 3. Do we want to as a group move the discussion to some other > non-ICANN forum and try to encourage people to go there? there do seem to be lots of other forums already in place > > 4. Do we want "someone" from ICANN to say that they didn't handle this > transition terribly well? (but then what?) absolutely, and it would be useful to know how the decision was made, and at what level of the organization -- that, by itself, would be a useful input into discussion of how much oversight of ICANN is needed, going forward perhaps a related matter: it sure would be interesting to get some feedback on to what extent anybody at ICANN was actually paying attention to input from list discussions > > Or is there something else people want? What is the action we want to > see coming out of this discussion? > Perhaps some direct recognition, by the transition group, that how ICANN has handled community input and discussion, is in itself an important consideration as transition planning goes forward. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Thu Jul 10 07:41:46 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B05C1A0A8A for ; Thu, 10 Jul 2014 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJUxI7N4ho61 for ; Thu, 10 Jul 2014 07:41:43 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75BE1A0A83 for ; Thu, 10 Jul 2014 07:41:43 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so3417254yha.40 for ; Thu, 10 Jul 2014 07:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HsyH5QV+SlmLMiDQxrqq5PWiPuwVhVelcnj6Oh32Yrs=; b=p2sVpRIdB022wXO8f1HY/ise+irU4egaIIU5Pfsib6FKV6Zf708Ls6U8rjvShkTwjQ +Ge0mHUWLJfM8N8YTj7S2MW/lQAu3r9d6hHkMEy9qerLUdOHczcYkCdXB7TmYKIgdIrk dsDpUA3ATYSP+qoFZnpTc8jHp7i2O5dbYsM49uoh7yv50Cm9m9ss7CAEe/ja3pHrum44 49aP2ccASVzVH8kprDJ+ANwO9vFW2+ImHv/fq3/B2L9XMtZTOj6Ou4IGCn/6+1mkwX// lDUeBV10fEwwc7GfUiwCRF5JSJwqYOHsqD7fyUpl2iiNDAEOHrV8uyitDbwtYkZ4e5i5 fwRA== X-Received: by 10.236.91.229 with SMTP id h65mr35776478yhf.89.1405003303089; Thu, 10 Jul 2014 07:41:43 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:605f:bb2e:438a:494e]) by mx.google.com with ESMTPSA id c25sm18175234yhn.3.2014.07.10.07.41.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 07:41:42 -0700 (PDT) Message-ID: <53BEA622.8000300@gmail.com> Date: Thu, 10 Jul 2014 11:41:38 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dan York , Eliot Lear References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <53BE99B6.3030604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WdjMRXYUwPdllsFV3NzdxB_O13g Cc: "internetgovtech@iab.org" , Avri Doria Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:41:45 -0000 Hello! On 7/10/14, 11:30 AM, Dan York wrote: > Eliot, > ... snip.... > > I guess the larger question I still have is whether it is reasonable to > assume that an ICANN-hosted mailing list would operate under the same > SoB and ToS as the online forum. To me I think it probably *is*, > although that may not have been explicitly stated in any list > communication or pages. Good point. However, MLs being what they are, everyone still keeps a copy of messages. There is further public record of all that is discussed and even if ICANN would take the misguided step of deleting messages from the ML archive, the messages would still be there. > > The other question is: what do people want as an outcome? > > 1. Do we want ICANN to reinstate the ianatransition email list? Yes > > 2. Do we want ICANN to change its Standards of Behavior to address the > concerns raised by Andrew and others? Yes > > 3. Do we want to as a group move the discussion to some other non-ICANN > forum and try to encourage people to go there? > Not necessarily. I still believe that a properly-behaving and adequately-supervised ICANN is still the best venue for this discussion. > 4. Do we want "someone" from ICANN to say that they didn't handle this > transition terribly well? (but then what?) Not necessarily. It would be however helpful to have some 'mea culpa'. > > Or is there something else people want? What is the action we want to > see coming out of this discussion? > > Thanks, > Dan Thank you for transforming the focus from catharsis into actions :-) -Carlos > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > From nobody Thu Jul 10 07:42:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602501A0A83 for ; Thu, 10 Jul 2014 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AUeAQRY0ZNw for ; Thu, 10 Jul 2014 07:42:19 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE211A01F4 for ; Thu, 10 Jul 2014 07:42:19 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id w7so7847877qcr.7 for ; Thu, 10 Jul 2014 07:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=54hZUdB9mdfm48qRF7SPSFXaTZv8G6i/BdOmWA96F/U=; b=AtPrqb6xQjR/IjT6SDKPGiiDBsjX41MIhgSSYoLM3vKsC7EHG0iqRxI0BETq8BM4Y5 g11URcsvIoSpvsTKUHhqsEDNkDP81AIORTeg39MvEJPQICKSFrTRF2lv4uCFYuTaWigJ mGo0g7dTdoG5s20BdkmEozxw6U7rPNZLQMpTqa40ncKJmAUG3Zi6ZDptfpcEA3UM07Fj cGssI/GFkdQRPqX0maQ/elrVPZq+rE2xOn+OfJSh3VeMYn9nc7Z7/+ag9jrNPuzB6pi6 Y7sKt3XjZFP5BpdNFlwkxNyVmSWF4Dsirk2AL4oQ1QlYuaWQRkfsJZkWBIHhnk2zTtuN rgqQ== MIME-Version: 1.0 X-Received: by 10.224.134.201 with SMTP id k9mr81736674qat.59.1405003338598; Thu, 10 Jul 2014 07:42:18 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Thu, 10 Jul 2014 07:42:18 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Thu, 10 Jul 2014 07:42:18 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> Date: Thu, 10 Jul 2014 15:42:18 +0100 Message-ID: From: Seun Ojedeji To: Lucy Lynch Content-Type: multipart/alternative; boundary=047d7b5d25a8e7ceae04fdd7d443 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Of0OR8_yh0_r4h17H0gtSx5CDm0 Cc: internetgovtech@iab.org, avri , Dan York Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:42:26 -0000 --047d7b5d25a8e7ceae04fdd7d443 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with the view stated by Lucy, it's not about discussing on another list. For me it's just the fact that ICANN seem not to care on this one by not making any attempt to address all the comments by the community. This is a community process that exceed ICANN immediate community and so it's somewhat militant to have acted the way they did. Whenever I read Fadi call for participation of various stakeholders in this process, I get encouraged because he seem passionate about it. However when you get the participation and don't by action show them that you are listening makes it against the "loose" term called M'ism which is supposed to be the foundation in this process! Regards sent from Google nexus 4 kindly excuse brevity and typos. On 10 Jul 2014 14:44, "Lucy Lynch" wrote: > On Thu, 10 Jul 2014, Dan York wrote: > > I find myself agreeing with Avri a bit here that I'm not entirely clear >> on what the issue is... >> > > Dan - > > For me this is about inclusion by default (the push of email to each user > with the opening for response in your own time) vs the need to constantly > check in on a coversation (the pull of on line forums with the requiremen= t > to fit yourself into the correct thread). The flow of a list works better > for me and it's easy enough to state norms for participstion when the > conversation drifts. I'd prefer to opt for tacit inclusion - you lose fol= ks > with every gate you put in the path. > > typing in alpine on a free bsd server... > > -Lucy > > > On Jul 10, 2014, at 7:24 AM, Avri Doria > >> >> wrote: >> >> BTW, I think I may have lost the thread on this. The thing we are upset >> about is a mailing list? >> >> I get that ICANN shut down the ianatransition@icann.org> ianatransition@icann.org> mailing list and asked everyone to move to a >> web discussion forum: >> >> http://mm.icann.org/pipermail/ianatransition/2014/001160.html >> >> I get that they did this without a whole lot of public notice and withou= t >> much discussion. I further understand that when you go to that web >> discussion forum at: >> >> http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47 >> >> you are agreeing by participating to abide by their Standards of >> Behavior[1], Privacy Policy[2], and Terms of Service[3]: >> >> [1] https://www.icann.org/resources/pages/expected- >> standards-2012-05-15-en >> [2] https://www.icann.org/resources/pages/privacy-2012-12-21-en >> [3] https://www.icann.org/resources/pages/tos-2014-06-13-en >> >> I've scanned through all three and they all seem to be the typical kinds >> of documents you see associated with discussion forums and online sites. >> Quite frankly, I'm glad to see they have these documents posted because= it >> provides a framework that can be used to deal with trolls and other peop= le >> who are being abusive. >> >> From some comments here on the list I gather there is a concern about >>> one bullet item in the Standards of Behavior [1]: >>> >> >> =E2=80=A2 Protect the organization=E2=80=99s assets and ensure their eff= icient and >> effective use. >> >> Which I personally took as "don't DDoS the website or otherwise do bad >> things to ICANN's infrastructure", but I gather others are perhaps >> interpreting as thinking of IANA as an ICANN "asset" and thereby biasing >> the discussion. >> >> Is that the primary concern here? If so, could we perhaps suggest to >> ICANN some clarifying language for this "Standards of Behavior" document= to >> address the concerns? Perhaps they would be fine making modifications t= o >> the document. >> >> Additionally, would it not be reasonable to assume that if these >> documents apply to an ICANN-hosted web discussion forum they would *ALSO= * >> apply to an ICANN-hosted mailing list? Perhaps that was never explicit= ly >> stated in the sign-up page for the mailing list, but I could see a messa= ge >> from "ICANN staff" going out to the mailing list stating something along >> these lines. Many or most of us have probably been on lists where this i= s >> done from time to time by the list admins. It seems to me to be a >> reasonable expectation. >> >> If people are still unhappy with all three of these documents then >> perhaps, as Avri noted, discussions should take place on some of the oth= er >> lists and forums that are out there on this issue. >> >> Or am I missing something else here? >> >> Thanks, >> Dan >> >> >> >> >> >> >> > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > --047d7b5d25a8e7ceae04fdd7d443 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with the view stated by Lucy, it's not about dis= cussing on another list. For me it's just the fact that ICANN seem not = to care on this one by not making any attempt to address all the comments b= y the community. This is a community process that exceed ICANN immediate co= mmunity and so it's somewhat militant to have acted the way they did.

Whenever I read Fadi call for participation of various stake= holders in this process, I get encouraged because he seem passionate about = it. However when you get the participation and don't by action show the= m that you are listening makes it against the "loose" term called= M'ism which is supposed to be the foundation in this process!

Regards
sent from Google nexus 4
kindly excuse brevity and typos.

On 10 Jul 2014 14:44, "Lucy Lynch" <= ;llynch@civil-tongue.net>= wrote:
On Thu, 10 Jul 2014, Dan York wrote:

I find myself agreeing with Avri a bit here that I'm not entirely clear= on what the issue is...

Dan -

For me this is about inclusion by default (the push of email to each user w= ith the opening for response in your own time) vs the need to constantly ch= eck in on a coversation (the pull of on line forums with the requirement to= fit yourself into the correct thread). The flow of a list works better for= me and it's easy enough to state norms for participstion when the conv= ersation drifts. I'd prefer to opt for tacit inclusion - you lose folks= with every gate you put in the path.

typing in alpine on a free bsd server...

-Lucy


On Jul 10, 2014, at 7:24 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>>
wrote:

BTW, I think I may have lost the thread on this. =C2=A0The thing we are ups= et
about is a mailing list?

I get that ICANN shut down the ianatransition@icann.org<mailto:ianatransition@icann.= org> mailing list and asked everyone to move to a web discussion= forum:

http://mm.icann.org/pipermail/ianatransition/2014/0= 01160.html

I get that they did this without a whole lot of public notice and without m= uch discussion. =C2=A0 I further understand that when you go to that web di= scussion forum at:

http://discuss-stewardship.icann.org/t/welcom= e-to-the-discussion/47

you are agreeing by participating to abide by their Standards of Behavior[1= ], Privacy Policy[2], and Terms of Service[3]:

[1] https://www.icann.org/resources/pages/= expected-standards-2012-05-15-en
[2] https://www.icann.org/resources/pages/privacy-201= 2-12-21-en
[3] https://www.icann.org/resources/pages/tos-2014-06-= 13-en

I've scanned through all three and they all seem to be the typical kind= s of documents you see associated with discussion forums and online sites. = =C2=A0Quite frankly, I'm glad to see they have these documents posted b= ecause it provides a framework that can be used to deal with trolls and oth= er people who are being abusive.

>From some comments here on the list I gather there is a concern about one b= ullet item in the Standards of Behavior [1]:

=E2=80=A2 Protect the organization=E2=80=99s assets and ensure their effici= ent and effective use.

Which I personally took as "don't DDoS the website or otherwise do= bad things to ICANN's infrastructure", but I gather others are pe= rhaps interpreting as thinking of IANA as an ICANN "asset" and th= ereby biasing the discussion.

Is that the primary concern here? =C2=A0 =C2=A0If so, could we perhaps sugg= est to ICANN some clarifying language for this "Standards of Behavior&= quot; document to address the concerns? =C2=A0Perhaps they would be fine ma= king modifications to the document.

Additionally, would it not be reasonable to assume that if these documents = apply to an ICANN-hosted web discussion forum they would *ALSO* apply to an= ICANN-hosted mailing list? =C2=A0 Perhaps that was never explicitly stated= in the sign-up page for the mailing list, but I could see a message from &= quot;ICANN staff" going out to the mailing list stating something alon= g these lines. Many or most of us have probably been on lists where this is= done from time to time by the list admins. =C2=A0It seems to me to be a re= asonable expectation.

If people are still unhappy with all three of these documents then perhaps,= as Avri noted, discussions should take place on some of the other lists an= d forums that are out there on this issue.

Or am I missing something else here?

Thanks,
Dan







_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech

--047d7b5d25a8e7ceae04fdd7d443-- From nobody Thu Jul 10 08:16:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5845B1A0AB6 for ; Thu, 10 Jul 2014 08:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vvXWD7bqYri for ; Thu, 10 Jul 2014 08:16:10 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40161B2920 for ; Thu, 10 Jul 2014 08:15:13 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 190168A031 for ; Thu, 10 Jul 2014 15:15:12 +0000 (UTC) Date: Thu, 10 Jul 2014 11:15:09 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140710151509.GH4720@mx1.yitter.info> References: <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <53BE99B6.3030604@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/VRzYz9HEMd0nWqfxx_Kl9B1X7jg Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:16:14 -0000 On Thu, Jul 10, 2014 at 02:30:47PM +0000, Dan York wrote: > > 1. Do we want ICANN to reinstate the ianatransition email list? As I think I've argued before, I don't especially care. I believe that the co-ordination group is supposed to be an ultra-lightweight process that just allows the different communities to work independently on their respective areas of interest. We don't actually need a single all-IANA-topics list or forum or any such thing at all. But _ICANN_ needs a list, or a forum, or something. The names community need to work on its stuff. But determining their needs and so on is just not a suitable topic for this (IAB) list. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 10 09:38:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3B21A0ADE for ; Thu, 10 Jul 2014 09:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ9Wyjlzc43z for ; Thu, 10 Jul 2014 09:38:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8CA1A0ABA for ; Thu, 10 Jul 2014 09:38:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.153]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6AGbqaY002569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 09:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405010286; x=1405096686; bh=QtzzJ4mLXv+K0fNg196hzgsUWl9kosoRhq3kOeSR/8U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VRpX6OHezZRs1dGQeCce+5Fya1/mNRPzJwvXhDASA/sujM82hYvWdeA9NKvHYDdNT asoPRiY3wPd0fEd/DsYuFVKIsv4ZSpdzYjrtfreIiLcUUukLNKSIvfQRz1oj6hH1Qy bxrospTYrj0u6PSLkMoi1gYem/2iHcpEhow96cng= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405010286; x=1405096686; i=@elandsys.com; bh=QtzzJ4mLXv+K0fNg196hzgsUWl9kosoRhq3kOeSR/8U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L5gP6HqIVVhN2O6/aPHrTinqt+kR7GngfPokZWOXMLqhWeAuZNQfU3v2mvROZrL0x YpP8MaTVZsw5P6wtTXsYiDqYTMBtqV/z1Pz3FJzZKJzTLRT+lSOzwljd0+OQqDmWoG egsqY0FDOh+fLBpcpJ/omdNrO1n9BZD4czjFpqLE= Message-Id: <6.2.5.6.2.20140710081651.0d06c730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Jul 2014 09:36:54 -0700 To: Dan York From: S Moonesamy In-Reply-To: <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OkNrOLVzhrEmNT6hIQ_XIC3APa4 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:38:09 -0000 Hi Dan, At 06:29 10-07-2014, Dan York wrote: >I find myself agreeing with Avri a bit here that=20 >I'm not entirely clear on what the issue is... The secondary issue was that ICANN staff ignored=20 the comments from an IAB member and an IESG=20 member. I did not mention that to the=20 representatives who seek to represent me. >I get that ICANN shut down the=20 >ianatransition@icann.org mailing list and asked=20 >everyone to move to a web discussion forum: > >http://mm.icann.org/pipermail/ianatransition/2014/001160.html > >I get that they did this without a whole lot of=20 >public notice and without much discussion. I=20 >further understand that when you go to that web discussion forum at: There was a public notification about that. The=20 issue here is that nobody from ICANN took responsibility for that decision. >http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47 > >you are agreeing by participating to abide by=20 >their Standards of Behavior[1], Privacy Policy[2], and Terms of Service[3]: > >[1] https://www.icann.org/resources/pages/expected-standards-2012-05-15-en >[2] https://www.icann.org/resources/pages/privacy-2012-12-21-en >[3] https://www.icann.org/resources/pages/tos-2014-06-13-en > >I've scanned through all three and they all seem=20 >to be the typical kinds of documents you see=20 >associated with discussion forums and online=20 >sites. Quite frankly, I'm glad to see they have=20 >these documents posted because it provides a=20 >framework that can be used to deal with trolls=20 >and other people who are being abusive. I could categorize a person who disagree with me=20 as "troll" or as "being abusive". However, I=20 would knowingly be treating the person=20 unfairly. If a person's messages are the cause=20 of a problem I would explain why I think it is a problem. > From some comments here on the list I gather=20 > there is a concern about one bullet item in the Standards of Behavior [1]: > >=95 Protect the organization=92s assets and ensure=20 >their efficient and effective use. > >Which I personally took as "don't DDoS the=20 >website or otherwise do bad things to ICANN's=20 >infrastructure", but I gather others are perhaps=20 >interpreting as thinking of IANA as an ICANN=20 >"asset" and thereby biasing the discussion. It takes a few minutes for an ICANN director to=20 post a message saying that IANA is not an ICANN asset. >Is that the primary concern here? If so,=20 >could we perhaps suggest to ICANN some=20 >clarifying language for this "Standards of=20 >Behavior" document to address the=20 >concerns? Perhaps they would be fine making modifications to the document. I am not inclined to participate in a discussion=20 about the IANA Transition which is subject to ICANN rules. >Additionally, would it not be reasonable to=20 >assume that if these documents apply to an=20 >ICANN-hosted web discussion forum they would=20 >*ALSO* apply to an ICANN-hosted mailing=20 >list? Perhaps that was never explicitly stated=20 >in the sign-up page for the mailing list, but I=20 >could see a message from "ICANN staff" going out=20 >to the mailing list stating something along=20 >these lines. Many or most of us have probably=20 >been on lists where this is done from time to=20 >time by the list admins. It seems to me to be a reasonable expectation. I haven't seen anyone with an icann.org email=20 address stating that on the ianatransition mailing list. >Or am I missing something else here? The following is a statement [1] from the Advisor=20 to the President on Global strategy: "we must first be sure that we all agree on the initial process." Could you please show me where the decision about=20 where to have the IANA Transition discussion was taken? Please note that I am okay with taking this=20 discussion to ietf@ietf.org as it might be off-topic for this IAB mailing= list. Regards, S. Moonesamy 1. https://www.icann.org/stewardship=20 From nobody Thu Jul 10 10:10:43 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148081A0AB4 for ; Thu, 10 Jul 2014 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_SMALL=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1lkVrcumfeh for ; Thu, 10 Jul 2014 10:10:40 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DEF1A016D for ; Thu, 10 Jul 2014 10:10:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 888AB216A3 for ; Thu, 10 Jul 2014 13:10:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 10 Jul 2014 13:10:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=BMXv/8S361uIdfGPngCl/72Z/Cg=; b=wQD+F+vQzONdA774cpJiGPFT2mfJ a7stu8J9+pEr86Ln48vABft4mzenaAMg7bHKD+2ga4DfZNqEaSucxRwDgsXufUUU adj0wTtDYvif3dvGzPbUpaOrJGUtZd58G9kQqyzcVQBub9EtpvSPFqQJdTN2I4/f rmInKFXMi/xzjEY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=BMXv/8S361uIdfGPngCl/7 2Z/Cg=; b=DG6i853HAyxBBwYN1Ly6DSCNTuVaOb94wvlFdi45uoWEaD0MVlxbP2 vDxTDVOd1xxyIlr/ZvE8aVvb4bT8o2CPgQzqXvzTnOs68B0+DGMoSjxTBbKleJQI FB9yq3Pm+1526LQSNyGFGZWWnpxe4SF5X9F0sehZQ0eeYbyK58P0o= X-Sasl-enc: zxOsZ0heJGzNYLcgoag+4wIRNLgDYO6o2/gN9lysjLlJ 1405012237 Received: from [171.68.18.44] (unknown [171.68.18.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E311C007AD; Thu, 10 Jul 2014 13:10:35 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 10 Jul 2014 10:10:31 -0700 From: Alissa Cooper To: S Moonesamy , Jari Arkko Message-ID: Thread-Topic: [Internetgovtech] Transition to the web References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BDA8B3.8050709@meetinghouse.net> <6.2.5.6.2.20140710010338.0cde2480@resistor.net> In-Reply-To: <6.2.5.6.2.20140710010338.0cde2480@resistor.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9AjqZbr6vWsdGu9dwEdBrxzBtkQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:10:42 -0000 SM, all, I think there are a few important pending developments to think about: 1. My personal opinion, as I stated at the ICANN50 session on the IANA stewardship transition, is that it would be reasonable for one of the roles of the coordination group to be to facilitate communications and information sharing about the transition plan development process. I hope this will include (1) a centralized location providing links to all of the separate mailing lists and discussions that will occur in the IETF, RIR, ICANN, and other communities about the transition, (2) periodic summaries/status updates of those discussions, and (3) facilitation of an over-arching mailing list/venue for transition discussion *if one is necessary* (opinions might differ as to whether one is necessary if there already exist sufficient venues for discussion in the separate communities). However, the CG is still in formation, so it may be a little while before any of those items get setup. My hope is that they will get setup, and that once they do the role of the ICANN forum and microsite may abate as focal points for information or discussion of the transition. 2. I think it would be very helpful for there to be a venue for names-specific transition issues discussion. There is a cross-community working group concerning the IANA stewardship transition forming among some of the ICANN constituencies (kicked off by ccNSO and gNSO =E2=80=94 see, e.g., http://ccnso.icann.org/node/45666). I don=E2=80=99t have enough ICANN background to fully understand how this group will work, but if it indeed provides an open forum where any interested party can discuss transition issues related to names (without agreeing to any sort of bylaws), I think that will be a good thing. Again, it may take a few more weeks to see if that can get setup. So, in summary, I am hopeful that in short order there will be an easy way to find out where to discuss each of the components of the transition plan development, that such places will exist for each of the IANA functions (and an overarching place will exist if that indeed seems useful to people), and that the discussions that take place will not require agreement to uphold the bylaws of any particular organization. Alissa On 7/10/14, 2:27 AM, "S Moonesamy" wrote: >Hi Alissa, Jari, > >I am writing to you as you are the representatives of the IETF in the >matter of the IANA Transition. > >One of the conditions required for participation in the IANA >Transition discussions is that the person must protect ICANN >assets. That decision has been taken by ICANN staff [1][2]. I find >it extremely difficult to accept that condition. I am curious about >whether you agreed to that condition. > >Regards, >S. Moonesamy > >1. http://mm.icann.org/pipermail/ianatransition/2014/001111.html >2. http://mm.icann.org/pipermail/ianatransition/2014/001160.html > From nobody Thu Jul 10 10:14:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259931A0ABF for ; Thu, 10 Jul 2014 10:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktc8NxUBpK5B for ; Thu, 10 Jul 2014 10:14:28 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E651A083D for ; Thu, 10 Jul 2014 10:14:28 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X5Hrr-000NMM-Ci; Thu, 10 Jul 2014 13:10:47 -0400 Date: Thu, 10 Jul 2014 13:14:17 -0400 From: John C Klensin To: Lucy Lynch , Dan York Message-ID: <24A8D27B7C24ADA4251A4114@JcK-HP8200.jck.com> In-Reply-To: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WIa73j0kCej6JBuagJ7YOSfEtdk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:14:30 -0000 --On Thursday, July 10, 2014 06:44 -0700 Lucy Lynch wrote: > On Thu, 10 Jul 2014, Dan York wrote: > >> I find myself agreeing with Avri a bit here that I'm not >> entirely clear on what the issue is... > > Dan - > > For me this is about inclusion by default (the push of email > to each user with the opening for response in your own time) > vs the need to constantly check in on a coversation (the pull > of on line forums with the requirement to fit yourself into > the correct thread). The flow of a list works better for me > and it's easy enough to state norms for participstion when the > conversation drifts. I'd prefer to opt for tacit inclusion - > you lose folks with every gate you put in the path. Lucy (and Dan), I think there are two entirely separate issues here and that the combination has been one of the sources of confusion. First, on which I agree with you, is the inherent difference between mailing lists and web-based forums, even when the latter are supplemented by notifications of when things change. Part of it is a matter of convenience, part is that the difference biases the profiles of the participants. IIR, a colleague who is now a senior ICANN staff member once described similar situations as the web forums selecting for greater participation by those who had too much time on their hands than for those who were busy and productive about other things. But not all of the community, even the IETT community, agrees with us. If you were to go back and review the IETF threads about DMARC a while back, you would definitely see signs of an attitude that can, I think, be summarized as "mailing lists are an outdated way of communication and, if anti-spam measures make mailing lists less effective or less usable, that is a cheap price to pay". From that perspective, sticking with mailing lists may bias the discussion toward those of us who are clinging to obsolete technologies. The other, IMO completely unrelated, issues is the one that Andrew, Eliot, and others have been discussing and analyzing. Intentionally or not, this isn't just a move to the web. It is a move that requires those who want to continue to agree to a long series of principles and requirements. Some are pretty typical and pretty harmless -- not much different, IPR rules aside, from the conditions for using the IETF's web sites. Others appear less benign. I tend to summarize them as requiring agreement that ICANN's best interests are ultimately more important than those of the Internet and that ICANN staff can control and/or censor conversations to support those interests or other ICANN norms. Andrew's analysis (and various followups) are better and more precise. Nothing would prevent ICANN from alleviating those concerns by posting a notice that said something like "in spite of the normal rules for our forums, while we expect courtesy, honesty, etc., you don't need to agree to support ICANN's bylaws and objectives to participate here". Perhaps ICANN leadership doesn't know, but there are (or were) fairly senior ICANN people on this list (and, I gather, in other places where similar discussions are occurring) so, unless they all dropped off at a convenient moment or are deliberately hiding the discussion and reactions from their leadership/management, each day that goes by without such a correction reinforces the view that it is intentional and that, for some people, calls into question the whole subject of whether the "IANA transition" process can succeed if ICANN is acting as steward or manager in any way. john From nobody Thu Jul 10 11:15:21 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D51A0406 for ; Thu, 10 Jul 2014 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2q5n9G4-Vfc for ; Thu, 10 Jul 2014 11:15:17 -0700 (PDT) Received: from mail.inlandnet.com (mail.inlandnet.com [204.14.96.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA711A0303 for ; Thu, 10 Jul 2014 11:15:16 -0700 (PDT) Received: from mail.inlandnet.com (localhost [127.0.0.1]) by mail.inlandnet.com (8.14.5/8.14.5) with ESMTP id s6AIF7YE086851; Thu, 10 Jul 2014 11:15:07 -0700 (PDT) (envelope-from springer@inlandnet.com) Received: from localhost (springer@localhost) by mail.inlandnet.com (8.14.5/8.14.5/Submit) with ESMTP id s6AIF6kR086848; Thu, 10 Jul 2014 11:15:06 -0700 (PDT) (envelope-from springer@inlandnet.com) X-Authentication-Warning: mail.inlandnet.com: springer owned process doing -bs Date: Thu, 10 Jul 2014 11:15:06 -0700 (PDT) From: John Springer To: Lucy Lynch In-Reply-To: Message-ID: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/XEq978SVyei_WNaEc55DZQevwY0 Cc: "internetgovtech@iab.org" , Avri Doria , Dan York Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:15:18 -0000 On Thu, 10 Jul 2014, Lucy Lynch wrote: > On Thu, 10 Jul 2014, Dan York wrote: > >> I find myself agreeing with Avri a bit here that I'm not entirely clear on >> what the issue is... > > Dan - > > For me this is about inclusion by default (the push of email to each user > with the opening for response in your own time) vs the need to constantly > check in on a coversation (the pull of on line forums with the requirement to > fit yourself into the correct thread). The flow of a list works better for me > and it's easy enough to state norms for participstion when the conversation > drifts. I'd prefer to opt for tacit inclusion - you lose folks with every > gate you put in the path. Whole heartedly agree. > typing in alpine on a free bsd server... also John Springer > -Lucy > > >> On Jul 10, 2014, at 7:24 AM, Avri Doria > >> wrote: >> >> BTW, I think I may have lost the thread on this. The thing we are upset >> about is a mailing list? >> >> I get that ICANN shut down the >> ianatransition@icann.org mailing list and >> asked everyone to move to a web discussion forum: >> >> http://mm.icann.org/pipermail/ianatransition/2014/001160.html >> >> I get that they did this without a whole lot of public notice and without >> much discussion. I further understand that when you go to that web >> discussion forum at: >> >> http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47 >> >> you are agreeing by participating to abide by their Standards of >> Behavior[1], Privacy Policy[2], and Terms of Service[3]: >> >> [1] https://www.icann.org/resources/pages/expected-standards-2012-05-15-en >> [2] https://www.icann.org/resources/pages/privacy-2012-12-21-en >> [3] https://www.icann.org/resources/pages/tos-2014-06-13-en >> >> I've scanned through all three and they all seem to be the typical kinds of >> documents you see associated with discussion forums and online sites. >> Quite frankly, I'm glad to see they have these documents posted because it >> provides a framework that can be used to deal with trolls and other people >> who are being abusive. >> >>> From some comments here on the list I gather there is a concern about one >>> bullet item in the Standards of Behavior [1]: >> >> ? Protect the organization?s assets and ensure their efficient and >> effective use. >> >> Which I personally took as "don't DDoS the website or otherwise do bad >> things to ICANN's infrastructure", but I gather others are perhaps >> interpreting as thinking of IANA as an ICANN "asset" and thereby biasing >> the discussion. >> >> Is that the primary concern here? If so, could we perhaps suggest to >> ICANN some clarifying language for this "Standards of Behavior" document to >> address the concerns? Perhaps they would be fine making modifications to >> the document. >> >> Additionally, would it not be reasonable to assume that if these documents >> apply to an ICANN-hosted web discussion forum they would *ALSO* apply to an >> ICANN-hosted mailing list? Perhaps that was never explicitly stated in >> the sign-up page for the mailing list, but I could see a message from >> "ICANN staff" going out to the mailing list stating something along these >> lines. Many or most of us have probably been on lists where this is done >> from time to time by the list admins. It seems to me to be a reasonable >> expectation. >> >> If people are still unhappy with all three of these documents then perhaps, >> as Avri noted, discussions should take place on some of the other lists and >> forums that are out there on this issue. >> >> Or am I missing something else here? >> >> Thanks, >> Dan >> >> >> >> >> >> > From nobody Thu Jul 10 13:06:03 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE0E1B29AC for ; Thu, 10 Jul 2014 13:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA6tOwnnX2uv for ; Thu, 10 Jul 2014 13:05:55 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9021B29AD for ; Thu, 10 Jul 2014 13:05:55 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6AK5sqi030135 for ; Thu, 10 Jul 2014 13:05:54 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53BEF222.6020007@abenaki.wabanaki.net> Date: Thu, 10 Jul 2014 13:05:54 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> In-Reply-To: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ydp8DICNqBMvykEZh5Bop2lDb4Y Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:05:57 -0000 My own two beads worth, which no one is required to share, is that (a) the subject matter pertains to a contract let by the government of the United States [the IANA Functions Contract], to which it [the USG] has, and continues to (b) assert a government interest [it could be a registry related to DNSSEC or to the unique identifiers of breakfast cereals available in the Congressional cafeterias, either would be sufficient], and (c) the incumbent contractor, on behalf of the government of the United States, has imposed restriction on speech in a public forum which is not content neutral, as Andrew has taken the pains to point out. Some will recall that legal council for the incumbent contractor (Joe Simms et alia) have asserted, and continue to assert, that the incumbent contractor does not act as an agent of government, and therefore that some constraints on its conduct do not apply. In the current instant that would be the restriction on imposing a content specific restriction on speech in a public forum. Expecting the incumbent contractor to abandon its position of record (for over a decade now) absent constraint seems to me to be an expectation unlikely to be realized. Eric P.S. A further issue arises from the finite term of the IANA Functions Contract, awarded by competitive bid. The incumbent contractor's content specific restriction may have the effect of precluding competition award of the IANA Functions Contract. P.P.S. The use of "incumbent contractor" rather than some acronym, has no purpose other than to separate the role of a government contractor from the its brand or identity, as these are not one and the same. From nobody Thu Jul 10 13:40:03 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81171B29F4 for ; Thu, 10 Jul 2014 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnhDuqfTaypZ for ; Thu, 10 Jul 2014 13:39:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF271B29F9 for ; Thu, 10 Jul 2014 13:39:52 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 20:39:49 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.41]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.214]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 20:39:49 +0000 From: Dan York To: John C Klensin Thread-Topic: [Internetgovtech] Transition to the web Thread-Index: AQHPmv8wihHRc8gERUWDMbx2tUdK4ZuXtAOAgAA4YoCAAAsbAIAABNyAgAAOL4CAAACUgIAAKoaAgADbFoCAAAP4AIAAGGaAgAAi1YCAAAQoAIAAOq6AgAA5aoA= Date: Thu, 10 Jul 2014 20:39:48 +0000 Message-ID: <71E87E07-B27E-4A37-B255-61314D0E8BB7@isoc.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE77FB.5080705@acm.org> <25D6CC36-C17D-4613-9F4E-F9CC3C6714B6@isoc.org> <24A8D27B7C24ADA4251A4114@JcK-HP8200.jck.com> In-Reply-To: <24A8D27B7C24ADA4251A4114@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(24454002)(377454003)(76176999)(101416001)(19580395003)(54356999)(20776003)(81342001)(33656002)(107046002)(99286002)(81542001)(106356001)(85852003)(83072002)(95666004)(50986999)(106116001)(83322001)(19580405001)(83716003)(64706001)(79102001)(87936001)(93886003)(4396001)(82746002)(110136001)(74662001)(46102001)(36756003)(92566001)(92726001)(80022001)(76482001)(77096002)(77982001)(86362001)(99396002)(105586002)(85306003)(21056001)(566704002)(2656002)(74502001)(31966008)(437434002)(104396001)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB243; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/yw_SKmojNVdnmE2cpVSXM3AQbRo Cc: Lucy Lynch , "" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:39:58 -0000 John, Good summary of the relevant points. Thank you. I do have one more philos= ophical comment...=20 On Jul 10, 2014, at 1:14 PM, John C Klensin wrote: > First, on which I agree with you, is the inherent difference > between mailing lists and web-based forums, even when the latter > are supplemented by notifications of when things change. Part > of it is a matter of convenience, part is that the difference > biases the profiles of the participants. =20 > But not all of the community, even the IETT community, agrees > with us. If you were to go back and review the IETF threads > about DMARC a while back, you would definitely see signs of an > attitude that can, I think, be summarized as "mailing lists are > an outdated way of communication and, if anti-spam measures make > mailing lists less effective or less usable, that is a cheap > price to pay". From that perspective, sticking with mailing > lists may bias the discussion toward those of us who are > clinging to obsolete technologies. There is the opposite side of Lucy's comment about the operation of mailing= lists (that she typed in alpine). I completely understand and sympathize = with her viewpoint. I started online in the early 1980's and for many, man= y years primarily read my email in pine with a whole set of procmail recipe= s helping keep me sane with a zillion different email lists. I know there = are MANY people within the IETF who still do that - I see it at meetings. = But, that ended for me a number of years back when I really got tired of ru= nning my own servers and switched to using webmail-based services and deskt= op clients. I also was doing more with files and graphics where the drag-an= d-drop world of the GUI mail clients worked a whole lot better for me. Eve= n still, I am a big supporter of mailing lists and prefer them in many case= s, not the least of which is that I can pretty much read email from whereve= r I am whenever I want. But... there's a whole generation now that has grown up on the Internet *w= ithout* experiencing the power of (al)pine and procmail. People use their = ISP's webmail or Gmail or Hotmail or AOL or whatever... and for them the ex= perience of email is typically a pretty poor one without much in the way of= sorting, threading and filtering. Instead of email they like the web-base= d discussion forums of Facebook or whatever other social network or forum s= ite you want to talk about. They'd rather have a lengthy discussion in Hac= ker News, Reddit or Slashdot with the easy capability to see threaded repli= es, to upvote/downvote, to reply to specific responses, to block people, to= choose to get notifications - or NOT - for specific threads, to share link= s to specific parts of conversations with others. A few of the email lists= I used to be on are quiet now while vigorous discussions are happening in = Facebook groups or Google+ communities. They don't want email. To them email is the communication medium of last = resort when every other option has failed. And I think some would dispute Lucy's characterization of email as "inclusi= on by default" because they would point out that in many web forums you can= choose how you want to be notified of new articles and have much finer con= trol of what you get versus having everything thrown in your inbox. And the= y might say that a web forum could be *more* inclusive because anyone can r= each it with a web browser and don't need a mail account. And yes... we could do what we do best as engineers and go down a really de= ep technical rathole about my last sentence... and everyone could pile on = in telling me how wrong I am and why email is so much better, etc., etc. But that's not the point. =20 The point is that for discussions to be truly "inclusive" of the wider Inte= rnet community we do need to find ways to involve people of both polarities= - those who want to only read email in pine (and despise web forums) and t= hose who want to only communicate in the web forums of Facebook or Reddit (= and despise email). I don't have the magic answer. Maybe there isn't one. If this was an IETF discussion we were talking about we could make it prett= y simple because mailing lists are based on the open standards of SMTP and = most web forums are their own proprietary walled gardens. But it's ICANN t= rying to have the discussion and they are not a standards organization wher= e these kind of things may matter as much. =20 Somewhere in there is a balance between the polarities that needs to be mad= e. Dan From nobody Thu Jul 10 13:48:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB55A1B29FE for ; Thu, 10 Jul 2014 13:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbuaMwRt917r for ; Thu, 10 Jul 2014 13:48:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722911B29F8 for ; Thu, 10 Jul 2014 13:48:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s6AKlx3p022769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jul 2014 13:48:03 -0700 Message-ID: <53BEFBA1.4010504@dcrocker.net> Date: Thu, 10 Jul 2014 13:46:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Lynn St.Amour" References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 10 Jul 2014 13:48:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/nUS2ItSgYIIeNIN6dX3oT4vEgqE Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:48:05 -0000 On 7/9/2014 12:18 PM, Lynn St.Amour wrote: > In thinking about how to turn this around, what if a few key people > (say IETF and IAB Chairs) were to write to Fadi and some of his key > advisors and suggest they reconsider their recent actions given how > counter this is to so many principles. ICANN senior staff may just > not be aware of this. (noting some additional postings about this today....) The major challenge in such a note is for it to be clear, direct, critical and careful. That is, it needs to explain the points of concern and the alternatives being recommended. It needs to be both comprehensive and concise, while maintaining a neutral tone about competence or intent, lest our own communication to them appear ham-fisted... So you'd be a good one to write the draft. And having it be signed by an aggregation of IETF community leadership makes sense. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 10 14:15:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4621B2A21 for ; Thu, 10 Jul 2014 14:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhlaTCwYceeZ for ; Thu, 10 Jul 2014 14:15:29 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) by ietfa.amsl.com (Postfix) with ESMTP id AF6591B29FA for ; Thu, 10 Jul 2014 14:15:28 -0700 (PDT) Received: from isoc-rem-mbp2227.home ([96.237.230.184]) by p3plsmtpa06-09.prod.phx3.secureserver.net with id QlFR1o00D3zMm3C01lFS1w; Thu, 10 Jul 2014 14:15:27 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Lynn St.Amour" In-Reply-To: <53BEFBA1.4010504@dcrocker.net> Date: Thu, 10 Jul 2014 17:15:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BEFBA1.4010504@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZT30LlNGHNnGgUgOGd7-SimJy1s Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 21:15:31 -0000 Hi Dave, thanks for thinking of me :^). Frankly, I was thinking of a fairly short peer-to-peer note. Simply = saying there are concerns, they have been quite well expressed on this = list, and that we wanted to ensure Fadi/ICANN senior management was = aware. No need to hand hold here. And, until we know ICANN senior = management is aware, we do not need to treat this as intentional. On the other hand, an equally reasonable course of action would be for = one of the ICANN staffers on this list to bring it to ICANN senior = management's attention and then "someone" gets back to the list. We are using a lot of cycles talking around something that should be = addressed directly, and probably as Andrew says elsewhere. But, this is just my .02. Lynn On Jul 10, 2014, at 4:46 PM, Dave Crocker wrote: > On 7/9/2014 12:18 PM, Lynn St.Amour wrote: >> In thinking about how to turn this around, what if a few key people >> (say IETF and IAB Chairs) were to write to Fadi and some of his key >> advisors and suggest they reconsider their recent actions given how >> counter this is to so many principles. ICANN senior staff may just >> not be aware of this. >=20 >=20 > (noting some additional postings about this today....) >=20 >=20 > The major challenge in such a note is for it to be clear, direct, > critical and careful. That is, it needs to explain the points of > concern and the alternatives being recommended. It needs to be both > comprehensive and concise, while maintaining a neutral tone about > competence or intent, lest our own communication to them appear > ham-fisted... >=20 > So you'd be a good one to write the draft. >=20 > And having it be signed by an aggregation of IETF community leadership > makes sense. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Thu Jul 10 14:26:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8CF1B2A46 for ; Thu, 10 Jul 2014 14:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxEWzz74Opcs for ; Thu, 10 Jul 2014 14:26:57 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4161B2A42 for ; Thu, 10 Jul 2014 14:26:56 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 10 Jul 2014 14:26:53 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Thu, 10 Jul 2014 14:26:52 -0700 From: Theresa Swinehart To: Lynn St.Amour , "dcrocker@bbiw.net" Thread-Topic: [Internetgovtech] Transition to the web Thread-Index: Ac+bqpJ4NaZ85q2vTMaubWAWaJeXngBEB2qAAAEDSID//8ccAA== Date: Thu, 10 Jul 2014 21:26:52 +0000 Message-ID: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BEFBA1.4010504@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [195.65.225.120] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3487859508_1799107" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/scJlmIiTf86CZoi-6JKqZKm01Rs Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 21:26:58 -0000 --B_3487859508_1799107 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Lynn and all, Appreciate the exchanges and the useful dialogues. Just to advise the issue is getting attention, and I should have something back to this list shortly. Kind regards, Theresa On 7/10/14 5:15 PM, "Lynn St.Amour" wrote: >Hi Dave, > >thanks for thinking of me :^). > >Frankly, I was thinking of a fairly short peer-to-peer note. Simply >saying there are concerns, they have been quite well expressed on this >list, and that we wanted to ensure Fadi/ICANN senior management was >aware. No need to hand hold here. And, until we know ICANN senior >management is aware, we do not need to treat this as intentional. > >On the other hand, an equally reasonable course of action would be for >one of the ICANN staffers on this list to bring it to ICANN senior >management's attention and then "someone" gets back to the list. > >We are using a lot of cycles talking around something that should be >addressed directly, and probably as Andrew says elsewhere. > >But, this is just my .02. > >Lynn > > > > >On Jul 10, 2014, at 4:46 PM, Dave Crocker wrote: > >> On 7/9/2014 12:18 PM, Lynn St.Amour wrote: >>> In thinking about how to turn this around, what if a few key people >>> (say IETF and IAB Chairs) were to write to Fadi and some of his key >>> advisors and suggest they reconsider their recent actions given how >>> counter this is to so many principles. ICANN senior staff may just >>> not be aware of this. >> >> >> (noting some additional postings about this today....) >> >> >> The major challenge in such a note is for it to be clear, direct, >> critical and careful. That is, it needs to explain the points of >> concern and the alternatives being recommended. It needs to be both >> comprehensive and concise, while maintaining a neutral tone about >> competence or intent, lest our own communication to them appear >> ham-fisted... >> >> So you'd be a good one to write the draft. >> >> And having it be signed by an aggregation of IETF community leadership >> makes sense. >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> Internetgovtech mailing list >> Internetgovtech@iab.org >> https://www.iab.org/mailman/listinfo/internetgovtech > >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech --B_3487859508_1799107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIT5AYJKoZIhvcNAQcCoIIT1TCCE9ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EbAwggcrMIIGE6ADAgECAhAIdtjUtK7QT3NoaZzvBRL0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA5MDYwMDAw MDBaFw0xNjA5MDYxMjAwMDBaMIHSMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczESMBAGA1UECxMJRXhlY3V0aXZlMRow GAYDVQQDExFUaGVyZXNhIFN3aW5laGFydDEqMCgGCSqGSIb3DQEJARMbdGhlcmVzYS5zd2lu ZWhhcnRAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2WpifUYI zzBKS3JzHOQFYu3T64+MQCpwxeEZwKTOZuzWWjKOERedHRdzkA2P0DlrP/Ue7ASWXsirOA4M u+9y6bBTFEPfQTFiLyN+jyf2c9BgQ10y9g7/1Ju/DJHoqBe145gmjy+nKwmsZktqFMq6S/Fq Gtn/PfuAa2b/AAA0RSUPI9Mc7KMz45jAyUwaFVWrAGjtmbqqQ1AvorNF3B/Fsj0Deov+IKu6 sKcUeXuU1L/q3xD1vH4pbP8P6ozrC32aalOF3ZgXBncn9pjvWhWn2lXzniwEJtOrUxonHYhp pSpYI1Q8Xu650TN0TZcWvOBkAytylmtXHl/xv30A3L4uZQIDAQABo4IDajCCA2YwHwYDVR0j BBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFN1D/9FvYoTYopLyTDCkR2Zl TZeGMCYGA1UdEQQfMB2BG3RoZXJlc2Euc3dpbmVoYXJ0QGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSG Mmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDig NqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNy bDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0 dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEF BQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABp AGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBu AGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABh AG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBt AGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAg AGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRz LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEFBQADggEBAM53htQ+sIXBmw4KMrJDKKKJteaZMF7HRN7fy6n6nN0oiWaV bbyNk9NwwL14/iz6Q2GMP1gZc1FMGBTywlKUZYVHAGJNogFu10m33Nemmj4PVZJmjVwK0/Rr kXnz31oSJGVTmF12kraaos5U0R2irbSGRDUkUXu82tu6eJImTE3whzpaN1Cln7Ysp1ViHCtF Aj6r9zRUXtKcEqxRkGPMFfa5td3bTuESA5CytvIPfYRCtJUkO2Y7itq75jv4rVViZ5mJhjJj qYpTN7e/JA9k0AJHovALdeBEz2pYBCLLKsPCn2prFjBUjSFPD/ijbKdbHtTguD/WOPBoQQsl 02MGJxAwggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjEx MTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0 IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiCLZn5 ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxArar8te a+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m9/ui zW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZdEkKB 4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJrGGWx wXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4GA1Ud DwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggr BgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAEMIIB pDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0 b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMBAf8E BTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl cnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRzL0Rp Z2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2Ny bDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0 cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNV HQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6ch nfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1lin1A KdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDiKaNR OENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/UlPMsi T/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh0lqv a+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirPlmB6 +CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEB BQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAe Fw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8K DIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8 R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQ jpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8B Rob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEw DgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1R i6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEB BQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk 0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe 3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7z fx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/DCC AfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQL ExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTEC EAh22NS0rtBPc2hpnO8FEvQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTyaWxkmWeQ KR7LvrLmv1APTtAKGjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA3MTAyMTUxNDhaMA0GCSqGSIb3DQEBAQUABIIBAHdrHnTEyeO6gQ1Lvop0iknBUxhE AMO/T0UqsUmCd/C9TWxvbFr6yonrlTzbxTjAYHZu7cgrnL2YTGWQAxiz+SaQyFagmXA2bpSZ UnCJogi8VElEjtQmMk9nWj45xnogS6fA5CJ4h6i9gfZ4inv76FPtXSB3ZAGs7BjZDTSOzpSC uGLpbddmLtCV4K8ln0QNlmll2+68pQ9W/vH9yxbGqqPwmOSUAHCRpZQU2b9F5h3REeTvx4dt WcQ0HEziBcyqyZKwyZEzdXzKEPnhew1XeAbV9ZSECyYciPB8nJ2sNd9rzCkSgjyxulxPb2hu ZiVEmsEDE7bC3rYa08tZXoDMeqU= --B_3487859508_1799107-- From nobody Thu Jul 10 15:37:38 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DB91A006D for ; Thu, 10 Jul 2014 15:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kweVK5DmTlB4 for ; Thu, 10 Jul 2014 15:37:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA9F1A004E for ; Thu, 10 Jul 2014 15:37:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.153]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6AMbIqw029033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 15:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405031852; x=1405118252; bh=7PM3cqH1tITukwafxzlqx1Ii8szHUjjBKsafSl5w9zs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rkY6ULzs3eIS5uSzHNQ75jKmq+l73ySDFJra+VRSKtdipBtbhqRnXzXyEPX4Fsaa1 XUgxVEkIug9RWo9ACpxt+63q3mu6thj/Cbp1p8lxiqUffj5VckHldZub68W2KagEGY j/QpKwTCzZEKcWGIZjlwfsoBKcogloZEqpZYNqR4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405031852; x=1405118252; i=@elandsys.com; bh=7PM3cqH1tITukwafxzlqx1Ii8szHUjjBKsafSl5w9zs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UslHfrWsgQX2TZNal5msBYJC5U6A8kvOh58I+Xni+orWdHDD2pZJX9oq1YeymG+Bz iqF+AFyidAXrE7N1FZG8IpLM4dzkLhZe2X+ZMpUf6qUZkUs3AaRZ0KUq79h8oHptOR phYqiNenYWeqCzy4P9YF8bPRboncH6caz5ntcRiM= Message-Id: <6.2.5.6.2.20140710133916.0c73f1c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Jul 2014 15:16:37 -0700 To: Alissa Cooper , Jari Arkko From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BDA8B3.8050709@meetinghouse.net> <6.2.5.6.2.20140710010338.0cde2480@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/7bUcRVqhYelXRSXd0Jy0EYJThLY Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 22:37:37 -0000 Hi Alissa, At 10:10 10-07-2014, Alissa Cooper wrote: >I think there are a few important pending developments to think about: > >1. My personal opinion, as I stated at the ICANN50 session on the IANA >stewardship transition, is that it would be reasonable for one of the >roles of the coordination group to be to facilitate communications and >information sharing about the transition plan development process. I hope >this will include (1) a centralized location providing links to all of the >separate mailing lists and discussions that will occur in the IETF, RIR, >ICANN, and other communities about the transition, (2) periodic >summaries/status updates of those discussions, and (3) facilitation of an >over-arching mailing list/venue for transition discussion *if one is >necessary* (opinions might differ as to whether one is necessary if there >already exist sufficient venues for discussion in the separate >communities). However, the CG is still in formation, so it may be a little >while before any of those items get setup. My hope is that they will get >setup, and that once they do the role of the ICANN forum and microsite may >abate as focal points for information or discussion of the transition. Thanks for the substantive response. You may=20 have seen the comments on the internetgovtech=20 mailing list about ICANN and the microsite. I=20 would not describe an ICANN forum or an ICANN=20 microsite as a venue where the word "equitable" is understood. >2. I think it would be very helpful for there to be a venue for >names-specific transition issues discussion. There is a cross-community >working group concerning the IANA stewardship transition forming among >some of the ICANN constituencies (kicked off by ccNSO and gNSO =97 see, >e.g., http://ccnso.icann.org/node/45666). I don't have enough ICANN >background to fully understand how this group will work, but if it indeed >provides an open forum where any interested party can discuss transition >issues related to names (without agreeing to any sort of bylaws), I think >that will be a good thing. Again, it may take a few more weeks to see if >that can get setup. I am ambivalent about the above. I'll choose not to comment for now. >So, in summary, I am hopeful that in short order there will be an easy way >to find out where to discuss each of the components of the transition plan >development, that such places will exist for each of the IANA functions >(and an overarching place will exist if that indeed seems useful to >people), and that the discussions that take place will not require >agreement to uphold the bylaws of any particular organization. I'll say okay for now to keep it easy for you. Regards, S. Moonesamy=20 From nobody Thu Jul 10 16:00:31 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02291A007F for ; Thu, 10 Jul 2014 16:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSpQC4p0DfOZ for ; Thu, 10 Jul 2014 16:00:23 -0700 (PDT) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 474EB1A0078 for ; Thu, 10 Jul 2014 16:00:23 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6AN0Kgn029419 for ; Thu, 10 Jul 2014 19:00:20 -0400 Received: (qmail 23292 invoked by uid 0); 10 Jul 2014 23:00:20 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 10 Jul 2014 23:00:20 -0000 Message-ID: <53BF1AF6.9060405@acm.org> Date: Thu, 10 Jul 2014 19:00:06 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BDA8B3.8050709@meetinghouse.net> <6.2.5.6.2.20140710010338.0cde2480@resistor.net> <6.2.5.6.2.20140710133916.0c73f1c0@elandnews.com> In-Reply-To: <6.2.5.6.2.20140710133916.0c73f1c0@elandnews.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140710-1, 07/10/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/aZfVPDS_oPHLIrMpOseTjR7tZlQ Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 23:00:30 -0000 > 2. I think it would be very helpful for there to be a venue for > names-specific transition issues discussion. There is a cross-community > working group concerning the IANA stewardship transition forming among > some of the ICANN constituencies (kicked off by ccNSO and gNSO — see, > e.g., http://ccnso.icann.org/node/45666). I don't have enough ICANN > background to fully understand how this group will work, but if it indeed > provides an open forum where any interested party can discuss transition > issues related to names (without agreeing to any sort of bylaws), I think > that will be a good thing. Again, it may take a few more weeks to see if > that can get setup. The design team is just getting started now. Reps from the ccNSO, ALAC, SSAC and GNSO parts of ICANN. As I learn more, I will pass it on for anyone interested. avri From nobody Thu Jul 10 20:46:51 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906A61A0439 for ; Thu, 10 Jul 2014 20:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhUdch-_vBhy for ; Thu, 10 Jul 2014 20:46:49 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 278831A026A for ; Thu, 10 Jul 2014 20:46:49 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6B3klxr026273 for ; Thu, 10 Jul 2014 23:46:47 -0400 Received: (qmail 19953 invoked by uid 0); 11 Jul 2014 03:46:47 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 11 Jul 2014 03:46:47 -0000 Message-ID: <53BF5E13.305@acm.org> Date: Thu, 10 Jul 2014 23:46:27 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BDA8B3.8050709@meetinghouse.net> <6.2.5.6.2.20140710010338.0cde2480@resistor.net> <6.2.5.6.2.20140710133916.0c73f1c0@elandnews.com> <53BF1AF6.9060405@acm.org> In-Reply-To: <53BF1AF6.9060405@acm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140710-1, 07/10/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/MJlcRqhiHZu-z3c17Duyj2M3CSc Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 03:46:50 -0000 On 10-Jul-14 19:00, Avri Doria wrote: > > > >> 2. I think it would be very helpful for there to be a venue for >> names-specific transition issues discussion. There is a cross-community >> working group concerning the IANA stewardship transition forming among >> some of the ICANN constituencies (kicked off by ccNSO and gNSO — see, >> e.g., http://ccnso.icann.org/node/45666). I don't have enough ICANN >> background to fully understand how this group will work, but if it indeed >> provides an open forum where any interested party can discuss transition >> issues related to names (without agreeing to any sort of bylaws), I think >> that will be a good thing. Again, it may take a few more weeks to see if >> that can get setup. > > The design team is just getting started now. I mean the charter drafting team. > Reps from the ccNSO, > ALAC, SSAC and GNSO parts of ICANN. > > As I learn more, I will pass it on for anyone interested. > > avri > From nobody Fri Jul 11 03:09:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704641B2AF2 for ; Fri, 11 Jul 2014 03:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaGu6ODkDYay for ; Fri, 11 Jul 2014 03:09:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB1E1B2AEF for ; Fri, 11 Jul 2014 03:09:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.153]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6BA9NeC003404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 03:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405073376; x=1405159776; bh=NZemgq4wTXjE0BkXpuPvaQXftXyH7V9zMGCAGAqRY5Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Udjc9CSGxSPucAnTVrqSDCwoKOxuEpQM6Am3QaY/rov3uJ/jnYkAv4LPIZ97ERI/W jt3pfz14LNJlGAr+5W+UXVra/KXAejSfUfPGOOJ1hiQo2Kz2Gq2YuatbSZXUYs+jV3 3fiM2UT7dw7nDBBxrv2lrUYP7Lc+kQ+dLsg8fE7k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405073376; x=1405159776; i=@elandsys.com; bh=NZemgq4wTXjE0BkXpuPvaQXftXyH7V9zMGCAGAqRY5Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kmxtDIdYll+E45T4xx9mvdJWhcGkxdUl53iTS6wXsprfetYKGhUwypqHzw/HBvdR1 hQpyOFwyzgzl0laGlnUMYdgd3dDUSZOwZRBuI/dLR+AthY5ukIT8yW7gekMemiaLc6 mIp+M1Xhw3iAZo9OxsV4KTm+IOLpoa89IURFxyHI= Message-Id: <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Jul 2014 02:19:14 -0700 To: cdel@firsthand.net, Stephen Farrell From: S Moonesamy In-Reply-To: <53BE69D2.9070509@firsthand.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/h7A9E7ztWaPw1JV3WDgQ1g6keaU Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:09:44 -0000 Hi Christian, At 03:24 10-07-2014, Christian de Larrinaga wrote: >However the intent of my point is that IETF is in danger of delegating >its own responsibilities by allowing the debates to be framed to protect >the interests of, and be owned and implemented by another institution >that is itself a vested interested party. That is ICANN. So there is >quite a bit of back peddling needed. I don't think that the IETF (the word does not include the IAB) is in danger. As mentioned above this is ICANN; parental guidance is advised. >Taking the initiative here is also important. IETF has responsibility >to establish process and requirements for any future contract it >directly makes without US Gov intercession with a registry operator >(whether that is at IANA/ ICANN or anywhere) The IETF does not have any responsibility. The IESG may receive questions if there is a problem with the protocol registry. My guess is that there is a view that the IETF can be used to solve problems with the other IANA Functions. The current IETF position is that those issues are not an IETF matter. Anyone disagreeing with that can talk to Mr Housley. >Brian talks about "oversight with teeth". That is looking increasingly >unlikely. The alternative is undersight with teeth and that is where >IETF and other bottom up communities can develop. I would not describe the IETF as a bottom-up community. As I think about all this the words "welfare state for the rich" comes to my mind. Regards, S. Moonesamy P.S. I made a mistake in a previous message about the number of IAB members. There were two IAB members who were ignored. From nobody Fri Jul 11 04:12:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECDD1B285C for ; Fri, 11 Jul 2014 04:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXL1sF5E6XBu for ; Fri, 11 Jul 2014 04:12:47 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD601B285B for ; Fri, 11 Jul 2014 04:12:47 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 11 Jul 2014 04:12:42 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 11 Jul 2014 04:12:42 -0700 From: Theresa Swinehart To: "internetgovtech@iab.org" Thread-Topic: update to discussion on Transition to the web Thread-Index: AQHPnPkIMqiHBIU+h0Gx2xgIoCadmw== Date: Fri, 11 Jul 2014 11:12:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [212.23.243.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3487909064_2635759" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/6-g5eGNpdumlnE559qEYYbx6sR8 Subject: [Internetgovtech] update to discussion on Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 11:12:49 -0000 --B_3487909064_2635759 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable All, Further to my note -- Thank you for your raising some important issues in relation to the migration of the IANA Transition mailing list to a web forum. We were trying to serve the broadest community we could as efficiently, transparently and as accessibly as we could, but recognize that the migration raised some concerns, which was not at all the intention, and I apologize for this. To address the feedback we have received, we are reinstating the mailing list and we are looking into the points raised around the terms of service. Further we apologize for instituting the previous changes without discussion or further feedback. While we are restoring the mailing list, there was - and still is - a purpose in setting up the forum, and though it's after the fact, it's nonetheless appropriate to share with you what motivated the change. We had input that some prospective participants are uncomfortable using email lists. We also had input that many people wanted additional functionality or different ways to manage communications. Specifically, the migration sought to provide a tool to those also less familiar with using only email lists. The forum was set up to provide the functionality expected from a mailing list, including that participants can send and receive posts via email just like the mailing list. It also some additional aspects some may find easier to manage via, including: =A1=A4 Ability to choose what they want to see (rather than have to set up email rules to filter out what they don't want). They can mute or follow specific threads. =A1=A4 Ability to sign up for digests (full or topic specific) on a schedule of their choosing. =A1=A4 Ability for search engines to search posts. =A1=A4 Ability to view and respond to specific topics. =A1=A4 Ability for participants to identify the most valuable contributions by 'liking' them. =A1=A4 It can be easier for some less familiar with email lists to see new topics and to navigate to different topics. =A1=A4 Questions can be made and answered and referred to, saving repetition. =A1=A4 Future options include such as user selectable machine translation of posts, thereby allowing multiple language participation in the same discussion, without the conversation fragmenting by language or locality. We appreciate that a forum only option raised other concerns, including many don=A9=F6t like to use discussion forums or manage communications that way. Given the interests expressed to retain the mailing list it will be reopened shortly. Thank you again for your continued feedback and suggestions for improvements, they are important to continue to improve the mechanisms and engagement in these important discussions. Kind regards, Theresa --B_3487909064_2635759 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIT5AYJKoZIhvcNAQcCoIIT1TCCE9ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EbAwggcrMIIGE6ADAgECAhAIdtjUtK7QT3NoaZzvBRL0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA5MDYwMDAw MDBaFw0xNjA5MDYxMjAwMDBaMIHSMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczESMBAGA1UECxMJRXhlY3V0aXZlMRow GAYDVQQDExFUaGVyZXNhIFN3aW5laGFydDEqMCgGCSqGSIb3DQEJARMbdGhlcmVzYS5zd2lu ZWhhcnRAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2WpifUYI zzBKS3JzHOQFYu3T64+MQCpwxeEZwKTOZuzWWjKOERedHRdzkA2P0DlrP/Ue7ASWXsirOA4M u+9y6bBTFEPfQTFiLyN+jyf2c9BgQ10y9g7/1Ju/DJHoqBe145gmjy+nKwmsZktqFMq6S/Fq Gtn/PfuAa2b/AAA0RSUPI9Mc7KMz45jAyUwaFVWrAGjtmbqqQ1AvorNF3B/Fsj0Deov+IKu6 sKcUeXuU1L/q3xD1vH4pbP8P6ozrC32aalOF3ZgXBncn9pjvWhWn2lXzniwEJtOrUxonHYhp pSpYI1Q8Xu650TN0TZcWvOBkAytylmtXHl/xv30A3L4uZQIDAQABo4IDajCCA2YwHwYDVR0j BBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFN1D/9FvYoTYopLyTDCkR2Zl TZeGMCYGA1UdEQQfMB2BG3RoZXJlc2Euc3dpbmVoYXJ0QGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSG Mmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDig NqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNy bDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0 dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEF BQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABp AGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBu AGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABh AG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBt AGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAg AGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRz LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEFBQADggEBAM53htQ+sIXBmw4KMrJDKKKJteaZMF7HRN7fy6n6nN0oiWaV bbyNk9NwwL14/iz6Q2GMP1gZc1FMGBTywlKUZYVHAGJNogFu10m33Nemmj4PVZJmjVwK0/Rr kXnz31oSJGVTmF12kraaos5U0R2irbSGRDUkUXu82tu6eJImTE3whzpaN1Cln7Ysp1ViHCtF Aj6r9zRUXtKcEqxRkGPMFfa5td3bTuESA5CytvIPfYRCtJUkO2Y7itq75jv4rVViZ5mJhjJj qYpTN7e/JA9k0AJHovALdeBEz2pYBCLLKsPCn2prFjBUjSFPD/ijbKdbHtTguD/WOPBoQQsl 02MGJxAwggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjEx MTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0 IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiCLZn5 ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxArar8te a+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m9/ui zW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZdEkKB 4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJrGGWx wXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4GA1Ud DwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggr BgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAEMIIB pDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0 b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMBAf8E BTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl cnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRzL0Rp Z2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2Ny bDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0 cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNV HQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6ch nfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1lin1A KdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDiKaNR OENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/UlPMsi T/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh0lqv a+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirPlmB6 +CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEB BQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAe Fw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8K DIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8 R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQ jpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8B Rob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEw DgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1R i6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEB BQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk 0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe 3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7z fx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/DCC AfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQL ExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTEC EAh22NS0rtBPc2hpnO8FEvQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSIhZYf5ior aDuYrmUbL7/dE4PXPzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA3MTExMTM3NDRaMA0GCSqGSIb3DQEBAQUABIIBAANHfuGvETdvRfE7g9ibyISNrffZ 5uXorRQXA+fJVZn+GwtgVzsreXl+rqN/vgFRd7KAyJoeJyr1IKcjldMOiUsWfsbVWV4M8IM4 J0zy55XwfBnx9QsMP/JjUsZyUDbJyGnE0i0jW55jZp0XJbxcohAoMIHl5zC4bECatBDsmhG0 SebAY3rJaqY7FEXutNAsxNH41NAvt1eEZvpQJSmyPCtakfxLVO1AQ7IaV95619JiS2BlAU4z 2+QQi0kZclwXcOmWtzSLzInnROYro4RnKk39Np9eryZOk/BO+ayvYknQprj83Jz0/arCSvqL x2cYA19Uo8PNFSx7zy4JUTtykfI= --B_3487909064_2635759-- From nobody Fri Jul 11 04:53:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7B41B2874 for ; Fri, 11 Jul 2014 04:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2PEVIrO9QTM for ; Fri, 11 Jul 2014 04:53:32 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C741B2872 for ; Fri, 11 Jul 2014 04:53:32 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so790749qgd.21 for ; Fri, 11 Jul 2014 04:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H/2+ss0JvSr7QQoNiSWh2y/IL3rJ78D4dnFKyVCcsnA=; b=DGjwksxWBgFsR3bpmn8JHk8HZP5/YdOA+DpXfMXcalXN1Hd5A3jtMUUBSPDSB+FG4w ZveW7Fem3mlxkViSJY8UOfz4EOWdxWHZXLA3e39hZciFFZe/O2Savy3P8JWn6t2Oal1p Q1Wl0/906Hxnk43Xa2pUypYWB+4gZnOalhnEaANrlS5lAk8OjAGZavFdTB8VU/FsRTZg v7aVbh3vkv5u8+kOWP7ezGioFXEPYiFBnkBzWWHBhwBREp98sh9+OUfj1rsRteTEKuoR NqXXY2uQpOaK0DV/6A4az4Vxih9EipmzKP6qwk3eS1XfR/E+bhoFOz2bd3wPA2Rj5Rs6 5FeQ== MIME-Version: 1.0 X-Received: by 10.140.100.181 with SMTP id s50mr7411484qge.106.1405079611198; Fri, 11 Jul 2014 04:53:31 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Fri, 11 Jul 2014 04:53:29 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Fri, 11 Jul 2014 04:53:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Jul 2014 12:53:29 +0100 Message-ID: From: Seun Ojedeji To: Theresa Swinehart Content-Type: multipart/alternative; boundary=001a1134f2b81b5f7504fde997ef Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/fK4qwHCijqaf0APJ52FP3ciThg0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] update to discussion on Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 11:53:34 -0000 --001a1134f2b81b5f7504fde997ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Theresa, Thank you for this information. Regards sent from Google nexus 4 kindly excuse brevity and typos. On 11 Jul 2014 12:12, "Theresa Swinehart" wrote: > All, > > Further to my note -- Thank you for your raising some important issues in > relation to the migration of the IANA Transition mailing list to a web > forum. We were trying to serve the broadest community we could as > efficiently, transparently and as accessibly as we could, but recognize > that the migration raised some concerns, which was not at all the > intention, and I apologize for this. To address the feedback we have > received, we are reinstating the mailing list and we are looking into the > points raised around the terms of service. > > Further we apologize for instituting the previous changes without > discussion or further feedback. While we are restoring the mailing list, > there was - and still is - a purpose in setting up the forum, and though > it's after the fact, it's nonetheless appropriate to share with you what > motivated the change. > > We had input that some prospective participants are uncomfortable using > email lists. We also had input that many people wanted additional > functionality or different ways to manage communications. Specifically, > the migration sought to provide a tool to those also less familiar with > using only email lists. The forum was set up to provide the functionality > expected from a mailing list, including that participants can send and > receive posts via email just like the mailing list. It also some > additional aspects some may find easier to manage via, including: > =C2=B7 Ability to choose what they want to see (rather than have to set u= p > email rules to filter out what they don't want). They can mute or follow > specific threads. > =C2=B7 Ability to sign up for digests (full or topic specific) on a sched= ule of > their choosing. > =C2=B7 Ability for search engines to search posts. > =C2=B7 Ability to view and respond to specific topics. > =C2=B7 Ability for participants to identify the most valuable contributio= ns by > 'liking' them. > =C2=B7 It can be easier for some less familiar with email lists to see ne= w > topics and to navigate to different topics. > =C2=B7 Questions can be made and answered and referred to, saving repetit= ion. > =C2=B7 Future options include such as user selectable machine translation= of > posts, thereby allowing multiple language participation in the same > discussion, without the conversation fragmenting by language or locality. > > We appreciate that a forum only option raised other concerns, including > many don=C2=B9t like to use discussion forums or manage communications th= at > way. Given the interests expressed to retain the mailing list it will be > reopened shortly. > > Thank you again for your continued feedback and suggestions for > improvements, they are important to continue to improve the mechanisms an= d > engagement in these important discussions. > > Kind regards, > > Theresa > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > --001a1134f2b81b5f7504fde997ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Theresa,

Thank you for this information.

Regards

sent from Google nexus 4
kindly excuse brevity and typos.

On 11 Jul 2014 12:12, "Theresa Swinehart&qu= ot; <theresa.swinehart@ic= ann.org> wrote:
All,

Further to my note -- Thank you for your raising some important issues in relation to the migration of the IANA Transition mailing list to a web
forum. We were trying to serve the broadest community we could as
efficiently, transparently and as accessibly as we could, but recognize
that the migration raised some concerns, which was not at all the
intention, and I apologize for this. =C2=A0To address the feedback we have<= br> received, we are reinstating the mailing list and we are looking into the points raised around the terms of service.

Further we apologize for instituting the previous changes without
discussion or further feedback. While we are restoring the mailing list, there was - and still is - a purpose in setting up the forum, and though it's after the fact, it's nonetheless appropriate to share with you= what
motivated the change.

We had input that some prospective participants are uncomfortable using
email lists. =C2=A0We also had input that many people wanted additional
functionality or different ways to manage communications. Specifically,
the migration sought to provide a tool to those also less familiar with
using only email lists. The forum was set up to provide the functionality expected from a mailing list, including that participants can send and
receive posts via email just like the mailing list. It also some
additional aspects some may find easier to manage via, including:
=C2=B7 Ability to choose what they want to see (rather than have to set up<= br> email rules to filter out what they don't want). They can mute or follo= w
specific threads.
=C2=B7 Ability to sign up for digests (full or topic specific) on a schedul= e of
their choosing.
=C2=B7 Ability for search engines to search posts.
=C2=B7 Ability to view and respond to specific topics.
=C2=B7 Ability for participants to identify the most valuable contributions= by
'liking' them.
=C2=B7 It can be easier for some less familiar with email lists to see new<= br> topics and to navigate to different topics.
=C2=B7 Questions can be made and answered and referred to, saving repetitio= n.
=C2=B7 Future options include such as user selectable machine translation o= f
posts, thereby allowing multiple language participation in the same
discussion, without the conversation fragmenting by language or locality.
We appreciate that a forum only option raised other concerns, including
many don=C2=B9t like to use discussion forums or manage communications that=
way. Given the interests expressed to retain the mailing list it will be reopened shortly.

Thank you again for your continued feedback and suggestions for
improvements, they are important to continue to improve the mechanisms and<= br> engagement in these important discussions.

Kind regards,

Theresa

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech

--001a1134f2b81b5f7504fde997ef-- From nobody Fri Jul 11 05:27:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7131B2ADC for ; Fri, 11 Jul 2014 05:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CGvOuqBD-eI for ; Fri, 11 Jul 2014 05:27:29 -0700 (PDT) Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [212.110.188.53]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0087B1B288F for ; Fri, 11 Jul 2014 05:27:28 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=firsthand.net; b=WvYqeKMGZQfjTrv7wPXGF4U9WP6hdd1vjGNcHo3AVhaviBUTT/jZ6DteLa/nWN3NbPhn4jCcoyYo1mnaKkmT8Q8nX21UVV8V5aOrYJPxi59XtyEQ0OS/ojLWxyRB56GT; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from orionlocal.local (host-78-147-2-204.as13285.net [78.147.2.204]) by bmtwo.vm.bytemark.co.uk (Postfix) with ESMTPSA id 50C97E0102; Fri, 11 Jul 2014 13:27:25 +0100 (BST) Message-ID: <53BFD828.3070007@firsthand.net> Date: Fri, 11 Jul 2014 13:27:20 +0100 From: Christian de Larrinaga User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> In-Reply-To: <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig92479E62D7F616B5A67746ED" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/sJP_E7UAqF7wKWzQ4ZGXRJor3Sw Cc: internetgovtech@iab.org, Miles Fidelman , Stephen Farrell Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cdel@firsthand.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:27:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92479E62D7F616B5A67746ED Content-Type: multipart/alternative; boundary="------------020207070306020309030005" This is a multi-part message in MIME format. --------------020207070306020309030005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good points. But I should be clearer. I was thinking of IANA as the contracted registry operator for those IANA considerations in RFCs. There is a cost to operating this which IETF as far as I am aware is not paying for. Who is paying? Does gov.us define this as part of its contract with ICANN for IANA? Is it a cost that is being cross subsidised in the round from overall revenue flows at ICANN? Does IETF pay into this pool? What happens when the overlying terms from gov.us for IANA contract comes to an end from IETF perspective? Working through these issues and being clear how IETF is able to exert what it wants from IANA registry functions is what I mean by IETF needing to take initiative. Christian S Moonesamy wrote: > Hi Christian, > At 03:24 10-07-2014, Christian de Larrinaga wrote: >> However the intent of my point is that IETF is in danger of delegating= >> its own responsibilities by allowing the debates to be framed to prote= ct >> the interests of, and be owned and implemented by another institution >> that is itself a vested interested party. That is ICANN. So there is >> quite a bit of back peddling needed. > > I don't think that the IETF (the word does not include the IAB) is in > danger. As mentioned above this is ICANN; parental guidance is advised= =2E > >> Taking the initiative here is also important. IETF has responsibility >> to establish process and requirements for any future contract it >> directly makes without US Gov intercession with a registry operator >> (whether that is at IANA/ ICANN or anywhere) > > The IETF does not have any responsibility. The IESG may receive > questions if there is a problem with the protocol registry. > > My guess is that there is a view that the IETF can be used to solve > problems with the other IANA Functions. The current IETF position is > that those issues are not an IETF matter. Anyone disagreeing with > that can talk to Mr Housley. > >> Brian talks about "oversight with teeth". That is looking increasingly= >> unlikely. The alternative is undersight with teeth and that is where >> IETF and other bottom up communities can develop. > > I would not describe the IETF as a bottom-up community. As I think > about all this the words "welfare state for the rich" comes to my mind.= > > Regards, > S. Moonesamy > > P.S. I made a mistake in a previous message about the number of IAB > members. There were two IAB members who were ignored. > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --=20 Christian de Larrinaga FBCS, CITP, MCMA ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel@firsthand.net ------------------------- --------------020207070306020309030005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
Go= od points. But I should be clearer.

I was thinking of IANA as the=20 contracted registry operator for those IANA considerations in RFCs.
Th= ere is a cost to operating this which IETF as far as I am aware is not=20 paying for.

Who is paying?

Does gov.us define this as=20 part of its contract with ICANN for IANA? Is it a cost that is being=20 cross subsidised in the round from overall revenue flows at ICANN?
Does IETF pay into this pool?

What happens when the overlying terms=20 from gov.us for IANA contract comes to an end from IETF perspective?=20 Working through these issues and being clear how IETF is able to exert=20 what it wants from IANA registry functions is what I mean by IETF=20 needing to take initiative.



Christian



S=20 Moonesamy wrote:Hi Christian,
At 03:24 10-07-2014, Christian de Larrinaga wrote:
However the intent of my point is that IETF= =20 is in danger of delegating
its own responsibilities by allowing the debates to be framed to=20 protect
the interests of, and be owned and implemented by another=20 institution
that is itself a vested interested party. That is ICANN. So there is
quite a bit of back peddling needed.

I don't think that the IETF (the word does not include the IAB) is=20 in=20 danger.=C2=A0 As mentioned above this is ICANN; parental guidance is advi= sed.

Taking the initiative here is also=20 important. IETF has responsibility
to=C2=A0 establish process and requirements for any future contract i= t
directly makes without US Gov intercession with a registry operator
(whether that is at IANA/ ICANN or anywhere)

The IETF does not have any responsibility.=C2=A0 The IESG may receive= =20 questions if there is a problem with the protocol registry.

My guess is that there is a view that the IETF can be used to solve=20 problems with the other IANA Functions.=C2=A0 The current IETF position i= s=20 that those issues are not an IETF matter.=C2=A0 Anyone disagreeing with=20 that can talk to Mr Housley.

Brian talks about "oversight with teeth".=20 That is looking increasingly
unlikely. The alternative is undersight with teeth and that is where
IETF and other bottom up communities can develop.

I would not describe the IETF as a bottom-up community.=C2=A0 As I th= ink=20 about all this the words "welfare state for the rich" comes to my mind.

Regards,
S. Moonesamy

P.S. I made a mistake in a previous message about the number of IAB=20 members.=C2=A0 There were two IAB members who were ignored.=20
_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internet= govtech

--
Christian de=20 Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand -------------------------
+44 7989 386778
= cdel@firsthand.net
-------------------------
--------------020207070306020309030005-- --------------enig92479E62D7F616B5A67746ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTv9gpAAoJEO8NEF3l27YrhfoIAI780ZJi842BhQcedzMV5itZ gm66iIQLMS2IhgnXT+gFDVpMNOEcILl0isnSsBE9ASDC9l1fyaWz9zuQJF4hSUSh YNAsA8kxW3pf4dIrM3t1RKnst4FnG2PqKd5GfrEGTMiV18HhlEjHPQzf7yta6Zzc goUkQ1fIgi/5LdrkMtqzH3G5gjlyc8BBTzH1OzprMkHNldPtUsyW+cGp63uB6VOl z+HvwcSd7EhMXIs6UEjzoViFn0yu8yfzRnGAoRKl44ufHUKxSi8480xJZn4PF/+d gZ9q/C9fJ2Q8nHd5+pBM/qmIIEZ4wkIaDYBbCD3CGJeWolBPuCEw53K8o3RbUsc= =cAHO -----END PGP SIGNATURE----- --------------enig92479E62D7F616B5A67746ED-- From nobody Fri Jul 11 05:38:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1611B2817 for ; Fri, 11 Jul 2014 05:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFUEJdPo8O5r for ; Fri, 11 Jul 2014 05:38:16 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7D61A0080 for ; Fri, 11 Jul 2014 05:38:16 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id 63so852643qgz.8 for ; Fri, 11 Jul 2014 05:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eT3+edJIL7lJ0o1HzQPzRG0PyxJv65y8X+fIbWtVxnM=; b=PwhuphIbo57iSE2ygC70AP+jmXnNV4vWhjKRA6HorENPT2RjU1h1ImAfV7NBpJD5MB APx/esQGdehG7WoBOkSU1cjqc4r6WZ9yPD/qjGi6p4k300jpHhz7ufZr7nFtBQYd0fbv X/NSuabLAM8yzRORUIhpy5Mxgg+DeUx+SHZhpijVl37+kntkuIdxiPgA5Qxtn8fvKlf5 64CsW1v+ylJthmSU89zDjwo8PhsiYo+vvJWtW8CyE/WsiYHaFKZCk+WlQK6xIRSCxKVa RbrANwPaoig4rhRr3lIGPZ41rZjoKFd0ji6RGwQ98Tx0b3/FM/ZR9OyBreRc6O5joCNO c9xQ== X-Received: by 10.224.134.201 with SMTP id k9mr92735237qat.59.1405082295558; Fri, 11 Jul 2014 05:38:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.147.15 with HTTP; Fri, 11 Jul 2014 05:37:45 -0700 (PDT) In-Reply-To: <53BFD828.3070007@firsthand.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> From: Seun Ojedeji Date: Fri, 11 Jul 2014 13:37:45 +0100 Message-ID: To: Christian de Larrinaga Content-Type: multipart/alternative; boundary=047d7b5d25a81b69de04fdea37e2 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vxdFBVgzXCqCAAa3FXW8twzJK54 Cc: internetgovtech@iab.org, Stephen Farrell , S Moonesamy , Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:38:18 -0000 --047d7b5d25a81b69de04fdea37e2 Content-Type: text/plain; charset=UTF-8 Hello Christian, This could also be likened to legacy IP holders whose resources is maintained on whois by paying member's fund Cheers! On Fri, Jul 11, 2014 at 1:27 PM, Christian de Larrinaga wrote: > Good points. But I should be clearer. > > I was thinking of IANA as the contracted registry operator for those IANA > considerations in RFCs. > There is a cost to operating this which IETF as far as I am aware is not > paying for. > > Who is paying? > > Does gov.us define this as part of its contract with ICANN for IANA? Is > it a cost that is being cross subsidised in the round from overall revenue > flows at ICANN? > > Does IETF pay into this pool? > > What happens when the overlying terms from gov.us for IANA contract comes > to an end from IETF perspective? Working through these issues and being > clear how IETF is able to exert what it wants from IANA registry functions > is what I mean by IETF needing to take initiative. > > > > Christian > > > > > S Moonesamy wrote: > > Hi Christian, > At 03:24 10-07-2014, Christian de Larrinaga wrote: > > However the intent of my point is that IETF is in danger of delegating > its own responsibilities by allowing the debates to be framed to protect > the interests of, and be owned and implemented by another institution > that is itself a vested interested party. That is ICANN. So there is > quite a bit of back peddling needed. > > > I don't think that the IETF (the word does not include the IAB) is in > danger. As mentioned above this is ICANN; parental guidance is advised. > > Taking the initiative here is also important. IETF has responsibility > to establish process and requirements for any future contract it > directly makes without US Gov intercession with a registry operator > (whether that is at IANA/ ICANN or anywhere) > > > The IETF does not have any responsibility. The IESG may receive questions > if there is a problem with the protocol registry. > > My guess is that there is a view that the IETF can be used to solve > problems with the other IANA Functions. The current IETF position is that > those issues are not an IETF matter. Anyone disagreeing with that can talk > to Mr Housley. > > Brian talks about "oversight with teeth". That is looking increasingly > unlikely. The alternative is undersight with teeth and that is where > IETF and other bottom up communities can develop. > > > I would not describe the IETF as a bottom-up community. As I think about > all this the words "welfare state for the rich" comes to my mind. > > Regards, > S. Moonesamy > > P.S. I made a mistake in a previous message about the number of IAB > members. There were two IAB members who were ignored. > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > > -- > Christian de Larrinaga > FBCS, CITP, MCMA > ------------------------- > @ FirstHand > ------------------------- > +44 7989 386778 > cdel@firsthand.net > ------------------------- > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --047d7b5d25a81b69de04fdea37e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Christian,

This could also be likened to= legacy IP holders whose resources is maintained on whois by paying member&= #39;s fund

Cheers!


On Fri, Jul 11, 2014 at 1:27 PM, Christi= an de Larrinaga <cdel@firsthand.net> wrote:
Good points. But I should be clearer.

I was thinking of IANA as the=20 contracted registry operator for those IANA considerations in RFCs.
Ther= e is a cost to operating this which IETF as far as I am aware is not=20 paying for.

Who is paying?

Does gov.us define this as=20 part of its contract with ICANN for IANA? Is it a cost that is being=20 cross subsidised in the round from overall revenue flows at ICANN?

D= oes IETF pay into this pool?

What happens when the overlying terms=20 from gov.us for IANA contra= ct comes to an end from IETF perspective?=20 Working through these issues and being clear how IETF is able to exert=20 what it wants from IANA registry functions is what I mean by IETF=20 needing to take initiative.



Christian



<= br>S=20 Moonesamy wrote:
Hi Christian,
At 03:24 10-07-2014, Christian de Larrinaga wrote:
However the intent of my point is that IETF= =20 is in danger of delegating
its own responsibilities by allowing the debates to be framed to=20 protect
the interests of, and be owned and implemented by another=20 institution
that is itself a vested interested party. That is ICANN. So there is
quite a bit of back peddling needed.

I don't think that the IETF (the word does not include the IAB) is= =20 in=20 danger.=C2=A0 As mentioned above this is ICANN; parental guidance is advise= d.

Taking the initiative here is also=20 important. IETF has responsibility
to=C2=A0 establish process and requirements for any future contract it
directly makes without US Gov intercession with a registry operator
(whether that is at IANA/ ICANN or anywhere)

The IETF does not have any responsibility.=C2=A0 The IESG may receive= =20 questions if there is a problem with the protocol registry.

My guess is that there is a view that the IETF can be used to solve=20 problems with the other IANA Functions.=C2=A0 The current IETF position is= =20 that those issues are not an IETF matter.=C2=A0 Anyone disagreeing with=20 that can talk to Mr Housley.

Brian talks about "oversight with teeth&= quot;.=20 That is looking increasingly
unlikely. The alternative is undersight with teeth and that is where
IETF and other bottom up communities can develop.

I would not describe the IETF as a bottom-up community.=C2=A0 As I thin= k=20 about all this the words "welfare state for the rich" comes to my= mind.

Regards,
S. Moonesamy

P.S. I made a mistake in a previous message about the number of IAB=20 members.=C2=A0 There were two IAB members who were ignored.=20
_______________________________________________
Internetgovtech mailing list
Internetgo= vtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech

--
Christian de= =20 Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand
-------------------------
+44 7989 386778
cdel@firsthand.net<= /a>
-------------------------

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech




--
--= ----------------------------------------------------------------------
<= font color=3D"#888888">
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--047d7b5d25a81b69de04fdea37e2-- From nobody Fri Jul 11 09:12:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549381B2BA5 for ; Fri, 11 Jul 2014 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqyD24ZiFymP for ; Fri, 11 Jul 2014 09:12:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F1A1B2BAC for ; Fri, 11 Jul 2014 09:11:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.159.106]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6BGAqMi007062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405095066; x=1405181466; bh=VDyti2JfwwcFvDyyF3ub4jPFjtn4R6E6SJY+R/9twBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RlJztwyrVUGeEaPloFM775BVtJvnIhy8G/ogmiVwMkT5ByM8sXSXadQ6F5L9HVnfz q2fkCX1E4cxDXMgixN1Nr8iHtMU53boUfxJCPpveAUq8amDDBl8kS4hcbH+l4F6Z2a T/vsGGX4rTUEN8fxYVVgQawA4SJ/scZyV+hIHR1g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405095066; x=1405181466; i=@elandsys.com; bh=VDyti2JfwwcFvDyyF3ub4jPFjtn4R6E6SJY+R/9twBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r8IfT5/JctXp2zgGCnxko9jkSZXgW8dBJkmDkJMPbxGviqn8zat4ybuzr1RB+1UQA XtanB1ANoC+AKK7n4JE1OwCh0SyQt3F79kgDk8RJQfD5ZHrjwLMYfnQ9kEBM7FxuNn 3saLvhhtR0jXQbBizUi4ZethbF14k3lmsXenMhMg= Message-Id: <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Jul 2014 09:08:13 -0700 To: cdel@firsthand.net From: S Moonesamy In-Reply-To: <53BFD828.3070007@firsthand.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/AbeQAM_8LKRNbiqamgr6Ts6J9uw Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:12:21 -0000 Hi Christian, At 05:27 11-07-2014, Christian de Larrinaga wrote: >I was thinking of IANA as the contracted registry operator for those >IANA considerations in RFCs. >There is a cost to operating this which IETF as far as I am aware is >not paying for. > >Who is paying? It is a fact that ICANN is paying for the cost of running the protocol registry. >Does gov.us define this as part of its contract with ICANN for IANA? >Is it a cost that is being cross subsidised in the round from >overall revenue flows at ICANN? This part is not clear. The government of the United States believes that it is part of the IANA contract. In the past the IETF has timidly expressed its view that the protocol registry is an IETF thing. On the wrong side of the equator this is known as cross-subsidization. >Does IETF pay into this pool? No. >What happens when the overlying terms from gov.us for IANA contract >comes to an end from IETF perspective? Working through these issues >and being clear how IETF is able to exert what it wants from IANA >registry functions is what I mean by IETF needing to take initiative. The corporation can decide to ask the IETF to pay. My advice to the IETF Chair might be "tell them that the IETF is not going to pay for this". I think that is clear enough. :-) Regards, S. Moonesamy From nobody Fri Jul 11 10:55:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A831B2C4F for ; Fri, 11 Jul 2014 10:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE7nwHtNiBTF for ; Fri, 11 Jul 2014 10:54:49 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F9B1B2C76 for ; Fri, 11 Jul 2014 10:54:46 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so1744018pdj.8 for ; Fri, 11 Jul 2014 10:54:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Rop2hRkH3bcCkevsZMmH8RST6llda/BrTBQzsRhinFI=; b=k5wV8L89+c0mSbcqapzCJnCQakE8MC9BXXTMDhY4loGh6AUahxz2Rd1W1kvUkkLlE3 UCTFjb9AKxHFIyDni/t4KVO1XJ14gB/T1W5L2kcqTQHiTRfgpPT9AFF4TsCAbGsI7BKI gdRuX39Re5Q/imd0jLtfWOst+25eYoMjOyW974qw5NB0FXVWsZ0gkyI50xbBF6n2UTZn s95cd+fbXeC4Z/SlFtJeCWsTvLeTEQMBgYWLI0aQVFCSYj/BJS3EuMofcix3fN11TQyY Olg5Kbh4JNXXaaRjdlnI39oAxImXPoW3ElKTZ7K2HuA2BS+fnXW1M0BwC+Kbi0ZXiLPB xCug== X-Gm-Message-State: ALoCoQkH4yB6Ap6KVjTlCAdn4bB0Us7fQjbaHxUl+782qjzfKQ75r7mezL0ExvHzs4VgqUKp5KjE X-Received: by 10.68.227.164 with SMTP id sb4mr262068pbc.63.1405101285988; Fri, 11 Jul 2014 10:54:45 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id cc8sm3848473pdb.57.2014.07.11.10.54.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 10:54:44 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_05571912-DEDF-413D-8F3A-55361219F88B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Conrad In-Reply-To: <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> Date: Fri, 11 Jul 2014 10:54:40 -0700 Message-Id: <83095BE4-17FE-456F-8C75-89AE295B4FF9@virtualized.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Kf0zFMjJPGdOD0wVRkL7NQvdgGY Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:54:52 -0000 --Apple-Mail=_05571912-DEDF-413D-8F3A-55361219F88B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 11, 2014, at 9:08 AM, S Moonesamy wrote: >> Who is paying? > It is a fact that ICANN is paying for the cost of running the protocol = registry. Yes (and all the other registries associated with the IANA Functions of = course). >> Does gov.us define this as part of its contract with ICANN for IANA? = Is it a cost that is being cross subsidised in the round from overall = revenue flows at ICANN? > This part is not clear. =20 It is actually quite clear (since it is explicit in the IANA Functions = contract) that the operation of the IANA Functions is at zero cost to = the US government, but ICANN is permitted to charge on a cost recovery = basis. Since ICANN does not charge for IANA Function services, it is = subsidized through ICANN's overall revenues. > The government of the United States believes that it is part of the = IANA contract. =20 Yes. > In the past the IETF has timidly expressed its view that the protocol = registry is an IETF thing. =20 I'm not sure I'd call RFC 6220 timid. > On the wrong side of the equator this is known as cross-subsidization. I don't know what this means. >> Does IETF pay into this pool? > No. Correct. ICANN's FY15 budget including projected revenues are publicly = documented at = https://www.icann.org/en/system/files/files/proposed-opplan-budget-comment= s-fy15-16jun14-en.pdf on page 7. Total root zone management-related = revenues (including new gTLD application fees) are 98.6% of ICANN's = revenues, Internet numbers-related revenues are 0.5%, and the rest is = ICANN meeting-related revenues. I believe the RIRs intend their = (voluntary) contribution to be for "their share" of the IANA services, = but this has never been formalized. In other words, domain name registrants are paying for the IANA Protocol = Parameter Registry function. >> What happens when the overlying terms from gov.us for IANA contract = comes to an end from IETF perspective? Working through these issues and = being clear how IETF is able to exert what it wants from IANA registry = functions is what I mean by IETF needing to take initiative. > The corporation can decide to ask the IETF to pay. My advice to the = IETF Chair might be "tell them that the IETF is not going to pay for = this". I think that is clear enough. :-) It is probably worth noting that in terms of person-hours required to do = the work, the IETF-related work was (back when I ran IANA) the most = significant. This may have changed since I left in 2010. Regards, -drc P.S. Full disclosure: I'll be (re)joining ICANN staff on Aug 4 but all = information above is from public sources. --Apple-Mail=_05571912-DEDF-413D-8F3A-55361219F88B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTwCTgAAoJENV6ebf0/4rXMicH/0OUd+7OUJ2PysOMbZklHfaq ktVVnJo7bQVSzOKsI2CG+JrkYdE039qAsYeRH/e9l6yFHbEmyhHzyze/GQLGZhI6 2T5IrJbCHxNJMwhw36Cv2weD3rLJ9Qg/oNjRiqAPqUvMTkxizN2cTvcOQOrMRvqI Zpkte0ee7//S8Dh4oFnqusYL/DA3q8PsmDddv6wcSm3XxWAp7gvtY/PE2ISFDfqb mkA6vzui9SH8Q5ktvbvK6ajAANxnaFgyiL0YLPv00u4kAJg2sePl+hsMXgdqH96F IFqXbrUOCmYu9TzYH6EZJZk4eNy7DDN+vWnIMLsl6NhS+p9nIAk74gkKkCzoJZQ= =LYaf -----END PGP SIGNATURE----- --Apple-Mail=_05571912-DEDF-413D-8F3A-55361219F88B-- From nobody Fri Jul 11 16:08:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E731A0026 for ; Fri, 11 Jul 2014 16:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkOM_TZun2NA for ; Fri, 11 Jul 2014 16:08:35 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9611A004A for ; Fri, 11 Jul 2014 16:08:35 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so2216891pab.32 for ; Fri, 11 Jul 2014 16:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Lg907rWXNdkf0Xh+aFDjEeyQjl198lbVEUVWr4BKKkI=; b=1KNo8nDxeafNyQKwl3Hp4gDkCcaLmccTtCey0E3PMCTmyE9DANc0nGUmH9KMPa2fGN K7+7XGCenlSaFCIPEN4i1K1UP/QWCfkJpLcRL5JOmV+MkKH0hbcsaM4oyW6uXUXwbzMt Y5muojNGFpaFVwmGnJWNVgDBbgHnz2vKlzknxYL/ilbjLWl7/IcINvOUbgDUZ52US6xZ 7ze1UxGI9ffb1iOWKgnBvQy6iJioDeqONPMWuFfKoGpcNR6YN3lXTwGU5kkA4x1K5qAl cYewf7C/PESnUPatsAi3UqYahwD092zpQej4J7TlSqqDGFLPPJGJ9Yd4S2lfoKr9aSxV OwLQ== X-Received: by 10.66.246.138 with SMTP id xw10mr1758830pac.142.1405120115302; Fri, 11 Jul 2014 16:08:35 -0700 (PDT) Received: from [192.168.178.23] (217.199.69.111.dynamic.snap.net.nz. [111.69.199.217]) by mx.google.com with ESMTPSA id i10sm14188549pat.36.2014.07.11.16.08.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 16:08:34 -0700 (PDT) Message-ID: <53C06E7C.4010903@gmail.com> Date: Sat, 12 Jul 2014 11:08:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: cdel@firsthand.net References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> In-Reply-To: <53BFD828.3070007@firsthand.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/z5ColxEOJYKrr0z4Yue_hY7lkxo Cc: internetgovtech@iab.org, Stephen Farrell , S Moonesamy , Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:08:43 -0000 On 12/07/2014 00:27, Christian de Larrinaga wrote: > Good points. But I should be clearer. > > I was thinking of IANA as the contracted registry operator for those > IANA considerations in RFCs. > There is a cost to operating this which IETF as far as I am aware is not > paying for. > > Who is paying? It doesn't matter, unless one side or the other gives notice to cancel the IETF/ICANN MOU. >From a fairness PoV, domain name holders benefit from the existence and viability of IETF protocols - without those protocols, there would be no Internet traffic. So it's entirely reasonable that the cost of the protocol registries is in practice a levy on domain name holders. User pays. Brian From nobody Fri Jul 11 16:38:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B891E1A0076 for ; Fri, 11 Jul 2014 16:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmB7TSNcP1Ez for ; Fri, 11 Jul 2014 16:38:24 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id B57391A0070 for ; Fri, 11 Jul 2014 16:38:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 20AADCC585; Fri, 11 Jul 2014 19:38:24 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YEdWqCLyhhoH; Fri, 11 Jul 2014 19:38:15 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 83CDACC581; Fri, 11 Jul 2014 19:38:14 -0400 (EDT) Message-ID: <53C07565.2010909@meetinghouse.net> Date: Fri, 11 Jul 2014 19:38:13 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> In-Reply-To: <53C06E7C.4010903@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/erdY0u549UnjpDNtc1cVWWkKEoo Cc: internetgovtech@iab.org, Stephen Farrell Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:38:25 -0000 Brian E Carpenter wrote: > On 12/07/2014 00:27, Christian de Larrinaga wrote: >> Good points. But I should be clearer. >> >> I was thinking of IANA as the contracted registry operator for those >> IANA considerations in RFCs. >> There is a cost to operating this which IETF as far as I am aware is not >> paying for. >> >> Who is paying? > It doesn't matter, unless one side or the other gives notice to cancel the > IETF/ICANN MOU. > > >From a fairness PoV, domain name holders benefit from the existence > and viability of IETF protocols - without those protocols, there > would be no Internet traffic. So it's entirely reasonable that > the cost of the protocol registries is in practice a levy on domain > name holders. User pays. > > More than that.. by designating ICANN to perform the IANA functions, IETF is essentially granting ICANN an exclusive license to charge for those functions. I.e., IETF may not be paying, but they are providing something to ICANN for which ICANN can charge a fee. (Not that different from a franchise agreement. McDonald's doesn't pay its franchisees, the franchisees pay them.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Jul 11 18:11:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4C61A00C0 for ; Fri, 11 Jul 2014 18:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSJHc9xs5EMe for ; Fri, 11 Jul 2014 18:11:10 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D117C1A00BF for ; Fri, 11 Jul 2014 18:11:09 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so2252573pde.10 for ; Fri, 11 Jul 2014 18:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6NExbWlj5BK2/VuLkMzptEyY6Wgs8EZzdJw4tToFpaI=; b=VS7kRc+imYqwCvFceO++JZLB2gWw4tJoNXchkr3EqBLpbQ5vUo7s/yHoro3PRPOXAh NOj27ZeG9nSzjXHLevwVBwQ8BXTT1+3JXc+6d8BXZsUeybXPszw5SXMp8Vxdaui/YUc6 1Pb9EOIRFx8QPRbpQqsQbzmPfvq3z3lxgV0gbUV/RqZWFodCcAhPcIHSzAfPFbFWVJ4F Gki6d3zSoedCrKnoBiB1cTxbaFuONYi5wBGJDBlhK2TzUYSZzPY9+S0ofPTQmPLIvr0P C3xQFK2coqtWEBzjYhdQkf9P/AQfJDYbm3jhDYKhb5mGXj1Yo+8SBIGLjhW1A7qidQLv W71A== X-Received: by 10.70.96.234 with SMTP id dv10mr2319752pdb.96.1405127469306; Fri, 11 Jul 2014 18:11:09 -0700 (PDT) Received: from [192.168.178.23] (217.199.69.111.dynamic.snap.net.nz. [111.69.199.217]) by mx.google.com with ESMTPSA id h10sm15171951pat.11.2014.07.11.18.11.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 18:11:08 -0700 (PDT) Message-ID: <53C08B38.4070906@gmail.com> Date: Sat, 12 Jul 2014 13:11:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miles Fidelman References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C07565.2010909@meetinghouse.net> In-Reply-To: <53C07565.2010909@meetinghouse.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ETdWYXWQuzKbWUHHd6vrXUaz5o8 Cc: internetgovtech@iab.org, Stephen Farrell Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 01:11:16 -0000 On 12/07/2014 11:38, Miles Fidelman wrote: > Brian E Carpenter wrote: >> On 12/07/2014 00:27, Christian de Larrinaga wrote: >>> Good points. But I should be clearer. >>> >>> I was thinking of IANA as the contracted registry operator for those >>> IANA considerations in RFCs. >>> There is a cost to operating this which IETF as far as I am aware is not >>> paying for. >>> >>> Who is paying? >> It doesn't matter, unless one side or the other gives notice to cancel >> the >> IETF/ICANN MOU. >> >> >From a fairness PoV, domain name holders benefit from the existence >> and viability of IETF protocols - without those protocols, there >> would be no Internet traffic. So it's entirely reasonable that >> the cost of the protocol registries is in practice a levy on domain >> name holders. User pays. >> >> > More than that.. by designating ICANN to perform the IANA functions, > IETF is essentially granting ICANN an exclusive license to charge for > those functions. I.e., IETF may not be paying, but they are providing > something to ICANN for which ICANN can charge a fee. (Not that > different from a franchise agreement. McDonald's doesn't pay its > franchisees, the franchisees pay them.) No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860. Brian From nobody Fri Jul 11 18:50:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D051B2A07 for ; Fri, 11 Jul 2014 18:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX1eDPqdyGWg for ; Fri, 11 Jul 2014 18:50:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE521A00CD for ; Fri, 11 Jul 2014 18:50:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.159.106]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6C1oMXj021352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 18:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405129839; x=1405216239; bh=bFcuqlD6ij/Bu6iBEKIAnIEcAGMrzMqg7XBfpWLXR5s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Hw2dsg1cSB9h3DxV4KAhQiq0ZC01O9Hf1+TQCDJ5CuwqXmn0UaPI4oYnbGzXFwWrG YqiDMsoBn9Pkby0sVimsw1rUVobLaJm0TVHrPcY/0l9gZ/UtWDWQhDcro5MdwW54zQ dlElB0n8kCVxLzYBW05usBjx2mdzNF6epf2bXmZA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405129839; x=1405216239; i=@elandsys.com; bh=bFcuqlD6ij/Bu6iBEKIAnIEcAGMrzMqg7XBfpWLXR5s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TJddjCpQOk5LWeXymX4GQotrwUEFSWDWltm5APGcdqebHjzHD5AI3whF5ICuQoig/ BabJuyaMvArA9N8v4w/BKPkgCOiB2hQhcBQsQFM48iPCb5c2oqhCC08XCeBauRK99o bKTjao+RpxhtzLg4e2i/Q2ERINfy9DIwmNYSv6qQ= Message-Id: <6.2.5.6.2.20140711172650.072c8e50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Jul 2014 18:47:31 -0700 To: David Conrad From: S Moonesamy In-Reply-To: <83095BE4-17FE-456F-8C75-89AE295B4FF9@virtualized.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> <83095BE4-17FE-456F-8C75-89AE295B4FF9@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/6UzeONBS8tiUBESM3VQcsWn4IBg Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 01:50:44 -0000 Hi David, I'll mention this for clarity; I am one of the Crypto Officers for DNSSEC. I don't have any financial interest in names, numbers, ICANN or the IETF. I do not derive any revenue from the protocol registry. At 10:54 11-07-2014, David Conrad wrote: >It is actually quite clear (since it is explicit in the IANA >Functions contract) that the operation of the IANA Functions is at >zero cost to the US government, but ICANN is permitted to charge on >a cost recovery basis. Since ICANN does not charge for IANA Function >services, it is subsidized through ICANN's overall revenues. I am aware that the contractor may establish fees. >I don't know what this means. My answer is that it is cross-subsidization. Other people might say that it isn't. >Correct. ICANN's FY15 budget including projected revenues are >publicly documented at >https://www.icann.org/en/system/files/files/proposed-opplan-budget-comments-fy15-16jun14-en.pdf >on page 7. Total root zone management-related revenues (including >new gTLD application fees) are 98.6% of ICANN's revenues, Internet >numbers-related revenues are 0.5%, and the rest is ICANN >meeting-related revenues. I believe the RIRs intend their >(voluntary) contribution to be for "their share" of the IANA >services, but this has never been formalized. > >In other words, domain name registrants are paying for the IANA >Protocol Parameter Registry function. Ok. >It is probably worth noting that in terms of person-hours required >to do the work, the IETF-related work was (back when I ran IANA) the >most significant. This may have changed since I left in 2010. My advice might still be "tell them that the IETF is not going to pay for this". Regards, S. Moonesamy From nobody Fri Jul 11 19:05:48 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BFF1A00F1 for ; Fri, 11 Jul 2014 19:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj6dvsc2LVh3 for ; Fri, 11 Jul 2014 19:05:45 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F9F1A00EF for ; Fri, 11 Jul 2014 19:05:45 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6C25ioQ044958 for ; Fri, 11 Jul 2014 19:05:44 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53C097F8.2060009@abenaki.wabanaki.net> Date: Fri, 11 Jul 2014 19:05:44 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> In-Reply-To: <53C06E7C.4010903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/PKMDxzUTsr1hF2te-OtoE5tt7fQ Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 02:05:46 -0000 On 7/11/14 4:08 PM, Brian E Carpenter wrote: > >From a fairness PoV, domain name holders benefit from the existence > and viability of IETF protocols - without those protocols, there > would be no Internet traffic. So it's entirely reasonable that > the cost of the protocol registries is in practice a levy on domain > name holders. User pays. Brian, While Jake, and then Jose, ran the NIC shop at SRI, the contract was cost-plus. I only mention this to point out that the "fairness PoV" assumes a set of conditions (privatization) that have not been continuous over time. Eric From nobody Fri Jul 11 19:32:38 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832111A014F for ; Fri, 11 Jul 2014 19:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh6F6o3PlBuq for ; Fri, 11 Jul 2014 19:32:36 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 201411A0135 for ; Fri, 11 Jul 2014 19:32:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 5119BCC5DC for ; Fri, 11 Jul 2014 22:32:35 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kGlRQjoDf3pN for ; Fri, 11 Jul 2014 22:32:26 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 41072CC5DB for ; Fri, 11 Jul 2014 22:32:26 -0400 (EDT) Message-ID: <53C09E39.1060007@meetinghouse.net> Date: Fri, 11 Jul 2014 22:32:25 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C07565.2010909@meetinghouse.net> <53C08B38.4070906@gmail.com> In-Reply-To: <53C08B38.4070906@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/TWzc_Fp3h_GHw7-blu8uL0Biv-s Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 02:32:37 -0000 Brian E Carpenter wrote: > On 12/07/2014 11:38, Miles Fidelman wrote: >> Brian E Carpenter wrote: >>> On 12/07/2014 00:27, Christian de Larrinaga wrote: >>>> Good points. But I should be clearer. >>>> >>>> I was thinking of IANA as the contracted registry operator for those >>>> IANA considerations in RFCs. >>>> There is a cost to operating this which IETF as far as I am aware is not >>>> paying for. >>>> >>>> Who is paying? >>> It doesn't matter, unless one side or the other gives notice to cancel >>> the >>> IETF/ICANN MOU. >>> >>> >From a fairness PoV, domain name holders benefit from the existence >>> and viability of IETF protocols - without those protocols, there >>> would be no Internet traffic. So it's entirely reasonable that >>> the cost of the protocol registries is in practice a levy on domain >>> name holders. User pays. >>> >>> >> More than that.. by designating ICANN to perform the IANA functions, >> IETF is essentially granting ICANN an exclusive license to charge for >> those functions. I.e., IETF may not be paying, but they are providing >> something to ICANN for which ICANN can charge a fee. (Not that >> different from a franchise agreement. McDonald's doesn't pay its >> franchisees, the franchisees pay them.) > No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860. > > Point taken. So where does the designation of IANA/ICANN as the domain and IP address authority come from, along with the "franchise" to charge for those functions? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Jul 11 23:35:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1B1A0ABC for ; Fri, 11 Jul 2014 23:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc_s3KG0dxDK for ; Fri, 11 Jul 2014 23:34:56 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1251A040F for ; Fri, 11 Jul 2014 23:34:56 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so1867238qcy.28 for ; Fri, 11 Jul 2014 23:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fcURYLda+lEXe7/6nTGsoY+F9U8vBttjTUJTb2VC8XQ=; b=eHT5Qnv4EcWd3OAmhWom8JmOTlnyripYZMODFtWjazZiYD2ylzXtvgkYB1ZX+4lfOT 7hCIa3PyIV5zXMuxf2xivr8jBJBGi8XPcZdWWyXxctOwUkVQ3TaeTkddkySD8dSoLvuU tsoQLFPE2gIe9NbS2LoH5HcjCEGeUFzUiuXnpuuwQcgTpaa88FHt1OXFEaYAAMQ041G2 nr+BjER5Nbn67XtncnEeI33R0Bm3SgxrfuqEFFB60C5G4KCXknoKqws9gb/mrmW7ZNje ez6ec1rB4cZoCTC7l6xjcKY3gY1hSZwLnHJIL76V5u1Ap0ks0RHmO3QoUPS2WhJsDFg6 DyLQ== MIME-Version: 1.0 X-Received: by 10.140.100.181 with SMTP id s50mr5211903qge.106.1405146895485; Fri, 11 Jul 2014 23:34:55 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Fri, 11 Jul 2014 23:34:55 -0700 (PDT) Received: by 10.229.147.15 with HTTP; Fri, 11 Jul 2014 23:34:55 -0700 (PDT) In-Reply-To: <53C06E7C.4010903@gmail.com> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> Date: Sat, 12 Jul 2014 07:34:55 +0100 Message-ID: From: Seun Ojedeji To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1134f2b890116e04fdf941e3 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/LtnOKfhIlrB94kcyrUdz5D222Fs Cc: Stephen Farrell , Christian de Larrinaga , internetgovtech@iab.org, Miles Fidelman , S Moonesamy Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 06:34:58 -0000 --001a1134f2b890116e04fdf941e3 Content-Type: text/plain; charset=UTF-8 sent from Google nexus 4 kindly excuse brevity and typos. On 12 Jul 2014 00:08, "Brian E Carpenter" wrote: > > On 12/07/2014 00:27, Christian de Larrinaga wrote: > > > >From a fairness PoV, domain name holders benefit from the existence > and viability of IETF protocols - without those protocols, there > would be no Internet traffic. So it's entirely reasonable that > the cost of the protocol registries is in practice a levy on domain > name holders. User pays. > I think this makes sense, also since IETF is not in anyway creating standards to make money directly from end users. Afterall IP addresses were at one point literally free before it became a business affair. Cheers! > Brian > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --001a1134f2b890116e04fdf941e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

sent from Google nexus 4
kindly excuse brevity and typos.
On 12 Jul 2014 00:08, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> On 12/07/2014 00:27, Christian de Larrinaga wrote:
>
>
> >From a fairness PoV, domain name holders benefit from the existenc= e
> and viability of IETF protocols - without those protocols, there
> would be no Internet traffic. So it's entirely reasonable that
> the cost of the protocol registries is in practice a levy on domain > name holders. User pays.
>
I think this makes sense, also since IETF is not in anyway creating standar= ds to make money directly from end users. Afterall IP addresses were at one= point literally free before it became a business affair.

Cheers!

> =C2=A0 =C2=A0 Brian
>
> _______________________________________________
> Internetgovtech mailing list
> Internetgovtech@iab.org=
> https= ://www.iab.org/mailman/listinfo/internetgovtech

--001a1134f2b890116e04fdf941e3-- From nobody Sat Jul 12 01:29:21 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BA1B2A40 for ; Sat, 12 Jul 2014 01:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI4Cr_iHTgXD for ; Sat, 12 Jul 2014 01:29:16 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9139B1B2A31 for ; Sat, 12 Jul 2014 01:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1102; q=dns/txt; s=iport; t=1405153756; x=1406363356; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=emis4IVkjKvxQtgl3wqgTtCN+cs68d/K/zaIc/in1oo=; b=RYqaMdyPqRMWol0Jz7hPqhBZyP7vKAsmDFQw14VxsU/46eZVwB4+paBW WQxRnAVHIJGUe9OthdypsuS/YGw95yqzvWuLODirrtNRZJudlPtmeQ/Ah NVz3xs9j784vmH1J/60p9h/TQ7LzoaIdKK6NsQATSroGkXkE04CJxW/n9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAGLxwFOtJssW/2dsb2JhbABZhyvGDgGBInWEAwEBAQMBI1UBBQsLGgIFFgsCAgkDAgECAUUGAQwBBwEBiDYIriWYPReBLI4fB4J3gUwBBJsOhxONCoNGOw X-IronPort-AV: E=Sophos;i="5.01,648,1400025600"; d="scan'208";a="103797479" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 12 Jul 2014 08:29:14 +0000 Received: from [10.61.84.25] (ams3-vpn-dhcp5146.cisco.com [10.61.84.25]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6C8TDBG032476; Sat, 12 Jul 2014 08:29:13 GMT Message-ID: <53C0F1D9.3090400@cisco.com> Date: Sat, 12 Jul 2014 10:29:13 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Seun Ojedeji , Brian E Carpenter References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/LmC--js8u1WkbEns6FYN7FlhDcg Cc: Miles Fidelman , Christian de Larrinaga , internetgovtech@iab.org, S Moonesamy , Stephen Farrell Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 08:29:18 -0000 Hi, On 7/12/14, 8:34 AM, Seun Ojedeji wrote: > I think this makes sense, also since IETF is not in anyway creating > standards to make money directly from end users. Afterall IP addresses > were at one point literally free before it became a business affair. > To me there are several aspects of stewardship to keep in mind. Domain names and unicast IP addresses are meant to be excludable resources. That is- if I pay for ofcourseimright.com, nobody else should have access to the name. The fee I pay serves two purposes: first and foremost (at least in my mind) to see that in fact the resource is being used, at least in some fashion. The second purpose is to pay the relatively nominal cost of administration of the IANA. IETF protocol parameters registries are on the whole non-excludable resources. That I am using port 25 doesn't mean you can't; although the purpose of port 25 is very clearly defined. Should another registry be created that has properties of excludable resources , then it should probably be handled more like an IP address or a name. Eliot From nobody Sat Jul 12 02:58:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5AE1B2A5E for ; Sat, 12 Jul 2014 02:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSL75xxZyejE for ; Sat, 12 Jul 2014 02:58:06 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4511B27B9 for ; Sat, 12 Jul 2014 02:58:06 -0700 (PDT) Received: from 254.74.14.81.rev.sfr.net ([81.14.74.254]:56901 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1X5u4B-0001Pn-9n; Sat, 12 Jul 2014 02:58:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 12 Jul 2014 11:24:34 +0200 To: S Moonesamy ,cdel@firsthand.net From: JFC Morfin In-Reply-To: <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vSQRO7XmgnkZfDovo7Hv_TM_M78 Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 09:58:08 -0000 Is there somewhere a IANA budget document or tax declaration so to understand better and the figures involved? jfc At 18:08 11/07/2014, S Moonesamy wrote: >Hi Christian, >At 05:27 11-07-2014, Christian de Larrinaga wrote: >>I was thinking of IANA as the contracted registry operator for >>those IANA considerations in RFCs. >>There is a cost to operating this which IETF as far as I am aware >>is not paying for. >> >>Who is paying? > >It is a fact that ICANN is paying for the cost of running the >protocol registry. > >>Does gov.us define this as part of its contract with ICANN for >>IANA? Is it a cost that is being cross subsidised in the round from >>overall revenue flows at ICANN? > >This part is not clear. The government of the United States >believes that it is part of the IANA contract. In the past the IETF >has timidly expressed its view that the protocol registry is an IETF >thing. On the wrong side of the equator this is known as cross-subsidization. > >>Does IETF pay into this pool? > >No. > >>What happens when the overlying terms from gov.us for IANA contract >>comes to an end from IETF perspective? Working through these issues >>and being clear how IETF is able to exert what it wants from IANA >>registry functions is what I mean by IETF needing to take initiative. > >The corporation can decide to ask the IETF to pay. My advice to the >IETF Chair might be "tell them that the IETF is not going to pay for >this". I think that is clear enough. :-) > >Regards, >S. Moonesamy > >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech From nobody Sat Jul 12 04:30:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC581B2A69 for ; Sat, 12 Jul 2014 04:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-2C0vO3KLHK for ; Sat, 12 Jul 2014 04:30:30 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A2C21B2860 for ; Sat, 12 Jul 2014 04:30:30 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id k15so337190qaq.41 for ; Sat, 12 Jul 2014 04:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=z16b9+/hPkyIHUjAMqIV2n8usD434rAaoqH8qyulc40=; b=UHfADl55PT/Ffky5uM3U4yJV/LGuOrFqWNXv0nMhHHMX1kEhPJl73fuMW5uG26FvB4 N/xjuAp9tKkOe2H0el+B2YOFSKswlmFU+OuI1d+3sxF9JSCsX4Y9ezaCcMHbgxFFZnbT t8e4NZzOZSL8HanjNEp1bWH1pd1oRZ/zcKw+WGU/0ylMn9L5MQ+TzVe+GdLwKQ/digbb OHv5pgKIbgMo6RhpyJudDHCPlJ9rFJXfO7IKX7L/PAgxAo7spYIydIl69v+hSGFEJRud g3Sy5OFVPHhmpFfgTUTD/A46AGqpTQVR7pL7dP/7FqhQtnQA1MT0BaJdlhdoOHhk42/R rEGw== X-Received: by 10.140.107.73 with SMTP id g67mr6954162qgf.100.1405164629439; Sat, 12 Jul 2014 04:30:29 -0700 (PDT) MIME-Version: 1.0 Sender: dogwallah@gmail.com Received: by 10.140.98.11 with HTTP; Sat, 12 Jul 2014 04:29:49 -0700 (PDT) In-Reply-To: <53C09E39.1060007@meetinghouse.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C07565.2010909@meetinghouse.net> <53C08B38.4070906@gmail.com> <53C09E39.1060007@meetinghouse.net> From: McTim Date: Sat, 12 Jul 2014 06:29:49 -0500 X-Google-Sender-Auth: ip2fLJlFa8rNemiugXvh9G_4haE Message-ID: To: Miles Fidelman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/k2hG5y1A4rzXR9RxEZ7lofS8jHo Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 11:30:32 -0000 On Fri, Jul 11, 2014 at 9:32 PM, Miles Fidelman wrote: > Brian E Carpenter wrote: >> >> On 12/07/2014 11:38, Miles Fidelman wrote: >>> >>> Brian E Carpenter wrote: >>>> >>>> On 12/07/2014 00:27, Christian de Larrinaga wrote: >>>>> >>>>> Good points. But I should be clearer. >>>>> >>>>> I was thinking of IANA as the contracted registry operator for those >>>>> IANA considerations in RFCs. >>>>> There is a cost to operating this which IETF as far as I am aware is >>>>> not >>>>> paying for. >>>>> >>>>> Who is paying? >>>> >>>> It doesn't matter, unless one side or the other gives notice to cancel >>>> the >>>> IETF/ICANN MOU. >>>> >>>> >From a fairness PoV, domain name holders benefit from the existence >>>> and viability of IETF protocols - without those protocols, there >>>> would be no Internet traffic. So it's entirely reasonable that >>>> the cost of the protocol registries is in practice a levy on domain >>>> name holders. User pays. >>>> >>>> >>> >>> More than that.. by designating ICANN to perform the IANA functions, >>> IETF is essentially granting ICANN an exclusive license to charge for >>> those functions. I.e., IETF may not be paying, but they are providing >>> something to ICANN for which ICANN can charge a fee. (Not that >>> different from a franchise agreement. McDonald's doesn't pay its >>> franchisees, the franchisees pay them.) >> >> No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860. >> >> > > > Point taken. > > So where does the designation of IANA/ICANN as the domain and IP address > authority come from, along with the "franchise" to charge for those > functions? http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority#History From nobody Sat Jul 12 05:13:37 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48111B2867 for ; Sat, 12 Jul 2014 05:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpAcTvugnDfV for ; Sat, 12 Jul 2014 05:13:34 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5D1B2866 for ; Sat, 12 Jul 2014 05:13:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 35743CC205 for ; Sat, 12 Jul 2014 08:13:33 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wITy+hKfd5TY for ; Sat, 12 Jul 2014 08:13:27 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 3AF7ECC209 for ; Sat, 12 Jul 2014 08:13:26 -0400 (EDT) Message-ID: <53C12663.9030408@meetinghouse.net> Date: Sat, 12 Jul 2014 08:13:23 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C07565.2010909@meetinghouse.net> <53C08B38.4070906@gmail.com> <53C09E39.1060007@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/-9p5HducsNWzOov8qY63yN-_Zd4 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 12:13:35 -0000 McTim wrote: > On Fri, Jul 11, 2014 at 9:32 PM, Miles Fidelman > wrote: >> Brian E Carpenter wrote: >>> On 12/07/2014 11:38, Miles Fidelman wrote: >>>> Brian E Carpenter wrote: >>>>> On 12/07/2014 00:27, Christian de Larrinaga wrote: >>>>>> Good points. But I should be clearer. >>>>>> >>>>>> I was thinking of IANA as the contracted registry operator for those >>>>>> IANA considerations in RFCs. >>>>>> There is a cost to operating this which IETF as far as I am aware is >>>>>> not >>>>>> paying for. >>>>>> >>>>>> Who is paying? >>>>> It doesn't matter, unless one side or the other gives notice to cancel >>>>> the >>>>> IETF/ICANN MOU. >>>>> >>>>> >From a fairness PoV, domain name holders benefit from the existence >>>>> and viability of IETF protocols - without those protocols, there >>>>> would be no Internet traffic. So it's entirely reasonable that >>>>> the cost of the protocol registries is in practice a levy on domain >>>>> name holders. User pays. >>>>> >>>>> >>>> More than that.. by designating ICANN to perform the IANA functions, >>>> IETF is essentially granting ICANN an exclusive license to charge for >>>> those functions. I.e., IETF may not be paying, but they are providing >>>> something to ICANN for which ICANN can charge a fee. (Not that >>>> different from a franchise agreement. McDonald's doesn't pay its >>>> franchisees, the franchisees pay them.) >>> No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860. >>> >>> >> >> Point taken. >> >> So where does the designation of IANA/ICANN as the domain and IP address >> authority come from, along with the "franchise" to charge for those >> functions? > > > http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority#History Not a particularly definitive, or detailed, source. The model of standards body and designated registration authority is pretty well defined one. For each specific case, how authority has been delegated, things get pretty murky. For IANA (and be reflection ICANN), this all remains just a bit murky (at least to me). Pretty clearly, one set of IANA responsibilities and authorities flow from RFC 2680, or rather RFC 2680 documents various practices and agreements, and another set from the NTIA contract. And, as I was reminded RFC 2680 excludes domain registration from its scope and excludes charging from its scope. So where, precisely, do the responsibilities for domain registration and IP address management come from, along with the authority to charge for those services. By precisely, I mean chapter and verse reference to contractual documents (along the lines of "clauses 4.4 and 4.5 of RFC 2860"). It strikes me that, whatever replaces those clauses, in a post NTIA world, is where a responsibility to financially support the full range of IANA functions, should be placed; and it's rather critical for this not to get overlooked in the transition. I.e., part of IANA's post-NTIA "franchise" to manage domains and addresses should require support of the full range of IANA functions. And, I guess that also raises the issue of what happens if, at some future date, IETF decides that the IANA functions under its purvue might better be served elsewhere? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Jul 12 05:16:39 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804041B2866 for ; Sat, 12 Jul 2014 05:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTcvi-rxri6R for ; Sat, 12 Jul 2014 05:16:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C591B2865 for ; Sat, 12 Jul 2014 05:16:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.159.106]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6CCGLct015040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jul 2014 05:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405167393; x=1405253793; bh=Tiix/J3p7T3kHcm5WIs9DOrVA9yJtda1bQdfHPEryyE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vJwNrpmR0Jzws+X+Tho+p2A7VAHbrT85WddRLZJ2MPJgF+iOIbM0/5WTnxvKxLDo0 axhdGPhthp0TbQcVtn98TnYFsKzbenv1Eg2S/UnVVipOA5jwhsOVxhTmltPY09Ex5o nAEB8WEi0mxGNkb98JyhSGKd7fM/VOYOZmg8eg48= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405167393; x=1405253793; i=@elandsys.com; bh=Tiix/J3p7T3kHcm5WIs9DOrVA9yJtda1bQdfHPEryyE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bQ/emz9J9T0gVHrK5qcutYz9F6BAOrytLCLNXfPbUH7PVQujWdl8uHrzMMID5wLvX GeszFtNTjYEQJ7X5I/I2EN/d09jKFjST740oxCXc5L4WdD9Pq6Zq3NDgo4L2c+ms1T 4Ik52/2YP2ERi4M0NZjmIVjui1A9oCzfqRaFxu3s= Message-Id: <6.2.5.6.2.20140712044114.0cbc1800@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 Jul 2014 05:15:19 -0700 To: JFC Morfin From: S Moonesamy In-Reply-To: <201407120958.s6C9w7Zi017618@mx.elandsys.com> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <6.2.5.6.2.20140711073822.0dfffea0@elandnews.com> <201407120958.s6C9w7Zi017618@mx.elandsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/W3ZaFAwHp15QAUvbLK03TI_0d60 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 12:16:36 -0000 Hello, At 02:24 12-07-2014, JFC Morfin wrote: >Is there somewhere a IANA budget document or tax declaration so to >understand better and the figures involved? There may be some information at https://www.icann.org/public-comments/op-budget-fy15-2014-05-16-en I don't recall whether it contains the figures mentioned above as it has been over a month since I took a quick look at the documents which were posted to that web page. Regards, S. Moonesamy From nobody Sat Jul 12 09:23:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908FF1B2B92 for ; Sat, 12 Jul 2014 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csv_jsx-0a24 for ; Sat, 12 Jul 2014 09:23:33 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731BE1B2B90 for ; Sat, 12 Jul 2014 09:23:33 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so1858058qaq.38 for ; Sat, 12 Jul 2014 09:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7fHouUN0+oxakbhAq0JzfjUkDC0XaX/RMlFjd3mWXDA=; b=N9urEB2eiG4VrG4wcyF4+5ZfPwlhzJBM8SWzFu6KIQANKJmWOx5+HlBOFEdUvJstwa t8Ti6vaZM2p8VssYlpRe7Nb8dRth0dS57THF9n7UZBUwEkYAGquqSZSJlFpBbaciw2Sr UAT2IOr8T8rUb3Mj0xhw6+lFBM4R1a+MKJG8TDTuz75BvGqnwq+WggK/v5Pdv6rDLaDH MpZRle3AA/a1I7XMMVAiGRlVCBfitNFZWMev6yfEVCKg6wFu0YVfgfUmnKlT1KLSXe7f 2IjibS9VRsg4/O+eJY0ijIHsUWTHgTDm0ZY2PvUkZBEsO13MynIdSk6nRC0qO/Jajyzp SdyQ== X-Received: by 10.229.82.74 with SMTP id a10mr9520141qcl.21.1405182212627; Sat, 12 Jul 2014 09:23:32 -0700 (PDT) MIME-Version: 1.0 Sender: dogwallah@gmail.com Received: by 10.140.98.11 with HTTP; Sat, 12 Jul 2014 09:22:52 -0700 (PDT) In-Reply-To: <53C12663.9030408@meetinghouse.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C07565.2010909@meetinghouse.net> <53C08B38.4070906@gmail.com> <53C09E39.1060007@meetinghouse.net> <53C12663.9030408@meetinghouse.net> From: McTim Date: Sat, 12 Jul 2014 11:22:52 -0500 X-Google-Sender-Auth: na8nqqBSrQNs5yDtzL1Sq9BjjWc Message-ID: To: Miles Fidelman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Ho7s9Gu-Gu43RJ6Pb_BMkEgAeNg Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 16:23:35 -0000 It does show the evolution of the role over time, I thought you would get that that was the point, apologies for being obtuse. It does detail the RFCs from the early days where the Registry functions are first mentioned. In any case it is a starting point. As far as specific other docs, well the ASO MoU is a good place to start: http://archive.icann.org/en/aso/aso-mou-29oct04.htm this is the second, there was an earlier one in 99. Of course there are earlier RFCs than this that lay out the address registry scheme. You can find them conveniently here: http://www.ipamworldwide.com/ipv4-addressing.html Start with 2050 Section 3 Registration perhaps http://datatracker.ietf.org/doc/rfc2050/ but this has been obsoleted by 7020: http://datatracker.ietf.org/doc/rfc7020/ On Sat, Jul 12, 2014 at 7:13 AM, Miles Fidelman wrote: > McTim wrote: >> >> On Fri, Jul 11, 2014 at 9:32 PM, Miles Fidelman >> wrote: >>> >>> Brian E Carpenter wrote: >>>> >>>> On 12/07/2014 11:38, Miles Fidelman wrote: >>>>> >>>>> Brian E Carpenter wrote: >>>>>> >>>>>> On 12/07/2014 00:27, Christian de Larrinaga wrote: >>>>>>> >>>>>>> Good points. But I should be clearer. >>>>>>> >>>>>>> I was thinking of IANA as the contracted registry operator for those >>>>>>> IANA considerations in RFCs. >>>>>>> There is a cost to operating this which IETF as far as I am aware is >>>>>>> not >>>>>>> paying for. >>>>>>> >>>>>>> Who is paying? >>>>>> >>>>>> It doesn't matter, unless one side or the other gives notice to cancel >>>>>> the >>>>>> IETF/ICANN MOU. >>>>>> >>>>>> >From a fairness PoV, domain name holders benefit from the existence >>>>>> and viability of IETF protocols - without those protocols, there >>>>>> would be no Internet traffic. So it's entirely reasonable that >>>>>> the cost of the protocol registries is in practice a levy on domain >>>>>> name holders. User pays. >>>>>> >>>>>> >>>>> More than that.. by designating ICANN to perform the IANA functions, >>>>> IETF is essentially granting ICANN an exclusive license to charge for >>>>> those functions. I.e., IETF may not be paying, but they are providing >>>>> something to ICANN for which ICANN can charge a fee. (Not that >>>>> different from a franchise agreement. McDonald's doesn't pay its >>>>> franchisees, the franchisees pay them.) >>>> >>>> No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860. >>>> >>>> >>> >>> Point taken. >>> >>> So where does the designation of IANA/ICANN as the domain and IP address >>> authority come from, along with the "franchise" to charge for those >>> functions? >> >> >> >> http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority#History > > > Not a particularly definitive, or detailed, source. > > The model of standards body and designated registration authority is pretty > well defined one. For each specific case, how authority has been delegated, > things get pretty murky. > > For IANA (and be reflection ICANN), this all remains just a bit murky (at > least to me). > > Pretty clearly, one set of IANA responsibilities and authorities flow from > RFC 2680, or rather RFC 2680 documents various practices and agreements, and > another set from the NTIA contract. And, as I was reminded RFC 2680 > excludes domain registration from its scope and excludes charging from its > scope. > > So where, precisely, do the responsibilities for domain registration and IP > address management come from, along with the authority to charge for those > services. By precisely, I mean chapter and verse reference to contractual > documents (along the lines of "clauses 4.4 and 4.5 of RFC 2860"). > > It strikes me that, whatever replaces those clauses, in a post NTIA world, > is where a responsibility to financially support the full range of IANA > functions, should be placed; and it's rather critical for this not to get > overlooked in the transition. I.e., part of IANA's post-NTIA "franchise" to > manage domains and addresses should require support of the full range of > IANA functions. And, I guess that also raises the issue of what happens if, > at some future date, IETF decides that the IANA functions under its purvue > might better be served elsewhere? > > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Sat Jul 12 11:16:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879911A0ADD for ; Sat, 12 Jul 2014 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, LOTS_OF_MONEY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEB2onpHIXM9 for ; Sat, 12 Jul 2014 11:15:58 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154D11A0AD2 for ; Sat, 12 Jul 2014 11:15:57 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6CIFv2K047777 for ; Sat, 12 Jul 2014 11:15:57 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53C17B5C.4090600@abenaki.wabanaki.net> Date: Sat, 12 Jul 2014 11:15:56 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> In-Reply-To: <53C0F1D9.3090400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ujBnYEZeqC0hZx_0Q4J8rZnzA9I Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 18:15:59 -0000 On 7/12/14 1:29 AM, Eliot Lear wrote: > Hi, > > On 7/12/14, 8:34 AM, Seun Ojedeji wrote: > >> I think this makes sense, also since IETF is not in anyway creating >> standards to make money directly from end users. Afterall IP addresses >> were at one point literally free before it became a business affair. >> > ... Domain > names and unicast IP addresses are meant to be excludable resources. The uniqueness property of association (of mnemonic and 32bit int), as well as curation of protocol parameters, predate the current contractual regimes. > That is- if I pay for ofcourseimright.com, nobody else should have > access to the name. The fee I pay serves two purposes: first and > foremost (at least in my mind) to see that in fact the resource is being > used, at least in some fashion. You appear to be making a claim that when the government provided unique identifiers at no cost to the requester that the unique identifiers were not used. > The second purpose is to pay the > relatively nominal cost of administration of the IANA. I've made a cursory glance at the current budget DRC was kind enough to provide a link to, and $2.6m/yr appears to be the incumbent contractor's projected cost to carry out the IANA Function. That's 17 cents per "Community Anchor Institution" (schools, etc., with broadband), according to the USG [1] or a fractional penny per installed CPE within the United States [2], or about two quarters per square foot of data center -- just in Loudoun Country (Northern Virginia) -- I'm going to guess that amortized over aggregated data center acreage for the rest of the United States this number approaches a penny per foot. Budget reading, math and industry stats error corrections appreciated. > > IETF protocol parameters registries are on the whole non-excludable > resources. That I am using port 25 doesn't mean you can't; although the > purpose of port 25 is very clearly defined. Should another registry be > created that has properties of excludable resources , then it should > probably be handled more like an IP address or a name. > > Eliot I don't quite catch the subtle distinction between something unique, and something "excludable". Eric [1] http://www.broadbandmap.gov/summarize/nationwide [2] http://en.wikipedia.org/wiki/List_of_countries_by_number_of_broadband_Internet_subscriptions [3] http://www.washingtonpost.com/business/capitalbusiness/loudoun-county-tops-5-million-square-feet-of-data-centers/2013/10/25/dc213cd4-3c39-11e3-b6a9-da62c264f40e_story.html From nobody Sat Jul 12 14:38:20 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7491A03F2 for ; Sat, 12 Jul 2014 14:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krUp5WDjcHm1 for ; Sat, 12 Jul 2014 14:38:13 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798411A03DF for ; Sat, 12 Jul 2014 14:38:13 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X64w7-0008mn-US; Sat, 12 Jul 2014 17:34:27 -0400 Date: Sat, 12 Jul 2014 17:38:06 -0400 From: John C Klensin To: Eric Brunner-Williams Message-ID: In-Reply-To: <53C17B5C.4090600@abenaki.wabanaki.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/cSO030LtJSMTRqCfHNBtSAeaNWM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 21:38:16 -0000 --On Saturday, July 12, 2014 11:15 -0700 Eric Brunner-Williams wrote: >... >> The second purpose is to pay the >> relatively nominal cost of administration of the IANA. > > I've made a cursory glance at the current budget DRC was kind > enough to provide a link to, and $2.6m/yr appears to be the > incumbent contractor's projected cost to carry out the IANA > Function. That's 17 cents per "Community Anchor Institution" > (schools, etc., with broadband), according to the USG [1] or a > fractional penny per installed CPE within the United States > [2], or about two quarters per square foot of data center -- > just in Loudoun Country (Northern Virginia) -- I'm going to > guess that amortized over aggregated data center acreage for > the rest of the United States this number approaches a penny > per foot. Budget reading, math and industry stats error > corrections appreciated. Assuming that your calculations are correct (I suspect they are close enough for analysis purposes). The "17 cents per..." style of analysis seems to me to be useful in only two sets or scenarios: (1) To claim that IANA is a public good that should be paid out of the public coffers without worrying too much about the amounts involved. If one makes that argument, one must, I think, be prepared to argue that IANA is more important (in terms of priority access to the public coffers) than other public goods, such a preventing starvation, educating small children, sundry emergency services such as police and fire departments, etc. I'm disinclined to go there; YMMD. (2) If one has taxing authority with regard to the sources whose resource impact is being measured and intends to use it. ICANN clearly does not have that authority (independent of whether it can assess fees on entities who do business with it, a different matter) and a further separation of ICANN from the US Government also further separates it from anyone with such authority. Even if ICANN's (or IANA's) ties to the government were closer, I don't think additional (or new) taxes, especially on "Community Anchor Institutions" who are mostly nonprofit and tax-exempt would have much chance in today's legislative environment in the US. All of that is obvious independent of the question of whether, if IANA is going to be treated as a public good or the equivalent thereof (as several of the discussion threads on this list effectively suggest even if they don't use those words), it isn't at all clear why the costs should be measured, assessed, or supported out of the US alone. The latter takes us to another issue to which I know you are as sensitive as I am. If the argument for community support of IANA (generally and the protocol registries in particular) is, as others have suggested, because everyone using the Internet benefits from those services, and that principal source of that support is DNS name-related revenues, then it seems to me that there is no excuse at all for the ccTLDs --at least the ccTLDs who are operated on other than an cost-recovery basis-- being exempt from paying for those services. IMO and for all sorts of reasons, it is not a good idea to try to insist on that, but that suggests to me that the analyses of the model and motivations need more thought. best, john From nobody Sat Jul 12 15:12:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214A71A0654 for ; Sat, 12 Jul 2014 15:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb6TLbS4cJn4 for ; Sat, 12 Jul 2014 15:12:36 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id D8C2F1A04C2 for ; Sat, 12 Jul 2014 15:12:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 2256E100927 for ; Sat, 12 Jul 2014 18:12:34 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DCQ7nrV0fbwl for ; Sat, 12 Jul 2014 18:12:24 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 97FBD1008D1 for ; Sat, 12 Jul 2014 18:12:23 -0400 (EDT) Message-ID: <53C1B2C6.40501@meetinghouse.net> Date: Sat, 12 Jul 2014 18:12:22 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9fXHFdWT39PwlcYwrPLQ1lShoxs Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 22:12:37 -0000 John C Klensin wrote: > > --On Saturday, July 12, 2014 11:15 -0700 Eric Brunner-Williams > wrote: > >> ... >>> The second purpose is to pay the >>> relatively nominal cost of administration of the IANA. >> I just spent some time pouring through the DOC-ICANN contract, the MOU between IETF and ICANN, and the "Affirmation of Committments"between DOC and ICANN (all courtesy of ICANN's web site, by the way). As far as I can tell: 1. ALL of ICANN's responsibilities and authority to perform the IANA function currently flow from the DOC-ICANN contract. 2. That includes the responsibilities for protocol numbers and such. 3. IETF's role is defined in the MOU, but seems to be in addition to, and/or enabled by the DOC-ICANN contract. 4. If/when the contract lapses, any "official" responsibilities and authority end - except for what comes out of the transition process. What I infer from this is that 1. The authority to charge for registry related activities, and use of those funds to pay for some of the other IANA functions, is all dictated by the DOC contract -- and it strike me as perfectly legitimate for DOC to require that the income stream support all of the IANA activities. In essence the contract is what grants ICANN it's franchise, and DOC can dictate the terms of that franchise. 2. If/when the contract lapses, absent a new governance mechanism, ICANN either a) has no authority to do anything, or b) has free reign to do whatever it wants within the constraints of it's bylaws (to the extent that anyone oversees compliance), terms of the MOU and Affirmation that outlive the contract, and the degree to which other players cooperate. Apropos the current discussion, this suggests that, beyond some kind of "grant of authority" and associated oversight mechanisms, whatever replaces the current contract needs to address: - what ICANN can and can't charge for (and limits on those charges) - use of proceeds, specifically as regards support for ALL of the IANA functions Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Jul 12 16:06:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD91A0B06 for ; Sat, 12 Jul 2014 16:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCcdzJNyiJ-z for ; Sat, 12 Jul 2014 16:06:01 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE721A0B02 for ; Sat, 12 Jul 2014 16:06:00 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id ft15so3249442pdb.14 for ; Sat, 12 Jul 2014 16:06:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0xc35xpT53KHUmXGPApxeovAzB1Tvlfy2oX226B2UZE=; b=G4kALWA+Z8+QeVHaZ2jTCvhV95OeL0l3C5hp/edXixprpaBd0j0Q6SNAdH+Yt/BmpD zVnIYtCXiPU9nPav9VvA+Jklzq7NCZnBTx7vfiBptSjXNs/Y3W8UWhK8POhdB6t+tnQ4 34xBNK04Xx97vtnyftyRfNAVSQIMsuo5FtLCg+ZmRWw9iR/Df5rus8l87czNoec13mHr spv5LoW6oX55+94ZPoq3Im6QJWshyxl6j3aFgXUS9n2Xl/6a/7d6WLS/1Zlf3Ba+no4u uNd8C+WRW4rP8TjioCnRrK3ZhmA2HbiPfcANC7E74rt04gIZYqCbkwzl8SNfrYel9q4L npTw== X-Gm-Message-State: ALoCoQk8SMnv46RoQ2oBAkxCXYBH7BbL2ES4FGqx/G48irwDivyOrauOyLoTOyYyBFuFXyc2BSPC X-Received: by 10.70.49.228 with SMTP id x4mr7591958pdn.80.1405206359470; Sat, 12 Jul 2014 16:05:59 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id nz7sm8345730pdb.48.2014.07.12.16.05.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 16:05:58 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C4F10FE1-EE79-4B99-B478-BBE79E292916"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Conrad In-Reply-To: <53C1B2C6.40501@meetinghouse.net> Date: Sat, 12 Jul 2014 16:05:55 -0700 Message-Id: <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> To: Miles Fidelman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/AETb293iDUiNCwcwoYSjf24eAUo Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 23:06:04 -0000 --Apple-Mail=_C4F10FE1-EE79-4B99-B478-BBE79E292916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Miles, On Jul 12, 2014, at 3:12 PM, Miles Fidelman = wrote: > 1. ALL of ICANN's responsibilities and authority to perform the IANA = function currently flow from the DOC-ICANN contract. > 2. That includes the responsibilities for protocol numbers and such. I think this will be quite surprising (if not amusing) to (e.g.) folks = at RIPE-NCC, AfriNIC, LACNIC, and APNIC. I know individuals at ARIN have = argued that there is a top-down chain of authority through various US = government agreements, but that always struck me more as transparent and = silly CYA driven by a lawyer than anything anyone actually believed in. It may also come as a surprise to many folks within the IETF (paging = Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220. > 3. IETF's role is defined in the MOU, but seems to be in addition to, = and/or enabled by the DOC-ICANN contract. I'm unclear why you think there is any relationship between the MoU and = the IANA Functions contract. How exactly does the IANA Functions = contract enable the IETF/IAB/ICANN MoU? > 4. If/when the contract lapses, any "official" responsibilities and = authority end - except for what comes out of the transition process. My impression has always been that the authority for the IANA Function = operator (and, in fact, pretty much all other parts of Internet's system = of unique identifiers) derives from the acceptance of the recipients of = those resources to accept the coordination performed by the operator. = For example, in the case of the IP addresses, an RIR serves as a = voluntary coordination point that facilitates a multilateral arrangement = for the association of IP address blocks with ISPs and others. Without = this coordination service, there is no way the system would scale since = it would require myriad bilateral agreements along the lines of "We = agree that I have 1.0.0.0/8 and you have 2.0.0.0/8". There is no law = that ensures this association -- it is purely the voluntary agreement of = the parties involved to accept the association that allows it to work. A more thorough albeit dated (1996!) description of this view can be = found in http://ccs.mit.edu/papers/CCSWP197/CCSWP197.html. > 1. The authority to charge for registry related activities, and use of = those funds to pay for some of the other IANA functions, is all dictated = by the DOC contract -- and it strike me as perfectly legitimate for DOC = to require that the income stream support all of the IANA activities. = In essence the contract is what grants ICANN it's franchise, and DOC can = dictate the terms of that franchise. Out of curiosity, why do you believe DoC has authority to grant the = franchise on management of the Internet's system of unique identifiers? As a reductio ad absurdum thought experiment, assume DoC decided that = this whole multistakeholder thing was a mistake and they decided to = grant "the franchise" of the IANA Functions to Evil Defense Contractor, = Inc., completely ignoring any input from the IETF, IAB, or anyone else. = EDC then decides to charge (say) $1000 for every protocol parameter = allocation, modification, or deletion. What would stop the IETF/IESG/IAB = from deciding to pick their own "IANA" and having that IANA provide = protocol parameter allocation, modifications, and deletion services = under the terms the IETF/IESG/IAB permits?=20 Similarly, as another absurd thought experiment, there are some who = argue that the U. S. Government owns all the address space. Suppose the = USG decided to take back "their" address space, perhaps to sell it off = to pay off the national debt. Why do you think ISPs of the world would = accept this assertion? Regards, -drc --Apple-Mail=_C4F10FE1-EE79-4B99-B478-BBE79E292916 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTwb9UAAoJENV6ebf0/4rX5qsIAIsFcZa6IpNx/iEK2oYA3pSm mUjA61MA43u8HvSNyOZmo5ureI341y/RCsn0QYAUGvLULI7w9uCf8aB0Qt6bScG+ 1PcPEPZQO3wMEFXNXSY6XwHpjzkzb1frJZT+Cr+LDE4HGUJEsZhEdSSCahpHuVcH SPg6QgkoHdtU5Y10Vej0jdy0oSx36RfdCEt+TC/C/cMYiUSdigwL8B+Qj1Sus3yf tXsRFpBaW/a0hq0VhbkU16kbH2C9KzFjYhLpvBUbmP+albKati0XTFTP7nxOpt36 psCLl8MR/LPbxmwJA74kRgSXheX+YxPtm/JdUEWTm0WJBhHJCqhn2t65mEvh4Xo= =DJGn -----END PGP SIGNATURE----- --Apple-Mail=_C4F10FE1-EE79-4B99-B478-BBE79E292916-- From nobody Sat Jul 12 18:14:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2173F1B291A for ; Sat, 12 Jul 2014 18:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5T1M9uBWsEA for ; Sat, 12 Jul 2014 18:14:26 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4212E1B2916 for ; Sat, 12 Jul 2014 18:14:26 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fb1so3395798pad.14 for ; Sat, 12 Jul 2014 18:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z1vPPiOlQM2UvZM+WgBFW7aAUE9zDeuzIa6pI2hLe9g=; b=fzD/VfKeHajqyTKCpN6SjWDrlq8ZU2nkiXKoQWjzuuzuPTRvwRhqSNKm8rUQpTJ8RL 1Nm59q7t/WcTYVazFPSLJvpXbfCI42BYgW68h3/yJJH6JEAoNQRpLrS9w6ANZ+TSiBG1 Xc71gjpRm1q1gbiBjzcb+5tGcmJi3URjglFY8sDicFFTEoTY+aw2ACbiZJGJ3H86rOkX imG21kNY/EjEir8WsqSKwXuA+OvmYYM3c65aYRNfwLoFrVFpi65kSqlOTAO/3bJc6Hov 4w5NgBbfZUT3lAidRFTiCgsXzAiRsPx5B4wZAIzRur4RCb9gMLtQsyhe2aGVHbQM1r/n ytyQ== X-Received: by 10.67.23.227 with SMTP id id3mr7814156pad.45.1405214064584; Sat, 12 Jul 2014 18:14:24 -0700 (PDT) Received: from [192.168.178.23] (139.198.69.111.dynamic.snap.net.nz. [111.69.198.139]) by mx.google.com with ESMTPSA id xx6sm26949402pab.34.2014.07.12.18.14.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 18:14:23 -0700 (PDT) Message-ID: <53C1DD6C.8030501@gmail.com> Date: Sun, 13 Jul 2014 13:14:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Conrad References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> In-Reply-To: <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ksCoyHYZRGYeypvtWUSShe2A6yE Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 01:14:30 -0000 On 13/07/2014 11:05, David Conrad wrote: > Miles, > > On Jul 12, 2014, at 3:12 PM, Miles Fidelman wrote: >> 1. ALL of ICANN's responsibilities and authority to perform the IANA function currently flow from the DOC-ICANN contract. > >> 2. That includes the responsibilities for protocol numbers and such. > > I think this will be quite surprising (if not amusing) to (e.g.) folks at RIPE-NCC, AfriNIC, LACNIC, and APNIC. I know individuals at ARIN have argued that there is a top-down chain of authority through various US government agreements, but that always struck me more as transparent and silly CYA driven by a lawyer than anything anyone actually believed in. > > It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220. Well, it's a very legalistic view in an area where there is actually no law (I mean international law) and no need for law, since things work perfectly well without it. In fact, the IETF/ICANN MoU is a signed and ratified document, and I have been told in other contexts that such a document is exactly the same thing as a contract if it ends up in court. Certainly the attention paid to its wording by lawyers on both sides in 1999/2000 was exactly what I have experienced in contract negotiations. Of course, if a court had to decide between conflicting provisions of an NTIA/ICANN contract and the IETF/ICANN MoU, one might trump the other. However, I think that a lot of the ICANN lawyer's amendments to the MoU draft were intended to avoid conflicting provisions. As far as I can see, the only problem that actually needs a solution right now is: who is the watchdog with adequate teeth to ensure that if ICANN takes bad decisions about TLD policy, they can be set back on the right track? Everything else is in the "not broken, don't fix" category as far as I am concerned. The RIRs and the IETF have ways to deal with bad decisions by ICANN in their own areas of concern. Apart from that, +1 to David's comments. Brian >> 3. IETF's role is defined in the MOU, but seems to be in addition to, and/or enabled by the DOC-ICANN contract. > > I'm unclear why you think there is any relationship between the MoU and the IANA Functions contract. How exactly does the IANA Functions contract enable the IETF/IAB/ICANN MoU? > >> 4. If/when the contract lapses, any "official" responsibilities and authority end - except for what comes out of the transition process. > > My impression has always been that the authority for the IANA Function operator (and, in fact, pretty much all other parts of Internet's system of unique identifiers) derives from the acceptance of the recipients of those resources to accept the coordination performed by the operator. For example, in the case of the IP addresses, an RIR serves as a voluntary coordination point that facilitates a multilateral arrangement for the association of IP address blocks with ISPs and others. Without this coordination service, there is no way the system would scale since it would require myriad bilateral agreements along the lines of "We agree that I have 1.0.0.0/8 and you have 2.0.0.0/8". There is no law that ensures this association -- it is purely the voluntary agreement of the parties involved to accept the association that allows it to work. > > A more thorough albeit dated (1996!) description of this view can be found in http://ccs.mit.edu/papers/CCSWP197/CCSWP197.html. > >> 1. The authority to charge for registry related activities, and use of those funds to pay for some of the other IANA functions, is all dictated by the DOC contract -- and it strike me as perfectly legitimate for DOC to require that the income stream support all of the IANA activities. In essence the contract is what grants ICANN it's franchise, and DOC can dictate the terms of that franchise. > > Out of curiosity, why do you believe DoC has authority to grant the franchise on management of the Internet's system of unique identifiers? > > As a reductio ad absurdum thought experiment, assume DoC decided that this whole multistakeholder thing was a mistake and they decided to grant "the franchise" of the IANA Functions to Evil Defense Contractor, Inc., completely ignoring any input from the IETF, IAB, or anyone else. EDC then decides to charge (say) $1000 for every protocol parameter allocation, modification, or deletion. What would stop the IETF/IESG/IAB from deciding to pick their own "IANA" and having that IANA provide protocol parameter allocation, modifications, and deletion services under the terms the IETF/IESG/IAB permits? > > Similarly, as another absurd thought experiment, there are some who argue that the U. S. Government owns all the address space. Suppose the USG decided to take back "their" address space, perhaps to sell it off to pay off the national debt. Why do you think ISPs of the world would accept this assertion? > > Regards, > -drc > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Sat Jul 12 18:53:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272841B292F for ; Sat, 12 Jul 2014 18:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj3BrW6zPKPQ for ; Sat, 12 Jul 2014 18:53:25 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 065F51B292B for ; Sat, 12 Jul 2014 18:53:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 610B51E3FAD; Sat, 12 Jul 2014 18:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YbIk3FpQvzZ; Sat, 12 Jul 2014 18:52:32 -0700 (PDT) Received: from [10.30.0.121] (unknown [83.150.71.93]) by c8a.amsl.com (Postfix) with ESMTPSA id 552DB1E1890; Sat, 12 Jul 2014 18:52:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: IETF Chair Date: Sun, 13 Jul 2014 04:53:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: To: ietf-announce@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/AVaT6ucND2ygy94LkdTCkRRBVOM Cc: ianaplan@ietf.org, internetgovtech@iab.org, IETF discussion list Subject: [Internetgovtech] IANAPLAN X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ianaplan@ietf.org List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 01:53:26 -0000 I wanted to draw attention to one of the meetings at IETF-90: The = IANAPLAN session. This meeting will discuss the transition of NTIA=92s stewardship of the = IANA functions to the global Internet community, including the IETF. = What is needed from the IETF, or are the RFCs, agreements, and = procedures that have evolved in this space during the last 15 years = already sufficient? The goal is to employ this forum for determining the eventual IETF = opinion on this matter. Our intent is also that IANAPLAN will form a = working group that will last until the transition is complete. In our = organisation the IAB has the responsibility for oversight of the IANA = relationship, so it is expected that the IAB and the IANA Program are = heavily involved in this discussion. Please join the meeting on Thursday, July 24, 0900-1130 in Ballroom, or = attend remotely. We have also started discussion on the list at = https://www.ietf.org/mailman/listinfo/ianaplan so please join that as = well. The session is chaired by Andrew Sullivan and Marc Blanchet (thank = you!). Jari Arkko IETF Chair From nobody Sat Jul 12 19:06:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17521B292D for ; Sat, 12 Jul 2014 19:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aigaYJQC8oWz for ; Sat, 12 Jul 2014 19:06:14 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1ABE1B292C for ; Sat, 12 Jul 2014 19:06:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id BD611118438 for ; Sat, 12 Jul 2014 22:06:11 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mBHd-7FwGTxJ for ; Sat, 12 Jul 2014 22:05:50 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 6B2C911842F for ; Sat, 12 Jul 2014 22:05:47 -0400 (EDT) Message-ID: <53C1E977.4050306@meetinghouse.net> Date: Sat, 12 Jul 2014 22:05:43 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> In-Reply-To: <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/f4mOUNS-fggS49zG-m5QoKyRur0 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 02:06:16 -0000 David Conrad wrote: > Miles, > > On Jul 12, 2014, at 3:12 PM, Miles Fidelman wrote: >> 1. ALL of ICANN's responsibilities and authority to perform the IANA function currently flow from the DOC-ICANN contract. >> 2. That includes the responsibilities for protocol numbers and such. > I think this will be quite surprising (if not amusing) to (e.g.) folks at RIPE-NCC, AfriNIC, LACNIC, and APNIC. I know individuals at ARIN have argued that there is a top-down chain of authority through various US government agreements, but that always struck me more as transparent and silly CYA driven by a lawyer than anything anyone actually believed in. > > It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220. Well, the RFC's specfically exclude domain and address functions, and preclude charging for anything - so that all comes from the DOC contract. The DOC contract - https://www.icann.org/en/system/files/files/contract-01oct12-en.pdf - includes things like this under contractor responsibilities: C.2.4 The Contractor is required to perform the IANA functions, which are critical for the operation of the Internet’s core infrastructure, in a stable and secure manner. The IANA functions are administrative and technical in nature based on established policies developed by interested and affected parties, as enumerated in Section C.1.3. The Contractor shall treat each of the IANA functions with equal priority and process all request spromptly and efficiently. C.2.9 Internet Assigned Numbers Authority (IANA) Functions include (1) the coordination of the assignment of technical Internet protocol parameters; (2) the administration of certain responsibilities associated with the Internet DNS root zone management; (3) the allocation of Internet numbering resources; and (4) other services related to the management of the ARPA and INT top level domains (TLDs). Which I read as saying: 1. We're paying you to perform all the IANA functions. 2. You've got to coordinate with all the other stakeholders. There's also a clause about: - you can't charge the USG - you CAN charge other people - but it has to be approved by the contract officer To the extent that anybody has "chartered" ICANN to play IANA - that seems to be where it comes from, as a follow-on to the old SRI-NIC contract. > >> 3. IETF's role is defined in the MOU, but seems to be in addition to, and/or enabled by the DOC-ICANN contract. > I'm unclear why you think there is any relationship between the MoU and the IANA Functions contract. How exactly does the IANA Functions contract enable the IETF/IAB/ICANN MoU? See above. > >> 4. If/when the contract lapses, any "official" responsibilities and authority end - except for what comes out of the transition process. > My impression has always been that the authority for the IANA Function operator (and, in fact, pretty much all other parts of Internet's system of unique identifiers) derives from the acceptance of the recipients of those resources to accept the coordination performed by the operator. For example, in the case of the IP addresses, an RIR serves as a voluntary coordination point that facilitates a multilateral arrangement for the association of IP address blocks with ISPs and others. Without this coordination service, there is no way the system would scale since it would require myriad bilateral agreements along the lines of "We agree that I have 1.0.0.0/8 and you have 2.0.0.0/8". There is no law that ensures this association -- it is purely the voluntary agreement of the parties involved to accept the association that allows it to work. > > A more thorough albeit dated (1996!) description of this view can be found in http://ccs.mit.edu/papers/CCSWP197/CCSWP197.html. > >> 1. The authority to charge for registry related activities, and use of those funds to pay for some of the other IANA functions, is all dictated by the DOC contract -- and it strike me as perfectly legitimate for DOC to require that the income stream support all of the IANA activities. In essence the contract is what grants ICANN it's franchise, and DOC can dictate the terms of that franchise. > Out of curiosity, why do you believe DoC has authority to grant the franchise on management of the Internet's system of unique identifiers? The contract, and a related document I came across where the DOC authorizes ICANN to charge registry fees. > > As a reductio ad absurdum thought experiment, assume DoC decided that this whole multistakeholder thing was a mistake and they decided to grant "the franchise" of the IANA Functions to Evil Defense Contractor, Inc., completely ignoring any input from the IETF, IAB, or anyone else. EDC then decides to charge (say) $1000 for every protocol parameter allocation, modification, or deletion. What would stop the IETF/IESG/IAB from deciding to pick their own "IANA" and having that IANA provide protocol parameter allocation, modifications, and deletion services under the terms the IETF/IESG/IAB permits? Well, that is the $64,000 dollar question underlying all this transition stuff, isn't it. > > Similarly, as another absurd thought experiment, there are some who argue that the U. S. Government owns all the address space. Suppose the USG decided to take back "their" address space, perhaps to sell it off to pay off the national debt. Why do you think ISPs of the world would accept this assertion? > > Chaos would ensue. This collaborative, multi-stakeholder stuff has been an experiment from day one - so far a successful one, but there have been blips - some of the games the backbone providers tried to pull around the NSFnet backbone, Michigan Bell trying to pull their dark fiber tariff - and so far, community reaction has righted the ship. Still, we're heading into another set of uncharted waters, where one organization is positioned to wreak havoc (either directly, or by community reaction to poor decisions). It seems only prudent to pay attention to some of these details. Right now, the DOC contract is a very loose framework that seems to be working. The transition group is charged with figuring out what comes next. Let's try to work out some of the details. The question of who pays for the IETF-related IANA functions seems to be one of those details. Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Jul 12 19:13:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875E21B2937 for ; Sat, 12 Jul 2014 19:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQVNCg2JzRfZ for ; Sat, 12 Jul 2014 19:13:26 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 42ACA1B2934 for ; Sat, 12 Jul 2014 19:13:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 26D1D138001 for ; Sat, 12 Jul 2014 22:13:24 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Hl99yJMmyxQV for ; Sat, 12 Jul 2014 22:12:56 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 2A39611842F for ; Sat, 12 Jul 2014 22:12:53 -0400 (EDT) Message-ID: <53C1EB22.9070907@meetinghouse.net> Date: Sat, 12 Jul 2014 22:12:50 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> In-Reply-To: <53C1DD6C.8030501@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/7fh10LZ6VotHwqM5fUGE6fT2LZs Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 02:13:27 -0000 Brian E Carpenter wrote: > On 13/07/2014 11:05, David Conrad wrote: >> Miles, >> >> On Jul 12, 2014, at 3:12 PM, Miles Fidelman wrote: >>> 1. ALL of ICANN's responsibilities and authority to perform the IANA function currently flow from the DOC-ICANN contract. >>> 2. That includes the responsibilities for protocol numbers and such. >> I think this will be quite surprising (if not amusing) to (e.g.) folks at RIPE-NCC, AfriNIC, LACNIC, and APNIC. I know individuals at ARIN have argued that there is a top-down chain of authority through various US government agreements, but that always struck me more as transparent and silly CYA driven by a lawyer than anything anyone actually believed in. >> >> It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220. > Well, it's a very legalistic view in an area where there is actually > no law (I mean international law) and no need for law, since things > work perfectly well without it. Arguably, things work because there's just enough law and contracts. Isn't the big concern all around "what happens when the very loose leash of the DOC contract expires?" It could be everything just continues to work, or chaos could ensue. The whole point of this multistakeholder discussion and transition process is to avoid chaos. > > In fact, the IETF/ICANN MoU is a signed and ratified document, > and I have been told in other contexts that such a document is exactly the > same thing as a contract if it ends up in court. Certainly the attention > paid to its wording by lawyers on both sides in 1999/2000 was exactly > what I have experienced in contract negotiations. Of course, if a court > had to decide between conflicting provisions of an NTIA/ICANN contract > and the IETF/ICANN MoU, one might trump the other. However, I think that > a lot of the ICANN lawyer's amendments to the MoU draft were intended > to avoid conflicting provisions. Yes, it's a contract - but it exists in the context of the DOC contract that says: C.2.4 The Contractor is required to perform the IANA functions, which are critical for the operation of the Internet’s core infrastructure, in a stable and secure manner. The IANA functions are administrative and technical in nature based on established policies developed by interested and affected parties, as enumerated in Section C.1.3. The Contractor shall treat each of the IANA functions with equal priority and process all request spromptly and efficiently. C.2.9 Internet Assigned Numbers Authority (IANA) Functions include (1) the coordination of the assignment of technical Internet protocol parameters; (2) the administration of certain responsibilities associated with the Internet DNS root zone management; (3) the allocation of Internet numbering resources; and (4) other services related to the management of the ARPA and INT top level domains (TLDs). Which, among other things is the framework under which ICANN charges for some IANA functions, and uses those funds to support the rest of the functions. Which funding is the issue that started this particular branch of discussion - who pays after the contract expires. > > As far as I can see, the only problem that actually needs a solution > right now is: who is the watchdog with adequate teeth to ensure that if > ICANN takes bad decisions about TLD policy, they can be set back on > the right track? That, and funding for the non-domain related functions! > > Everything else is in the "not broken, don't fix" category as far > as I am concerned. The RIRs and the IETF have ways to deal with > bad decisions by ICANN in their own areas of concern. As much as I'm in agreement with "if it ain't broke, don't fix it" - there is this looming change and a transition process underway. Seems only prudent to take steps to avoid breakage resulting from too little, or too much change and transition. Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Jul 12 20:20:39 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF481B294D for ; Sat, 12 Jul 2014 20:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scTsm9hoA5PZ for ; Sat, 12 Jul 2014 20:20:34 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D191B294C for ; Sat, 12 Jul 2014 20:20:33 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so3377210pde.26 for ; Sat, 12 Jul 2014 20:20:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xaUHECONIA4medsTzNPL3KrJPVusr4p/vRLqOXyfdNE=; b=VIPC4/H1GQUizdS7djUA+AVJmyJZjQ3YxTcI+VbJQeD02heTO8FOC0USuSp6jqh0Jt 7PELX91G95CkFi4rsV1y5iC7i7HvTSH67qE2+a9v6gPBs+fimqS3YkoEWpgkCB3sr2HX zqkzLqWipKJAT/Iv+wxxoEcQfwoR9ZDKpfb9IwyB9svsFrUe8C5auEVWiacUV99tsaNo Ed3T+hMs/5/8meaEShEXOsYJuqbqkFgjJTNr8hkHHFzv9CYjmEn6K0KZTeyCKC+Uib89 Duw+7JbnMylqOshaACVS2yl4Nm8W8Xdl87gRTZyTtwffD0DvI5+dXB7weAJpso8mI9SV oofA== X-Gm-Message-State: ALoCoQlTBIrc8TvgRS1MBR9QZzdEBbi5NWp+YAkIacCdhUYv69Uq/z8ED1liC64c/GpbgfQE+xyx X-Received: by 10.70.100.131 with SMTP id ey3mr8669717pdb.60.1405221633336; Sat, 12 Jul 2014 20:20:33 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id kn1sm6596782pbd.13.2014.07.12.20.20.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 20:20:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_35C28A5A-87C6-4A05-A49F-E4D35265A78E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Conrad In-Reply-To: <53C1E977.4050306@meetinghouse.net> Date: Sat, 12 Jul 2014 20:20:29 -0700 Message-Id: <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> To: Miles Fidelman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/uuLwPl4NAEsKaKMLFNyMe2UgBKg Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 03:20:37 -0000 --Apple-Mail=_35C28A5A-87C6-4A05-A49F-E4D35265A78E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Miles, On Jul 12, 2014, at 7:05 PM, Miles Fidelman = wrote: > Well, the RFC's specfically exclude domain and address functions, and = preclude charging for anything - so that all comes from the DOC = contract. No. It means that policy issues are dealt with outside of the context of = RFC 2860. That does not imply that the authority rests within the DoC = contract which did not even exist until the late '90s. If you traveled = back in time to the mid-90s and asked the folks who ran the RIRs, I can = say with some certainty that the authority for coordination of addresses = came from the membership of the RIRs, not the US government (in fact, = the RIRs provided funding for the IANA when the NSF/DARPA contracts = ended and before DOC unilaterally asserted its authority to define the = future of what eventually (and very unfortunately) became known as = "Internet Governance"). > To the extent that anybody has "chartered" ICANN to play IANA - that = seems to be where it comes from, as a follow-on to the old SRI-NIC = contract. That is one perspective, one that was popular within the US government = and very few other places. There are other perspectives, including the = one I've been mentioning and the arguments for those perspectives are as = valid as yours are. However, the arguments those differing perspectives lead to are also = pointless because in the end, the role that the IANA Function operators = performs is to implement what the communities it serves require it = implements. It is a coordinative function that ISPs, resolver operators, = registry operators, etc., voluntarily agree to participate in. If the = IANA Function operators screw up, then the communities will choose to = assign the function(s) to another entity. Period. >> What would stop the IETF/IESG/IAB from deciding to pick their own = "IANA" and having that IANA provide protocol parameter allocation, = modifications, and deletion services under the terms the IETF/IESG/IAB = permits? > Well, that is the $64,000 dollar question underlying all this = transition stuff, isn't it. No. The transition stuff is trying to figure out how to not disrupt the = way the Internet works while removing NTIA from the functions it = provides. As far as I can tell, those functions are: 1) ensure ICANN has followed its own processes in validating changes to = the root zone; 2) provide a mechanism by which ICANN can be held accountable for its = actions; 3) facilitate obtaining exemptions for dealing with entities under = sanction in order to provide registry services; and 4) reduce the risk ICANN will be subject to inappropriate legal, = economic, and/or geo-political pressure. (I've been told #3 isn't that big an issue anymore, but don't have = direct knowledge -- haven't been at ICANN for 4 years now and I'm told = things have changed) However, instead of dealing with that issue, my impression is that = people on this list and elsewhere have been far more focused on whether = or not a mailing list is used for communication instead of a web-based = forum and how that demonstrates ICANN is incompetent, inappropriate, = and/or evil. > The transition group is charged with figuring out what comes next. = Let's try to work out some of the details. =20 Great idea! > The question of who pays for the IETF-related IANA functions seems to = be one of those details. That is not a function that is currently performed by NTIA. Section 4.4 = and 4.5 of RFC 2860 is explicit that ICANN may not charge for = IETF-related IANA services. The existing arrangement appears to be = working and I have heard no one (other than perhaps yourself) arguing = that this is an issue that needs to be addressed as part of the = transition. In particular, neither the chair of the IETF, the chair of = the IAB, nor ICANN's CEO have suggested that the MOU needs to be = revised/terminated to allow ICANN to charge for IETF-related registry = services. I'm unclear why you think it is an issue. Regards, -drc --Apple-Mail=_35C28A5A-87C6-4A05-A49F-E4D35265A78E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTwfr+AAoJENV6ebf0/4rXFQgIAPiXUaC3csQGESY2lzw/F67H RSCOkSV+hjVpWjsQWumJ1GlfdxzB+AO7Me4sIp13vFawaaL+lczKSOiteY7czvsr sN/rJQsjtasSHa409FzMXfr1K9hqcVs2OKNEGB1OoVuCLA4Ws8JUvKOn31gB5Jmd HixQst83w25ZABrz8JOKYIGmF1/1dxYd5S44/DcxgOObjujBlxE3f963WDtzhoeL QXW/ENwicXQghmVXQRRml7pyMN8f3LrvU9LL2ztcqq2H9n9du2ALBFWmhm/aElZ5 U2UB14ILxVu21vA6GOyy7wEyY2Z9xKSA1fBO9/T/yHj7EktvQpOWnIeRimxey5M= =WzYA -----END PGP SIGNATURE----- --Apple-Mail=_35C28A5A-87C6-4A05-A49F-E4D35265A78E-- From nobody Sat Jul 12 22:19:03 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974A71B2953 for ; Sat, 12 Jul 2014 22:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROckBpfWeYtf for ; Sat, 12 Jul 2014 22:19:00 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A081B28A1 for ; Sat, 12 Jul 2014 22:18:54 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6D5Ir7p060173 for ; Sat, 12 Jul 2014 22:18:53 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53C216BD.1010605@abenaki.wabanaki.net> Date: Sat, 12 Jul 2014 22:18:53 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OcYJ0xgnA0Hut05JqBOYlQgsgwA Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 05:19:01 -0000 On 7/12/14 2:38 PM, John C Klensin wrote: > ... > Assuming that your calculations are correct (I suspect they are > close enough for analysis purposes). The "17 cents per..." > style of analysis seems to me to be useful in only two sets or > scenarios: My point John is merely that this function, for which the US Government takes some present interest, through both the Executive and Legislative branches, is presently implemented through a no-cost contract. Were Government to return to the prior contractual form, this particular item, when amortized across some nominal broad notion of users (Elliot, and Brian, have been making a user-pays argument, where user appears to be defined as domain registrants, privatization presumed, though a "user pays" claim for protocol parameters, generally, is rather narrow if limited to domain registrants, and has the effect of privileging a former monopoly retaining market power, and its sales channels, and trademark holders, with more access to policy making than other, larger definitions of "user"), has a "cost" that is rather small. > > (1) To claim that IANA is a public good that should be paid out > of the public coffers without worrying too much about the > amounts involved. Before looking to whether or not the IANA is a "public good", it is a public function, authorized by legislation which in turn is interpreted and implemented by an agency of government. > If one makes that argument, one must, I > think, be prepared to argue Nope. See above. > that IANA is more important (in > terms of priority access to the public coffers) than other > public goods, such a preventing starvation, educating small > children, sundry emergency services such as police and fire > departments, etc. I'm disinclined to go there; YMMD. > (2) If one has taxing authority with regard to the sources whose > resource impact is being measured and intends to use it. ICANN > clearly does not have that authority (independent of whether it > can assess fees on entities who do business with it, a different > matter) and a further separation of ICANN from the US Government > also further separates it from anyone with such authority. > Even if ICANN's (or IANA's) ties to the government were closer, > I don't think additional (or new) taxes, especially on > "Community Anchor Institutions" who are mostly nonprofit and > tax-exempt would have much chance in today's legislative > environment in the US. $7.2bn/$4.7bn. The BTOP. And the $0.17/yr salami slice can be taken before it is distributed to the subscriber CAIs. > All of that is obvious independent of the question of whether, > if IANA is going to be treated as a public good or the > equivalent thereof (as several of the discussion threads on this > list effectively suggest even if they don't use those words) ... The IANA function benefits the public. However, that isn't the issue. Eric From nobody Sun Jul 13 04:49:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF241B2B45 for ; Sun, 13 Jul 2014 04:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuUE-cpaXkPk for ; Sun, 13 Jul 2014 04:49:30 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 101261B2A8F for ; Sun, 13 Jul 2014 04:49:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 195B5CC080 for ; Sun, 13 Jul 2014 07:49:24 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1LYRxd58E0w2 for ; Sun, 13 Jul 2014 07:49:15 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 4CACCCC07E for ; Sun, 13 Jul 2014 07:49:15 -0400 (EDT) Message-ID: <53C2723A.7030101@meetinghouse.net> Date: Sun, 13 Jul 2014 07:49:14 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> In-Reply-To: <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/CthXNYtJurkQHRgUzNxG7jPGmE0 Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 11:49:31 -0000 David Conrad wrote: > >>> What would stop the IETF/IESG/IAB from deciding to pick their own "IANA" and having that IANA provide protocol parameter allocation, modifications, and deletion services under the terms the IETF/IESG/IAB permits? >> Well, that is the $64,000 dollar question underlying all this transition stuff, isn't it. > No. The transition stuff is trying to figure out how to not disrupt the way the Internet works while removing NTIA from the functions it provides. As far as I can tell, those functions are: > > 1) ensure ICANN has followed its own processes in validating changes to the root zone; > 2) provide a mechanism by which ICANN can be held accountable for its actions; > 3) facilitate obtaining exemptions for dealing with entities under sanction in order to provide registry services; and > 4) reduce the risk ICANN will be subject to inappropriate legal, economic, and/or geo-political pressure. Isn't that what I just said? >> The question of who pays for the IETF-related IANA functions seems to be one of those details. > > That is not a function that is currently performed by NTIA. Section 4.4 and 4.5 of RFC 2860 is explicit that ICANN may not charge for IETF-related IANA services. The existing arrangement appears to be working and I have heard no one (other than perhaps yourself) arguing that this is an issue that needs to be addressed as part of the transition. In particular, neither the chair of the IETF, the chair of the IAB, nor ICANN's CEO have suggested that the MOU needs to be revised/terminated to allow ICANN to charge for IETF-related registry services. I'm unclear why you think it is an issue. > Umm.. yes, it is. ICANN plays its role in the process, because the DOC contract says that it must perform those functions. And it cross-subsidizes those functions from its income stream from other IANA functions. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sun Jul 13 05:04:50 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A111B2B5F for ; Sun, 13 Jul 2014 05:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_j7DieGooWR for ; Sun, 13 Jul 2014 05:04:48 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092661B2B55 for ; Sun, 13 Jul 2014 05:04:48 -0700 (PDT) Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:59905 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X6IVt-0008CS-Bg for internetgovtech@iab.org; Sun, 13 Jul 2014 05:04:46 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_B2FFA107-A862-4A12-8C24-5E2E1D107AAF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sun, 13 Jul 2014 08:04:17 -0400 References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <6F94B6B7-1C04-47BF-B04A-DF8C69E5D5C5@cs.georgetown.edu> To: internetgovtech@iab.org In-Reply-To: <6F94B6B7-1C04-47BF-B04A-DF8C69E5D5C5@cs.georgetown.edu> X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 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 - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/47eLvKEpqN4LCZKG7Wi3Z6hFZrk Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 12:04:49 -0000 --Apple-Mail=_B2FFA107-A862-4A12-8C24-5E2E1D107AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is not just David's perception - these are the facts on the ground. The IANA works because everyone =91happens=92 to use it. There are no = contracts mandating it, no treaties mandating it, no laws mandating it. = Tomorrow, someone could say, =93I=92m the new IANA function, use me!=94 = In fact, that has happened: c.f. Name.Space, OpenNIC, New.net, etc. And=85= no one cared and for the most part, everyone uses the ICANN IANA = directories. If anything, those facts on the ground means we need to be MORE careful = about how we proceed than sanguine. One can envision an organization = imposing a treaty regime requiring the use of a particular IANA protocol = parameters function, IP address function, and domain name function. That = would most likely not be in the IETF=92s interest. On Jul 12, 2014, at 7:05 PM, David Conrad wrote: > My impression has always been that the authority for the IANA Function = operator (and, in fact, pretty much all other parts of Internet's system = of unique identifiers) derives from the acceptance of the recipients of = those resources to accept the coordination performed by the operator. = For example, in the case of the IP addresses, an RIR serves as a = voluntary coordination point that facilitates a multilateral arrangement = for the association of IP address blocks with ISPs and others. Without = this coordination service, there is no way the system would scale since = it would require myriad bilateral agreements along the lines of "We = agree that I have 1.0.0.0/8 and you have 2.0.0.0/8". There is no law = that ensures this association -- it is purely the voluntary agreement of = the parties involved to accept the association that allows it to work. >=20 > A more thorough albeit dated (1996!) description of this view can be = found in http://ccs.mit.edu/papers/CCSWP197/CCSWP197.html. >=20 >> 1. The authority to charge for registry related activities, and use = of those funds to pay for some of the other IANA functions, is all = dictated by the DOC contract -- and it strike me as perfectly legitimate = for DOC to require that the income stream support all of the IANA = activities. In essence the contract is what grants ICANN it's = franchise, and DOC can dictate the terms of that franchise. >=20 > Out of curiosity, why do you believe DoC has authority to grant the = franchise on management of the Internet's system of unique identifiers? >=20 > As a reductio ad absurdum thought experiment, assume DoC decided that = this whole multistakeholder thing was a mistake and they decided to = grant "the franchise" of the IANA Functions to Evil Defense Contractor, = Inc., completely ignoring any input from the IETF, IAB, or anyone else. = EDC then decides to charge (say) $1000 for every protocol parameter = allocation, modification, or deletion. What would stop the IETF/IESG/IAB = from deciding to pick their own "IANA" and having that IANA provide = protocol parameter allocation, modifications, and deletion services = under the terms the IETF/IESG/IAB permits?=20 >=20 > Similarly, as another absurd thought experiment, there are some who = argue that the U. S. Government owns all the address space. Suppose the = USG decided to take back "their" address space, perhaps to sell it off = to pay off the national debt. Why do you think ISPs of the world would = accept this assertion? --Apple-Mail=_B2FFA107-A862-4A12-8C24-5E2E1D107AAF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTwnXCAAoJEDY/T2tCIPW3UAcP/264xIPHQsn+d0XUaQppH+P/ Jw3OgU864tgVVRjPhtCow3GBnjjcrmOs8kaQCRMFzaxU5CJnkXW02jidB5i2ry7v 8Wt/GEh/XxEApyjzJOwYgtrCh5aRVpcVEdGqcxx1c4470rydPBfZ35q1Xga4F30T u8iOD+0rG9wliAHEX4W20OOY7hTzazGXyV2cOj2sdrFr9Jkq8MtDLqNdjIdjE2c1 61BpdGY0BcoWYG3pf1XdB/ROolcBwMBYk//TR5z7uvt5K4iMvjpxuRwck9nJX5a4 rjnuNHeCp1aD+m7NsXAHS2j/ml9UHhB8q1DoC5lGP+xztfyPKjiR7+s0Er5064dh ZRIi8cRf8RAQeUCTU6LLfuvsK0zZfoc6YjMFLjcMjA+nQihlDNCBFa22lCmDC+AH gYVHbAPvBaTl06Ph5s0zAG4nK24wK+FKfCLffrT075oIe6PDPjNxziRlnlWuUBVb 7MJRELemG+UVwH0F6YOkkMCUdc04U0Meme7vOS6rCJiDJJ7PguTWLPK5oMQyAPYE dLF+9bB0E8gc9NwyoHHnw2zIY+LBctB5nptmWsgXwK6Y8lUP1AA2HanUkIwFKDOj ivDHglWP1i75BzETJm6Uvc5VT4Kc3rpk3khiLdR6imffc5yRUVHLTm6shOG4DTdX ptSpRE1iB4pFivNuJtPY =jjiF -----END PGP SIGNATURE----- --Apple-Mail=_B2FFA107-A862-4A12-8C24-5E2E1D107AAF-- From nobody Sun Jul 13 05:07:09 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5491B2B63 for ; Sun, 13 Jul 2014 05:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SvWGb9pxNCD for ; Sun, 13 Jul 2014 05:07:05 -0700 (PDT) Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id EDF1B1B2B62 for ; Sun, 13 Jul 2014 05:07:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1D8B42CCC0; Sun, 13 Jul 2014 15:07:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wegofMroL8w; Sun, 13 Jul 2014 15:06:55 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 14FBA2CC48; Sun, 13 Jul 2014 15:06:55 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_4ED3DEB5-1D62-4305-9F6B-4324F02DE8A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> Date: Sun, 13 Jul 2014 15:06:45 +0300 Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WuGdr7CpuIEEOmSjO6RGYOCd3zY Cc: internetgovtech@iab.org Subject: [Internetgovtech] Costs (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 12:07:07 -0000 --Apple-Mail=_4ED3DEB5-1D62-4305-9F6B-4324F02DE8A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > No. The transition stuff is trying to figure out how to not disrupt = the way the Internet works while removing NTIA from the functions it = provides. As far as I can tell, those functions are: >=20 > 1) ensure ICANN has followed its own processes in validating changes = to the root zone; > 2) provide a mechanism by which ICANN can be held accountable for its = actions; > 3) facilitate obtaining exemptions for dealing with entities under = sanction in order to provide registry services; and > 4) reduce the risk ICANN will be subject to inappropriate legal, = economic, and/or geo-political pressure. >=20 > (I've been told #3 isn't that big an issue anymore, but don't have = direct knowledge -- haven't been at ICANN for 4 years now and I'm told = things have changed) >=20 > However, instead of dealing with that issue, my impression is that = people on this list and elsewhere have been far more focused on whether = or not a mailing list is used for communication instead of a web-based = forum and how that demonstrates ICANN is incompetent, inappropriate, = and/or evil. The above list is indeed good. >> The question of who pays for the IETF-related IANA functions seems to = be one of those details. >=20 >=20 > That is not a function that is currently performed by NTIA. Section = 4.4 and 4.5 of RFC 2860 is explicit that ICANN may not charge for = IETF-related IANA services. The existing arrangement appears to be = working and I have heard no one (other than perhaps yourself) arguing = that this is an issue that needs to be addressed as part of the = transition. In particular, neither the chair of the IETF, the chair of = the IAB, nor ICANN's CEO have suggested that the MOU needs to be = revised/terminated to allow ICANN to charge for IETF-related registry = services. I'm unclear why you think it is an issue. For what it is worth, David is right above. I would like to suggest that = focusing on the costs is the wrong way to approach the issue. Lets first = ensure that we have a system that performs the right functions, and I = think we are already close to that. =46rom the 10.000 ft perspective the = costs are not such a big issue that they should drive the transition in = any particular direction. At least not for protocol parameters. Jari --Apple-Mail=_4ED3DEB5-1D62-4305-9F6B-4324F02DE8A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTwnZVAAoJEM80gCTQU46qI5sQAIlXsdqhWb45LG2OmGQqxGLn zAnMNSXUAaaON/1ZCY3oesbctr/N0i1khpOW1F9AgvoXZ4rdhxeHohBySnH53U3i vat6DxwZCb3BL/fBIX3cWGZ4N5/aHOFIY2tPY0LeNXP7niaodruAD5Q1HzJ6QSpi OzkdbMlaRwvAi0ZyjHoBh4Tlgubpg6fzIWuasKdmhDMCbE8JHuKvYv3M3QD9DWij +UjLe1gDfrKXHSwWnyoUrtWa+pKfDgxPg6lCQUtRdHI9F4jatlyZtqRglGF/j6Gb dR0IuAN+hWrg+X13tlgZPsqaPyiVBSQFxfSEHymL4B8aNgqJx2d61rwDZGfFcPtJ udh7hbrRaWwmLpWi0IvzhLXuBvgXH4RMXsJVudTdBUl0poz4q6VvViNC3UGct0Na lUr5Lgj5vrnS3isodKSbdO41pjGuJlTH4eNmvsOc7gnSy5CAC37kkrmPlDhmgbAB emCb4svdr+6bJBDFZMMl4kyUrt4zeda+R+tbRhOg1zLkmfOfV1kTLkgdITsHrbO8 5fALJjN3LfJz4/8Xvn5ittd2l2zcljn9p0o7CZ6I79IfAgaiNH8rnxYvIJai49mU 6MAi3v03KwQ9EtGriYX+ALvOdZSFjCOupWrx070ZYPSAII55kPCMEwK2/6pTdAH8 J//ihNVhNm68uCafNvAb =G+ML -----END PGP SIGNATURE----- --Apple-Mail=_4ED3DEB5-1D62-4305-9F6B-4324F02DE8A2-- From nobody Sun Jul 13 08:23:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533E01B2AA5 for ; Sun, 13 Jul 2014 08:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS60iWt8-VVE for ; Sun, 13 Jul 2014 08:23:03 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105741B2909 for ; Sun, 13 Jul 2014 08:23:02 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so3008631wgg.28 for ; Sun, 13 Jul 2014 08:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E8y57LF5plnkoZ2mB5unNvW4zjjJACwlpNS/KVHxeVI=; b=ubs2j3w1YYE6ccPJMuORI52HVtKMsXnIiQ4WqM5aIOaz3WeCjvAj9yOM0q2bulLHxH Sqvo+eT8gQEx+587TM8lM2nQk5XDbEiBDeImXdYBnqUEOzefZCFrdvBHyU3B/xoGdQXi 9pqzTWcWBtaOzjbofp2bCx7EfKgpqQw1ISyy+5NJxDPKDUQDoZgelksUcYzW4eFzSMKI NWZt9i00oeKnwnNv9u7nOGrRsd1J2L97u2Ja7+zCyy4fAmNPkjHl7esxJZyKQ6i4OW7c 926cM2YOAHnph7hZ6AozbHXlXSc+P4W2pRIo28B98pVNUbUNHeTyNIiO5mMwqQwXHO1A zR4A== MIME-Version: 1.0 X-Received: by 10.180.74.11 with SMTP id p11mr2250665wiv.68.1405264981654; Sun, 13 Jul 2014 08:23:01 -0700 (PDT) Received: by 10.181.13.18 with HTTP; Sun, 13 Jul 2014 08:23:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Jul 2014 16:23:01 +0100 Message-ID: From: Abdussalam Baryun To: "ianaplan@ietf.org" Content-Type: multipart/alternative; boundary=f46d043891c30c03fd04fe14c00c Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/zvZ30li_Gtu0L6anjjqbk8Kco2s Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] IANAPLAN X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 15:23:04 -0000 --f46d043891c30c03fd04fe14c00c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support that we form an IETF WG for discussing and delivering RFCs for the transition. IMO, in IETF only WGs can present for the internet community. As IETF opinion SHOULD always be based on the community. AB On Sunday, July 13, 2014, IETF Chair wrote: > I wanted to draw attention to one of the meetings at IETF-90: The IANAPLA= N > session. > > This meeting will discuss the transition of NTIA=E2=80=99s stewardship of= the IANA > functions to the global Internet community, including the IETF. What is > needed from the IETF, or are the RFCs, agreements, and procedures that ha= ve > evolved in this space during the last 15 years already sufficient? > > The goal is to employ this forum for determining the eventual IETF opinio= n > on this matter. Our intent is also that IANAPLAN will form a working grou= p > that will last until the transition is complete. In our organisation the > IAB has the responsibility for oversight of the IANA relationship, so it = is > expected that the IAB and the IANA Program are heavily involved in this > discussion. > > Please join the meeting on Thursday, July 24, 0900-1130 in Ballroom, or > attend remotely. We have also started discussion on the list at > https://www.ietf.org/mailman/listinfo/ianaplan so please join that as > well. > > The session is chaired by Andrew Sullivan and Marc Blanchet (thank you!). > > Jari Arkko > IETF Chair > > --f46d043891c30c03fd04fe14c00c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support that we form an IETF WG for discussing and delivering RFCs for th= e transition. IMO,=C2=A0in IETF only WGs can present=C2=A0for the internet= =C2=A0community. As=C2=A0IETF opinion SHOULD always=C2=A0be based on the=C2= =A0community.=C2=A0

AB

On Sunday, July 13, 2014, IETF Chair wrote:
I wanted to draw attention to one of the meetings at IET= F-90: The IANAPLAN session.

This meeting will discuss the transition of NTIA=E2=80=99s stewardship of t= he IANA functions to the global Internet community, including the IETF. Wha= t is needed from the IETF, or are the RFCs, agreements, and procedures that= have evolved in this space during the last 15 years already sufficient?
The goal is to employ this forum for determining the eventual IETF opinion = on this matter. Our intent is also that IANAPLAN will form a working group = that will last until the transition is complete. In our organisation the IA= B has the responsibility for oversight of the IANA relationship, so it is e= xpected that the IAB and the IANA Program are heavily involved in this disc= ussion.

Please join the meeting on Thursday, July 24, 0900-1130 in Ballroom, or att= end remotely. We have also started discussion on the list at https://www.= ietf.org/mailman/listinfo/ianaplan so please join that as well.

The session is chaired by Andrew Sullivan and Marc Blanchet (thank you!).
Jari Arkko
IETF Chair

--f46d043891c30c03fd04fe14c00c-- From nobody Sun Jul 13 08:53:54 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D13D1B2A80 for ; Sun, 13 Jul 2014 08:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_FINANCIALPROBLEM=1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBsQtffXlZW3 for ; Sun, 13 Jul 2014 08:53:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78E71B2A79 for ; Sun, 13 Jul 2014 08:53:50 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X6M2M-000Aaq-PG; Sun, 13 Jul 2014 11:50:02 -0400 Date: Sun, 13 Jul 2014 11:53:44 -0400 From: John C Klensin To: Miles Fidelman Message-ID: In-Reply-To: <53C2723A.7030101@meetinghouse.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> <53C2723A.7030101@meetinghouse.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3eAG4tLuK_5k2AXmLK6aOIty594 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 15:53:53 -0000 --On Sunday, July 13, 2014 07:49 -0400 Miles Fidelman wrote: >> That is not a function that is currently performed by NTIA. >> Section 4.4 and 4.5 of RFC 2860 is explicit that ICANN may >> not charge for IETF-related IANA services. The existing >> arrangement appears to be working and I have heard no one >> (other than perhaps yourself) arguing that this is an issue >> that needs to be addressed as part of the transition. In >> particular, neither the chair of the IETF, the chair of the >> IAB, nor ICANN's CEO have suggested that the MOU needs to be >> revised/terminated to allow ICANN to charge for IETF-related >> registry services. I'm unclear why you think it is an issue. > > Umm.. yes, it is. ICANN plays its role in the process, > because the DOC contract says that it must perform those > functions. And it cross-subsidizes those functions from its > income stream from other IANA functions. Miles, I think what you (and a few others) are losing track of is that there is both a legal contract and social contract involved in this. The latter has existed much longer, long before ICANN came in being. Had NTIA, as part of the initial ICANN contract, said "we don't care what you do with IANA, the only thing we care about is the path from your decisions about TLDs to distribution of the root zone" we'd be having different "governance" debates today (I agree with David about the odiousness of that term and believe its use has distorted the discussion) but it still would have been very much in ICANN's interest to preserve (and pay for) the IANA function. Similarly, even if one believes that the IETF-IAB-ICANN MOU has no (or at least dubious) enforceable legal status, it is documentation of the intent of parties involved in IANA (out of mutual self-interest, not contractual obligations) as to how those functions will be carried out, thereby avoiding misunderstandings. It is worth remembering that, significantly pre-ICANN, IANA actually was the locus of the policy functions. The IETF _requested_ that IANA create registries and, and some cases, make allocations; IANA occasionally said "no, that makes no sense". A large fraction of registrations occurred without IETF involvement -- the level of detail and IETF authority in RFC 5226 and its predecessors not only didn't exist, but such a document might well have been rejected by the IANA because it exceeded the IETF's authority to approve such a thing (a discussion that would have occurred within the IAB, by the way). The transition to an IANA that was almost entirely an administrative function rather than a policy one started before ICANN but the formation of ICANN marks, IMO, the major switchover. Even today, ICANN, at least IMO, draws a considerable portion of its perceived legitimacy from hosting the IANA function. If only out of self-interest, I think the odds of their intentionally and consciously abusing that function sufficiently to cause other parties to make and carry out other plans are too small to be worried about. I thing we should probably worry much more about the same sorts of "seemed like a good idea at the time" moves, without adequate consultation to understand the undesirable effects, that seem to have characterized the transition move that started this thread. That probably reinforces being careful about the oversight questions but, at least absent doomsday scenarios [1], doesn't have much to do with finances. The shift of policy authority to IANA's "clients" didn't prevent misunderstandings and what we would now claim were attempts at abuse. There were early incidents of ICANN/IANA staff believing that IANA's historic policy authority allowed them to review IETF allocation requests and implement (or change) them unilaterally. Those incidents slipped under the radar of the ICANN Board and stopped only after NTIA stepped in (after requests from the direction of the IETF). In part because I think even more goes on without effective, in-depth oversight from the ICANN Board today than was the case in ICANN's earliest days (but perhaps I'm just suffering from nostalgic delusions), that history probably reinforces the case for ICANN not being allowed to be self-overseeing, but it has little or nothing to do with finances. Similarly, one of the advantages of the early IANA arrangements --in which the IETF/IESG was insulated from allocation decisions rather than directly supervising them-- was that it provided considerable protection against perceptions of business conspiracies and antitrust claims. Today, if someone claimed that a registration had been denied (or one granted that shouldn't have been) because the IESG was dominated by competitors of the applicant and/or had appointed a biased expert, things would get _lots_ more complicated. Neither being a lawyer nor a good predictor of the future, I can't guess whether that situation would become more or less difficult without even nominal US Government oversight/ supervision of IANA, but I'd rather see people worried about that than about the details of financial relationships. I also think there may be some lessons for the IETF and the IANA protocol registry functions in the care that most of the RIRs have exerted to separate actual allocation decisions from policy-making, but those issues are not part of the divesture or oversight questions and actually run counter to the tone and assumptions of RFC 5226 and some later documents and actions. best, john [1} I do worry about finances a bit more than Jari's note suggests that he does. The reason is the hypothesis that the "domain name market" is a bit of a bubble that could collapse (e.g., as the understanding becomes more general that users are lots more dependent on search engines and local bookmarks/favorites than on the details of DNS names at the top few levels of the tree). Should that bubble burst, drying up new TLD applications and even significantly reducing registrations and reregistrations in existing TLDs, ICANN and other organizations that are dependent on the revenue stream associated with the names market (including ISOC) could find themselves faced with some very hard decisions about priorities, decisions that, in the extreme case, could involving trading off staff, offices, and travel against supporting IANA (and the IETF) in the style to which they have become accustomed. A few years ago, I would have been confident that the RIRs would step in again but, with the exhaustion of IPv4 space and allocations of IPv6 space in very large blocks, their business (and revenue flow) models aren't what they were a half-dozen years ago either. So there could, long-term, be a financial problem. But it isn't the oversight / divesture problem and, IMO, should not be used to distract from conversations about that problem. From nobody Sun Jul 13 14:16:28 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C72F1A016A for ; Sun, 13 Jul 2014 14:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHwRK0HDqWjH for ; Sun, 13 Jul 2014 14:16:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF131A0162 for ; Sun, 13 Jul 2014 14:16:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 12E092CEAE; Mon, 14 Jul 2014 00:16:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Im7PBQEgof; Mon, 14 Jul 2014 00:16:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 225012CC48; Mon, 14 Jul 2014 00:16:13 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_1A7D3145-E5D5-4641-A07C-B6C78C745C3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: Date: Mon, 14 Jul 2014 00:16:01 +0300 Message-Id: <7C8D6A8D-EF99-4D78-8B8F-0D93BBF76648@piuha.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> <53C2723A.7030101@meetinghouse.net> To: John C Klensin X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Dun-NvE1PYoYwabd16tPygZvnEo Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Costs (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 21:16:25 -0000 --Apple-Mail=_1A7D3145-E5D5-4641-A07C-B6C78C745C3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your note, John. I think we are in agreement=85 perhaps even=20= more than you assume :-) I just wanted to clarify my thinking regarding=20= the finances part: > [1} I do worry about finances a bit more than Jari's note > suggests that he does. The reason is the hypothesis that the > "domain name market" is a bit of a bubble that could collapse > (e.g., as the understanding becomes more general that users are > lots more dependent on search engines and local > bookmarks/favorites than on the details of DNS names at the top > few levels of the tree). There are several scenarios where something like the above could happen. My slightly smaller worry of the finances than yours is not so much dependent on believing that such things could not happen. They could, particularly on a longer timescales. My opinion was based more on the relative size of the cost associated with the protocol parameters function. And a personal opinion about the likelihood of being able to finance that in some=20 new scenario. Not hoping a bad scenario comes to reality, but I am relatively confident about the kinds of things we could do under different circumstances. YMMV. Jari --Apple-Mail=_1A7D3145-E5D5-4641-A07C-B6C78C745C3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTwvcRAAoJEM80gCTQU46q2XwP/ArDrGVj9D1rstGJszG0kDqO QcyOKrW4JvGgLUTBw2h4BmFkKUU4oBoWDFQ5JQ3GkusRGm6UGFH6lkJpOnnlp+Te rZdJfandwyDWhB2QXHCgpFRin9SQt1LPQJb7qdw0O0drBiHyDs+/bXEZmPBvI+j1 kLiJC6pU1/tsKV+AUdB4y/c0bUW/M4H99HkHXvZJh8TmqxOVHLa8NyE5Z/GVkKFE 9GVKIWOFzz9P9wKsStfxEXyhVdYGWZUa3NRrs27fpRSz4upq7i8d3tZrxMiVdSNy Sr63wBLty7BfUVBtNcymhb3A97wgklHSb3n+4pqg54JEOZDtxnB+FpFfSIyQ7C3h OzxUkIdjAyOPTdhrUTrO8Qp4YufQLHMjScF6ZT5kIWYxP4yYWcmGq+SB92Vf8tqb n+ITcPe7K4uKDPS+HChFuwTqqbemkBdbPWO3fPm1t64wlT1zvVAeJcVMAIYAjIRa lhWikCz0YS/07+TcogBqLiqvpW0JHMAlcxseTDhSkeXpz046KFt5zbSd55EOHMfn L1Rvo8Vk9tlwnZ+f3+VL4NRFep3i2mcfkakVemLgsX/dtAgo5Qzc4dHwkP+z5YZi i0DDcWpIE54IeAnromj3SYr/a00huiJOqcCwx098bYYGv75Tv2DynEj8kmgEEPGA vLlOO1Mzneopc2md6n7W =j72W -----END PGP SIGNATURE----- --Apple-Mail=_1A7D3145-E5D5-4641-A07C-B6C78C745C3F-- From nobody Sun Jul 13 15:20:52 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27901A01C3 for ; Sun, 13 Jul 2014 15:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.819 X-Spam-Level: * X-Spam-Status: No, score=1.819 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRDSdRqVCOFs for ; Sun, 13 Jul 2014 15:20:46 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id D99AA1A01BA for ; Sun, 13 Jul 2014 15:20:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id CD246118445 for ; Sun, 13 Jul 2014 18:20:42 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KYV2zAxQZ85A for ; Sun, 13 Jul 2014 18:20:32 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id BFD2B11842F for ; Sun, 13 Jul 2014 18:18:31 -0400 (EDT) Message-ID: <53C305B5.4020108@meetinghouse.net> Date: Sun, 13 Jul 2014 18:18:29 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> <53C2723A.7030101@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Q2nlN2wFHqwbswZWaGzwQPsLciQ Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 22:20:48 -0000 John C Klensin wrote: > Miles, > > I think what you (and a few others) are losing track of is that > there is both a legal contract and social contract involved in > this. The latter has existed much longer, long before ICANN > came in being. John, Thanks for the thoughtful note. I guess I'm just a bit more jaded about the strength of the social contract in the face of shifting legal contracts and economic considerations. Yes - the Internet operates, and operates pretty well, because of a web of social contracts and conventions - but.... my perception is that there has always been a near-invisible hand that enabled and supported the social contracts - right back to the days of the initial RFCs. If it weren't for the gentle, and sometimes not so gentle hands of the early DARPA and NSF program managers involved in the early days (and NASA, and DoE, ...) we could easily be living in a world of balkanized networks, and/or a world much more like that of the telcos and cable companies. In the early days, it was a matter of key personalities, some of whom controlled everyone's funding, that framed the cooperative governance style that has evolved for what has become global infrastructure (personally I give a lot of the credit to Bob Kahn, during his tenure as ARPANET PM, and Vint Cerf for the notion of transitioning IETF to ISOC stewardship). And, of course, John Postel, when it comes to what's become IANA. I'm a little less sanguine about how things might develop, now that the early players are getting a bit long in the tooth, and large pieces of both the network infrastructure and its supporting organizations have become "big business." And, of course, we have the growing focus of government regulators entering the fray. I see the NTIA contract as sort of the last legacy of a guiding hand that has nurtured and protected the social contracts that keep the net "working." And I see the transition as an opportunity for a lot of things to go wrong - whether by intent (traditional regulators getting their nose into the tent, repressive governments doing their things, business interests doing their thing) or accident. All going on in parallel with the wranglings over "network neutrality" work their way through the FCC and the courts. I worry that the sentiment of "if it ain't broke, don't fix it" doesn't recognize that something really is shifting in the framework that has shaped Internet governance to date - and if we're not careful, a few years down the road we're going to be wringing our hands about details that we should have worried about today. I think it behooves us to lift up the hood and understand, in detail, the interplay between legal contracts, social contracts, and general understanding and cultural conventions - as we go into this transition. Regards, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Jul 14 08:01:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4A61A0653 for ; Mon, 14 Jul 2014 08:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKthjXHIYyf7 for ; Mon, 14 Jul 2014 08:00:47 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B191A0648 for ; Mon, 14 Jul 2014 08:00:47 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1X6hkD-0001Eh-H5; Mon, 14 Jul 2014 17:00:45 +0200 Received: from localhost by x27.adm.denic.de with local id 1X6hkD-00053U-C8; Mon, 14 Jul 2014 17:00:45 +0200 Date: Mon, 14 Jul 2014 17:00:45 +0200 From: Peter Koch To: internetgovtech@iab.org Message-ID: <20140714150045.GF27563@x28.adm.denic.de> Mail-Followup-To: internetgovtech@iab.org References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <7D8B6314-F38B-4B49-A146-5AE59F371C14@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vArHs4FmiA2kbL6p1I1Lun_FjDM Subject: Re: [Internetgovtech] Costs (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 15:00:56 -0000 On Sun, Jul 13, 2014 at 03:06:45PM +0300, Jari Arkko wrote: > For what it is worth, David is right above. I would like to suggest that focusing on the costs is the wrong way to approach the issue. agree with "focussing", since this is not the IETF-IANA migration list. However, somewhere down the priorities list there should be an item to think about other options, probably including loooking for a different service provider. At one of the recent IETF meetings, during an IANA session, we were informed that the cost for the IETF part of the IANA function isn't even assessed and instead subsumed under the overall IANA budget. This likely takes advantage of some synergies having the 3.25(*) pillars served at the same place, but OTOH limits the exploration of said other options. I'm not interested in the actual figures now and here, nor in (alternative) sources of funding, but in making sure we do have a way to get there. As a side effect, putting a cost against (opening) an IANA registry might give valuable input to the standardization process. -Peter (*) 0.25 extra for the entangled subjects "names" and "root zone" From nobody Mon Jul 14 08:52:55 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F75B1B2922 for ; Sat, 12 Jul 2014 18:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GudWWkPzMgT for ; Sat, 12 Jul 2014 18:25:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C648C1B291A for ; Sat, 12 Jul 2014 18:25:35 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-6c-53c1e00d3c92 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.68.04090.D00E1C35; Sun, 13 Jul 2014 03:25:33 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.174.1; Sun, 13 Jul 2014 03:25:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C9C45110298; Sun, 13 Jul 2014 04:25:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 18C534E9C6; Sun, 13 Jul 2014 04:26:25 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 981F34E97B; Sun, 13 Jul 2014 04:26:24 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C5EF1A1E-1877-410F-9566-DC364EFC1C59"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: <53C1DD6C.8030501@gmail.com> Date: Sun, 13 Jul 2014 04:25:24 +0300 Message-ID: <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvjS7vg4PBBju+SFu0XdzHZHHiy0wW i6V/3C1+zL/A4sDisXPWXXaPW1dfMnv8/aztsX7qU8YAligum5TUnMyy1CJ9uwSujDMvW5kK FptWnF+7mKmB8bxRFyMnh4SAicTFa82sELaYxIV769lAbCGBo4wSj9fJdzFyAdkbGCV+v3nP CuHsZZQ4ce8jC4SzjlHi0vfNUM48oMzU22BlzAJTgHpmrmACGcYrYCCxbvExRhBbWCBZ4v+/ R+wgNpuAlsTG5QvAFnIKaErsbZsOZrMIqEr0H24FO4pZoEDiwtqtrBBz7CVe3Gtng9h2n01i 54NPLCAJEQFjicau01BfyEvMaD/BDmGrSVw9t4kZ4iMViVt/z7JNYBSZhezAWUgOnAW2UFti 2cLXzBC2gcTTzlesELapxOujH6FqrCVm/DrIBmErSkzpfsi+gJF9FaNocWpxcW66kZFealFm cnFxfp5eXmrJJkZgHB7c8ttqB+PB546HGAU4GJV4eB+uPxgsxJpYVlyZe4hRmoNFSZx34bl5 wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYS7vqxdIWyLpcTfKY+UHBZld42yzlHmbDn679 GXs9L01RfFN60/d+xaVVOxO9nl9cl6E4oaNx8aWp21Y+mb3zWserGVZXTj4y/zTT4IO0+om5 loFLM2/e7hK280/XYTDIODjDSzUxboviL3+Pt/2m/9NSdrBc7pv9bQH/vUvdMrPuNSpl5Bxh VGIpzkg01GIuKk4EAFwK30+kAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/4nbe0GOoG8sRFgxnN3fySe6iJa8 X-Mailman-Approved-At: Mon, 14 Jul 2014 08:52:51 -0700 Cc: internetgovtech@iab.org, David Conrad , Miles Fidelman Subject: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 01:25:38 -0000 --Apple-Mail=_C5EF1A1E-1877-410F-9566-DC364EFC1C59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 First, I=92m re-naming the thread where we deviate from the original = issue. Second, I=92m agreeing with Brian=92s and David=92s recent messages. In = particular this: > As far as I can see, the only problem that actually needs a solution > right now is: who is the watchdog with adequate teeth to ensure that = if > ICANN takes bad decisions about TLD policy, they can be set back on > the right track? >=20 > Everything else is in the "not broken, don't fix" category as far > as I am concerned. The RIRs and the IETF have ways to deal with > bad decisions by ICANN in their own areas of concern. Indeed. There are contracts. There are ways to track performance. There = are audits. Jari --Apple-Mail=_C5EF1A1E-1877-410F-9566-DC364EFC1C59 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCBEUw ggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVs aWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4X DTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv 1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqT u3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMc CYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUb Az2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB /wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2 MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb 8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXI v6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzY FSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67 OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3k MXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OY CMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAw OjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDgg VjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVy YSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5D uVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe 1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF4 6H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjgh XYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGj ggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7ga YqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0F BgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7Bgcq hXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20w cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkww DgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUE kUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDC fkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6b KuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHn tP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPd OI5GtDYPMIIEqjCCA5KgAwIBAgIQTyXs3vXto5joAjtwrbnc3jANBgkqhkiG9w0BAQUFADA5MREw DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMB4X DTEzMDMwNDEzMjUyMVoXDTE2MDMwNDEzMjUxOVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzARBgNV BAMMCkphcmkgQXJra28xEDAOBgNVBAUTB2xtZmphYXIxJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJr a29AZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhwriyJIY5Bbz yZrfnFAjWFLMNc6O6Z6dw5HqexTVyrUymDobuwcFtGl3n+yc6tYcvzM85LJMotJlOJH4NHEqClEc iMw+gFvN17PXxM2aAPuv1ZUL1wSdQ9dS94zxQEQuh4Myyfy+eqvrEBkzZaDPu4Evz6xsmCYPYSZP t4Bo6zbwQqkRvSQUO659ytmlyiPOiWN6wxEpwwO43LEw12xFrVSOQw3AG8ULW/xHbQvInuyWQdBC ug/1n6IJETsMWSrLFnk888IjABXKkmq42EG6RQ0BWLw8lAQwTju7rsDF9HrcTYBcu9z2u/d4cSgH P9SkRncRm68xrt7bD2RhPf3rkQIDAQABo4IBgzCCAX8wgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZx bGRhcDovL2xkYXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFs JTIwQ0EwMSxvPUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2Uw IgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEw MTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0O BBYEFLk/k+8oySkNxYm0GyPaFaKSRQufMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCb MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAECF65IiGH7GS+EEHre+itv2wv0OQ Z68DWR6G9IqMkBgb8dj6JcfFsu+9p8ID1e1L/0ybeTwz1t4IPhuOuWBPohj5irYiCBJkIokUr09B rWPyxfBrSoZ+uXVWfmZSdp15pWlEnHhuGuJkZ2a0MKrj+OEM9qfQR5Cvdlmx5PvsIhFkAFcZWldI xBwHsEeSoGJbVvvNImiY6M27u6rhuR8HanXVdcW4B8gK489LutxKhyhT9QDFUhmyWk2qYCUJgwM/ w44sLz8tv95jDbJxAR/aOwdwF3fQgj8VB5Xwvdn6B0PhfEcd3Ju4yUz6HE6ELZWG4ruE2haUCOn4 8WStKZ/RPDGCApMwggKPAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQTyXs3vXto5joAjtwrbnc3jAJBgUrDgMCGgUAoIIBGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MTMwMTI1MjVaMCMG CSqGSIb3DQEJBDEWBBTue1JF002vQWcodfqbvG0Sju6wxDBcBgkrBgEEAYI3EAQxTzBNMDkxETAP BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l 7N717aOY6AI7cK253N4wXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l7N717aOY6AI7cK253N4wDQYJ KoZIhvcNAQEBBQAEggEAG+FJzvZS57Jq/xzH6ASCdBMk+E6IjPmJnfp//q+Hx7iY+qEJcacPXmbn 1X9zKjRGqLTns3ytZRn/nNKl6i7BSKEvcmLc/7op5285SHtwrvDtLeTZvd3uXBQdxzYL7cPj8lKv y5hft3MUcp9y8yY1DwDwMg0QvSlTfQWREQbQpoL26VRgE/QAl+CCq6sS2Yk/0rgJnwHOnfkSP2Vk wxugKD4hoGmFLFe+Yc5YfrppVGEuZvi2+w2OtiLQjoIw9YE+ybaogRSx6DbR0SlwmzFD5fFccQaa l+wLTd6mnfZTzyBnt5am5ITaUvCXAXEsfBz9gAbN8/1r+RlRkY2PlgPMYAAAAAAAAA== --Apple-Mail=_C5EF1A1E-1877-410F-9566-DC364EFC1C59-- From nobody Mon Jul 14 09:08:26 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA541A0AB6 for ; Mon, 14 Jul 2014 09:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDHW6JtHyWaS for ; Mon, 14 Jul 2014 09:08:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC571A0A9B for ; Mon, 14 Jul 2014 09:08:24 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s6EG8HFA023740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Jul 2014 09:08:20 -0700 Message-ID: <53C4000C.4030401@dcrocker.net> Date: Mon, 14 Jul 2014 09:06:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jari Arkko References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> In-Reply-To: <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 14 Jul 2014 09:08:20 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/5dwhYPUWUUuJfM5ddUDryvDwzRI Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:08:25 -0000 On 7/12/2014 6:25 PM, Jari Arkko wrote: > Indeed. There are contracts. There are ways to track performance. There are audits. An essential point to a legitimate contract is providing for the possibility of switching to someone else. To the extent that such provision is real and practical, then the contract has meaningful, operational teeth. To the extent it doesn't, then we do not have real leverage. The issue is not to be critical of the current service provider, but to honestly consider what to do if we become disenchanted with them. The nature of contract-writing is to worry about this possibility, no matter how unlikely we might think it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 14 11:08:21 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8551A0011 for ; Mon, 14 Jul 2014 11:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c48JS5H_eG2Z for ; Mon, 14 Jul 2014 11:07:54 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E001A000F for ; Mon, 14 Jul 2014 11:07:54 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6EI7rBI075591 for ; Mon, 14 Jul 2014 11:07:53 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53C41C78.1090006@abenaki.wabanaki.net> Date: Mon, 14 Jul 2014 11:07:52 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> In-Reply-To: <53C4000C.4030401@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WZ2H4EvYTnrB9Z8KlDMhGCtIDPk Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 18:07:56 -0000 On 7/14/14 9:06 AM, Dave Crocker wrote: > An essential point to a legitimate contract is providing for the > possibility of switching to someone else. The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions contract to be awarded through a competitive bid process, and for a finite term. The subsequent contract was awarded to the sole bidder, upon re-tender, the incumbent contractor, for a term of three (3) years, extensible to five (5) years. Removing either the finiteness of the term, or the competitive process of bidding, really should be explained by their respective advocates, if any. Eric From nobody Mon Jul 14 11:13:34 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0141A0022 for ; Mon, 14 Jul 2014 11:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbRZ2lydvhFI for ; Mon, 14 Jul 2014 11:13:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB081A0011 for ; Mon, 14 Jul 2014 11:13:20 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s6EIDH0l000890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Jul 2014 11:13:20 -0700 Message-ID: <53C41D58.6060303@dcrocker.net> Date: Mon, 14 Jul 2014 11:11:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> In-Reply-To: <53C41C78.1090006@abenaki.wabanaki.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 14 Jul 2014 11:13:20 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/mNibxmqOz-hFfmV0mNW1L1dfThQ Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 18:13:28 -0000 On 7/14/2014 11:07 AM, Eric Brunner-Williams wrote: > On 7/14/14 9:06 AM, Dave Crocker wrote: >> An essential point to a legitimate contract is providing for the >> possibility of switching to someone else. > > The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions contract > to be awarded through a competitive bid process, and for a finite term. Term limitations are necessary, but not sufficient, to ensure that switching is a realistic alternative. The only way to make sure that necessary detail is covered is to formulate a transition plan and then make sure that the service provider is obligated to provide whatever information and assistance is needed to achieve it. For example, providers often develop assorted tools and information that they claim as proprietary, which which are essential to the actual operation. This effectively locks the operation to that provider. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 14 12:11:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF121A006B for ; Mon, 14 Jul 2014 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14yhSdJpIliz for ; Mon, 14 Jul 2014 12:11:03 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B2C1A0069 for ; Mon, 14 Jul 2014 12:11:02 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so2005993qcv.23 for ; Mon, 14 Jul 2014 12:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YLjAubBmmo83foxoTzkmohW5PRHFkK6y/koYZAOVBJ8=; b=cLVEQS5ZzWG7fYNRb9XkTK0Jiu0+eYIe4XrnbOlqJKT1eaa9eXMEe9/ogrqPTsjDjn ghmiKkEjzsxMp45P0HUNOjMD4+bgNggFczBDkoEa37v0OwNPnt+s44pNo5QnopD5PEew vwev8csIcjU1Lf+GapQIE4NdIxWVS0pKEbgGKqcBN4nPBQ621fJ+pd78vHG+aMhw2HBC qgMbYUuAVp2/UdvJTCGMDAvrPGf9zR06ZwJcTgVp1dhUh306YurH8UFWvL/woX13CH4v FEk/fxdGrep+Ylfa5m/vIHOcv/bKnClBjtqWEb5cX61LYb/BbUNouk9IdUYmseCwj6ZR n2qA== X-Received: by 10.224.87.195 with SMTP id x3mr27564217qal.1.1405365061905; Mon, 14 Jul 2014 12:11:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.147.15 with HTTP; Mon, 14 Jul 2014 12:10:31 -0700 (PDT) In-Reply-To: <53C41C78.1090006@abenaki.wabanaki.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> From: Seun Ojedeji Date: Mon, 14 Jul 2014 20:10:31 +0100 Message-ID: To: Eric Brunner-Williams Content-Type: multipart/alternative; boundary=001a11c3dbba4b76ea04fe2c0d76 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vYq1EvWY4Eq_CxOYx-9Sk0IUoAU Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:11:05 -0000 --001a11c3dbba4b76ea04fe2c0d76 Content-Type: text/plain; charset=UTF-8 Hello Eric, Pardon me if i may have missed something, this discussion seem to be going in the line of maintaining the IANA contract regime. If yes, then who will be the awarder and in whose capacity/authority will the awarder be doing that? While i also agree that there is really noting much about IP and Protocol (although IP process to me may need some re-dress), i am not sure the way to handle the names is by continuing the contracting approach. There is absolutely no need to create another layer of lobbying politics; ICANN should be self healing and IMO, review of the role of the AC/SO backed up with an external process to resolve conflict may be helpful. Regards On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote: > On 7/14/14 9:06 AM, Dave Crocker wrote: > >> An essential point to a legitimate contract is providing for the >> possibility of switching to someone else. >> > > The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions contract > to be awarded through a competitive bid process, and for a finite term. > > The subsequent contract was awarded to the sole bidder, upon re-tender, > the incumbent contractor, for a term of three (3) years, extensible to five > (5) years. > > Removing either the finiteness of the term, or the competitive process of > bidding, really should be explained by their respective advocates, if any. > > Eric > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --001a11c3dbba4b76ea04fe2c0d76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Eric,

Pardon me if i may= have missed something, this discussion seem to be going in the line of mai= ntaining the IANA contract regime. If yes, then who will be the awarder and= in whose capacity/authority will the awarder be doing that?

While i also agree that there is really noting much about IP and = Protocol (although IP process to me may need some re-dress), i am not sure = the way to handle the names is by continuing the contracting approach. Ther= e is absolutely no need to create another layer of lobbying politics; ICANN= should be self healing and IMO, review of the role of the AC/SO backed up = with an external process to resolve conflict may be helpful.

Regards


On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net> wrote:
On 7/14/14 9:06 AM, Dave Cro= cker wrote:
An essential point to a legitimate contract is providing for the
possibility of switching to someone else.

The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions contract to= be awarded through a competitive bid process, and for a finite term.

The subsequent contract was awarded to the sole bidder, upon re-tender, the= incumbent contractor, for a term of three (3) years, extensible to five (5= ) years.

Removing either the finiteness of the term, or the competitive process of b= idding, really should be explained by their respective advocates, if any.

Eric


_______________________________________________
Internetgovtech mailing list
Internetgovtec= h@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech



--
---------------------------------------------------------------------= ---
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--001a11c3dbba4b76ea04fe2c0d76-- From nobody Mon Jul 14 12:15:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390A51A0078 for ; Mon, 14 Jul 2014 12:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V6_gDVDsk10 for ; Mon, 14 Jul 2014 12:15:07 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCBE1A0040 for ; Mon, 14 Jul 2014 12:15:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id ADF24CC6AE for ; Mon, 14 Jul 2014 15:15:06 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 341j3rXuqniX for ; Mon, 14 Jul 2014 15:14:58 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 3086CCC0D4 for ; Mon, 14 Jul 2014 15:14:58 -0400 (EDT) Message-ID: <53C42C31.4060002@meetinghouse.net> Date: Mon, 14 Jul 2014 15:14:57 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/lOhEGJZIzwnrtwJuOeVIX1ulUCI Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:15:09 -0000 Is not the threat of non-renewal the single oversight mechanism currently in place for ICANN? And is not the central question of the transition, what should replace it? Personally, I have seen very few cases of self-oversight - and none come immediately to mind. Miles Fidelman Seun Ojedeji wrote: > Hello Eric, > > Pardon me if i may have missed something, this discussion seem to be > going in the line of maintaining the IANA contract regime. If yes, > then who will be the awarder and in whose capacity/authority will the > awarder be doing that? > > While i also agree that there is really noting much about IP and > Protocol (although IP process to me may need some re-dress), i am not > sure the way to handle the names is by continuing the contracting > approach. There is absolutely no need to create another layer of > lobbying politics; ICANN should be self healing and IMO, review of the > role of the AC/SO backed up with an external process to resolve > conflict may be helpful. > > Regards > > > On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams > > wrote: > > On 7/14/14 9:06 AM, Dave Crocker wrote: > > An essential point to a legitimate contract is providing for the > possibility of switching to someone else. > > > The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions > contract to be awarded through a competitive bid process, and for > a finite term. > > The subsequent contract was awarded to the sole bidder, upon > re-tender, the incumbent contractor, for a term of three (3) > years, extensible to five (5) years. > > Removing either the finiteness of the term, or the competitive > process of bidding, really should be explained by their respective > advocates, if any. > > Eric > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > > > > -- > ------------------------------------------------------------------------ > > /Seun Ojedeji, > Federal University Oye-Ekiti > web: http://www.fuoye.edu.ng > Mobile: +2348035233535 > //alt email:seun.ojedeji@fuoye.edu.ng > / > > The key to understanding is humility - my view ! > > > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Jul 14 13:41:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADA81A0AF1 for ; Mon, 14 Jul 2014 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE5s_YPQF54H for ; Mon, 14 Jul 2014 13:40:59 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E630D1A0ACD for ; Mon, 14 Jul 2014 13:40:58 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so5575214pab.2 for ; Mon, 14 Jul 2014 13:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wc1GKopWGs6Mx587Mk7GdxCeJw0XFICq+PNANq+tS9k=; b=qvgGyTg1ks5RodT7c8y/3vtED283hTAEREPUKp190GDYBZWpJp0euYPr1bKCwIUYPb 160NujWwg0uJgZoiJx9cug3bIDgPhNuaoLfLJCWdfHn59ztmpfMbyy7uJvfEji4GmRmI j9Kt2gjCHKLPN39M3qmyeCBLGFnpUDvPfetWT8zdrh4xkANMhG51XcOOgE3hSCbkt9WZ Uu4SZP672p5It43qAM4MLOvbLT4ZWPVQiOjHBeAQ4FlqVi+3HHWMpVSArvbIgviikTE+ BfEMagWELI8XPMnOzPYmKUDUCFHAbIuELsg1aXzE6Z9Gb0br7jVjV3vcYA2oTT8W6yaE Zwtw== X-Received: by 10.70.61.103 with SMTP id o7mr3421181pdr.134.1405370458573; Mon, 14 Jul 2014 13:40:58 -0700 (PDT) Received: from [192.168.178.23] (76.195.69.111.dynamic.snap.net.nz. [111.69.195.76]) by mx.google.com with ESMTPSA id ug1sm49350353pac.9.2014.07.14.13.40.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 13:40:58 -0700 (PDT) Message-ID: <53C4405B.7010002@gmail.com> Date: Tue, 15 Jul 2014 08:40:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Brunner-Williams References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> In-Reply-To: <53C41C78.1090006@abenaki.wabanaki.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/48gPmlivOvO_-BOow6az2-zTCp0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:41:00 -0000 On 15/07/2014 06:07, Eric Brunner-Williams wrote: > On 7/14/14 9:06 AM, Dave Crocker wrote: >> An essential point to a legitimate contract is providing for the >> possibility of switching to someone else. > > The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions contract > to be awarded through a competitive bid process, and for a finite term. > > The subsequent contract was awarded to the sole bidder, upon re-tender, > the incumbent contractor, for a term of three (3) years, extensible to > five (5) years. > > Removing either the finiteness of the term, or the competitive process > of bidding, really should be explained by their respective advocates, if > any. Why does the arcane way that the NTIA contracts worked matter for the future? We all know that the competitive appearance was just that and nothing to do with reality. The question now is about teeth for the watchdog. Brian Brian From nobody Mon Jul 14 13:44:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1B1A00EF for ; Mon, 14 Jul 2014 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICc-_G6rIDqf for ; Mon, 14 Jul 2014 13:44:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912BC1A00E9 for ; Mon, 14 Jul 2014 13:44:21 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s6EKiGQV010425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Jul 2014 13:44:20 -0700 Message-ID: <53C440BC.7010406@dcrocker.net> Date: Mon, 14 Jul 2014 13:42:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> <53C4405B.7010002@gmail.com> In-Reply-To: <53C4405B.7010002@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 14 Jul 2014 13:44:20 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/12yX75UmvHTkdkU6VP_T9ZH3xxc Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:44:22 -0000 On 7/14/2014 1:40 PM, Brian E Carpenter wrote: > Why does the arcane way that the NTIA contracts worked matter for > the future? We all know that the competitive appearance was just that > and nothing to do with reality. The question now is about teeth for > the watchdog. An important source of useful teeth is the reality of competitive bidding. That is, competitive bidding that is... you know... competitive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 14 14:35:20 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5427E1B27B3 for ; Mon, 14 Jul 2014 14:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or0fu4PT77dI for ; Mon, 14 Jul 2014 14:35:15 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC1A1A0118 for ; Mon, 14 Jul 2014 14:35:15 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id r5so3430778qcx.10 for ; Mon, 14 Jul 2014 14:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2eZy746AFbxZpXpgF/7LQRdOv03ENbnXBkZhpJENvig=; b=H5SL9nfdSMbO0I4T6j2CwvVK6wsqXuUYMYsiLtCks275qpt8TOfRjXR0U+cRRquwMS tpIxm8ot6ZlsOw1olDaQSS/HldEZSDWg0XUzzGw3nMOCMQ9Q0oB2gd4fu0AnlpMDs1DM SV96Ec7DKZiQ/SYJiUF3Badscqy1Ouy/s6MGiOHkq0OBXfUfjh9rawj5EWKhRg9HrjMD bq60iMDRylNVWvmpHBlg/rldh6POrylT1kbvLXI9nQQO4i+7InAHxna3GdGkbTCEwyOR sphXUhhzH3Ij96bMO6nUBuYlo0wr6ZBWq5jpKwVbTUeHzd+O43ukrb2+JXE38nizAADa d9rA== X-Received: by 10.140.102.142 with SMTP id w14mr21710108qge.101.1405373714548; Mon, 14 Jul 2014 14:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.147.15 with HTTP; Mon, 14 Jul 2014 14:34:44 -0700 (PDT) In-Reply-To: <53C440BC.7010406@dcrocker.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> <53C4405B.7010002@gmail.com> <53C440BC.7010406@dcrocker.net> From: Seun Ojedeji Date: Mon, 14 Jul 2014 22:34:44 +0100 Message-ID: To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=001a11c163e008504104fe2e1120 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/A8H-Hn1qL3s8eOn5GTVfsvKV7AE Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 21:35:17 -0000 --001a11c163e008504104fe2e1120 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 14, 2014 at 9:42 PM, Dave Crocker wrote: > On 7/14/2014 1:40 PM, Brian E Carpenter wrote: > > Why does the arcane way that the NTIA contracts worked matter for > > the future? We all know that the competitive appearance was just that > > and nothing to do with reality. The question now is about teeth for > > the watchdog. > > > An important source of useful teeth is the reality of competitive > bidding. That is, competitive bidding that is... you know... competitive. > > Would you classify the agreement with ICANN on protocol parameters as being competitive? maybe not, but i am sure ICANN knows that the agreement got teeth. Cheers! > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --001a11c163e008504104fe2e1120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 14, 2014 at 9:42 PM, Dave Crocker <dhc@dcrocker.net> = wrote:
On 7/14/2014 1:40 PM, Brian = E Carpenter wrote:
> Why does the arcane way that the NTIA contracts worked matter for
> the future? We all know that the competitive appearance was just that<= br> > and nothing to do with reality. The question now is about teeth for > the watchdog.


An important source of useful teeth is the reality of competitive
bidding. =C2=A0That is, competitive bidding that is... you know... competit= ive.

Would you classify the= agreement with ICANN on protocol parameters as being competitive? maybe no= t, but i am sure ICANN knows that the agreement got teeth.

Cheers!
d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_____________________________= __________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech



--
---------------------------------------------------------------------= ---
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--001a11c163e008504104fe2e1120-- From nobody Mon Jul 14 15:24:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590571A0158 for ; Mon, 14 Jul 2014 15:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97UfKYk59rbG for ; Mon, 14 Jul 2014 15:24:49 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D139A1A0154 for ; Mon, 14 Jul 2014 15:24:49 -0700 (PDT) Received: from 254.74.14.81.rev.sfr.net ([81.14.74.254]:57935 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1X6ofw-00027O-CF; Mon, 14 Jul 2014 15:24:48 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jul 2014 00:21:48 +0200 To: Miles Fidelman From: JFC Morfin In-Reply-To: <53C42C31.4060002@meetinghouse.net> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> <53C42C31.4060002@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wQRfsHEBoRcNoxikFQmRm5riX18 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 22:24:51 -0000 At 21:14 14/07/2014, Miles Fidelman wrote: >Is not the threat of non-renewal the single oversight mechanism >currently in place for ICANN? And is not the central question of >the transition, what should replace it? IMHO, the IANA contract should simply be replaced by a IANA protocol. This way every technology parameter provider and multi-registry ledger administrator could pass information in a consistant and responsible manner to every would be/VGN repository. Would a repository not be maintained properly users could switch to a more serious one. What you call a "societal contract" is a multitude emergence: people just agree to do it for their convenience. If there is a better one (or less bad on - depends on politicals events, e.g. an ICANN Snowdenia) they may change their mind. For example, let imagine that at some stage people start being fed-up working for Google for free and in addition paying their taxes: this may unballance the equilibrium. Why would people continue to pay for the ICANN DNS when some can organize naming in a better, cheaper and more reliable way? All these things are subject to competition: why to create IANA monopolies? IETF is the source provider for protocol parameters. ICANN is the source for DNS Class IN names. NRO is the source for one IPv4 and 2 IPv6 numbering plans. Probably large alliances (EU, China, ITU, Libre) will also claim for IPv6 numbering plans. Every other network technology and namespaces will have their own parameters and names. This way ISO will be able to directly maintain ISO 3166, 639, 15924, 10646. The question only is: who takes the lead in normalizing the IANA protocol: the providers or the users side? RFC 6852 has left us in the middle of nowhere: there are global communities with their own formal or not standards, the only operational global communities are US, Chinese, Google, Apple, Windows, sometimes EU? and probably at some stage Libre and/or IUse ones.This leaves the internet as fragmented in many areas. The IANA should be another fragmentation occasion in having several pseudo-dominant or national or edge-provider repositories, but a single protocol for all. I can only say that as a registered non-profit local public operator I will not trust any commercialized name/parameter system. I am aware and sure that I am not alone. This is why we started the http://fsp4.net (fail safe plan for the net) alliance and confirmed its creation during the https://2014.rmll.info/?lang=en meeting last week. Best jfc >Personally, I have seen very few cases of self-oversight - and none >come immediately to mind. > >Miles Fidelman > >Seun Ojedeji wrote: >>Hello Eric, >> >>Pardon me if i may have missed something, this discussion seem to >>be going in the line of maintaining the IANA contract regime. If >>yes, then who will be the awarder and in whose capacity/authority >>will the awarder be doing that? >> >>While i also agree that there is really noting much about IP and >>Protocol (although IP process to me may need some re-dress), i am >>not sure the way to handle the names is by continuing the >>contracting approach. There is absolutely no need to create another >>layer of lobbying politics; ICANN should be self healing and IMO, >>review of the role of the AC/SO backed up with an external process >>to resolve conflict may be helpful. >> >>Regards >> >> >>On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams >>> wrote: >> >> On 7/14/14 9:06 AM, Dave Crocker wrote: >> >> An essential point to a legitimate contract is providing for the >> possibility of switching to someone else. >> >> >> The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions >> contract to be awarded through a competitive bid process, and for >> a finite term. >> >> The subsequent contract was awarded to the sole bidder, upon >> re-tender, the incumbent contractor, for a term of three (3) >> years, extensible to five (5) years. >> >> Removing either the finiteness of the term, or the competitive >> process of bidding, really should be explained by their respective >> advocates, if any. >> >> Eric >> >> >> _______________________________________________ >> Internetgovtech mailing list >> Internetgovtech@iab.org >> https://www.iab.org/mailman/listinfo/internetgovtech >> >> >> >> >>-- >>------------------------------------------------------------------------ >> >> /Seun Ojedeji, >> Federal University Oye-Ekiti >> web: http://www.fuoye.edu.ng >> Mobile: +2348035233535 >> //alt email:seun.ojedeji@fuoye.edu.ng >> / >> >> The key to understanding is humility - my view ! >> >> >> >> >>_______________________________________________ >>Internetgovtech mailing list >>Internetgovtech@iab.org >>https://www.iab.org/mailman/listinfo/internetgovtech > > >-- >In theory, there is no difference between theory and practice. >In practice, there is. .... Yogi Berra > >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech From nobody Tue Jul 15 06:00:35 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0481B2895 for ; Tue, 15 Jul 2014 06:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHjhsTg_sLeM for ; Tue, 15 Jul 2014 06:00:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 00B171B2894 for ; Tue, 15 Jul 2014 06:00:32 -0700 (PDT) Received: from [87.93.104.198] (87-93-104-198.bb.dnainternet.fi [87.93.104.198]) by p130.piuha.net (Postfix) with ESMTPSA id 21EF32CC48; Tue, 15 Jul 2014 16:00:28 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jari Arkko X-Mailer: iPad Mail (11D257) In-Reply-To: <53C4000C.4030401@dcrocker.net> Date: Tue, 15 Jul 2014 16:00:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> To: "dcrocker@bbiw.net" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/iKxcp5DA0COFV9DYDvCsFX3gV3w Cc: "internetgovtech@iab.org" , Jari Arkko Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 13:00:35 -0000 Dave: I agree, of course. (Although not as the only thing; any relationship needs a= n escalating set of remedies to deal with issues. If they arise.) Jari= From nobody Tue Jul 15 07:02:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0171C1B28B5 for ; Tue, 15 Jul 2014 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvMl_iQXH4ZR for ; Tue, 15 Jul 2014 07:02:41 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728571B2883 for ; Tue, 15 Jul 2014 07:02:41 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X73JY-000FnE-8C; Tue, 15 Jul 2014 14:02:40 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+2QJqaSgBNAvoHwdJqoalQ Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53C1DD6C.8030501@gmail.com> Date: Tue, 15 Jul 2014 10:02:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pXdfEOKghMp-k_dGoYMDuFMYZgI Cc: internetgovtech@iab.org, David Conrad , Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:02:50 -0000 On Jul 12, 2014, at 9:14 PM, Brian E Carpenter = wrote: > ... > In fact, the IETF/ICANN MoU is a signed and ratified document, > and I have been told in other contexts that such a document is exactly = the > same thing as a contract if it ends up in court. Certainly the = attention > paid to its wording by lawyers on both sides in 1999/2000 was exactly > what I have experienced in contract negotiations. Of course, if a = court > had to decide between conflicting provisions of an NTIA/ICANN contract > and the IETF/ICANN MoU, one might trump the other. However, I think = that > a lot of the ICANN lawyer's amendments to the MoU draft were intended > to avoid conflicting provisions. Also, in a model absent NTIA contract, there would be nothing to = conflict... > As far as I can see, the only problem that actually needs a solution > right now is: who is the watchdog with adequate teeth to ensure that = if > ICANN takes bad decisions about TLD policy, they can be set back on > the right track? Hmm... "bad decisions about TLD policy" can be a very subjective topic. It might be worth thinking about two distinct situations: - Situations where the contracted IANA party fails to follow the = published guidance provided by the IETF (or a delegated authority) in = administration of a given registry. Some of this appears to be already = well-addressed =20 in section 4.1/4.2 of RFC 2860 (and why public registry visibility,=20= reporting and SLA's are all quite useful...) - Situations where a delegated policy authority for a registry (e.g. = one=20 of the general purpose subsets of the DNS root or IP spaces) should=20= chronically fail to represent the affected registry user community = via=20 policy development done in an open, inclusive and transparent = manner...=20 (i.e. in accordance with sections 3 & 4 of the IANA framework doc=20 ) Ideally, one would make the accountability to be very clearly stated to be performance against specific principles, and periodic assessment of=20= same, since anything else risks creating a mechanism which could be=20= inundated with individual appeals of policy development decisions,=20 rather than the actual question of whether the delegated policy=20 development body is following the IETF's expected IANA principles. /John Disclaimer: My views alone. This email message is provided "as-is", with = no=20 warranty expressed or implied. Please use your own judgement when = building=20 global Internet coordination systems. From nobody Tue Jul 15 07:20:58 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3070F1B287C for ; Tue, 15 Jul 2014 07:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSNMPXIn4Kcq for ; Tue, 15 Jul 2014 07:20:53 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC241A04E7 for ; Tue, 15 Jul 2014 07:20:53 -0700 (PDT) Received: from mx1.yitter.info (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EDFB78A031 for ; Tue, 15 Jul 2014 14:20:49 +0000 (UTC) Date: Tue, 15 Jul 2014 10:20:48 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140715142048.GE8847@mx1.yitter.info> References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C4000C.4030401@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RWgwVVDkGWuv4krZZ6Rvf2pGzBo Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:20:54 -0000 On Mon, Jul 14, 2014 at 09:06:36AM -0700, Dave Crocker wrote: > An essential point to a legitimate contract is providing for the > possibility of switching to someone else. As something about which the IAB could properly have an opinion, what is the possibility that the protocol parameters registry could shift somewhere else? (There are similar questions for domain names and for numbers, of course, but those are problems that need to be worked out in other communities, not here. If you have opinions about those topics, I urge you to take them to the relevant forums in the relevant communities.) I think the possibility that the IETF could change the provider for the protocol parameters registry is pretty high, but the way we might pay for that change is perhaps unclear. That is, it's nice of ICANN to provide us this service for free right now, and it's also really great that they do a good, satisfying job. If that should cease to be the case, of course, the IAB could inform ICANN that we were making a change, and then we could just start publishing the data on a different set of web pages published somewhere else. Since the IETF is the change control authority for the data in the IANA registries, there isn't (nominally) anyone else who could disagree with that conclusion. This has been the IETF and IAB position all along, and at the igovupdate BoF in London we heard the Chair of the ICANN Board say quite the same thing. So, I don't think there's any real issue there. The question is, how would we pay for the maintenance of such a system? Right now, we get this service at no cost to ourselves. So there might be a question of practical possibility. But that seems to me actually to be a question that we could just ask the IAOC. Something like this: "For three scenarios -- of increasing, flat, and declining revenues -- how would we pay for the IANA function if we had to, and what might we have to give up?" It seems that a budget somewhere close to maintaining the tools systems or perhaps the RFC Editor function would be a reasonable approximation for these purposes, but I'm open to argument about why or why not. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 15 07:24:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA571A04E7 for ; Tue, 15 Jul 2014 07:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m-s9RKLesOI for ; Tue, 15 Jul 2014 07:24:37 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860C31A03FC for ; Tue, 15 Jul 2014 07:24:37 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X73em-0005sQ-Qc; Tue, 15 Jul 2014 14:24:36 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18TK2a1BKinxY382u37T7TE Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53C1E977.4050306@meetinghouse.net> Date: Tue, 15 Jul 2014 10:24:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> To: Miles Fidelman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Axts5FoJL16CTbsJhwlvuwo74ZE Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:24:39 -0000 On Jul 12, 2014, at 10:05 PM, Miles Fidelman = wrote: >=20 > Well, the RFC's specfically exclude domain and address functions, ... RFC 2860 does not exclude domain and address functions - please read it = again=20 carefully.=20 Section 4.1 says that the IANA will assign and register Internet = protocol=20 parameters per technical considerations specified by the IETF; section = 4.3=20 notes that two particular assigned spaces present "policy issues" in = addition=20 to the technical considerations, and places those "policy issues" = outside the=20 scope of the MOU. It goes on further to note that ICANN needs to take = care=20 not to make conflicts with technical reservations within those same = assigned=20 spaces.=20 Placing "policy issues" outside of the MOU space does not exclude the = duty of the IANA to maintain these registries; it is simply a recognition = that=20 there are delegations of policy authority for the general purpose = portions of these spaces to other parties (e.g. for IP spaces, it's in RFC 7020 = and=20 RFC 7249) Remember, there is only one DNS root zone (registry) and one IPv4 space = and=20 one IPv6 space... each of these registry spaces consist of both = technical/ specialized entries and "general purpose" entries, but in the end each = space=20 must have single consistent registry published containing all entries. = This is particularly important when dealing with non-trivial publications = protocols such as DNSSEC. Thanks, /John Disclaimer: My views alone. From nobody Tue Jul 15 07:49:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB20B1B28BF for ; Tue, 15 Jul 2014 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0456Q6Ji3CqZ for ; Tue, 15 Jul 2014 07:47:30 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237001B28CB for ; Tue, 15 Jul 2014 07:44:59 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X73yU-000K3x-Dn; Tue, 15 Jul 2014 14:44:58 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/I0+iDfuQ08Ljz5s0WLst7 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: John Curran X-Priority: 1 In-Reply-To: <53C1B2C6.40501@meetinghouse.net> Date: Tue, 15 Jul 2014 10:44:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E45CDDF-D741-4538-8CD0-CC0B042F01C1@istaff.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> To: Miles Fidelman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9qKwgWZp_C0VUVvv8dpJWsEJKBM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:47:52 -0000 On Jul 12, 2014, at 6:12 PM, Miles Fidelman = wrote: > 3. IETF's role is defined in the MOU, but seems to be in addition to, = and/or enabled by the DOC-ICANN contract. Oh please... Thought-exercise: If the IETF were to specify a entirely new naming = protocol or new Internet address protocol (including a new associated registry = space), the protocol specification by the IETF would, upon adoption of the = appropriate IANA Considerations section, cause a registry to come into being. On = day one, the policy authority for that registry would be the IAB, with the IANA = doing=20 whatever form of administration was specified in the considerations = section. Now one would hope that if the IETF created a general-purpose registry = space (where pieces where to be eventually assigned to real-world entities = rather=20 than simply code points) that it would leverage existing organizations = which=20 strive to represent the affected user communities (e.g. ICANN, RIRs) but = such=20 delegation is _not_ inevitable. The registry spaces are _created_ as a result of IETF's adoption of a = protocol=20 specification, and IETF wisely realizes it should provide for = administration=20 of same (hence the IANA). It's probably not worth dwelling on this for = the=20 existing DNS, IPv4, and IPv6 address spaces, but the IETF's role is = fundamental=20 to the existence of these registries themselves, and not "in addition = to, and/or=20 enabled by" NTIA-DoC, ICANN, or any other party. /John Disclaimer: My view alone. From nobody Tue Jul 15 09:43:42 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F351A0AD5 for ; Tue, 15 Jul 2014 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5DhH2gGYIQd for ; Tue, 15 Jul 2014 09:43:38 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDB11A0AAB for ; Tue, 15 Jul 2014 09:43:38 -0700 (PDT) Received: from 254.74.14.81.rev.sfr.net ([81.14.74.254]:51592 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1X75pI-00045l-Mk; Tue, 15 Jul 2014 09:43:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jul 2014 18:40:38 +0200 To: John Curran , Miles Fidelman From: JFC Morfin In-Reply-To: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/aM039unyqKrq7Mv7DYqaemsOJv8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 16:43:40 -0000 At 16:24 15/07/2014, John Curran wrote: >Remember, there is only one DNS root zone (registry) and one IPv4 space and >one IPv6 space... each of these registry spaces consist of both technical/ >specialized entries and "general purpose" entries, but in the end each space >must have single consistent registry published containing all entries. This >is particularly important when dealing with non-trivial publications protocols >such as DNSSEC. John, why to repeat the same error ad nauseam? In the hope it becomes true (it would then be a lie)? Or in order to eventually upset the other stakeholders and disrupt any conciliatory process. All of us know they are 40.000 possible roots (ICANN could claim all of them?) and 256 per user, i.e a trillion of them. This is a basic fundamental element every serious multistakeholder must consider if they want we concur on an internet governance paradigm. Talking of paradigm. One also must take into consideration RFC 6852 in which most of the stakeholders involved in Internet standardization process explains that the internet "huge bounty" for the world results from a modern paradigm for standards they solemnly embrace. In this paradigm the economics of global markets, fueled by technological advancements, drive global deployment of standards ***regardless of their formal status***.and contribute to the creation of ***global communities, benefiting humanity*** What an odd approach to read this as leading in the end at "each space must have single consistent registry published containing all entries" outside of any inter-community agreement. Let be frank, an ICANN-IETF agreement will solve nothing as long as it is not a global agreement, global meaning here both worldwide, on every involved matter, and by every stakeholder (and every VGN is a stakeholder). Trying to pursue the ICANN scope in the way it is currently designed will only spur the fragmentation of the Internet into "global communities, benefiting humanity" and multiply them by nations, languages, trades, political lines, commercial interests instead of helping their compatibility. Unless, obviously, unless your strategy is to reach a situation of self-organized criticality because you have in mind a self-organized criticality control scheme (http://en.wikipedia.org/wiki/Self-organized_criticality_control). In such a case please have a look at the "complex network" link in there (in relation to RFC 3439). As you know my own scheme is VGNs. However, I do not know which level of disruption will be necessary for it to self-apply. jfc From nobody Tue Jul 15 09:51:00 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F431B28E6 for ; Tue, 15 Jul 2014 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtAJWTXmBhi7 for ; Tue, 15 Jul 2014 09:50:57 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32EE1B28E5 for ; Tue, 15 Jul 2014 09:50:57 -0700 (PDT) Received: from mx1.yitter.info (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DAD9F8A036 for ; Tue, 15 Jul 2014 16:50:55 +0000 (UTC) Date: Tue, 15 Jul 2014 12:50:54 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140715165054.GK8847@mx1.yitter.info> References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164343.3E1601B28C7@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140715164343.3E1601B28C7@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/AzTcMIULjTXzTje2kNxGZFySSzg Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 16:50:59 -0000 On Tue, Jul 15, 2014 at 06:40:38PM +0200, JFC Morfin wrote: > At 16:24 15/07/2014, John Curran wrote: > >Remember, there is only one DNS root zone (registry) > why to repeat the same error ad nauseam? I presume you meant the one quoted above. If so, it's because it's technically true, not an error. I have explained why several times, but the key thing to repeat to yourself is, "CNAME." Of course, anyone _can_ have their own picture of a root. People do this effectively every time they run a split horizon. But split horizons cause all kinds of trouble, and increase user confusion, and therefore cost real money in the form of support calls. The IAB has talked about this already. "Single root" is not a political position, it's a fact of mathematics. It's just a distraction to talk about multiple roots. I'd ask that we not investigate that pointless rathole (again) on this list. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 15 09:59:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C1C1B28F3 for ; Tue, 15 Jul 2014 09:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQrR_baNfurr for ; Tue, 15 Jul 2014 09:58:43 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F301B28F1 for ; Tue, 15 Jul 2014 09:58:42 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X763s-000Hdb-5o; Tue, 15 Jul 2014 16:58:40 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19CEfDaAdAePDUV/S+b6dWC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> Date: Tue, 15 Jul 2014 12:58:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4341AA4C-33BE-436B-9272-4BD87171A43B@istaff.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> To: JFC Morfin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/5MgU7-NtMVUdRwUl0zJXMF9siFc Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 16:58:47 -0000 On Jul 15, 2014, at 12:40 PM, JFC Morfin wrote: > At 16:24 15/07/2014, John Curran wrote: >> Remember, there is only one DNS root zone (registry) and one IPv4 = space and >> one IPv6 space... each of these registry spaces consist of both = technical/ >> specialized entries and "general purpose" entries, but in the end = each space >> must have single consistent registry published containing all = entries. This >> is particularly important when dealing with non-trivial publications = protocols >> such as DNSSEC. >=20 > What an odd approach to read this as leading in the end at "each space = must have single consistent registry published containing all entries" = outside of any inter-community agreement. JFC - We've been here before... My reference (to a single consistent = registry for each space) is with respect to the specific community of users who = happen=20 to find value in the identifier coordination provided by the "default" = registries=20 administered by the IANA at behest of the IETF. Clearly, other = communities can use whatever coordination mechanisms and values they choose (with = obvious interoperability implications for communications between communities...) I expect most of the readers of this list are interested in the = coordination resulting from these singular IANA registries, as opposed to the = frameworks=20 for multiple instances of registries with self-organizing communities = (but I easily could be mistaken.) Thanks! /John Disclaimers: My views alone. From nobody Tue Jul 15 10:33:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8391A0AD3 for ; Tue, 15 Jul 2014 10:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN8z5CHZ8znI for ; Tue, 15 Jul 2014 10:33:36 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAED61A0ABB for ; Tue, 15 Jul 2014 10:33:36 -0700 (PDT) Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:52456 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X76bW-0004kU-55 for internetgovtech@iab.org; Tue, 15 Jul 2014 10:33:35 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_8BAF55AC-3A01-4AFF-8030-5B46127AA249"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 15 Jul 2014 13:33:26 -0400 References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> <4341AA4C-33BE-436B-9272- 4BD87171A43B@istaff.org> To: internetgovtech@iab.org In-Reply-To: <4341AA4C-33BE-436B-9272-4BD87171A43B@istaff.org> X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 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 - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/SXhrrSvlSagrHXuwPLG9iIAqvZg Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:33:38 -0000 --Apple-Mail=_8BAF55AC-3A01-4AFF-8030-5B46127AA249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 If the proposal is to have gobs of new registries, that=92s a bad idea. = Been there and luckily not too much bad happened, but one can envision = how lots of badness can happen in the future. However, if the proposal is to have gobs of redundant, distributed, = cryptographically secure (meaning compromise is obvious) of an = allocation data base, that is an excellent idea. BitCoin works without a = centralized data base, so we have existence proofs, too. I vaguely = recall something about =93working code=94 and the IETF=85 That could work for IP address allocation, which would admittedly be a = less than ideal situation for the RIR=92s businesses. For this scheme to = work for the parameters directory, we would need a technology such that = only the IETF Trust (as holder of the copyright) could update it. I = really do not see it working for the DNS root zone, because what goes = in, and what does not go in, is a matter of politics, not a matter of a = sufficient number of uncompromised nodes agreeing on what a value is. On Jul 15, 2014, at 12:58 PM, John Curran wrote: > On Jul 15, 2014, at 12:40 PM, JFC Morfin wrote: >> At 16:24 15/07/2014, John Curran wrote: >>> Remember, there is only one DNS root zone (registry) and one IPv4 = space and >>> one IPv6 space... each of these registry spaces consist of both = technical/ >>> specialized entries and "general purpose" entries, but in the end = each space >>> must have single consistent registry published containing all = entries. This >>> is particularly important when dealing with non-trivial publications = protocols >>> such as DNSSEC. >>=20 >> What an odd approach to read this as leading in the end at "each = space must have single consistent registry published containing all = entries" outside of any inter-community agreement. >=20 > JFC - We've been here before... My reference (to a single consistent = registry > for each space) is with respect to the specific community of users who = happen=20 > to find value in the identifier coordination provided by the "default" = registries=20 > administered by the IANA at behest of the IETF. Clearly, other = communities > can use whatever coordination mechanisms and values they choose (with = obvious > interoperability implications for communications between = communities...) >=20 > I expect most of the readers of this list are interested in the = coordination > resulting from these singular IANA registries, as opposed to the = frameworks=20 > for multiple instances of registries with self-organizing communities = (but I > easily could be mistaken.) >=20 > Thanks! > /John >=20 > Disclaimers: My views alone. >=20 >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --Apple-Mail=_8BAF55AC-3A01-4AFF-8030-5B46127AA249 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTxWXmAAoJEDY/T2tCIPW3wHsQAI3xKkaW/+1nCbcQhzkupvuY CpeaLx1Lcq9JneZCkiUqBwWBfwTDCRCvPvtENlyFoCMTRQ+xVBJHsDd3hL2TXEKN f36oEQFLLfbnukJfAXR6EyICPQ2MkZ48e/qyBmIT7zhZfpxO2bnCdMTI55YwxWpr hIwlGa7XFzBdpUJMoRbaVlhrJTt3dtKbESSOp5Ob/LWlCS6DsIldrLfDQ1AwdsQ+ hhjASzo8SzBjbHd2e+FqxGN3UHNqg/6P3HYTK5zT04eiJnf8Gd+jgRmVaFVaPwra XemwqDxcSb7XEAyP2LvAEhpgbYTYGUgphjAWHKJHWMUkZRwubn9LUaW6IkiFo2DU 64UvPJY6w3zOz+iiJt8SJ4OkmHyNGaedwewHYxxuH8bhNAHMsCO5k3M9K33pJ6Zq Ur8cIdFitltnjLtVPhjMyCZkE+JQ4rr+GZczFxJD3gXXUe1xYcpB1f8PrK9v5iuy xqvuL6MC5wh7ZAaLGo+Z7PQkTMu4KK1Dgc/AsfyzpsPN/a93ADOnkwGJSDD+afHN hheordXjbQn8dm1DxTqPTQo8H84sXD1rpI2yCW+RpagLWlHvok5MFRsISxYsqaEA CfWTj90TB8AWE9CtE+TLG2wsr9GkRmp55z7bJEja+uyt5pYQIKjPOE2NGAecgz+u c8OGqLvnPm6DcsjntiqQ =Z5l5 -----END PGP SIGNATURE----- --Apple-Mail=_8BAF55AC-3A01-4AFF-8030-5B46127AA249-- From nobody Tue Jul 15 10:38:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6B11A0AC0 for ; Tue, 15 Jul 2014 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-WrsKgTL5y1 for ; Tue, 15 Jul 2014 10:38:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 869A71A0AAC for ; Tue, 15 Jul 2014 10:38:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6FHcfgM007469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2014 10:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405445933; x=1405532333; bh=EHr376US3F5mBfdPKU1I8uGjHz7fQAgHQCLz2B2Y8vM=; h=Date:To:From:Subject:In-Reply-To:References; b=mCZsyoMZJgZjWEUaLGYg1DjpjJxgO6xz15e2nB2xy/e6NkKd0exjbC5WN5dTDAB6l wme7ee0ORgG0Gtwwdr8rSgFnFHChXSlvr4zlMrahkUHxXgx+0nOzkO/lBMUMwGthoy bf9kqpaAv0SzN7MhwMaSPiNT7WPgBNy0ew3XFKPM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405445933; x=1405532333; i=@elandsys.com; bh=EHr376US3F5mBfdPKU1I8uGjHz7fQAgHQCLz2B2Y8vM=; h=Date:To:From:Subject:In-Reply-To:References; b=J+rJgos9U2aZ7M3I3S8Z2KWdVOuhINHhx8QeeiS7uvV6vsP5ikK0rBKo1hWWY9rNc 1kppobDOxaKy7mKmnv80BQ7ocaHd8qq6vIZRYLr6/EE+G1h3W2mi5mAmRYc10yyV1T 0WWpMw/xQqxdp3lomwrwhoaFylWZj/X4HzBp30gQ= Message-Id: <6.2.5.6.2.20140715100237.08757120@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 15 Jul 2014 10:31:19 -0700 To: Andrew Sullivan , internetgovtech@iab.org From: S Moonesamy In-Reply-To: <20140715142048.GE8847@mx1.yitter.info> References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/NK2A-ud0KTUCZ6jCrdTqLSjV4rs Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:38:57 -0000 Hi Andrew, At 07:20 15-07-2014, Andrew Sullivan wrote: >I think the possibility that the IETF could change the provider for >the protocol parameters registry is pretty high, but the way we might >pay for that change is perhaps unclear. That is, it's nice of ICANN >to provide us this service for free right now, and it's also really >great that they do a good, satisfying job. If that should cease to be >the case, of course, the IAB could inform ICANN that we were making a >change, and then we could just start publishing the data on a >different set of web pages published somewhere else. Since the IETF >is the change control authority for the data in the IANA registries, >there isn't (nominally) anyone else who could disagree with that >conclusion. This has been the IETF and IAB position all along, and at >the igovupdate BoF in London we heard the Chair of the ICANN Board say >quite the same thing. So, I don't think there's any real issue there. There are eleven other groups represented in the discussions. The ICANN Board is not part of those groups. If there isn't anyone who would disagree with that conclusion it may help if that position could be expressed publicly. The IETF could then have its (internal) discussion about the questions in your message and the other messages posted to this mailing list. Regards, S. Moonesamy From nobody Tue Jul 15 10:51:43 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23EE1A0AE1 for ; Tue, 15 Jul 2014 10:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FlyUlbh_ERn for ; Tue, 15 Jul 2014 10:51:40 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D54D1A0AD9 for ; Tue, 15 Jul 2014 10:51:39 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so3824827wgh.10 for ; Tue, 15 Jul 2014 10:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rrqQsDjKCJ6mLEDLpaXORgqhqKONvVsPDDfvGrhUc8k=; b=dKdPtIjzdsS0o21Y9wMybpTy7z8T6BLtq6zERCLPEr1uJHSIG/x3Mk2i3AfTach6Ul L5XErqjlBVaPauU6MUNPp1UY6r+DmxjOnvaCRU7Lv94XcqsKL4iHhUWz0cWCE1FW44dq yWAqWm3oO75yyfFQMbdA+BZnJ2XdKBSObkRtxDBYWWRW6qncEi0sK89zBKd8glXkctl+ i2/yeN5Sz9v1jwtZ4N41YV8hbzzqaYq2iMu0N7Zr/JsUOt+biwkOOLIcG6JKE04md+hr faHBye/Oceaj6tncV3OMCEh7lTaMMnbBKoETDsFlgI55RbQznF/zBv8PncINsatcuNGO 7r1Q== MIME-Version: 1.0 X-Received: by 10.180.9.202 with SMTP id c10mr7414763wib.13.1405446697756; Tue, 15 Jul 2014 10:51:37 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.123.167 with HTTP; Tue, 15 Jul 2014 10:51:37 -0700 (PDT) In-Reply-To: <20140709161653.GM59034@mx1.yitter.info> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> Date: Tue, 15 Jul 2014 13:51:37 -0400 X-Google-Sender-Auth: VstL7fNG6LNrjVqVs7uQXVRO0fw Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2abda2baee004fe3f0fc6 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/47vOMOvggneq-GjS5P4W7GVOWgQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:51:42 -0000 --001a11c2abda2baee004fe3f0fc6 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 9, 2014 at 12:16 PM, Andrew Sullivan wrote: > On Wed, Jul 09, 2014 at 12:55:05PM +0000, Michele Neylon - Blacknight > wrote: > > There's a lot of content, including a discussion forum, over on > https://www.icann.org/stewardship > > Yes, and it's all ridiculous. That site (or "microsite", as it's been > styled) both attempts to impose ICANN policies on the global > discussion about all IANA and pretends to be a single discussion point > for the entire transition. But as we heard in London at the ICANN > meeting's session on the IANA transition, the way this should really > be pursued is by working on the separate parts of the IANA function > inside the concerned communities. > > So, we don't actually need a single site, or list, or anything to > discuss the overall IANA transition. The co-ordination group is there > to solve that problem. But if we did need such a site, it could not > possibly come under ICANN's terms of service, which include a rule > that one has to protect ICANN's assets. > All of which is the reason I keep suggesting a split in the IANA responsibilities. The whole problem of Internet governance is that there are a small number of functions that either have a 'one ring to rule them all' quality to them or people imagine that they do (which is just as much a problem). We do not need oversight of IANA. What we need is oversight of a small subset of IANA functions. Less than 5% of the whole. The protocol registries are not a control point. At the application layer the Internet has got on fine without an SRV prefix registry for over a decade. Having a registry is better and makes things a lot easier but many unofficial registries stepped into the role of avoiding collisions when it was needed. Its the assignments that go out to external organizations that are the problem. That is the only area where the problem of ICANN or IANA playing favorites can come up. At the moment there are the following areas: IPv4 allocations (exhausted) IPv6 allocations (might become necessary but should never become an essential concern in our lifetimes as the RIRs can reduce the increments they allocate) AS numbers (could become an issue but not very likely to, it is in any case desirable to limit supply unnecessarily as this imposes costs on routers.) X.500 OID arc allocations to organizations (a convenience function only that could easily be met by others.) Those are the only areas where 'oversight' is necessary in the IANA functions. In all other areas the consequence of IANA refusing to issue a validly approved registration would be that the IANA registry would be bypassed and a new registry emerge. The biggest problem with IANA registrations today is when they don't actually get requested. As in the recent April Fools RFC that assigned an OID on the PKIX arc but didn't register it. And that is hardly an IANA issue. --001a11c2abda2baee004fe3f0fc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 9, 2014 at 12:16 PM, Andrew Sullivan = <ajs@anvilwa= lrusden.com> wrote:
On Wed, Jul 09, 2014 at 12:55:05PM +0000, = Michele Neylon - Blacknight wrote:
> There's a lot of content, including a discussion forum, over on https://www.i= cann.org/stewardship

Yes, and it's all ridiculous. =C2=A0That site (or "microsite= ", as it's been
styled) both attempts to impose ICANN policies on the global
discussion about all IANA and pretends to be a single discussion point
for the entire transition. =C2=A0But as we heard in London at the ICANN
meeting's session on the IANA transition, the way this should really be pursued is by working on the separate parts of the IANA function
inside the concerned communities.

So, we don't actually need a single site, or list, or anything to
discuss the overall IANA transition. =C2=A0The co-ordination group is there=
to solve that problem. =C2=A0But if we did need such a site, it could not possibly come under ICANN's terms of service, which include a rule
that one has to protect ICANN's assets.

=
All of which is the reason I keep suggesting a split in the IANA respo= nsibilities.

The whole problem of Internet governa= nce is that there are a small number of functions that either have a 'o= ne ring to rule them all' quality to them or people imagine that they d= o (which is just as much a problem).

We do not need oversight of IANA.=C2=A0

<= /div>
What we need is oversight of a small subset of IANA functions. Le= ss than 5% of the whole.=C2=A0

The protocol regist= ries are not a control point. At the application layer the Internet has got= on fine without an SRV prefix registry for over a decade. Having a registr= y is better and makes things a lot easier but many unofficial registries st= epped into the role of avoiding collisions when it was needed.

Its the assignments that go out to external organizatio= ns that are the problem. That is the only area where the problem of ICANN o= r IANA playing favorites can come up. At the moment there are the following= areas:

IPv4=C2=A0allocations=C2=A0(exhausted)

IPv6 allocations (might become necessary but should never become a= n essential concern in our lifetimes as the RIRs can reduce the increments = they allocate)

AS numbers (could become an issue but not very likely t= o, it is in any case desirable to limit supply unnecessarily as this impose= s costs on routers.)

X.500 OID arc allocations to = organizations (a convenience function only that could easily be met by othe= rs.)


Those are the only areas where 'over= sight' is necessary in the IANA functions. In all other areas the conse= quence of IANA refusing to issue a validly approved registration would be t= hat the IANA registry would be bypassed and a new registry emerge.

The biggest problem with IANA registrations today is wh= en they don't actually get requested. As in the recent April Fools RFC = that assigned an OID on the PKIX arc but didn't register it. And that i= s hardly an IANA issue.
=C2=A0
--001a11c2abda2baee004fe3f0fc6-- From nobody Tue Jul 15 10:53:00 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71AB1A0AE1 for ; Tue, 15 Jul 2014 10:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxgviv_qH5F6 for ; Tue, 15 Jul 2014 10:52:57 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E3A1A0AD9 for ; Tue, 15 Jul 2014 10:52:57 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X76uO-000Kkl-Ip; Tue, 15 Jul 2014 17:52:56 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18xLgvZcdjBbwSUSqwvbMiV Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: Date: Tue, 15 Jul 2014 13:52:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E0A3629-062E-4BF2-8987-B5E549CE2F3F@istaff.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> <"4341AA4C-33BE-436B-9272 - 4BD87171A43B"@istaff.org> To: Eric Burger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RTMD6CI6uV7Ld0hjCgm8Ey4GRI8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:52:58 -0000 On Jul 15, 2014, at 1:33 PM, Eric Burger = wrote: > If the proposal is to have gobs of new registries, that=92s a bad = idea. Been there and luckily not too much bad happened, but one can = envision how lots of badness can happen in the future. >=20 > However, if the proposal is to have gobs of redundant, distributed, = cryptographically secure (meaning compromise is obvious) of an = allocation data base, that is an excellent idea. BitCoin works without a = centralized data base, so we have existence proofs, too. I vaguely = recall something about =93working code=94 and the IETF=85 >=20 > That could work for IP address allocation, which would admittedly be a = less than ideal situation for the RIR=92s businesses. For this scheme to = work for the parameters directory, we would need a technology such that = only the IETF Trust (as holder of the copyright) could update it. I = really do not see it working for the DNS root zone, because what goes = in, and what does not go in, is a matter of politics, not a matter of a = sufficient number of uncompromised nodes agreeing on what a value is. There's no reason for the IETF shouldn't explore new and innovative mechanisms for identifier coordination, as long as the resulting=20 identifiers are useful to the affected community (remember that one=20 side effect of the current mechanisms is some degree of routing=20 aggregation for routine cases.) If a better mechanism comes along,=20 the affected community is very likely figure out how to fund it=20 one way or the other. (However, I think much of the present IANA Stewardship discussion=20 should be focused on how to keep the current IANA model running in=20 a proposed post-NTIA world, since there's quite a bit of real-world reliance on it today) /John Disclaimer: My views alone. From nobody Tue Jul 15 10:53:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A051A0AD9 for ; Tue, 15 Jul 2014 10:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ_K3IRn862t for ; Tue, 15 Jul 2014 10:53:20 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id DCDE01A0AD8 for ; Tue, 15 Jul 2014 10:53:19 -0700 (PDT) Received: from dummy.name; Tue, 15 Jul 2014 17:53:19 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Steve Crocker In-Reply-To: <6.2.5.6.2.20140715100237.08757120@resistor.net> Date: Tue, 15 Jul 2014 13:53:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/VZvG3prPzknDMQeJJkdb-4YkuAA Cc: "Stephen D. Crocker" , internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:53:21 -0000 On Jul 15, 2014, at 1:31 PM, S Moonesamy wrote: > Hi Andrew, > At 07:20 15-07-2014, Andrew Sullivan wrote: >> I think the possibility that the IETF could change the provider for >> the protocol parameters registry is pretty high, but the way we might >> pay for that change is perhaps unclear. That is, it's nice of ICANN >> to provide us this service for free right now, and it's also really >> great that they do a good, satisfying job. If that should cease to = be >> the case, of course, the IAB could inform ICANN that we were making a >> change, and then we could just start publishing the data on a >> different set of web pages published somewhere else. Since the IETF >> is the change control authority for the data in the IANA registries, >> there isn't (nominally) anyone else who could disagree with that >> conclusion. This has been the IETF and IAB position all along, and = at >> the igovupdate BoF in London we heard the Chair of the ICANN Board = say >> quite the same thing. So, I don't think there's any real issue = there. >=20 > There are eleven other groups represented in the discussions. The = ICANN Board is not part of those groups. If there isn't anyone who = would disagree with that conclusion it may help if that position could = be expressed publicly. The IETF could then have its (internal) = discussion about the questions in your message and the other messages = posted to this mailing list. I=92ve been watching this thread. I=92m not sure I understand precisely = what the issue is, but I=92m happy to repeat what I said during the = igovupdate BoF in London. The registries maintained by IANA on behalf of the IETF, viz the port = assignments, the PEN assignments and the various protocol parameter = registries are under the control of the IETF. The operative agreements = are the ones between the IETF and ICANN. I believe these are an MoU and = an SLA. If the IETF wished to use some other organization for this = service, they can do so. (I haven=92t checked recently, but I suspect = there are some words in the agreement about giving notice.) ICANN does = not have any rights to the information in the registries, so the entire = corpus can be served by someone else. That said, ICANN was purpose = built to provide the IANA function and we consider it an integral part = of our operation. We fully expect to continue the IANA operation as a = service to the community and we are committed to doing so in a manner = that meets the needs and expectations of the multiple parties it serves. Steve Crocker Chair, ICANN Board of Directors >=20 > Regards, > S. Moonesamy=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Tue Jul 15 11:01:37 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EC51A0AE3 for ; Tue, 15 Jul 2014 11:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta_itEvuL3WO for ; Tue, 15 Jul 2014 11:01:32 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F171A0AE1 for ; Tue, 15 Jul 2014 11:01:32 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id w10so227817pde.32 for ; Tue, 15 Jul 2014 11:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zUJ2lhgtqZX/eJ+YSFlyPzqJkb03CInph1e9p0heuss=; b=AurkY7yNpOPkdnwIIII8e8HYusBam66egxwsWAYIUtkVC22zBj4UjZf71uEVmbsKy1 jpp5ph1tLHdXxKyHxAQTP3gH5s1nEfsr8J79U8wnp7/hkcG1VgmpeMFRvmrFQTJSr3Iy VmPHV3uNecWlnrtqP8qYWpNG28pJutN6fvlQiOunYDJCv6MhPx/QaJL8rvi1Yzt22Emr vUnuvHCB/wS+9VtQQVDzzbSPTSkT4yz04aeWSyHQPtnQqPWUpY6dpMeqNNC5nu+ZDiAW 6Yv6hrNpkdnG4Kqq2P5i1GVyPqbPXb2IfvWJnyWRm0BDJI5j4haABegYTroa6tKgtYnq vO6A== X-Gm-Message-State: ALoCoQlCQ53MqaFd2iLz1GBwoTeuOKlfmfpJ2xUo86MOHUltQstLXJdZy4srvx3QoFQIx+Y5hO11 X-Received: by 10.68.57.175 with SMTP id j15mr2452986pbq.164.1405447289875; Tue, 15 Jul 2014 11:01:29 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id hl1sm19467598pdb.41.2014.07.15.11.01.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 11:01:28 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_ACF1FB6E-3488-4B46-AC70-D5A0766C6ED2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Conrad In-Reply-To: <6.2.5.6.2.20140715100237.08757120@resistor.net> Date: Tue, 15 Jul 2014 11:01:25 -0700 Message-Id: <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org> References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/kYyCW_i_Qfb5zxWvR05CWomQ-24 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:01:34 -0000 --Apple-Mail=_ACF1FB6E-3488-4B46-AC70-D5A0766C6ED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Jul 15, 2014, at 10:31 AM, S Moonesamy wrote: >> That is, it's nice of ICANN >> to provide us this service for free right now, and it's also really >> great that they do a good, satisfying job. If that should cease to = be >> the case, of course, the IAB could inform ICANN that we were making a >> change, and then we could just start publishing the data on a >> different set of web pages published somewhere else. =20 Given the various references (some hardwired?) to IANA.ORG, that might = get a bit confusing. Perhaps it might be important to ensure that there = be a clear understanding that the IANA.ORG domain name is 'owned' by the = IAB/IETF and/or associated with the protocol parameters function? >> This has been the IETF and IAB position all along, and at >> the igovupdate BoF in London we heard the Chair of the ICANN Board = say >> quite the same thing. So, I don't think there's any real issue = there. >=20 > There are eleven other groups represented in the discussions. The = ICANN Board is not part of those groups. If there isn't anyone who = would disagree with that conclusion it may help if that position could = be expressed publicly. =20 Well, the position was expressed publicly (it's in the transcript of the = igovupdate session). Perhaps you mean expressed formally in writing? Regards, -drc --Apple-Mail=_ACF1FB6E-3488-4B46-AC70-D5A0766C6ED2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTxWx2AAoJENV6ebf0/4rXQ+EH/ih+7cQuKJ8SNy0ANMBe6J0J 3u+ATngcsRcmyx9fn46c2FKVilRMySK9nr0wtl/UPh1EitY8lCcHWVOqO8I7S/+v UbGhDotL4H4oyzpphZx/Wsqqau7pOoHP0jSI5yCIagaEUi3McL0WBQQWULiVtfRd eJXn0Mca354x+Q3Gk6BsMnCV0OzTU34vxpXjPeoDMQw70os/fOi1FXu43FdOLL/y FHueLMepCZCiawrfTZX7dGbZkgZlIJjflCTfoqIk8U/hF2WpA/Y4cAtSZENToRhQ UjjCRV5Vryd5mim8EXw03be4DcSTvlcZmpIqjzLW6olNB2ixzh99wsu1Jie1N78= =z68i -----END PGP SIGNATURE----- --Apple-Mail=_ACF1FB6E-3488-4B46-AC70-D5A0766C6ED2-- From nobody Tue Jul 15 11:46:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E051A001D for ; Tue, 15 Jul 2014 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RLaTcL1Gm-0 for ; Tue, 15 Jul 2014 11:46:42 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128611A000D for ; Tue, 15 Jul 2014 11:46:41 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l6so5445142qcy.3 for ; Tue, 15 Jul 2014 11:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e7FDCIKsPkT6fNO55HvXQM3WPwXaYKsvgbA5lksTse8=; b=v/y3O29QKNlsVJGS0+dDQ5k+8TQD20CPMHDCOfDppZsbhkV8uJZRdxnqN+PJHxIHJ9 UN6g6sojTxJX6WWcoBci5Q7MhzZn1Hycd58BBDJqufwyRFRRO1wbY2sF7fWzR2n9MEEV n/yFIoODTlGwToOHE7PljonMpeBOlt4awohj+9fD2QDcmBOwNXQNF5z+DcQBua5pFZQb xwwar3blEKY65DSNwVJMqIIlBmkTwiMi4zi8Fyoyh7JWIzcfEaXsbM9H5SxzpkNZrZuS 0pD0bFkmKoTJbmYFc/owElXUgkBOVyXHnSwiZBX5uENqhLeqvUoXr1OFPD59mVuWpvaO smIg== X-Received: by 10.224.2.196 with SMTP id 4mr35960762qak.60.1405450001186; Tue, 15 Jul 2014 11:46:41 -0700 (PDT) Received: from ?IPv6:2601:6:3a80:77e:854b:c9f:86d6:fdf6? ([2601:6:3a80:77e:854b:c9f:86d6:fdf6]) by mx.google.com with ESMTPSA id o10sm27285357qah.3.2014.07.15.11.46.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 11:46:40 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <0E0A3629-062E-4BF2-8987-B5E549CE2F3F@istaff.org> Date: Tue, 15 Jul 2014 14:46:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> <"4341AA4C-33BE-436B-9272 - 4BD87171A43B"@istaff.org> <0E0A3629-062E-4BF2-8987-B5E549CE2F3F@istaff.org> To: John Curran X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/SsKm05QMhLjckQBdqIjWUQBathA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:46:43 -0000 On Jul 15, 2014, at 1:52 PM, John Curran wrote: > (However, I think much of the present IANA Stewardship discussion=20 > should be focused on how to keep the current IANA model running in=20 > a proposed post-NTIA world, since there's quite a bit of real-world > reliance on it today) +1, and as a related principle, the groups contributing the pieces of = the final proposal to the current ICANN-convened "IANA stewardship = transition proposal process" should be looking at all (and only) the = changes necessary and sufficient for a robust, reliable post-NTIA IANA. = Processes for improvement in the future are important and interesting, = but also separate.=20 =46rom what I've heard here and in assorted other public meetings and = discussion, this is the IAB's and IETF's intention in the ianaplan = process. It seems like the right one, as long as the ability is = preserved to evolve in the future as needed. best, Suzanne (no hats)= From nobody Tue Jul 15 12:10:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756AB1B28F9 for ; Tue, 15 Jul 2014 12:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSYZotj73OnM for ; Tue, 15 Jul 2014 12:10:08 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBB11A0031 for ; Tue, 15 Jul 2014 12:10:08 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X7875-000KPJ-IK; Tue, 15 Jul 2014 19:10:07 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18cYZcDI5oWGYMnKM4VCKqV Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: Date: Tue, 15 Jul 2014 15:10:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> To: Steve Crocker X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/CTCmIPVR6UnwEOkGHcUQWV8Ckiw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:10:10 -0000 On Jul 15, 2014, at 1:53 PM, Steve Crocker wrote: > The registries maintained by IANA on behalf of the IETF, viz the port = assignments, the PEN assignments and the various protocol parameter = registries are under the control of the IETF. The operative agreements = are the ones between the IETF and ICANN. I believe these are an MoU and = an SLA. If the IETF wished to use some other organization for this = service, they can do so. (I haven=92t checked recently, but I suspect = there are some words in the agreement about giving notice.) ICANN does = not have any rights to the information in the registries, so the entire = corpus can be served by someone else. =20 While I seriously doubt such a change would be prudent from an overall = Internet stability perspective, it is probably a worthwhile thought exercise = which would=20 help somewhat in understanding the existing relationships between the = parties. Presume (for sake of argument) that we consider the IETF (collectively) = to be=20 policy authority for the technical "protocol parameter" registries, the = RIRs (collectively) the policy authority for the general-purpose portion of = the=20 IPv4, IPv6, and ASN spaces, and ICANN as the policy authority for the = general- purpose portion of the DNS root zone. I say "for sake of argument" = because=20 everyone has their own view about such authority, origins, constraints, = and=20 we could probably fill several tomes with alternative theories and = structures. So, proceeding ahead with the respective authorities "as given", what = exactly would be the practical result of the changing the IANA registry operator = to=20 some other hypothetical party (e.g. "XYZ Corp.") For the IETF, the "IANA" would be some new team at XYZ, running similar = systems to the existing IANA team for generating and updating various protocol = parameter=20 tables on IANA.ORG. If the RIRs are the authority for the = general-purpose address=20 space, then the not-yet-assigned (e.g. in IPv6) and technical entries in = IPv4 and IPv6 spaces would also be maintained by the "IANA". The in-addr.arpa = and IPv6 zones would need to be generated by this new IANA team. Requests for = new ASN=20 or IPv6 blocks from the RIRs would be handled by this team, based on = established=20 global number resource policy. An interesting question question would be with respect to administration = of global=20 DNS policy; one would think this would also be done by the IANA team, = but it is=20 potentially too integrated with the policy development body (ICANN) to = now be=20 discernible as an actual distinct function. It might instead require = that "IANA"=20 feed its information on the specialized and technical portions of the = DNS to be=20 integrated into a single space and published by ICANN (i.e. we've had = the policy=20 authority, policy development, policy administration, and publication = together=20 for so long that they are effectively integrated, as opposed to the = original ICANN model where ICANN was to be simply the accountability/oversight = body for=20 the Internet identifier system as well as the IANA record-keeper, but as = opposed to having primary policy development responsibilities as well. > That said, ICANN was purpose built to provide the IANA function and we = consider it an integral part of our operation. We fully expect to = continue the IANA operation as a service to the community and we are = committed to doing so in a manner that meets the needs and expectations = of the multiple parties it serves. I believe that it's generally recognized that ICANN does an excellent = job=20 providing the IANA services, and personally have every hope that it = continues=20 to serve in that role for a very, very long time. An interesting exercise to consider alternatives, nonetheless... /John Disclaimer: My views alone. From nobody Tue Jul 15 12:10:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452341B2904 for ; Tue, 15 Jul 2014 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v5deVQz0BMT for ; Tue, 15 Jul 2014 12:10:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DAD1B2902 for ; Tue, 15 Jul 2014 12:10:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6FJA21e001680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2014 12:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405451415; x=1405537815; bh=V4L/Gretb7Q6KKoEjKuRqqDHPDF2J1KoZ1htC6xgbls=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YOIUiUjtiIzdoYfA93Z4PSX3r0vCPTNk7JClbnYK73QJR16v0j/z9j49rtde42KhU HgsdsDYxu3nCsfLS7Nx0kEU/rw4CRNwHiFYy1ow8Rld85Jtrm54o951w2fJpUojD46 5a3vktbZTVKz6dZBmtndljcGNB9fwaSf8k40lVTk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405451415; x=1405537815; i=@elandsys.com; bh=V4L/Gretb7Q6KKoEjKuRqqDHPDF2J1KoZ1htC6xgbls=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EmvdQamvS/VA0OUusIo6UBgd49Z8aKRSBe4M6ir3ytpm05ezUDSmewRZqlOY+frE3 90+cII/4djxDAPGdshDPVGK4Myapph6L9FeP5qGq6f/b2v8wvTO442xLgSdCPuxWh2 AsGTqULmaFcFA/mGOVBkKeaNZwe9/gTMyCdwtBpM= Message-Id: <6.2.5.6.2.20140715110728.08a97a98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 15 Jul 2014 12:09:27 -0700 To: David Conrad From: S Moonesamy In-Reply-To: <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org> References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/2xL-gCGu_ZfESbVdMeq0N2zm99k Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:10:19 -0000 Hi David, At 11:01 15-07-2014, David Conrad wrote: >Given the various references (some hardwired?) to IANA.ORG, that >might get a bit confusing. Perhaps it might be important to ensure >that there be a clear understanding that the IANA.ORG domain name is >'owned' by the IAB/IETF and/or associated with the protocol >parameters function? I have been thinking about the domain name. I think that IANA.ORG is not an IETF asset. The association of the protocol parameters function with the domain name could be a headache. My guess would be not to deal with that now. >Well, the position was expressed publicly (it's in the transcript of >the igovupdate session). Perhaps you mean expressed formally in writing? I'll explain that in my response to Dr Crocker instead of here to keep that in one message. Regards, S. Moonesamy From nobody Tue Jul 15 12:20:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EC81A0AEC for ; Tue, 15 Jul 2014 12:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6G43tqIcm5U for ; Tue, 15 Jul 2014 12:20:02 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7261F1A0027 for ; Tue, 15 Jul 2014 12:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1440; q=dns/txt; s=iport; t=1405452002; x=1406661602; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lK8f5kOMR/VtyR4m3qZXWBgNilaXzn3zbBgwHL4xCnc=; b=CcQ83TJeNbm3U7Bdf9SK1y1TAN/pOPVnaB8+j43ClM2slF1AFrARuU17 3+pK5hCYPnpUMd53kuUITNRa/7HaAxBXeBmfpS7f5GmkSQOihEIDQmHed nd1bapx0QTTIaOZrO9iXoFZ+7vGH079dwp3Ainij+OOYshNYwYRxahqoF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAHR+xVOtJssW/2dsb2JhbABZhy3GRQGBJnWEBAEBBCNVARALDgoCAgUWCwICCQMCAQIBRQYBDAEHAQGIPrIQmCMXgSyOHweCd4FMAQSbGIcTjRKDRjs X-IronPort-AV: E=Sophos;i="5.01,667,1400025600"; d="scan'208";a="108211076" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 15 Jul 2014 19:19:59 +0000 Received: from [10.61.83.230] (ams3-vpn-dhcp5095.cisco.com [10.61.83.230]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6FJJxiX007710; Tue, 15 Jul 2014 19:19:59 GMT Message-ID: <53C57EDF.8070501@cisco.com> Date: Tue, 15 Jul 2014 21:19:59 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Suzanne Woolf , John Curran References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> <"4341AA4C-33BE-436B-9272 - 4BD87171A43B"@istaff.org> <0E0A3629-062E-4BF2-8987-B5E549CE2F3F@istaff.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/AQLK8Fd9mQORE0_3Hx7SAIEKAdM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:20:05 -0000 On 7/15/14, 8:46 PM, Suzanne Woolf wrote: >> (However, I think much of the present IANA Stewardship discussion >> should be focused on how to keep the current IANA model running in >> a proposed post-NTIA world, since there's quite a bit of real-world >> reliance on it today) > +1, and as a related principle, the groups contributing the pieces of the final proposal to the current ICANN-convened "IANA stewardship transition proposal process" should be looking at all (and only) the changes necessary and sufficient for a robust, reliable post-NTIA IANA. Processes for improvement in the future are important and interesting, but also separate. > > >From what I've heard here and in assorted other public meetings and discussion, this is the IAB's and IETF's intention in the ianaplan process. It seems like the right one, as long as the ability is preserved to evolve in the future as needed. > >From my perspective, yes. There has been no credible alternative proposed, and we have repeatedly all acknowledged that at least as far as the protocol parameters are concerned, there have been no credible complaints in the recent past. Quite the opposite. And what's more, most of the discussion here has all been about how to go about keeping things in a good state. That is not to say there isn't room for improvement in some areas, but the existing processes allow for that improvement to take place. Eliot From nobody Tue Jul 15 12:31:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5911A004D for ; Tue, 15 Jul 2014 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F10yvdmt_5g for ; Tue, 15 Jul 2014 12:31:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B9F1A0039 for ; Tue, 15 Jul 2014 12:31:21 -0700 (PDT) Received: from mx1.yitter.info (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DE1A58A031 for ; Tue, 15 Jul 2014 19:31:19 +0000 (UTC) Date: Tue, 15 Jul 2014 15:31:18 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140715193118.GQ8847@mx1.yitter.info> References: <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YgOTTHsN6coMgYpDmlKXKcpGdzE Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:31:22 -0000 On Tue, Jul 15, 2014 at 11:01:25AM -0700, David Conrad wrote: > > Given the various references (some hardwired?) to IANA.ORG, that might get a bit confusing. If we split the different IANA functions apart (as the idea of the IETF going elsewhere with its protocol parameters implies), the name "IANA" would presumably be wrong, so maybe we couldn't stick with iana.org anyway. Anyway, whatever happens it'd be part of the cost of "changing providers". Just to be clear, in my opinion the idea of splitting the IANA function is in general a bad one. In some important senses, IP addresses and domain names are just different parameters of protocols anyway. They each happen to have detailed policy implications that gives good reason to split the policy functions for them away from other protocol parameters. There's also the fact of close co-ordination needed when special-purpose registries get updated (particularly when they're overlapping, like parts of the IP space and some TLDs); it's much easier to ensure that co-ordination with smaller numbers of people needing to be involved. Therefore, I believe that any possible advantage would have to be pretty huge in order to cause us to split off -- something along the lines of dealing with willful divergence that couldn't be remedied. For example, suppose IANA added something to a registry in express contradiction to the IETF's instructions. Note that this might not be an IANA choice. Given ICANN's numerous office presences, I can certainly imagine a circumstance where some court with jurisdiction over ICANN but not the IETF ordered the "wrong" outcome. So, I think we need to have a good idea of what we'd have to do, what it'd cost us, and so on. That's just responsible contingency planning. But we should not be supposing that the effort would be cheap or easy or in any way a happy outcome. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 15 12:33:45 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3351A0054 for ; Tue, 15 Jul 2014 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlYRiB-pLPOu for ; Tue, 15 Jul 2014 12:33:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5291A0058 for ; Tue, 15 Jul 2014 12:33:42 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s6FJXbxS022079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 12:33:40 -0700 Message-ID: <53C581AB.7000406@dcrocker.net> Date: Tue, 15 Jul 2014 12:31:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrew Sullivan References: <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org> <20140715193118.GQ8847@mx1.yitter.info> In-Reply-To: <20140715193118.GQ8847@mx1.yitter.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 15 Jul 2014 12:33:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HiuDsfBfeYcKkDvVZiHY1FNWPgM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:33:44 -0000 On 7/15/2014 12:31 PM, Andrew Sullivan wrote: > So, I think we need to have a good idea of what we'd have to do, what > it'd cost us, and so on. That's just responsible contingency > planning. Exactly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 15 15:20:35 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C941A0118 for ; Tue, 15 Jul 2014 15:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLpASYQSh8MG for ; Tue, 15 Jul 2014 15:20:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 753E61A013B for ; Tue, 15 Jul 2014 15:20:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6FMKEi4016359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2014 15:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1405462827; x=1405549227; bh=r0F7meFrmAPBzXJPRdTlBZeYcW1yfQg1pz7lReGtZ60=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=z2vKMsOFaj05Y7AHrmTa2DkR/+PgN/0lY6tf2bgZ83bnIOfWwII6MbcXQZDJwUDIG Wsr/HffhLIptWj82paOi8WNUiutm3exnPVc/20kEWyKSaIxn1jqbhLUtnTJP2vE6cD T5bMqNCTZZVgrP5CBBcCsq1g60Kja3xmI/0uM1wc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1405462827; x=1405549227; i=@elandsys.com; bh=r0F7meFrmAPBzXJPRdTlBZeYcW1yfQg1pz7lReGtZ60=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q4OfHwW7Oc7WRSjfhDs0+2hmNGipVzlFN1ylGOSM8+pEGLhkj/TBw2GSp4ukKY64a IZUlpftx2l3Th+cOekqsH/YStxf0b8b2fJuFAmn8uayO4EcThu+3CZt1PxCKqP2pLi kUkAnRBExtCvw64Sfd3NKbdtNwu2mGEXryYBnR54= Message-Id: <6.2.5.6.2.20140715140912.08a9f598@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 15 Jul 2014 15:01:45 -0700 To: Steve Crocker From: S Moonesamy In-Reply-To: References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/KITzQzc4kI2OeUZSQOWaJkus45g Cc: internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 22:20:33 -0000 Dear Dr Crocker, At 10:53 15-07-2014, Steve Crocker wrote: >I've been watching this thread. I'm not sure I understand precisely >what the issue is, but I'm happy to repeat what I said during the >igovupdate BoF in London. Thank you for being clear about the position of the ICANN Board of Directors. I should have made it clear that it is not an issue. I'll explain. Quoting the IETF Chair (out of context): "The coordination group is likely to be ultimately responsible for delivering a combined transition proposal to NTIA ..." In my opinion it would bring some clarity, and maybe some progress, if there is some agreement about a topic which is not considered as an issue that the coordination group would have to look into. The IETF has a documented position about the Protocol Parameter Registry. Speaking for myself, I do not see any disagreement between the position of the ICANN Board of Directors and the IETF position. I don't know the position of the groups which are part of the coordination group. I could presume that it is similar to the position of the ICANN Board of Directors. In this case I think that it is better to ask. I used the word "publicly" as I think that it is better to keep things transparent. Regards, S. Moonesamy From nobody Tue Jul 15 15:51:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCC11B29A1 for ; Tue, 15 Jul 2014 15:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNfI_88qjZQZ for ; Tue, 15 Jul 2014 15:51:24 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24AE1B299B for ; Tue, 15 Jul 2014 15:51:23 -0700 (PDT) Received: from 254.74.14.81.rev.sfr.net ([81.14.74.254]:55666 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1X7BZB-0002Qa-PH; Tue, 15 Jul 2014 15:51:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jul 2014 00:48:07 +0200 To: John Curran ,JFC Morfin From: JFC Morfin In-Reply-To: <4341AA4C-33BE-436B-9272-4BD87171A43B@istaff.org> References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1E977.4050306@meetinghouse.net> <20140715164338.DD4681F86B4@mail-01-ewr.dyndns.com> <4341AA4C-33BE-436B-9272-4BD87171A43B@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OX68jUitjwi3YVWt-tCbpDP-5vM Cc: internetgovtech@iab.org, Miles Fidelman Subject: Re: [Internetgovtech] Transition to the web X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 22:51:25 -0000 At 18:58 15/07/2014, John Curran wrote: >I expect most of the readers of this list are interested in the coordination >resulting from these singular IANA registries, as opposed to the frameworks >for multiple instances of registries with self-organizing communities (but I >easily could be mistaken.) Dear John, you are most probably mistaken. However this your opinion vs. mine. The issue is that ICANN is only one of the potential 40.000 ledgers (registry of registries) admitted by the DNS, and has no experience about such a situation of competition (it should have fostered). When you discover yourself 40.000 possible competitors and in addition a trillon of independent alternatives, you can hardly organize yourself as a monopoly. ICANN has to present to the NTIA a credible description of its project to match a deregulation process where regular competition is introduced. No real difference with the 1977/1987 period. The question is how the incumbent is to manage its relations with the new comers and welcome them. This question is going to be discussed by 192 other States, by the US Congress, by DSPs (digital services providers) all over the planet, by users all over the world. The answer will be by 193 digital services, privacy, revenue tax legislations around the world. If you wish IETF/IAB to limit their considerations to the US VGN, let be it. But do not be surprised that the 192 other countries consider the IETF/IAB as US standardization consulting bodies, read ICP-3, and ask ITU to put some order into what is becoming a commercial (cf. RFC 6852) as a multi-"global community beniffiting humanity" fragmented economic system. jfc From nobody Tue Jul 15 16:27:35 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC61A0165 for ; Tue, 15 Jul 2014 16:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iamsa8iPqCRu for ; Tue, 15 Jul 2014 16:27:33 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DB01A0164 for ; Tue, 15 Jul 2014 16:27:32 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6FNRS3v069508 for ; Tue, 15 Jul 2014 16:27:32 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53C5B8E0.4030505@abenaki.wabanaki.net> Date: Tue, 15 Jul 2014 16:27:28 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WY0ZKkBJcqiicgkEU4bzq1h1ECo Subject: Re: [Internetgovtech] Contracts, what problems we are solving X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:27:33 -0000 On 7/15/14 12:10 PM, John Curran wrote: > While I seriously doubt such a change would be prudent from an overall Internet > stability perspective ... See below. > So, proceeding ahead with the respective authorities "as given", what exactly > would be the practical result of the changing the IANA registry operator to > some other hypothetical party (e.g. "XYZ Corp.") > > For the IETF, the "IANA" would be some new team at XYZ, running similar systems > to the existing IANA team for generating and updating various protocol parameter > tables on IANA.ORG. When Pinkus Warburg did the management buyout of the North American Numbering Plan Administrator business unit from Lockheed Martin in 1999 everything remained the same -- office space, management, and hardly surprisingly, the NANPA Function, mandated in the Telecommunications Act of 1996. (Yes, the L-M office space was dowdy.) This is "below." The Chicago NPAC did not go down, nor did the overall circuit switching system (in +1 only) become unstable in 1999, though its ownership changed. Eric From nobody Tue Jul 15 16:59:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414E51A01C1 for ; Tue, 15 Jul 2014 16:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_xZraDqA3hS for ; Tue, 15 Jul 2014 16:59:23 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74601A01BE for ; Tue, 15 Jul 2014 16:59:23 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X7Cd0-0007AN-UV; Tue, 15 Jul 2014 23:59:23 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182dkg8IRTMZX30bFNSvQpm Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53C5B8E0.4030505@abenaki.wabanaki.net> Date: Tue, 15 Jul 2014 19:59:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5BDD502D-3902-4B57-874F-2D8CFB257E18@istaff.org> References: <53C06E7C.4010903@gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> <53C5B8E0.4030505@abenaki.wabanaki.net> To: Eric Brunner-Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9BeBJ0Zb41NAPXlg7fjMeAWSOWQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Contracts, what problems we are solving X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:59:25 -0000 On Jul 15, 2014, at 7:27 PM, Eric Brunner-Williams = wrote: > On 7/15/14 12:10 PM, John Curran wrote: >> While I seriously doubt such a change would be prudent from an = overall Internet >> stability perspective ... >=20 > See below. Actually, there are much more relevant transitions that have already = been successfully accomplished for various portions of this space = [SRI->GSI/NSI, NSI->ARIN, DDN/ISI->ICANN, ARIN->ICANN], and yes, the Internet continued throughout. The fact that we can transition providers for these = services still does not mean we should do so without good cause. FYI, /John Disclaimer: My views alone. From nobody Wed Jul 16 15:25:04 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339BD1A0354 for ; Wed, 16 Jul 2014 15:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDedPHYd_8Xj for ; Wed, 16 Jul 2014 15:24:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5F01A038E for ; Wed, 16 Jul 2014 15:24:43 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 064A920D90; Wed, 16 Jul 2014 18:24:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 16 Jul 2014 18:24:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=BWMPZ3ygOPujN0lSWtP5vzn L6aI=; b=nV6yHfm60wzTTzg06PCs1D201d4LA+2CPc64Xa63wpbtqwcXHwLghLJ 2ASCdk8EZa9IbhuEIkiS95NwP+UrsJRc0LYGERhLFHBoVC7NbbDZHtkTN0iA1opJ RUMgTUrOXOFqZIvjvYx3tQdi4CmJGcpipwsNYFJ1bjhRkKMxKEeY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=BWMPZ3ygOPujN0lSWtP5vznL6aI=; b=EunJraQcPpW2lwjwh0nztBzdlcOH gXY881C9uwK/bpbS//7s1rerHmcgBZFymmy7EBwggWUu0V8nBovggnFA96XhhOu6 CTOip3uzpttXhw16qU6bnEAh8KUV5eGCG+cc3q/THz2ReykSbYc9n9kFp+4Q9yeb ZKZ1eL2zTs9L/PA= X-Sasl-enc: yYWvNCtPEFZ8PA6DSlQ8sFnSSvL2lTzTse2Si6t45wJx 1405549475 Received: from [10.15.32.34] (unknown [217.39.2.56]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D935680131; Wed, 16 Jul 2014 18:24:31 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 16 Jul 2014 23:24:20 +0100 From: Alissa Cooper To: , Message-ID: Thread-Topic: First coordination group meeting Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jQdN1Q5MZ2dtTB2OQ36imeqqdU0 Subject: [Internetgovtech] First coordination group meeting X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:24:52 -0000 The first face-to-face meeting of the IANA coordination group is taking place July 17-18 in London, UK. Information about the remote participation is available here: https://www.icann.org/news/announcement-2014-07-16-en The draft agenda is below. All times are local (UTC+1). The names of the coordination group members are listed here: https://www.icann.org/resources/pages/coordination-group-2014-06-17-en == Day 1 == 9:00 - 9:15 Introduction and level-setting. (Alissa) Live streaming, administrivia, and logistics. Brief explanation of why we are gathered to meet. Agenda bash. 9:15 - 10:45 Introductions. (Alissa) It would be useful to hear from each rep about: - What group appointed them - What that group does and who participates in it - How that group does its work and what its decision processes are - Whether they are "representing" their groups or participating as individuals in the CG - How they view their group's work in relation to the coordination group's work 10:45 - 11:00 Break. 11:00 - 12:30 Charter of the CG. (Jari) It would be good to obtain a shared understanding in the whole group of the role and charter of the CG. Charter proposals circulated in advance of July 17 would help here -- on the IETF/IAB side we may be able to work one up based on the IAB's April 29 comments. 12:30 - 13:30 Lunch. Continued discussion of charter. 13:30 - 15:00 Transition scope and expectations about work in the communities. (Paul) It would be good to clarify the CG's understanding of the scope of the work of the transition, what the community processes need to produce, and where/how areas of overlap will be handled. We will want to communicate this publicly if we get agreement on it. 15:00 - 16:15 Coordination group participation. (Lynn) Having hopefully developed some shared understanding of the charter of the CG and the work expected in the communities, it would be good to verify that the composition of the CG is suitable for its tasks and to resolve any outstanding questions concerning group representation in the CG. 16:15 - 16:30 Break. 16:30 - 17:30 Self-organization. (Joseph) Initial discussion about how the CG wants to organize itself, e.g., do we want a chair and/or vice-chair, do we need to form sub-groups for any particular tasks, how will we select people for these things. I think it would be good to talk about this on the first day and try to come to some conclusions, and then make the decisions on the second day. If people know they would like to serve in a particular role, they could make that known to the group. 17:30 - 18:00 Parking lot for items we want to come back to before day 2 or in case we run over time. == Day 2 == 9:00 - 9:45 Parking lot for leftover charter/community work/CG participation discussion items from yesterday. 9:45 - 10:15 Internal and external communications needs. (Martin) Whether the CG needs public and/or private mailing lists for its own work, whether we should stand up our own web site, where that site should be hosted, what we would use the web site for, what we think about ICANN's web-based platform and whether it should continue to exist and/or be replaced by other list(s). 10:15 - 10:30 Break. 10:30 - 11:45 Secretariat tasks and selection. (Daniel) ICANN will be selecting an independent secretariat for the CG. To make this selection, they will need an RFP. So the CG needs to agree on what the secretariat's responsibilities will be, and possibly needs to come up with that RFP (or work on it together with ICANN). Again having a draft RFP going into the meeting might be a useful thing. 11:45 - 12:45 Lunch. Self-organization, continued. (Joseph) If we're ready by this point, we could solicit candidates for chair/vice chair/whatever other positions we think we need and hear from them each briefly about what they would bring to the role(s). 12:45 - 13:30 Complete self-organization. 13:30 - 14:15 Timeline. (Russ H.) It would be good to get some agreement about the drop-dead date for the final proposal to be submitted to NTIA (assuming they need some lead time to review it and socialize it within the USG before the contract actually expires). We can then work backwards from there and set goals for when it would be good to have the community discussions come to a close. As with the charter, it would be helpful for someone to come up with a proposal for this in advance of the meeting. Jari has provided a proposal for this. 14:15 - 15:00 CG meeting/conference call schedule. (Milton) We need to figure out how often we'd like to have calls and when our face-to-face meetings will be. This would be another good item to have a proposal for in advance. 15:00 - 15:45 Parking lot for any item we need to come back to. 15:45 - 16:00 Break. 16:00 - 16:30 Parking lot for any item we need to come back to. 16:30 - 17:00 Summary and wrap-up. From nobody Thu Jul 17 22:31:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585FF1A064E for ; Thu, 17 Jul 2014 22:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hinmXD0ge9Jh for ; Thu, 17 Jul 2014 22:31:16 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB951A063B for ; Thu, 17 Jul 2014 22:31:15 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A5AC521F1B; Fri, 18 Jul 2014 01:31:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 18 Jul 2014 01:31:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=6QhzBPEkWwNa5zR3bbMjmdw O2Zo=; b=0IiMV6xYHjy1hPoNcuE2GEkPjEyLz7foi7MyaGypxLx5jUcnNo7RSOY WRM/pXF1UT+OGUXpjoUCNTXgA+gcjgD5c01jInSTYaGZb20wTyR5IdsDfNcSxLUP QVwHCVuBRL8SJVLAXSlvQZ8SK0jZgLM2aDv4ZSt9WXdGzYVvgSPo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=6QhzBPEkWwNa5zR3bbMjmdwO2Zo=; b=K2b6+HxeN/oNCii/WPfXliQWw23r LYxz4RFNkz5pK9CNqeb7vHZ0XRbPvHpJHrPy5/HFMaTxsNzpeWyCXrrZOKCkE3TF H9gymV9LUetkKkIO5sNLxhgsBwK4d+l7tqvE3qWREfgDVAGNqY8LdDceW9luEXiV mAoaNaqMviRnuS8= X-Sasl-enc: 5bpumK71qrHfm7hzmBO1fmOxlxkXqr0BiKNpCBG7MACm 1405661469 Received: from [10.15.32.172] (unknown [217.39.1.42]) by mail.messagingengine.com (Postfix) with ESMTPA id C3CDC68016B; Fri, 18 Jul 2014 01:31:08 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 18 Jul 2014 06:31:03 +0100 From: Alissa Cooper To: Alissa Cooper , , Message-ID: Thread-Topic: [Ianaplan] First coordination group meeting Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/i3NLUr2uJQaJ3iqmRFbH3UwwIXQ Subject: Re: [Internetgovtech] [Ianaplan] First coordination group meeting X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 05:31:18 -0000 Updated agenda for day 2: == Day 2 == 9:00 - 10:00 Parking lot for leftover charter, scope, and community work discussion items. (Jari/Paul) 10:00 - 10:45 Internal and external communications needs. (Martin) Whether the CG needs public and/or private mailing lists for its own work, whether we should stand up our own web site, where that site should be hosted, what we would use the web site for, what we think about ICANN's web-based platform and whether it should continue to exist and/or be replaced by other list(s). 10:45 - 11:00 Break. 11:00 - 12:00 Secretariat tasks and selection. (Daniel) ICANN will be selecting an independent secretariat for the CG. To make this selection, they will need an RFP. So the CG needs to agree on what the secretariat's responsibilities will be, and possibly needs to come up with that RFP (or work on it together with ICANN). Again having a draft RFP going into the meeting might be a useful thing. 12:00 - 13:00 Lunch. Framework for the transition. (Jean-Jacques) If we're ready by this point, we could solicit candidates for chair/vice chair/whatever other positions we think we need and hear from them each briefly about what they would bring to the role(s). 13:00 - 13:30 Self-organization, continued from yesterday. (Joseph) 13:30 - 14:15 Timeline. (Russ H.) It would be good to get some agreement about the drop-dead date for the final proposal to be submitted to NTIA (assuming they need some lead time to review it and socialize it within the USG before the contract actually expires). We can then work backwards from there and set goals for when it would be good to have the community discussions come to a close. As with the charter, it would be helpful for someone to come up with a proposal for this in advance of the meeting. Jari has provided a proposal for this. 14:15 - 15:00 CG meeting/conference call schedule. (Milton) We need to figure out how often we'd like to have calls and when our face-to-face meetings will be. This would be another good item to have a proposal for in advance. 15:00 - 15:30 Parking lot for CG participation discussion. (Lynn) 15:30 - 16:00 Break. 16:00 - 16:45 Parking lot for any item we need to come back to. 16:45 - 17:30 Summary and wrap-up. (Alissa) Includes compilation of statement to be published concerning the outcomes of the meeting and discussion of development of a more detailed meeting summary. On 7/16/14, 11:24 PM, "Alissa Cooper" wrote: >The first face-to-face meeting of the IANA coordination group is taking >place July 17-18 in London, UK. Information about the remote participation >is available here: https://www.icann.org/news/announcement-2014-07-16-en > >The draft agenda is below. All times are local (UTC+1). The names of the >coordination group members are listed here: >https://www.icann.org/resources/pages/coordination-group-2014-06-17-en > > >== Day 1 == > >9:00 - 9:15 >Introduction and level-setting. (Alissa) >Live streaming, administrivia, and logistics. >Brief explanation of why we are gathered to meet. >Agenda bash. > >9:15 - 10:45 >Introductions. (Alissa) >It would be useful to hear from each rep about: >- What group appointed them >- What that group does and who participates in it >- How that group does its work and what its decision processes are >- Whether they are "representing" their groups or participating as >individuals in the CG >- How they view their group's work in relation to the coordination group's >work > >10:45 - 11:00 >Break. > >11:00 - 12:30 >Charter of the CG. (Jari) >It would be good to obtain a shared understanding in the whole group of >the role and >charter of the CG. Charter proposals circulated in advance of July 17 >would help here -- >on the IETF/IAB side we may be able to work one up based on the IAB's >April 29 comments. > >12:30 - 13:30 >Lunch. >Continued discussion of charter. > >13:30 - 15:00 >Transition scope and expectations about work in the communities. (Paul) >It would be good to clarify the CG's understanding of the scope of the >work of the >transition, what the community processes need to produce, and where/how >areas of overlap >will be handled. We will want to communicate this publicly if we get >agreement on it. > >15:00 - 16:15 >Coordination group participation. (Lynn) >Having hopefully developed some shared understanding of the charter of the >CG and the work >expected in the communities, it would be good to verify that the >composition of the CG is >suitable for its tasks and to resolve any outstanding questions concerning >group >representation in the CG. > >16:15 - 16:30 >Break. > >16:30 - 17:30 >Self-organization. (Joseph) >Initial discussion about how the CG wants to organize itself, e.g., do we >want a chair >and/or vice-chair, do we need to form sub-groups for any particular tasks, >how will we >select people for these things. I think it would be good to talk about >this on the first >day and try to come to some conclusions, and then make the decisions on >the second day. If >people know they would like to serve in a particular role, they could make >that known to >the group. > >17:30 - 18:00 >Parking lot for items we want to come back to before day 2 or in case we >run over time. > > >== Day 2 == > >9:00 - 9:45 >Parking lot for leftover charter/community work/CG participation >discussion items from >yesterday. > >9:45 - 10:15 >Internal and external communications needs. (Martin) >Whether the CG needs public and/or private mailing lists for its own work, >whether we >should stand up our own web site, where that site should be hosted, what >we would use the >web site for, what we think about ICANN's web-based platform and whether >it should >continue to exist and/or be replaced by other list(s). > >10:15 - 10:30 >Break. > >10:30 - 11:45 >Secretariat tasks and selection. (Daniel) >ICANN will be selecting an independent secretariat for the CG. To make >this selection, >they will need an RFP. So the CG needs to agree on what the secretariat's >responsibilities >will be, and possibly needs to come up with that RFP (or work on it >together with ICANN). >Again having a draft RFP going into the meeting might be a useful thing. > >11:45 - 12:45 >Lunch. >Self-organization, continued. (Joseph) >If we're ready by this point, we could solicit candidates for chair/vice >chair/whatever >other positions we think we need and hear from them each briefly about >what they would >bring to the role(s). > >12:45 - 13:30 >Complete self-organization. > >13:30 - 14:15 >Timeline. (Russ H.) >It would be good to get some agreement about the drop-dead date for the >final proposal to >be submitted to NTIA (assuming they need some lead time to review it and >socialize it >within the USG before the contract actually expires). We can then work >backwards from >there and set goals for when it would be good to have the community >discussions come to a >close. As with the charter, it would be helpful for someone to come up >with a proposal for >this in advance of the meeting. Jari has provided a proposal for this. > >14:15 - 15:00 >CG meeting/conference call schedule. (Milton) >We need to figure out how often we'd like to have calls and when our >face-to-face meetings >will be. This would be another good item to have a proposal for in >advance. > >15:00 - 15:45 >Parking lot for any item we need to come back to. > >15:45 - 16:00 >Break. > >16:00 - 16:30 >Parking lot for any item we need to come back to. > >16:30 - 17:00 >Summary and wrap-up. > > > > > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan From nobody Sat Jul 19 13:58:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4E01B299B for ; Sat, 19 Jul 2014 13:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bLIHEGIP_sh for ; Sat, 19 Jul 2014 13:58:15 -0700 (PDT) Received: from services-1.meeting.ietf.org (services-1.meeting.ietf.org [IPv6:2001:67c:370:229::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B291B2982 for ; Sat, 19 Jul 2014 13:58:15 -0700 (PDT) Received: from wireless-a-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:6233:4bff:fe20:eb18]) by services-1.meeting.ietf.org (Postfix) with ESMTP id B76924E766; Sat, 19 Jul 2014 20:58:14 +0000 (UTC) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Jul 2014 16:58:14 -0400 Message-Id: To: internetgovtech@iab.org, ianaplan@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/1zlzvsCrjn1WW_auQJaNpkPt4do Subject: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 20:58:17 -0000 Documents from the IANA Stewardship Coordination Group (ICG) meeting = last week have been posted. The ICG charter: = https://www.icann.org/en/system/files/files/draft-charter-coordination-gro= up-17jun14-en.pdf A statement about the meeting that took place in London last week: = https://www.icann.org/en/system/files/files/draft-icg-statement-18jul14-en= .pdf The agenda, transcripts, and so on are available here: = https://www.icann.org/resources/pages/coordination-group-resources-2014-07= -18-en Russ= From nobody Mon Jul 21 07:08:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC351A000B for ; Mon, 21 Jul 2014 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.812 X-Spam-Level: ** X-Spam-Status: No, score=2.812 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfuP2Es6NYep for ; Mon, 21 Jul 2014 07:08:43 -0700 (PDT) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 56B671A0024 for ; Mon, 21 Jul 2014 07:07:20 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LE7Ia7014391 for ; Mon, 21 Jul 2014 10:07:18 -0400 Received: (qmail 19045 invoked by uid 0); 21 Jul 2014 14:07:15 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 21 Jul 2014 14:07:15 -0000 Message-ID: <53CD1E8A.1060804@acm.org> Date: Mon, 21 Jul 2014 10:07:06 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140721-0, 07/21/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OwJAeylSrqI7L8-ini780r2lNhI Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:08:44 -0000 Hi, > > The ICG charter: > https://www.icann.org/en/system/files/files/draft-charter-coordination-group-17jun14-en.pdf I have a question of the slice and dice methodology for the topics into 3 categories. Does the IETF, though it includes the protocol work on DNS and the tools to support the likes of WHOIS functionality and the design on numbering systems, plan to only contribute 'outputs' on protocol parameters? Not commenting for now on the orphan issues - things NTIA stewards a that don't fit into any of the 3 defined operational groups. that is a problem for other messages. I understand why various organization may be the ones to take the first shot and even the lead on various issues, I am concerned that we building walls to who can prodice recommendations that need to be coordinated on which aspects. I think that silo orientation is a losing methodology and is one that put too much control in the hands of the IGC. avri From nobody Mon Jul 21 07:16:52 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E981A002A for ; Mon, 21 Jul 2014 07:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE9Y3K-z9VK2 for ; Mon, 21 Jul 2014 07:16:48 -0700 (PDT) Received: from services-1.meeting.ietf.org (services-1.meeting.ietf.org [31.130.229.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BA91A0063 for ; Mon, 21 Jul 2014 07:16:46 -0700 (PDT) Received: from hotel-wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:144:6233:4bff:fe20:eb18]) by services-1.meeting.ietf.org (Postfix) with ESMTP id 3FBFD4E75E; Mon, 21 Jul 2014 14:16:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <53CD1E8A.1060804@acm.org> Date: Mon, 21 Jul 2014 10:16:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CD1E8A.1060804@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/JljQlWKBCxZwR7A5cHxyUK1f4PE Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:16:50 -0000 Avri: >> The ICG charter: >> = https://www.icann.org/en/system/files/files/draft-charter-coordination-gro= up-17jun14-en.pdf >=20 >=20 > I have a question of the slice and dice methodology for the topics = into > 3 categories. >=20 > Does the IETF, though it includes the protocol work on DNS and the = tools > to support the likes of WHOIS functionality and the design on = numbering > systems, plan to only contribute 'outputs' on protocol parameters? >=20 > Not commenting for now on the orphan issues - things NTIA stewards a > that don't fit into any of the 3 defined operational groups. that is = a > problem for other messages. >=20 > I understand why various organization may be the ones to take the = first > shot and even the lead on various issues, I am concerned that we > building walls to who can prodice recommendations that need to be > coordinated on which aspects. I think that silo orientation is a = losing > methodology and is one that put too much control in the hands of the = IGC. The IETF community will be responsible for the proposal for protocol = parameters. I expect that interested individuals will be working with = the name community or the numbers community to make sure that the right = things are happening in each of those proposals as well. Coordination = will be needed where there is overlap, such as anycast addresses and = special-purpose names. That said, once the whole proposal is stitched = together, it will be reviewed by all three communities and many other = interested parties. Russ= From nobody Mon Jul 21 07:26:28 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5971A00F1 for ; Mon, 21 Jul 2014 07:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm2Aa-ronnfL for ; Mon, 21 Jul 2014 07:26:20 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC21A000E for ; Mon, 21 Jul 2014 07:26:15 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LEQEhb032047 for ; Mon, 21 Jul 2014 10:26:14 -0400 Received: (qmail 8012 invoked by uid 0); 21 Jul 2014 14:26:14 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 21 Jul 2014 14:26:14 -0000 Message-ID: <53CD2300.5050307@acm.org> Date: Mon, 21 Jul 2014 10:26:08 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140721-0, 07/21/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Zjnf4Soa5sD2LonEYDUsV1faenA Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:26:25 -0000 Hi, > > The IETF community will be responsible for the proposal for protocol > parameters. I expect that interested individuals will be working with > the name community or the numbers community to make sure that the > right things are happening in each of those proposals as well. > Coordination will be needed where there is overlap, such as anycast > addresses and special-purpose names. That said, once the whole > proposal is stitched together, it will be reviewed by all three > communities and many other interested parties. > > Is that what the community as a whole has decided or just what is decreed by the ICG. I fund this silo approach very problematic and more likely to produce a disjointed set of solutions - leaving too much power to the ICG to fit things as it sees fit. But time will tell and if it has been decided by the powers-that-be, I guess I will just have to live with it. avri From nobody Mon Jul 21 07:31:14 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EACF1A0058 for ; Mon, 21 Jul 2014 07:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdVKsIRKw3hd for ; Mon, 21 Jul 2014 07:31:05 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D90B1A004A for ; Mon, 21 Jul 2014 07:31:04 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so6593862wgh.22 for ; Mon, 21 Jul 2014 07:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5IkUhIGXdP7j7obi6Mj1ntBhtQwd61eFjO/HuSpRk0g=; b=oBi/CBnY1b9q/ikntNEWNOd8/NS/GVYaqozConQGpDak2yHENTOdgdLx1/TEeL5FD+ YnXdQuoz4HDkqqJWdo4M7vV+MMlTsjFQ7TXUOtISk64UZKblXozD97ygqX1PE3nvv78G w+ZxmSTTSx7FIifMPxcgH/5XYNdMGatKdFkst3kWakpa/trmGCeo1PyPogQn4popWBWJ +lv9R2zbHhI6hrWB91/vUtdNVffZGsi7eecrSm0AZHV4Ljaa+gaBCLFZNLnPyhTw685D JRoVpfmnvM6F2s8Ahy/RK+W8oHhiq2GO7YMjNGeQQ5HzdpzV/wjKC8mHvbBIQPJzDbba tb8Q== X-Received: by 10.194.243.200 with SMTP id xa8mr23376556wjc.97.1405953062639; Mon, 21 Jul 2014 07:31:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.162.195 with HTTP; Mon, 21 Jul 2014 07:30:32 -0700 (PDT) In-Reply-To: <53CD1E8A.1060804@acm.org> References: <53CD1E8A.1060804@acm.org> From: Seun Ojedeji Date: Mon, 21 Jul 2014 15:30:32 +0100 Message-ID: To: Avri Doria Content-Type: multipart/alternative; boundary=089e01493e54de9f1304feb4f45e Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/56ipVO_cz-itOURtCnA2N9PMMhQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:31:08 -0000 --089e01493e54de9f1304feb4f45e Content-Type: text/plain; charset=UTF-8 Hello Avri, On Mon, Jul 21, 2014 at 3:07 PM, Avri Doria wrote: > > ....I am concerned that we building walls to who can prodice > recommendations that need to be coordinated on which aspects. I think that > silo orientation is a losing methodology and is one that put too much > control in the hands of the IGC. > This was one the concern i raised within the number community[1]. The thing is the process is trying to be organisaed however the attempt is making possibility of getting diverse contribution more complex and less probable. Regards 1. https://lists.afrinic.net/pipermail/ianaoversight/2014-July/000010.html > > avri > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --089e01493e54de9f1304feb4f45e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hell= o Avri,

On Mon, Jul 21, 2014 at 3:07 PM, Avri Doria <avri@acm.org>= ; wrote:

=C2=A0 ....I am concerned that we building walls to who can prodice recommendations that need to be coordinated on which aspects. =C2=A0I think that silo orientation is a losi= ng methodology and is one that put too much control in the hands of the IGC.

This was one the concern i raised within= the number community[1]. The thing is the process is trying to be organisa= ed however the attempt is making possibility of getting diverse contributio= n more complex and less probable.


avri

_______________________________________________
Internetgovtech mailing list
Internetgovtech@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech



--
---------------------------------------------------------------------= ---
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--089e01493e54de9f1304feb4f45e-- From nobody Mon Jul 21 07:31:15 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828511A004E for ; Mon, 21 Jul 2014 07:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H81CAJLRHvo for ; Mon, 21 Jul 2014 07:31:12 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7411A004A for ; Mon, 21 Jul 2014 07:31:08 -0700 (PDT) Received: from mx1.yitter.info (dhcp-bc45.meeting.ietf.org [31.133.188.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7F9CF8A031 for ; Mon, 21 Jul 2014 14:31:07 +0000 (UTC) Date: Mon, 21 Jul 2014 10:31:06 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140721143105.GH16966@mx1.yitter.info> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CD2300.5050307@acm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/KwOwFzihyrbt-hKw03gyfH0l2PM Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:31:13 -0000 On Mon, Jul 21, 2014 at 10:26:08AM -0400, Avri Doria wrote: > I fund this silo approach very problematic and more likely to produce a > disjointed set of solutions Where would be the joint whereof you speak? To put this another way, in my opinion protocol parameters belong squarely in the IETF's purview, and nobody else's. Similarly, given the protocols, names fall squarely into ICANN's purview, no? What is the "joint" that wouldn't be better solved (in the case of names) by working within the ICANN community? Similarly for number resources, except a different community. I don't think there's any handed-down-ness about it. This is a fully community-based approach, I think. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 21 07:36:56 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43001A007C for ; Mon, 21 Jul 2014 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2neP1d4N2sht for ; Mon, 21 Jul 2014 07:36:46 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DA61A000D for ; Mon, 21 Jul 2014 07:36:46 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9Eho-00076g-Og; Mon, 21 Jul 2014 14:36:44 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX192cneI2qOiX7ULjBUS73H9 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: Date: Mon, 21 Jul 2014 10:36:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8EFBBF2B-0FFD-4C1A-B189-DFC6374C957E@istaff.org> References: <53CD1E8A.1060804@acm.org> To: Russ Housley X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/DRMzCxpAJ7aGudQiE4_EJgCi6gk Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:36:49 -0000 On Jul 21, 2014, at 10:16 AM, Russ Housley wrote: > The IETF community will be responsible for the proposal for protocol = parameters. I expect that interested individuals will be working with = the name community or the numbers community to make sure that the right = things are happening in each of those proposals as well. Coordination = will be needed where there is overlap, such as anycast addresses and = special-purpose names. That said, once the whole proposal is stitched = together, it will be reviewed by all three communities and many other = interested parties. This is a reasonable approach, given that there is a dedicated = coordinating group that can facilitate the necessary review and coordination steps to = make=20 a consistent proposal. It would also be helpful if an IAB/IETF IANA = framework=20 for all of the = IETF registries (i.e. technical "protocol parameter" ones, more "general = purpose"=20 registries of DNS root zone, IP address spaces, ASN spaces, etc.) were = to=20 be published, as this would help make plain the IETF's generic = expectations=20 for the registries component of its successful Internet protocol = development efforts. Thanks! /John Disclaimer: My views alone. =20 From nobody Mon Jul 21 07:52:32 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9A1A014B for ; Mon, 21 Jul 2014 07:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr68QvePm9kN for ; Mon, 21 Jul 2014 07:52:22 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id E086A1A00B8 for ; Mon, 21 Jul 2014 07:52:21 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LEqKRh004499 for ; Mon, 21 Jul 2014 10:52:20 -0400 Received: (qmail 21531 invoked by uid 0); 21 Jul 2014 14:52:20 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 21 Jul 2014 14:52:20 -0000 Message-ID: <53CD291E.1020801@acm.org> Date: Mon, 21 Jul 2014 10:52:14 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> In-Reply-To: <20140721143105.GH16966@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140721-0, 07/21/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/tkfC1UCMAGgqvFEmSFTGSR536X8 Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:52:24 -0000 Hi, I am not necessarily looking for joint efforts - though it might be nice, just allowing for any of the communities to produce recommendations on any of the aspects. There are cross over concerns, for example in ICANN the Advisory Committees (At Large, Government, Security etc) have purview to advise on addresses as well as numbers and even parameters when it concerns tech that will be used to manage those names and numbers. Why does our process say that they can't make recommendations on that? Likewise the IETF has great concerns over the allocations of some names and may want to make a suggestion of how the allocation of names is done given the IETF's decision that it is able to assign names for protocol reasons. That is a tussle waiting in the wings that needs to come out into the light for all of this assignment of responsibilities. Yes, the IETF will naturally choose to mostly produce recommendations on parameters, but need it be limited to that? Likewise with the other groups. I have no problem with the notion of an expectation that mostly parameters will be covered by IETF and names by GNSO and the ccNSO, and numbers by the NRO. What I have problems with is the construction of silo walls that indicate an expectation that others might not have standing and ability to contribute to the proposed solutions on particular subjects. I do not want there to be a possibility that someone calls an uncomfortable recommendaton out of scope for the organization making it. As for this have been handed down, I do not remember there ever being a community wide discussion on slice and dice, just announcements of this being the way it would be from various leaders. avri On 21-Jul-14 10:31, Andrew Sullivan wrote: > On Mon, Jul 21, 2014 at 10:26:08AM -0400, Avri Doria wrote: >> I fund this silo approach very problematic and more likely to produce a >> disjointed set of solutions > > Where would be the joint whereof you speak? To put this another way, > in my opinion protocol parameters belong squarely in the IETF's > purview, and nobody else's. Similarly, given the protocols, names > fall squarely into ICANN's purview, no? What is the "joint" that > wouldn't be better solved (in the case of names) by working within the > ICANN community? Similarly for number resources, except a different > community. > > I don't think there's any handed-down-ness about it. This is a fully > community-based approach, I think. > > A > From nobody Mon Jul 21 07:54:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BD11A010F for ; Mon, 21 Jul 2014 07:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5DDhrFeoM0N for ; Mon, 21 Jul 2014 07:54:09 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAF71A008D for ; Mon, 21 Jul 2014 07:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2530; q=dns/txt; s=iport; t=1405954448; x=1407164048; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=aSmh9hlHT6b6ItGLbiGMC484+wP1wQL/fpfDTrIVhBM=; b=ICeHhJUYI20E+s5R2LRUI0ZPSukdh2MZftxp/0+V4wewwyvBZiQidGIM a/M5z1Y7s8N+xsRiFSo5lQ50Hp9NmOqTTukvYGwHhjCfJWvKTttf6kNLv yGGN/eyoNvVSL1Uhc0Oqu9VKpysmfCa2qlXE7I0DWhdFqGtchNltDZfco U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAGsozVOtJssW/2dsb2JhbABZhy/KHQGBLnaEBAEBBCNJCgIRCwQBEwkWCwICCQMCAQIBRQYBDAgBARAHiCenTZcIF459VYJ4gU4BBJslhxWNGoNgIQ X-IronPort-AV: E=Sophos;i="5.01,701,1400025600"; d="scan'208,217";a="118758574" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 Jul 2014 14:54:06 +0000 Received: from [10.86.240.218] (che-vpn-cluster-1-218.cisco.com [10.86.240.218]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6LEs2LG009521; Mon, 21 Jul 2014 14:54:03 GMT Message-ID: <53CD298B.8050807@cisco.com> Date: Mon, 21 Jul 2014 10:54:03 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Avri Doria , internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> In-Reply-To: <53CD2300.5050307@acm.org> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010207030807020305010808" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/m-EErOviUZC8TLl6qGlpCrsY40c Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:54:10 -0000 This is a multi-part message in MIME format. --------------010207030807020305010808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/21/14, 10:26 AM, Avri Doria wrote: > Is that what the community as a whole has decided or just what is > decreed by the ICG. > > I fund this silo approach very problematic and more likely to produce a > disjointed set of solutions - leaving too much power to the ICG to fit > things as it sees fit. But time will tell and if it has been decided by > the powers-that-be, I guess I will just have to live with it. > The alternative is creating more one time processes that are by definition untested. We could spend months more doing just that and do it poorly, rather than actually developing proposals to be knitted together. The words in the current charter make clear that the key role of the ICG is to gain consensus among the different communities, and specifically *not* to develop the contents. And so let's just please manage the corner cases (there are several). Eliot --------------010207030807020305010808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/21/14, 10:26 AM, Avri Doria wrote:
Is that what the community as a whole has decided or just what is
decreed by the ICG.

I fund this silo approach very problematic and more likely to produce a
disjointed set of solutions - leaving too much power to the ICG to fit
things as it sees fit. But time will tell and if it has been decided by
the powers-that-be, I guess I will just have to live with it.

The alternative is creating more one time processes that are by definition untested.  We could spend months more doing just that and do it poorly, rather than actually developing proposals to be knitted together.  The words in the current charter make clear that the key role of the ICG is to gain consensus among the different communities, and specifically not to develop the contents.  And so let's just please manage the corner cases (there are several).

Eliot
--------------010207030807020305010808-- From nobody Mon Jul 21 09:09:02 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973611A0059 for ; Mon, 21 Jul 2014 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebOxrvchAWO7 for ; Mon, 21 Jul 2014 09:08:58 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1111A004B for ; Mon, 21 Jul 2014 09:08:57 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9G93-000GeH-0I; Mon, 21 Jul 2014 16:08:57 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX189PVKVr++kG/Xs8Du5dccF Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53CD291E.1020801@acm.org> Date: Mon, 21 Jul 2014 12:08:54 -0400 Content-Transfer-Encoding: 7bit Message-Id: <74A399C5-BDA0-4DDB-A52A-BC2F6D98222F@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0nYDjMZrhEWq6RYNBZiPDdK6cT4 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:08:59 -0000 On Jul 21, 2014, at 10:52 AM, Avri Doria wrote: > I have no problem with the notion of an expectation that mostly > parameters will be covered by IETF and names by GNSO and the ccNSO, and > numbers by the NRO. What I have problems with is the construction of > silo walls that indicate an expectation that others might not have > standing and ability to contribute to the proposed solutions on > particular subjects. Avri - Since the ICG charter specifically states that everyone's input is to be welcome across all topics, I'm not certain how anyone's contribution could be excluded for a lack of "standing"... From how I read the process, any such input will be considered by the ICG, and potentially provided back to the appropriate operational community for consideration; this is regardless of its origin. (Of course, that's just my take based on the charter just published, I am not in London/Toronto nor part of the ICG.) Do you read it differently? /John Disclaimer: My views alone - no IANA accountability mechanisms are proposed by way of this email. From nobody Mon Jul 21 09:27:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AAB1A02F4 for ; Mon, 21 Jul 2014 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agM3Zzcc9KSQ for ; Mon, 21 Jul 2014 09:27:09 -0700 (PDT) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id 663B11A02DE for ; Mon, 21 Jul 2014 09:27:09 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LGR6ZH014899 for ; Mon, 21 Jul 2014 12:27:06 -0400 Received: (qmail 17442 invoked by uid 0); 21 Jul 2014 16:27:06 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 21 Jul 2014 16:27:06 -0000 Message-ID: <53CD3F54.6000502@acm.org> Date: Mon, 21 Jul 2014 12:27:00 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <74A399C5-BDA0-4DDB-A52A-BC2F6D98222F@istaff.org> In-Reply-To: <74A399C5-BDA0-4DDB-A52A-BC2F6D98222F@istaff.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140721-0, 07/21/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vvpMy0WcHGdUpcfyLn91LnAsrbw Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:27:10 -0000 Hi > Do you read it differently? Yes. I read it as saying the while comments can be accepted by all, outputs/proposals seem to only come from the 3 designated operational actors, each restricted to their assigned topic. I.e. first there are proposals from the 3 operational assignees on their assigned topic then there is broader input on the transition proposal avri On 21-Jul-14 12:08, John Curran wrote: > On Jul 21, 2014, at 10:52 AM, Avri Doria wrote: > >> I have no problem with the notion of an expectation that mostly >> parameters will be covered by IETF and names by GNSO and the ccNSO, and >> numbers by the NRO. What I have problems with is the construction of >> silo walls that indicate an expectation that others might not have >> standing and ability to contribute to the proposed solutions on >> particular subjects. > > Avri - > > Since the ICG charter specifically states that everyone's input is to be > welcome across all topics, I'm not certain how anyone's contribution could > be excluded for a lack of "standing"... From how I read the process, any > such input will be considered by the ICG, and potentially provided back to > the appropriate operational community for consideration; this is regardless > of its origin. (Of course, that's just my take based on the charter just > published, I am not in London/Toronto nor part of the ICG.) > > Do you read it differently? > /John > > Disclaimer: My views alone - no IANA accountability mechanisms are proposed > by way of this email. > > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > From nobody Mon Jul 21 09:37:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0B81A005F for ; Mon, 21 Jul 2014 09:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbbpBllqFJYz for ; Mon, 21 Jul 2014 09:37:21 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147AF1A0059 for ; Mon, 21 Jul 2014 09:37:21 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9GaW-000Fkc-Ac; Mon, 21 Jul 2014 16:37:20 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5sXbvW+TkHvbGTU1phc71 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53CD291E.1020801@acm.org> Date: Mon, 21 Jul 2014 12:37:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Q_clQfoiKB9w731JpmgBgeD9PI0 Cc: internetgovtech@iab.org Subject: [Internetgovtech] Cross community (was: Re: ICANN Re: Documents from the ICG Meeting Last Week are Available) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:37:22 -0000 On Jul 21, 2014, at 10:52 AM, Avri Doria wrote: > There are cross over concerns, for example in ICANN the Advisory > Committees (At Large, Government, Security etc) have purview to advise > on addresses as well as numbers and even parameters when it concerns > tech that will be used to manage those names and numbers. Could you elaborate some on the above concepts? I understand how there is potential for consultation with such advisory committees if considered appropriate by the ICANN Board (and as provided for in the ASO Global Policy Development process), but the more typical method of engagement is directly in the policy development processes taking place in each RIR region... in this way, the input is considered closer to those affected by the outcome. Similarly, I am not aware of any ICANN advisory committees providing input to the IETF regarding issues in protocol parameter registry administration; any/all parties with concerns are encouraged to participate in the relevant IETF working group and/or last call process to make sure their concerns are heard in a timely manner. I guess I'm trying to understand what "IANA stewardship" responsibilities the various ICANN advisory groups may feel with respect to the IP registry and technical protocol parameter spaces? Do you see it with respect to the policy development aspect or policy administration/IANA registry operations? > Why does our process say that they can't make recommendations on that? I do not believe it does; my reading of the charter indicates that anyone can make recommendations regarding IANA stewardship and related transition matters. Thanks! /John Disclaimer: My views alone. From nobody Mon Jul 21 10:15:24 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D681A0031 for ; Mon, 21 Jul 2014 10:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEbe3vvPwdqN for ; Mon, 21 Jul 2014 10:15:22 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149731A026A for ; Mon, 21 Jul 2014 10:15:16 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6LHDq8Y037766 for ; Mon, 21 Jul 2014 10:14:20 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53CD4A4B.4090507@abenaki.wabanaki.net> Date: Mon, 21 Jul 2014 10:13:47 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> In-Reply-To: <20140721143105.GH16966@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/zvci_qKzFEl-LKEDAC_2-RshbnQ Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:15:23 -0000 Andrew, When applicants (note the plural) sought single Han script character (necessarily 5 or more octets) labels in the IANA root, the IETF's liaison objected, and when an applicant sought to use only characters in the 0-9 range as a label in the IANA root, again, the IETF's liaison objected. Other examples of third-party involvement in the policy development of the GNSO (the only portion of ICANN with ByLaws responsibilities for domain name policy development) exist. I appreciate that you were expressing your own opinion, and perhaps brevity could have been equally well served by "most names" or "names, with some exceptions", in your response to Avri. Also, just to be somewhat formal, since the removal of the Protocol Supporting Organization from the ByLaws in 2003, other than the persuasive abilities of Liaisons, the "members" of the ICANN community -- and recall ICANN is a 501(c)(3) with no members -- however vigorous and vocal, are but (a very few) individuals with no particular status, commenting on policy developed by a ByLaws body, and so unlikely to participate effectively in review/purview/oversight/ghastly-error-avoidance. Perhaps if you'd written "names fall squarely into the GNSO purview, no?" Then the locus of control, and the composition of the controllers -- that community -- would be unambiguous, and modulo persuasive Liaisons, supra, and the efforts of third-parties such as the GNSO, and correct. Eric On 7/21/14 7:31 AM, Andrew Sullivan wrote: > On Mon, Jul 21, 2014 at 10:26:08AM -0400, Avri Doria wrote: >> I fund this silo approach very problematic and more likely to produce a >> disjointed set of solutions > Where would be the joint whereof you speak? To put this another way, > in my opinion protocol parameters belong squarely in the IETF's > purview, and nobody else's. Similarly, given the protocols, names > fall squarely into ICANN's purview, no? What is the "joint" that > wouldn't be better solved (in the case of names) by working within the > ICANN community? Similarly for number resources, except a different > community. > > I don't think there's any handed-down-ness about it. This is a fully > community-based approach, I think. > > A > From nobody Mon Jul 21 10:33:49 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528591A01E6 for ; Mon, 21 Jul 2014 10:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzTYxviGtOR9 for ; Mon, 21 Jul 2014 10:33:41 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA781A01AC for ; Mon, 21 Jul 2014 10:33:40 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so6845007wgh.5 for ; Mon, 21 Jul 2014 10:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QfWnZbecPIQPCBgfiN8kFUfb//vyh9DMKI7r6mCuuXw=; b=FVPi6RlpHhepi8Zs9XcBwBpFtpA72ec3a+vnMt0Ia9+NEXQjJ42SaW083yHLUzpd4H 4cx/OKN47J8Ml5BKrJitD5pWU8bheRRkEKRVJqfIDlyqO6rbm0RrZX9nF6VrH8XpAXfQ 0sYSF02KMmdu2H/2NxKDHYU5aeG9q5IkP4jY81WMa7wrnUcYLSe7cyyCnkn19OucCmsM 3zPXgsSoPF41050VdkLdRC9E7iXV4uixu1pjvlYdsG6x6VEiZ1uCRHxHsTLiXP9qzpl3 Jdbtp9LmQlPxUksz7g+n91IFt5WCaHSMbwqOgcMoIxZqEnrNmayNY968Ieaolx9KtPXP vhdA== MIME-Version: 1.0 X-Received: by 10.180.19.200 with SMTP id h8mr6647647wie.32.1405964019444; Mon, 21 Jul 2014 10:33:39 -0700 (PDT) Received: by 10.194.162.195 with HTTP; Mon, 21 Jul 2014 10:33:39 -0700 (PDT) Received: by 10.194.162.195 with HTTP; Mon, 21 Jul 2014 10:33:39 -0700 (PDT) In-Reply-To: <74A399C5-BDA0-4DDB-A52A-BC2F6D98222F@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <74A399C5-BDA0-4DDB-A52A-BC2F6D98222F@istaff.org> Date: Mon, 21 Jul 2014 18:33:39 +0100 Message-ID: From: Seun Ojedeji To: John Curran Content-Type: multipart/alternative; boundary=bcaec53d5eb7f2305c04feb781c6 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/LN4tmvchLceMvbumx4YMsPMmkHE Cc: internetgovtech@iab.org, avri Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:33:44 -0000 --bcaec53d5eb7f2305c04feb781c6 Content-Type: text/plain; charset=UTF-8 sent from Google nexus 4 kindly excuse brevity and typos. On 21 Jul 2014 17:09, "John Curran" wrote: From how I read the process, any > such input will be considered by the ICG, and potentially provided back to > the appropriate operational community for consideration; this is regardless > of its origin. > If I may ask where is the process that "anyone" will take to provide input indicated? Thanks Cheers! (Of course, that's just my take based on the charter just > published, I am not in London/Toronto nor part of the ICG.) > > Do you read it differently? > /John > > Disclaimer: My views alone - no IANA accountability mechanisms are proposed > by way of this email. > > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --bcaec53d5eb7f2305c04feb781c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

sent from Google nexus 4
kindly excuse brevity and typos.
On 21 Jul 2014 17:09, "John Curran" <jcurran@istaff.org> wrote:

=C2=A0From how I read the process, any
> such input will be considered by the ICG, and potentially provided bac= k to
> the appropriate operational community for consideration; this is regar= dless
> of its origin.
>
If I may ask where is the process that "anyone" will take to prov= ide input indicated?

Thanks

Cheers!
=C2=A0(Of course, that's just my take based on the charter just
> published, I am not in London/Toronto nor part of the ICG.)
>
> Do you read it differently?
> /John
>
> Disclaimer: =C2=A0My views alone - no IANA accountability mechanisms a= re proposed
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by way of this email.<= br> >
>
>
> _______________________________________________
> Internetgovtech mailing list
> Internetgovtech@iab.org=
> https= ://www.iab.org/mailman/listinfo/internetgovtech

--bcaec53d5eb7f2305c04feb781c6-- From nobody Mon Jul 21 10:47:09 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9098B1A00D2 for ; Mon, 21 Jul 2014 10:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-O9Y6dRn9_J for ; Mon, 21 Jul 2014 10:47:06 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8491A0021 for ; Mon, 21 Jul 2014 10:47:06 -0700 (PDT) Received: from mx1.yitter.info (dhcp-bc45.meeting.ietf.org [31.133.188.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8C7358A031 for ; Mon, 21 Jul 2014 17:47:05 +0000 (UTC) Date: Mon, 21 Jul 2014 13:47:04 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140721174703.GB17107@mx1.yitter.info> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CD4A4B.4090507@abenaki.wabanaki.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YqSpkx1PGy6LAkXwUNxVpDxtvpY Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:47:08 -0000 On Mon, Jul 21, 2014 at 10:13:47AM -0700, Eric Brunner-Williams wrote: > When applicants (note the plural) sought single Han script character > (necessarily 5 or more octets) labels in the IANA root, the IETF's > liaison objected, and when an applicant sought to use only > characters in the 0-9 range as a label in the IANA root, again, the > IETF's liaison objected. Right. What's wrong with that? In that case, we've actually created a formal mechanism for the IETF to deliver its opinions to ICANN -- a liaison. Also, because all the relevant communities (IETF, ICANN, all the RIRs) run open, community-driven processes, people can have a foot in both worlds: there's nothing that says you have to participate in only one community. I think you'd be seeing a very different set of proposals if some of these communities were closed. But they're not, and I don't think it's worth inventing a process for a problem we don't have. Anyway, by and large, there are three areas of interest here with three associated communities _qua_ community. I'm not sure I see how trying to mix that up (and invent a complete new process by which we co-ordinate across these communities in real time) is better than saying, "Just use the existing processes we have for the three broad areas." Now, are there some corner cases? Of course. But reasonable engineering says that, for a one-time event, you can deal with the small number of corner cases one at a time by hand, rather than create a process. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 21 11:12:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A81A0175 for ; Mon, 21 Jul 2014 11:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YefXtv88OH3A for ; Mon, 21 Jul 2014 11:12:00 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61A1A00B5 for ; Mon, 21 Jul 2014 11:12:00 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LIBwta019780 for ; Mon, 21 Jul 2014 14:11:58 -0400 Received: (qmail 9487 invoked by uid 0); 21 Jul 2014 18:11:58 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 21 Jul 2014 18:11:58 -0000 Message-ID: <53CD57E8.4000909@acm.org> Date: Mon, 21 Jul 2014 14:11:52 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> In-Reply-To: <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140721-0, 07/21/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/hmwKD-6SLbvxO_o1E_iLuVA1Fzk Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:12:04 -0000 Hi, On 21-Jul-14 12:37, John Curran wrote: > On Jul 21, 2014, at 10:52 AM, Avri Doria wrote: > >> > There are cross over concerns, for example in ICANN the Advisory >> > Committees (At Large, Government, Security etc) have purview to advise >> > on addresses as well as numbers and even parameters when it concerns >> > tech that will be used to manage those names and numbers. > Could you elaborate some on the above concepts? I understand how there is > potential for consultation with such advisory committees if considered > appropriate by the ICANN Board (and as provided for in the ASO Global Policy > Development process), but the more typical method of engagement is directly > in the policy development processes taking place in each RIR region... in > this way, the input is considered closer to those affected by the outcome. The ASO is part of ICANN. Anything it does, is open to comment by any of the Adivisory Committees (AC). I am assuming that the ASO and the NRO are not identical as they both got seats on the ICG. That indicates that there are ICANN concerns with numbers that may be more appropriately dealt by ICANN participants. I understand that the RIRs all have their own regional participants, but at the global level, there is very little stakeholder participation, with the ICANN Advisory Committees being the only possible venue for such concerns. doea the NRO provide a multistakeholder venue at the global level or is that the task of the ASO? Because the ASO is part of ICANN, the ACs have a voice in their activities and thus have a say in the accountability methods for those issues. On a specific example that I pay more attention to than numbers, the IETF has recently asserted its ability to take names out of the general pool of labels available for TLDs by declaring them to be protocol artifacts, i.e. RFC 6761 on Special Use Names. To assert IETF having full control of this interface without any accountability to others is problematic. While this may just be an edge case from the IETF protocol perspective, it could could be a huge issue from the ICANN perspective. It is just not as simple as one group per each issue. And I am sure that as we go on, we will find other issues of commonality that need to be explored. And I still don't know who submits proposals on the .arpa, or .int issue and the root server issues. In a world where the various tech and the various policy issues are so intertwined and interdependent, I think siloing is risky and should be avoided. avri BTW, i have sent too many messages to this list today and figure i better stop before someone speaks to me sternly. From nobody Mon Jul 21 11:21:02 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173F21A0362 for ; Mon, 21 Jul 2014 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_JIIykGUX7p for ; Mon, 21 Jul 2014 11:21:00 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80901A035E for ; Mon, 21 Jul 2014 11:20:55 -0700 (PDT) Received: from [192.168.1.58] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id C87D32286B; Mon, 21 Jul 2014 20:20:53 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_55310A25-16F9-4474-890C-F0B53A8B0F1B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <53CD3F54.6000502@acm.org> Date: Mon, 21 Jul 2014 20:20:44 +0200 Message-Id: <3A4D8BFC-9778-4721-BF5F-014A77051978@frobbit.se> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <74A399C5-BDA0-4DDB-A52A-BC2F6D98222F@istaff.org> <53CD3F54.6000502@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/R-aSpaqUOQhvEAMzMlqiAE_R6I8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:21:01 -0000 --Apple-Mail=_55310A25-16F9-4474-890C-F0B53A8B0F1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 jul 2014, at 18:27, Avri Doria wrote: >> Do you read it differently? >=20 > Yes. I read it as saying the while comments can be accepted by all, > outputs/proposals seem to only come from the 3 designated operational > actors, each restricted to their assigned topic. >=20 > I.e. first there are proposals from the 3 operational assignees on = their > assigned topic >=20 > then there is broader input on the transition proposal Avri, let me express it differently. There are _main_ categories and _main_ holders of processes for each one = of them. But there are (as you pointed out yourself) a few IANA "things" = that are not so clear where they fit, and there are groups (like SSAC) = that is chartered to work with all three. What the CG have identified already now is that the maturity of the PDP = and relationship between the policy development and IANA is different = for the various categories, and we found it being good to already now = identify that fact, and that it might be that the various categories = must be treated slightly differently. No one like silos, and that is definitely not the intention. Trust me! It is to not create too many dependencies between various processes that = have different maturity. Patrik --Apple-Mail=_55310A25-16F9-4474-890C-F0B53A8B0F1B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTzVn8rMabGguI180RAqvBAJ9MFifS0vD3EfYg2QbBoWEVO9ZoLwCffIyn kAcH7MTuHlv2PlEBHFElpT4= =318/ -----END PGP SIGNATURE----- --Apple-Mail=_55310A25-16F9-4474-890C-F0B53A8B0F1B-- From nobody Mon Jul 21 12:41:34 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9E41A00AB for ; Mon, 21 Jul 2014 12:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB60itPdmIfK for ; Mon, 21 Jul 2014 12:41:30 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6C11A0398 for ; Mon, 21 Jul 2014 12:41:28 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6LJesCS083859 for ; Mon, 21 Jul 2014 12:41:06 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53CD6CBC.40804@abenaki.wabanaki.net> Date: Mon, 21 Jul 2014 12:40:44 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info> In-Reply-To: <20140721174703.GB17107@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wSgt844TQ6DP0tPP2scMffnSRE8 Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:41:32 -0000 Andrew, If I wrote that there was "something wrong with that", you're response would be ... responsive. You've observed that, in your opinion, "names fall squarely into ICANN's purview", and I've pointed out that there are examples where the policy of the GNSO, the only ICANN ByLaws entity with responsibility for names policy, has been altered by third-parties. See also Avri's note on some restrictions on labels offered by some third-parties. Eric P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels? With 3 octet labels? And finally, with 2 octet labels? P.P.S. Exactly what is wrong with a terminal label consisting only of characters in the 0-9 range, that is not completely cured by a requirement that the next subordinate label contain one or more characters from the range g-z? On 7/21/14 10:47 AM, Andrew Sullivan wrote: > On Mon, Jul 21, 2014 at 10:13:47AM -0700, Eric Brunner-Williams wrote: > >> When applicants (note the plural) sought single Han script character >> (necessarily 5 or more octets) labels in the IANA root, the IETF's >> liaison objected, and when an applicant sought to use only >> characters in the 0-9 range as a label in the IANA root, again, the >> IETF's liaison objected. > Right. What's wrong with that? In that case, we've actually created > a formal mechanism for the IETF to deliver its opinions to ICANN -- a > liaison. Also, because all the relevant communities (IETF, ICANN, all > the RIRs) run open, community-driven processes, people can have a foot > in both worlds: there's nothing that says you have to participate in > only one community. I think you'd be seeing a very different set of > proposals if some of these communities were closed. But they're not, > and I don't think it's worth inventing a process for a problem we > don't have. > > Anyway, by and large, there are three areas of interest here with > three associated communities _qua_ community. I'm not sure I see how > trying to mix that up (and invent a complete new process by which we > co-ordinate across these communities in real time) is better than > saying, "Just use the existing processes we have for the three broad > areas." > > Now, are there some corner cases? Of course. But reasonable > engineering says that, for a one-time event, you can deal with the > small number of corner cases one at a time by hand, rather than create > a process. > > Best regards, > > A > From nobody Mon Jul 21 12:48:45 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAFB1A03C2 for ; Mon, 21 Jul 2014 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjTJbSCIJs0J for ; Mon, 21 Jul 2014 12:48:41 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FF81A02FA for ; Mon, 21 Jul 2014 12:48:40 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9JZg-000Hb7-2L; Mon, 21 Jul 2014 19:48:40 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19hM7CMD0+ZpLCDhTP4M8dx Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53CD57E8.4000909@acm.org> Date: Mon, 21 Jul 2014 15:48:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WFcMMu8LbRZc-M4abEmc7bi4KZo Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:48:43 -0000 On Jul 21, 2014, at 2:11 PM, Avri Doria wrote: >> Could you elaborate some on the above concepts? I understand how = there is=20 >> potential for consultation with such advisory committees if = considered=20 >> appropriate by the ICANN Board (and as provided for in the ASO Global = Policy=20 >> Development process), but the more typical method of engagement is = directly=20 >> in the policy development processes taking place in each RIR = region... in=20 >> this way, the input is considered closer to those affected by the = outcome. =20 >=20 > The ASO is part of ICANN. Anything it does, is open to comment by any > of the Adivisory Committees (AC). Yes - in accordance with the agreement between ICANN and the NRO = including the Global Policy Development Process contained therein. I expect that = the=20 ICANN Board would want to promptly seek such advisory committee comment=20= given the timelines involved... > I understand that the RIRs all have their own regional participants, = but > at the global level, there is very little stakeholder participation, > with the ICANN Advisory Committees being the only possible venue for > such concerns. Given that something does not get to ICANN until it has been fully = agreed=20 as a result of policy development meetings in all of the regions = generally=20 over a period of years, it would probably be more productive to engage = in=20 the regional processes leading to the formation of the global policy = (i.e. rather than at the very end of lengthly consensus building process) =20 It might make sense for ICANN to look at that model for its own policy development efforts; it might help address some of the concerns I heard expressed at the recent IGF-USA meeting about ICANN advisory committees=20= needing to be more involved in the policy development process and hence more invested in the developed outcomes. > doea the NRO provide a multistakeholder venue at the > global level or is that the task of the ASO? Because the ASO is part = of > ICANN, the ACs have a voice in their activities and thus have a say in > the accountability methods for those issues. The ASO does provide for global policy _coordination_ and participates in ICANN's accountability review processes. Note that the ASO does not=20= do policy development; that takes place closer to the effected parties=20= via meetings in each region. You probably need to look over the agreements between ICANN and the RIRs/NRO, as the RIRs are accountable (as actual membership orgs) to their respective communities via elected leaderships and open policy development processes. The ICANN Board is accountable per agreement to the collected addressing community for the timely review and=20 ratification of proposed global address policies. > On a specific example that I pay more attention to than numbers, the > IETF has recently asserted its ability to take names out of the = general > pool of labels available for TLDs by declaring them to be protocol > artifacts, i.e. RFC 6761 on Special Use Names. To assert IETF having > full control of this interface without any accountability to others is > problematic. While this may just be an edge case from the IETF = protocol > perspective, it could could be a huge issue from the ICANN = perspective. Strange... The IETF created the namespace through definition of the DNS protocol, just as they did with IPv4 and IPv6 number spaces. If there=20= are technical/specialized reservations that they (the IETF) see fit to=20= make, then that portion of the identifier space is no longer part of=20 the "general purpose" portion of the affected registry. =20 We work these issues fairly routinely on the addressing side, and I=20 would say have excellent working relationships. Ultimately, those who are actually affected (service providers, equipment makers, researchers) know to show up in appropriate working groups in the IETF to make their views heard. I have ample faith in the openness and accountability=20 of the IETF processes to the affected community in these matters, but would be willing to consider bodies such as the RIRs as equally capable given their membership structure. Trying to claim accountability absent=20= the ingrained institutional record of the IETF or an actual membership model does seem more difficult. > And I still don't know who submits proposals on the .arpa, or .int = issue > and the root server issues. If those are technical reservations from the DNS space, then they are = backed by RFCs and will be followed by ICANN per the existing IETF MOU (RFC = 2860). In the event ICANN adopts a policy that prevents it from complying with = such guidance, things would get interesting real fast (see MOU section = 4.3...)=20 > In a world where the various tech and the various policy issues are so > intertwined and interdependent, I think siloing is risky and should be > avoided. It's much simpler if you look at things one parameter space at a time:=20= who created it, what technical reservations does it have, is there a=20 general purpose portion & if so who is the delegated policy authority,=20= what entity administers the resulting policy, and what party performs=20 registry operations/publication for the entire parameter space? The=20 general purpose DNS and IP registries are only portions are subsets=20 of the entire registry spaces; keeping that in mind may help quite a bit with clarity of roles. FYI, /John Disclaimer: My views alone. From nobody Mon Jul 21 13:08:31 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF5E1A03C6 for ; Mon, 21 Jul 2014 13:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7nCjTE2HFOz for ; Mon, 21 Jul 2014 13:08:27 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611CC1A02EF for ; Mon, 21 Jul 2014 13:08:27 -0700 (PDT) Received: from mx1.yitter.info (dhcp-ab55.meeting.ietf.org [31.133.171.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 916CD8A031 for ; Mon, 21 Jul 2014 20:08:25 +0000 (UTC) Date: Mon, 21 Jul 2014 16:08:24 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140721200823.GG17453@mx1.yitter.info> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info> <53CD6CBC.40804@abenaki.wabanaki.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CD6CBC.40804@abenaki.wabanaki.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Ob1q17gpVkpTJGbwpjOepze_bJo Subject: [Internetgovtech] off topic: labels (was Re: Documents from the ICG Meeting Last Week are Available) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:08:30 -0000 Since you asked on list, I'll reply, but I don't think this is the right list to pursue this discussion and if we're going to have to do that I suggest perhaps DNSOP or the dns-operations OARC list or perhaps dnsext@ietf.org (which is still open), depending on whether you want to talk about protocol or operations. On Mon, Jul 21, 2014 at 12:40:44PM -0700, Eric Brunner-Williams wrote: > P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels? > With 3 octet labels? And finally, with 2 octet labels? Nothing, in principle. In practice, it depends. You might want to have a look at RFC 6912. Even though it was particularly about Unicode code points for U-labels, the general principles outlined there are useful in other ways too. > P.P.S. Exactly what is wrong with a terminal label consisting only > of characters in the 0-9 range, that is not completely cured by a > requirement that the next subordinate label contain one or more > characters from the range g-z? Well, the actual terminal label cannot contain any characters at all, but I think you knew that and meant the second-to-last label (conventionally called a TLD). So, first, there's actually no technical way to require what you're saying, really. That's what "delegation" means. You could do it with contracts, though. But what you're really saying is that the heuristic implied in RFC 1123 might break. That seems like an extremely incautious thing to do, and therefore a responsible operator of the root zone wouldn't do it. Technology is not infinitely plastic: once you have deployed something, it affects the world. In the case of the DNS, the way it has affected the world is partly based in the assumptions people have about what their software may depend on. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 21 13:21:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777F1A023E for ; Mon, 21 Jul 2014 13:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJj9q0PJFToV for ; Mon, 21 Jul 2014 13:21:45 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032A51A000E for ; Mon, 21 Jul 2014 13:21:44 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6LKKbiH084011 for ; Mon, 21 Jul 2014 13:21:05 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53CD760F.4090902@abenaki.wabanaki.net> Date: Mon, 21 Jul 2014 13:20:31 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info> <53CD6CBC.40804@abenaki.wabanaki.net> <20140721200823.GG17453@mx1.yitter.info> In-Reply-To: <20140721200823.GG17453@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/lUwKyc82w9E-1cq7VASQoYGwDxM Subject: Re: [Internetgovtech] off topic: labels (was Re: Documents from the ICG Meeting Last Week are Available) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:21:45 -0000 Yeah, that was a mistake. If you ever get around to responding to the main point that would be ... well, too late at this point. On 7/21/14 1:08 PM, Andrew Sullivan wrote: > Since you asked on list, I'll reply, but I don't think this is the > right list to pursue this discussion and if we're going to have to do > that I suggest perhaps DNSOP or the dns-operations OARC list or > perhaps dnsext@ietf.org (which is still open), depending on whether > you want to talk about protocol or operations. > > On Mon, Jul 21, 2014 at 12:40:44PM -0700, Eric Brunner-Williams wrote: > >> P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels? >> With 3 octet labels? And finally, with 2 octet labels? > Nothing, in principle. In practice, it depends. You might want to > have a look at RFC 6912. Even though it was particularly about > Unicode code points for U-labels, the general principles outlined > there are useful in other ways too. > >> P.P.S. Exactly what is wrong with a terminal label consisting only >> of characters in the 0-9 range, that is not completely cured by a >> requirement that the next subordinate label contain one or more >> characters from the range g-z? > Well, the actual terminal label cannot contain any characters at all, > but I think you knew that and meant the second-to-last label > (conventionally called a TLD). So, first, there's actually no > technical way to require what you're saying, really. That's what > "delegation" means. You could do it with contracts, though. > > But what you're really saying is that the heuristic implied in RFC > 1123 might break. That seems like an extremely incautious thing to > do, and therefore a responsible operator of the root zone wouldn't do > it. Technology is not infinitely plastic: once you have deployed > something, it affects the world. In the case of the DNS, the way it > has affected the world is partly based in the assumptions people have > about what their software may depend on. > > Best regards, > > A > From nobody Mon Jul 21 13:52:38 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7128E1A04F1 for ; Mon, 21 Jul 2014 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTRXvu8k8fXF for ; Mon, 21 Jul 2014 13:52:33 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3A21A049C for ; Mon, 21 Jul 2014 13:52:33 -0700 (PDT) Received: from mx1.yitter.info (dhcp-bc45.meeting.ietf.org [31.133.188.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 05B428A031 for ; Mon, 21 Jul 2014 20:52:31 +0000 (UTC) Date: Mon, 21 Jul 2014 16:52:30 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140721205230.GC19399@mx1.yitter.info> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info> <53CD6CBC.40804@abenaki.wabanaki.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CD6CBC.40804@abenaki.wabanaki.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/A19wkVhPOGZePQ4hW6d0oGJyNgU Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:52:36 -0000 On Mon, Jul 21, 2014 at 12:40:44PM -0700, Eric Brunner-Williams wrote: > ICANN's purview", and I've pointed out that there are examples where > the policy of the GNSO, the only ICANN ByLaws entity with > responsibility for names policy, has been altered by third-parties. Well, first, for the current discussion, I don't have a theory of how policy development goes on inside ICANN, which is why I think the discussions about that ought to live inside the relevant community. But also, see John's remarks about the scope of all this. I agree with what he said, so I won't repeat it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 21 14:11:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848C31A03E5 for ; Mon, 21 Jul 2014 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mzJIMIu853T for ; Mon, 21 Jul 2014 14:11:58 -0700 (PDT) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B7D1A02E1 for ; Mon, 21 Jul 2014 14:11:57 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6LLAvA7084195 for ; Mon, 21 Jul 2014 14:11:12 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53CD81D7.6040806@abenaki.wabanaki.net> Date: Mon, 21 Jul 2014 14:10:47 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info> <53CD6CBC.40804@abenaki.wabanaki.net> <20140721205230.GC19399@mx1.yitter.info> In-Reply-To: <20140721205230.GC19399@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/_oq8bgq49Ba6aR4H4_sF9GNVtrM Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:11:58 -0000 On 7/21/14 1:52 PM, Andrew Sullivan wrote: > I don't have a theory of how > policy development goes on inside ICANN, and, a few hours earlier. > names > fall squarely into ICANN's purview, no? Eric From nobody Mon Jul 21 15:08:13 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB771A0135 for ; Mon, 21 Jul 2014 15:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPRMTZO-D5QJ for ; Mon, 21 Jul 2014 15:08:04 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2a00:19e8:10:5::b]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1191A00A9 for ; Mon, 21 Jul 2014 15:08:04 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 7B4FA18F3C8; Mon, 21 Jul 2014 23:08:01 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=r5dSWWpwC hzHHRCvOIYEgk0HFeg=; b=oiVYAKr85J5ebRaRnAyozm5XxePEJYBdQSaBxTdjk pHb3PeWVHkH2WcixH/IxKsI2QCYpxx3oW+xduNWkqZ5I0YOM83eXO/36pFYdP2Xt 5uFLqDmCSFeMzYRh2KhurF6Q2HKTWQLabsAtD9zz6LsUGwc13Iy+W4arUWBp1GGD vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=VgB SthLlO/bQvV0gGQcKGVEiA2sjWooPG7BlDtAy+nQP8U6tt/8ySTk0sNmQ7Q0DMy9 zPaAIK/s16uwxgWUOmj8eddpys+K6FLwGQ6zfSSbSNjur5TPPAoPpApqJ8gUxRAO S5yYQ57WtVE6IpDFSo1yTfbkWvvaJCbH6vAaTk/w= Received: from [IPv6:2a02:120b:2c79:4e00:4895:44ab:65aa:afc8] (unknown [IPv6:2a02:120b:2c79:4e00:4895:44ab:65aa:afc8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id CF67118F3C5; Mon, 21 Jul 2014 23:08:00 +0100 (BST) Message-ID: <53CD8F41.9060909@gih.com> Date: Tue, 22 Jul 2014 00:08:01 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Curran , Avri Doria References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/bIv13rQ4jv6FlFjB6KDMbu0EJ4o Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:08:08 -0000 Dear John, On 21/07/2014 21:48, John Curran wrote: > It's much simpler if you look at things one parameter space at a time: > who created it, what technical reservations does it have, is there a > general purpose portion & if so who is the delegated policy authority, > what entity administers the resulting policy, and what party performs > registry operations/publication for the entire parameter space? The > general purpose DNS and IP registries are only portions are subsets > of the entire registry spaces; keeping that in mind may help quite a > bit with clarity of roles. Is there going to also be a study of accountability mechanisms for each of the parties administering each parameter space? Kindest regards, Olivier From nobody Mon Jul 21 15:26:42 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09A51A026A for ; Mon, 21 Jul 2014 15:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRZ55lXpkC-F for ; Mon, 21 Jul 2014 15:26:39 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D9B1A006B for ; Mon, 21 Jul 2014 15:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=561; q=dns/txt; s=iport; t=1405981598; x=1407191198; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1ifr/gW1RwzImmWHHSU0854Be9O/K3QsVDh5RoWhEnY=; b=go4y8TSkPpmFOSRC9A8EqyHheAzJ8vzwge4IJZnX6NqZzL3qJS14tAxv d3AaTcHT25Q/R6cN17SPn8btLmq7PZJ70KSLBIDlguzRhLCWB+C0Tqq32 nOUA7aKod9uPfnPa8JKZuJRkQC6BrUrUHsLjLS5sfO1MRG+zx5R6qqSuW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAGiSzVOtJssW/2dsb2JhbABZhy/LSwGBMHaEBAEBBCNVARALGAICBRYLAgIJAwIBAgFFBgEMAQcBARCILqgZlyAXgSyNS1QHgniBTgEEmyWHFY0ag2Ah X-IronPort-AV: E=Sophos;i="5.01,704,1400025600"; d="scan'208";a="119421454" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Jul 2014 22:26:35 +0000 Received: from [10.86.240.218] (che-vpn-cluster-1-218.cisco.com [10.86.240.218]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6LMQYd5003238; Mon, 21 Jul 2014 22:26:34 GMT Message-ID: <53CD939D.5020001@cisco.com> Date: Mon, 21 Jul 2014 18:26:37 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Olivier MJ Crepin-Leblond , John Curran , Avri Doria References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> In-Reply-To: <53CD8F41.9060909@gih.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/IAg1nttHFlgRa8rD0q2VC_hwepc Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:26:40 -0000 Olivier, On 7/21/14, 6:08 PM, Olivier MJ Crepin-Leblond wrote: > Is there going to also be a study of accountability mechanisms for > each of the parties administering each parameter space? Certainly the community should review our existing model to decide what needs to change. But we should be mindful that we do have a functioning service, and some principles that were reviewed on this list and presented in London that do guide us. I also think the proposed charter that Andrew put out makes pretty clear what needs to be reviewed. Eliot From nobody Mon Jul 21 18:03:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFB11A01E1 for ; Mon, 21 Jul 2014 18:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHi0LGOZb80y for ; Mon, 21 Jul 2014 18:03:25 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6680C1A0197 for ; Mon, 21 Jul 2014 18:03:25 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9OUE-000Gll-UU; Tue, 22 Jul 2014 01:03:23 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+jaIBaiNi856yY5ztmHspw Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53CD8F41.9060909@gih.com> Date: Mon, 21 Jul 2014 21:03:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3683599A-0C7F-4556-9B46-4C41444D0424@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> To: Olivier MJ Crepin-Leblond X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/l4jhAHnRD4hs-6TKpmBZkWANDwk Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 01:03:27 -0000 On Jul 21, 2014, at 6:08 PM, Olivier MJ Crepin-Leblond = wrote: > On 21/07/2014 21:48, John Curran wrote: >> It's much simpler if you look at things one parameter space at a = time:=20 >> who created it, what technical reservations does it have, is there a=20= >> general purpose portion & if so who is the delegated policy = authority,=20 >> what entity administers the resulting policy, and what party performs=20= >> registry operations/publication for the entire parameter space? The=20= >> general purpose DNS and IP registries are only portions are subsets=20= >> of the entire registry spaces; keeping that in mind may help quite a >> bit with clarity of roles. >=20 > Is there going to also be a study of accountability mechanisms for = each > of the parties administering each parameter space? Olivier -=20 =20 As I understand it, we have been discussing the charter of the=20 "IANA Stewardship Transition Coordination Group (ICG)", which=20 is responsible for coordinating in the formation of a plan for=20 the transitioning of NTIA=92s stewardship of the IANA functions. The IANA Functions are administrative/clerical registry functions for all of the parameter spaces, including protocol parameters in general, and the general purpose portions of the DNS and IP address spaces. All of these are administered by the "IANA" (by a team of folks within ICANN); if the ICG does its job, the resulting plan will cover (as your state) the "accountability=20 mechanisms for each of the parties administering each parameter=20 space", but in this case, the administration is being done by=20 all the same party, i.e. ICANN in its performance as the IANA. I believe what you meant to ask is a significantly different=20 question regarding study of accountability mechanisms for the=20 _policy authority and policy development_ aspects of each of the parameter spaces. =20 I know that ICANN has kicked off an ICANN Accountability effort=20 which presumably will encompass such with respect to its DNS policy=20 efforts... With respect to policy authority and relationships=20 for the address parameter spaces, the 5 RIRs have stated that=20 "we believe than a review is appropriate at this time, prior to=20 the expected NTIA transition, along with reviews by each of the=20 RIRs of their own accountability mechanisms." =20 = As with regard to accountability mechanisms for the technical=20 protocol parameter spaces created by the IETF, I do not know if=20 any review is planned or even warranted. Protocol use is nominally=20 a voluntary choice, and to the extent that the IETF predominantly=20 sticks to technical criteria and its open & transparent development=20 processes, it should be the rightful authority for any registries=20 created out of that process. I guess if the IETF were to make a habit of embedding social policy aspects into its protocol design,=20 one could argue that its processes and accountability mechanisms=20 become a valid item to review, but the IETF hasn't historically=20 been embedding public policy values into its protocol designs... (and any claim that the present day NTIA contract provides a "accountability mechanism" in this regard is specious.)=20 FYI, /John Disclaimer: My views alone. From nobody Tue Jul 22 01:32:00 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D041A031A for ; Tue, 22 Jul 2014 01:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDz482CtTiYv for ; Tue, 22 Jul 2014 01:31:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BD01A00CF for ; Tue, 22 Jul 2014 01:31:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.135]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6M8VPk3009784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 01:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406017900; x=1406104300; bh=2bVUhoMa+ju5qNRdNQWkINQZWTP/ubSPQlcaXUKEMO8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fmpBFIiM7uNX4aIzN5/6oI4CaR0BIT9Rka0SBCyX6kaYX59TQmKkbaFPCZOxyZ8Xw Ii6GxGotyxQxqrDDd1MQZuBvghBzbWkrEXb2WBlJ1m6jvUB1hZO6mQcEJ2KeCUeTWs 3KBATl0mlqNwc1iOuJVZbh0HUhZzoFlxRbW2WLiw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406017900; x=1406104300; i=@elandsys.com; bh=2bVUhoMa+ju5qNRdNQWkINQZWTP/ubSPQlcaXUKEMO8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=M7At9uWTGWndDFsK36pgvyMPPe4s426sZwJ27i+bu4n7Oz56qnzZUVMijNimSXg+V gsq8lQdFoVDskpnSl+DdszcutuWj+1FCJeFDkXRzAWDdacurGvGp3yLjw/6cBhgadB /WODk5Kdu7Gzc+TDdl6hkhuUV7/VcRKZfxrYDQoo= Message-Id: <6.2.5.6.2.20140721232728.0cc67788@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 Jul 2014 01:20:16 -0700 To: Seun Ojedeji , Avri Doria From: S Moonesamy In-Reply-To: References: <53CD1E8A.1060804@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/50tEVwdp1V8c12i1gsWzUD3SHhQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 08:31:58 -0000 Hi Seun, At 07:30 21-07-2014, Seun Ojedeji wrote: >This was one the concern i raised within the number community[1]. >The thing is the process is trying to be organisaed however the >attempt is making possibility of getting diverse contribution more >complex and less probable. The concern in that message was about the process for the various numbers communities. It isn't directly related to the protocol parameters registry. I'll mention that I have previously reviewed numbers-related requests in IETF drafts. Several persons who have posted on this thread (and another one) have an interest in names. They didn't mention concerns about the names side. I took a quick look at the proposed charter. According to that document the coordination group will be acting as a clearinghouse for proposals about the various IANA Functions. There is already some discussion in the IETF about the process for the protocol parameter Function. As I am already familiar with the IETF process I did not consider it as useful to ask questions about that process at this stage. One thing that I found odd is why this discussion is taking place on this IAB mailing list instead of the venues for the relevant communities. This is where I will get blamed for starting the (previous) off-topic thread. Please note that I do not have any concern about the following. The problem [1] is that the proposed (coordination) charter does not provide much information about the process. From that document: "The ICG will then put this proposal up for public comment involving a reasonable period of time for reviewing the draft proposal, analyzing and preparing supportive or critical comments. The ICG will then review these comments and determine whether modifications are required. If no modifications are needed, and the coordination group agrees, the proposal will be submitted to NTIA." If I was able to suggest something I would say: (a) Please don't use words such as "reasonable period of time". (b) Please don't use words such as "supportive or critical comments". (c) Please clarify how the comments will be reviewed. Regards, S. Moonesamy 1. I picked the first word that came to my mind. From nobody Tue Jul 22 03:44:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051EF1A0AC2 for ; Tue, 22 Jul 2014 03:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6GDIt_XIheG for ; Tue, 22 Jul 2014 03:44:13 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689A31A0AB9 for ; Tue, 22 Jul 2014 03:44:13 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so7696440wgh.20 for ; Tue, 22 Jul 2014 03:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tEgtyHhTf27lY5IwncdAQegxx7iUC+340Pukj63oA1s=; b=egPGgz1lznm7Wrj3NfpCoJFn/9BBO3BuNhh6UEEQWCsB88p56KolACjj+RYZgQnHzF BojB68QeDUwmTUW59uBUlkPz8iHo2+lB1kjMsfm3N5iKiH4zf8t/OORR+OKmB69hUhIa esQvlg4lUtWCvrawzeK2EFRBcA2YT8TQXJO3OhbYNQntAtgaqH/Yg2tf9l7Rn0rP6VRf FEt6cRLFGITqXIchxyDcmdFKdb7bMfa84qPQ99MEvHi2kxKLO7kD70j2weTd+6ysHJfG z27vPkH3Kfc21Ghzgxu79AXy9NqPEmdnW4JW4RteRLooi/FaKcE9mGGcngJRmjHOlRv7 Sn+Q== X-Received: by 10.180.100.193 with SMTP id fa1mr13519795wib.16.1406025850863; Tue, 22 Jul 2014 03:44:10 -0700 (PDT) Received: from dhcp-9078.meeting.ietf.org (dhcp-9078.meeting.ietf.org. [31.133.144.120]) by mx.google.com with ESMTPSA id ut2sm2284wjc.49.2014.07.22.03.44.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 03:44:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <53CD939D.5020001@cisco.com> Date: Tue, 22 Jul 2014 06:00:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/61PgjDX_unQCYYwKgXIMJC_hLaI Cc: Olivier MJ Crepin-Leblond , John Curran , Avri Doria , internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 10:44:15 -0000 On Jul 21, 2014, at 6:26 PM, Eliot Lear wrote: > Olivier, >=20 > On 7/21/14, 6:08 PM, Olivier MJ Crepin-Leblond wrote: >> Is there going to also be a study of accountability mechanisms for >> each of the parties administering each parameter space? >=20 > Certainly the community should review our existing model to decide = what > needs to change. But we should be mindful that we do have a = functioning > service, and some principles that were reviewed on this list and > presented in London that do guide us. I also think the proposed = charter > that Andrew put out makes pretty clear what needs to be reviewed. Perhaps I can rephrase Eliot's point by referring back to the previous = discussion of Andrew's proposed charter for the ianaplan activity. It seems that the task at hand is limited to assessing and planning what = needs to change if the NTIA contract with ICANN for the IANA functions = goes away. NTIA today has nothing to do with "accountability mechanisms for each of = the parties administering each parameter space" under IETF policy = management, and touches only a very small handful of general purpose = parameter spaces associated with IETF protocols (DNS and IP). Could you explain why "study[ing]=85accountability mechanisms" of the = rest of the "parties administering each protocol space" is important to = move beyond the current ICANN-NTIA IANA functions contract? I guess I = don't understand what organizations or processes you're proposing to = "study," or to what purpose. thanks, Suzanne From nobody Tue Jul 22 04:30:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512A1A0ACA for ; Tue, 22 Jul 2014 04:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVeuWghfIDYC for ; Tue, 22 Jul 2014 04:30:11 -0700 (PDT) Received: from atl4mhob02.myregisteredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) by ietfa.amsl.com (Postfix) with ESMTP id 56CF91A0ABF for ; Tue, 22 Jul 2014 04:30:11 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6MBU9nc028616 for ; Tue, 22 Jul 2014 07:30:09 -0400 Received: (qmail 25117 invoked by uid 0); 22 Jul 2014 11:30:09 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 22 Jul 2014 11:30:09 -0000 Message-ID: <53CE4B39.1090202@acm.org> Date: Tue, 22 Jul 2014 07:30:01 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> In-Reply-To: <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140722-0, 07/22/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/StjAcX94RifYmsHRns5akahnQHw Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 11:30:13 -0000 On 22-Jul-14 06:00, Suzanne Woolf wrote: > NTIA today has nothing to do with "accountability mechanisms for each > of the parties administering each parameter space" under IETF policy > management, and touches only a very small handful of general purpose > parameter spaces associated with IETF protocols (DNS and IP). I disagree. NTIA provides a giant accountability function. Just about everyone goes running to NTIA whenever something they don't like happens. And the fine folks at NTIA finesse the situation and get things back on the right track. I believe it happens all the time. NTIA are the adults in the room and we better have adequate accountability all around when they step out of their role. avri From nobody Tue Jul 22 04:43:50 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372171A0ACE for ; Tue, 22 Jul 2014 04:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XzGEOguQTgO for ; Tue, 22 Jul 2014 04:43:47 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F15E1A00E8 for ; Tue, 22 Jul 2014 04:43:45 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so224830wib.4 for ; Tue, 22 Jul 2014 04:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fJjKSlQ9zdWXXBoUMjo1AWQxiToUHiTW/CebgQlnCyA=; b=IN4aG6aeEt2ahDGSsudwC/2iZbfk8t9+jYm7V55pUmKppv9FEWZDsU7Fo5Pt5dtZR8 XhNuvnCdLv9Iy4m/RjzaF/dW1IP20Qa3X/2EpNRw66O+qoQmzeIccU44y8VT0YA1z0xJ lDJx+6ycZpzlDTGS6jCw1AXHc0IJrbb2n8eZrlscg/Ppxb0+OQvrK51RV6ZaoRYLt+yP D4eOWLfQyNcb2ss+46yOunWca89r77RpfG5zTvpYGfqKRcxQvd+z8zh1aTZeDWPcw7gP l6zT8SwnJBgej2CgTvQdyiAVaEgPMpiGo6c6VSQ/2MtIStk6XEeSY7y6l/N5UA4+UPyQ bTDg== X-Received: by 10.180.82.97 with SMTP id h1mr13951731wiy.30.1406029422106; Tue, 22 Jul 2014 04:43:42 -0700 (PDT) Received: from dhcp-9078.meeting.ietf.org (dhcp-9078.meeting.ietf.org. [31.133.144.120]) by mx.google.com with ESMTPSA id n8sm53009696wia.19.2014.07.22.04.43.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 04:43:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <53CE4B39.1090202@acm.org> Date: Tue, 22 Jul 2014 07:43:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jJq09PLoVr055wG8W8kKyE_5_QA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 11:43:48 -0000 On Jul 22, 2014, at 7:30 AM, Avri Doria wrote: >=20 >=20 > On 22-Jul-14 06:00, Suzanne Woolf wrote: >> NTIA today has nothing to do with "accountability mechanisms for each >> of the parties administering each parameter space" under IETF policy >> management, and touches only a very small handful of general purpose >> parameter spaces associated with IETF protocols (DNS and IP). >=20 > I disagree. NTIA provides a giant accountability function. >=20 > Just about everyone goes running to NTIA whenever something they don't > like happens. And the fine folks at NTIA finesse the situation and = get > things back on the right track. I believe it happens all the time. Just to be clear: the scope of my remarks was intended to be primarily = on the IETF, as this is the IAB's list and I'm trying to keep to that = focus.=20 Is your assertion that "everyone goes running to NTIA" and that "it = happens all the time" intended to describe the situation regarding the = IETF and the IANA protocol parameter registries? If so, I'm curious how people directly involved in the IETF's = relationship with IANA will respond. As I am not one of those people, = I'll simply confess to being deeply surprised by this assertion if it's = intended to include the IETF and the protocol parameter registries for = which it provides direction to IANA. thanks, Suzanne From nobody Tue Jul 22 04:49:42 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186BF1A0AD5 for ; Tue, 22 Jul 2014 04:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF97zjgq_xRO for ; Tue, 22 Jul 2014 04:49:40 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1231A00FE for ; Tue, 22 Jul 2014 04:49:39 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9YZe-000LQY-VU; Tue, 22 Jul 2014 11:49:39 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18MPjCyJoTZou4qxX2KGv7f Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53CE4B39.1090202@acm.org> Date: Tue, 22 Jul 2014 07:49:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <13B40B76-5D7E-4288-82E3-7162795936C1@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HRrPHVFqBwm8RXyiUjgvlXE22SI Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 11:49:41 -0000 On Jul 22, 2014, at 7:30 AM, Avri Doria wrote: > On 22-Jul-14 06:00, Suzanne Woolf wrote: >> NTIA today has nothing to do with "accountability mechanisms for each >> of the parties administering each parameter space" under IETF policy >> management, and touches only a very small handful of general purpose >> parameter spaces associated with IETF protocols (DNS and IP). > > I disagree. NTIA provides a giant accountability function. > > Just about everyone goes running to NTIA whenever something they don't > like happens. And the fine folks at NTIA finesse the situation and get > things back on the right track. I believe it happens all the time. That might happen with respect to DNS general-purpose identifiers, but such is consequential of ICANN being in all of the roles at once when it comes to DNS (coordination/accountability, policy development, policy administration, registry update, and registry publication), whereas the original blueprint called DNS policy development to be primarily arms-length to ICANN in an independent body. Mash all of those roles together, and you get lots of accountability concerns and opportunities for NTIA involvement. Both the RIRs and IETF operate with policy development external to ICANN; NTIA has not, to my knowledge, ever been involved in "finessing" any issue in those areas. > NTIA are the adults in the room and we better have adequate > accountability all around when they step out of their role. It's worth noting that (for IP addresses and protocol parameters) that we've had that solid accountability via membership structures, long-established use of open/transparent practices, and contractual separation of roles from the IANA since day one, so it would indeed be nice to see some of that sort of progress in the DNS area. Please remember that both the IETF and several of teh Regional Internet registries predate ICANN and have represented "running code" long before the IANA functions contract came into being. Thanks! /John Disclaimer: My views alone. From nobody Tue Jul 22 11:23:46 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53A1A0061 for ; Tue, 22 Jul 2014 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcVKFx_O5jTV for ; Tue, 22 Jul 2014 11:23:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 624411A0004 for ; Tue, 22 Jul 2014 11:23:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6MINJIe017441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 11:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406053413; x=1406139813; bh=dpNOsNgtdSoKOX+dcGZysLUtPsum+u4OzJd06+XcQdU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oUTzDlSwEvCr0irQ70sDy4eLxFHY+7SAuHHogpIr0ty3PNEFD58FMdLbDVPzZ8D7E GTTNvouyoBNA5xUvF+E1rEy8zqJvyHirGkmDt5AcHuy6Myj/1AjiXTS4e7lEhl9pLL 3JNu5KT6b/4L3oGU4GeUgIDF6xtmAtAjg9kRgS1I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406053413; x=1406139813; i=@elandsys.com; bh=dpNOsNgtdSoKOX+dcGZysLUtPsum+u4OzJd06+XcQdU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HLn5hAdp4vv4I3iS3Tod6+1nbdK7iQybXotHzB5vSTYq1d8mCQlG34QYCSItRjw+U A3EI6NzLgsnmX9Gon/PkdVqex57w/1WZ4XTckIQeDEZHDRUC2EybNr4UUxOvlS+s/i j2iAMEToqHpzYocFPbfp4okleCCuIiUnwt704sQI= Message-Id: <6.2.5.6.2.20140722095605.0bfc4d08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 Jul 2014 10:48:02 -0700 To: John Curran , Olivier MJ Crepin-Leblond From: S Moonesamy In-Reply-To: <3683599A-0C7F-4556-9B46-4C41444D0424@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <3683599A-0C7F-4556-9B46-4C41444D0424@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9OaLf2GMRwfZYouSd5EPMIZEfs0 Cc: internetgovtech@iab.org, Avri Doria Subject: [Internetgovtech] Policy aspects (was: Cross community) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:23:43 -0000 Hi John, This comment is unrelated to the transition. At 18:03 21-07-2014, John Curran wrote: >created out of that process. I guess if the IETF were to make a >habit of embedding social policy aspects into its protocol design, >one could argue that its processes and accountability mechanisms >become a valid item to review, but the IETF hasn't historically >been embedding public policy values into its protocol designs... During discussions about protocol design there are instances where the line between the technical aspects and the other aspects not that clear. As an example, I posted a review of a BCP at http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html My personal experience is that it is becoming difficult to determine whether I am straying too far away from the technical aspects during discussions about surveillance. There was an IETF discussion yesterday about an IETF technology and Africa. Someone argued [1] that security is not considered as a high priority in Africa and that it makes sense to do have intermediaries in between the servers and the users. There are technical benefits for having intermediaries. This is where a person would have to decide whether it is appropriate, as part of the design, to allow interception in the protocol. Regards, S. Moonesamy 1. I did not catch the exact words and I could be misinterpreting what was said. From nobody Tue Jul 22 12:14:42 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571A41A0B11 for ; Tue, 22 Jul 2014 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVXEo6-8BY89 for ; Tue, 22 Jul 2014 12:14:37 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6122B1A0364 for ; Tue, 22 Jul 2014 12:14:37 -0700 (PDT) Received: from xarin.arin.net ([192.149.252.135] helo=[192.168.36.160]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9fWE-000CB5-3J; Tue, 22 Jul 2014 19:14:34 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 192.149.252.135 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+FGpHaJXvSmdTuoHcG+GZC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <6.2.5.6.2.20140722095605.0bfc4d08@resistor.net> Date: Tue, 22 Jul 2014 15:14:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <039D96CB-9E34-437D-AF55-2273FC22E9ED@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <3683599A-0C7F-4556-9B46-4C41444D0424@istaff.org> <6.2.5.6.2.20140722095605.0bfc4d08@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/JpvO6mXEQGuD_ddgcQX-reY324M Cc: Olivier MJ Crepin-Leblond , internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Policy aspects (was: Cross community) X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:14:38 -0000 On Jul 22, 2014, at 1:48 PM, S Moonesamy wrote: > During discussions about protocol design there are instances where the = line between the technical aspects and the other aspects not that clear. = =20 Indeed - to the extent that the IETF decides to embed specific public policy positions into protocols being developed, it becomes much easier=20= to argue that it should have some responsibility (and accountability) = for=20 engagement beyond its traditional technical community on such issues. /John Disclaimer: My views alone. From nobody Tue Jul 22 12:51:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7517D1B28A5 for ; Tue, 22 Jul 2014 12:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k5EMdvqRSdk for ; Tue, 22 Jul 2014 12:51:09 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D8A1A0126 for ; Tue, 22 Jul 2014 12:51:08 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so1042476wib.2 for ; Tue, 22 Jul 2014 12:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D5ZBOsJLhbK6K5L+CHt/ubS0wbeiWNRgxmzJZAk5PQ4=; b=BpHeoct5wdTnXbW534NPWrFTYiCgr3QKNzjf853QR69OPH4CrkErknD+1fwbbme5zK w84hUeEQLlgfGzDKJ940gLktgWpJHMqM/72XFthX3gJqNCSK5fBu+ry/YZqsASAqtZy1 JAPIoJTuE4GtfVxsgpOnPc+B5uB4D7G47Mm3udDy7LnCPxzruk9Ldx2YcBOgRLVif3PH +mhzcmsShQenZV7c0nh+HGjD9D9zxVo/8Zmx/FFrgdNk3VC2sSYRX82NHSDDh3k/ZIbl Tak8A1TGuV9iB0urg7kauii+5isF+7oLeA+f/KSdGpIV2JnV9oBChIQ59sYPu6l9hIwQ LJnA== X-Received: by 10.194.86.225 with SMTP id s1mr37360292wjz.21.1406058664863; Tue, 22 Jul 2014 12:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.162.195 with HTTP; Tue, 22 Jul 2014 12:50:34 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140721232728.0cc67788@resistor.net> References: <53CD1E8A.1060804@acm.org> <6.2.5.6.2.20140721232728.0cc67788@resistor.net> From: Seun Ojedeji Date: Tue, 22 Jul 2014 20:50:34 +0100 Message-ID: To: S Moonesamy Content-Type: multipart/alternative; boundary=089e0102fedc40adf404fecd8be8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/h_ASVPCQiy1jhk-xbz65lNLy2oQ Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:51:10 -0000 --089e0102fedc40adf404fecd8be8 Content-Type: text/plain; charset=UTF-8 Hi SM, On Tue, Jul 22, 2014 at 9:20 AM, S Moonesamy wrote: > Hi Seun, > > At 07:30 21-07-2014, Seun Ojedeji wrote: > >> This was one the concern i raised within the number community[1]. The >> thing is the process is trying to be organisaed however the attempt is >> making possibility of getting diverse contribution more complex and less >> probable. >> > > The concern in that message was about the process for the various numbers > communities. It isn't directly related to the protocol parameters > registry. I'll mention that I have previously reviewed numbers-related > requests in IETF drafts. Several persons who have posted on this thread > (and another one) have an interest in names. They didn't mention concerns > about the names side. > > I took a quick look at the proposed charter. According to that document > the coordination group will be acting as a clearinghouse for proposals > about the various IANA Functions. There is already some discussion in the > IETF about the process for the protocol parameter Function. As I am > already familiar with the IETF process I did not consider it as useful to > ask questions about that process at this stage. > > One thing that I found odd is why this discussion is taking place on this > IAB mailing list instead of the venues for the relevant communities. Well you are right about this; i posted here about numbers to qualify the "names" interest. On whether my concern was discussed in relevant community, well can i assume you are also subscribed on that AFRINIC IANA list, as it sure looks like the list is in listening mode ;).[1] The other reason why i do respond on comments that is of interest on any list is because right now there is no global space to discuss the transition process. For instance, the charter which ICG refer to as a draft and say is up for comment does not have a clear process on how they receive comments beyond the 3 communities. The charter indicates that its open and at the same time will receive contribution from the 3 communities; how about those who like to comment on names for instance but belong to the numbers community(it seem like a community based restriction to me). I had thought a global space will be maintained and the ICG will let us know that they are watching the list for comments. This is where I will get blamed for starting the (previous) off-topic > thread. > > Please note that I do not have any concern about the following. The > problem [1] is that the proposed (coordination) charter does not provide > much information about the process. From that document: > (c) Please clarify how the comments will be reviewed. > This is the summary of what i am trying to communicate. Cheers! 1. I have posted my view on the list about the numbers process in engaging its community and Adiel indicated he will check the possibility out with the other RIRs. Will be good to read your view via that medium also. > > Regards, > S. Moonesamy > > 1. I picked the first word that came to my mind. > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --089e0102fedc40adf404fecd8be8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi S= M,
On Tue, Jul 22, 2014 at 9:20 AM, S Moonesamy <sm+ietf@elandsys.co= m> wrote:
Hi Seun,
<= br> At 07:30 21-07-2014, Seun Ojedeji wrote:
This was one the concern i raised within the number community[1]. The thing= is the process is trying to be organisaed however the attempt is making po= ssibility of getting diverse contribution more complex and less probable.

The concern in that message was about the process for the various numbers c= ommunities. =C2=A0It isn't directly related to the protocol parameters = registry. =C2=A0I'll mention that I have previously reviewed numbers-re= lated requests in IETF drafts. =C2=A0Several persons who have posted on thi= s thread (and another one) have an interest in names. =C2=A0They didn't= mention concerns about the names side.

I took a quick look at the proposed charter. =C2=A0According to that docume= nt the coordination group will be acting as a clearinghouse for proposals a= bout the various IANA Functions. =C2=A0There is already some discussion in = the IETF about the process for the protocol parameter Function. =C2=A0As I = am already familiar with the IETF process I did not consider it as useful t= o ask questions about that process at this stage.

One thing that I found odd is why this discussion is taking place on this I= AB mailing list instead of the venues for the relevant communities.

Well you are right about this; i posted here abou= t numbers to qualify the "names" interest. On whether my concern = was discussed in relevant community, well can i assume you are also subscri= bed on that AFRINIC IANA list, as it sure looks like the list is in listeni= ng mode ;).[1] The other reason why i do respond on comments that is of int= erest on any list is because right now there is no global space to discuss = the transition process. For instance, the charter which ICG refer to as a d= raft and say is up for comment does not have a clear process on how they re= ceive comments beyond the 3 communities. The charter indicates that its ope= n and at the same time will receive contribution from the 3 communities; ho= w about those who like to comment on names for instance but belong to the n= umbers community(it seem like a community based restriction to me). I had t= hought a global space will be maintained and the ICG will let us know that = they are watching the list for comments.

=C2=A0This is w= here I will get blamed for starting the (previous) off-topic thread.

Please note that I do not have any concern about the following. =C2=A0The p= roblem [1] is that the proposed (coordination) charter does not provide muc= h information about the process. =C2=A0From that document:
=C2=A0
=C2=A0 (c) Please clarify how the comments will be reviewed.

This is the summary of what i am trying to communicat= e.

Cheers!
1. I have posted my view on th= e list about the numbers process in engaging its community and Adiel indica= ted he will check the possibility out with the other RIRs. Will be good to = read your view via that medium also.

Regards,
S. Moonesamy

1. I picked the first word that came to my mind.



--
------= ------------------------------------------------------------------
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--089e0102fedc40adf404fecd8be8-- From nobody Tue Jul 22 17:43:34 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B047E1A00FC for ; Tue, 22 Jul 2014 17:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw00mH6vEaE0 for ; Tue, 22 Jul 2014 17:43:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB631A0066 for ; Tue, 22 Jul 2014 17:43:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6N0hDc2020644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 17:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406076205; x=1406162605; bh=8qhcAhPMBs1xbBy9Qnf7/3AGOc4BcFxsEXDdIXy0MYg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EKik3iix1McxPn9kar4DUqQcdmNz4RqWY+2Pkz7CurXjS/wzSaYTbybIGLa9stxG4 DVwUcvDEih1ZmXzI16HrsEAI83EG8qGWvFps50cIRZRzC8OwrFNinzlDMPBFxYLIRF ia1001KIERkGRTDg9b+LBFa2XiRbEOhl+BYYJ8FE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406076205; x=1406162605; i=@elandsys.com; bh=8qhcAhPMBs1xbBy9Qnf7/3AGOc4BcFxsEXDdIXy0MYg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ic6kY1wc0Hvi6h5hNhJKWiLk6DuSfhEumg1zKqhEnEixy9TVPBOFmrD0w57n0AplD 2ElwICLdo0k+Qxw2Kc1suNgW9JRRcOs8cbIPdcZ4dHqvumbXQhiOq2iTaocWZHkdnq VE2cEORrxE69Y5D36Xno/+/803UU9ckQWqp2iUHY= Message-Id: <6.2.5.6.2.20140722143525.0c0363d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 Jul 2014 16:58:18 -0700 To: Seun Ojedeji From: S Moonesamy In-Reply-To: References: <53CD1E8A.1060804@acm.org> <6.2.5.6.2.20140721232728.0cc67788@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/O_yGeLq0Bwbk2CKW_505AI8R8V0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 00:43:33 -0000 Hi Seun, At 12:50 22-07-2014, Seun Ojedeji wrote: >Well you are right about this; i posted here about numbers to >qualify the "names" interest. On whether my concern was discussed in >relevant community, well can i assume you are also subscribed on >that AFRINIC IANA list, as it sure looks like the list is in >listening mode ;).[1] The other reason why i do respond on comments >that is of interest That assumption is correct. :-) > on any list is because right now there is no global space to > discuss the transition process. For instance, the charter which ICG > refer to as a draft and say is up for > comment does not have a clear process on how they receive comments > beyond the 3 communities. The charter indicates that its open and > at the same time will receive contribution from the 3 communities; > how about those who like to comment on names for instance but > belong to the numbers community(it seem like a community based > restriction to me). I had thought a global space will be maintained > and the ICG will let us know that they are watching the list for comments. According to a stewardship transition document there are 13 communities: ASO, ICC/BASIS, ISOC, NRO, IETF, IAB, SSAC, RSSAC, ALAC, GAC, GSNO, gTLD Registries and ccNSO. The draft charter mentions that the Functions are divided into three main categories. It looks like the theory of those who came up with the plan is that a person will be able to find a representative in one of those communities to represent his or her interests. The draft charter also mentions that there are relevant community processes and it says that the coordination group may refer input it receives to the relevant community discussion. Let's assume that you belong to the numbers community and you have an interest in names. I guess that you could contact a representative from https://www.icann.org/resources/pages/coordination-group-2014-06-17-en for advice. >1. I have posted my view on the list about the numbers process in >engaging its community and Adiel indicated he will check the >possibility out with the other RIRs. Will be good to read your view >via that medium also. One definition of conflict of interest is "when a person has separate duties to act in the best interest of two or more clients in relation to the same or related matter, and those duties conflict, or there is a significant risk that those duties may conflict". I would be increasing the risk by getting involved in a discussion about the numbers process. Regards, S. Moonesamy From nobody Tue Jul 22 18:13:02 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CA91A0092 for ; Tue, 22 Jul 2014 18:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8WtpE9H4Lbl for ; Tue, 22 Jul 2014 18:12:58 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7831A0012 for ; Tue, 22 Jul 2014 18:12:58 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9l73-000J8Z-0q; Wed, 23 Jul 2014 01:12:57 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19WWcwDnoos61PG+LXtdVXr Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <6.2.5.6.2.20140722143525.0c0363d8@elandnews.com> Date: Tue, 22 Jul 2014 21:12:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3768DA89-A937-4A8A-8412-002C7C4374AA@istaff.org> References: <53CD1E8A.1060804@acm.org> <6.2.5.6.2.20140721232728.0cc67788@resistor.net> <6.2.5.6.2.20140722143525.0c0363d8@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZCnQ5_THTruAAHgzNWst5FgjpxY Cc: internetgovtech@iab.org, Seun Ojedeji Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 01:13:00 -0000 On Jul 22, 2014, at 7:58 PM, S Moonesamy wrote: > According to a stewardship transition document there are 13 = communities: ASO, ICC/BASIS, ISOC, NRO, IETF, IAB, SSAC, RSSAC, ALAC, = GAC, GSNO, gTLD Registries and ccNSO. The draft charter mentions that = the Functions are divided into three main categories. =20 ... > It looks like the theory of those who came up with the plan is that a = person will be able to find a representative in one of those communities = to represent his or her interests. I don't see anything to support that theory in any of the materials; as I understand it, the coordinating group acts as liaisons for the solicitation of proposals, assembly of a complete proposal, and the=20 related communications. =20 > The draft charter also mentions that there are relevant community = processes and it says that the coordination group may refer input it = receives to the relevant community discussion. Relevant community processes are mentioned in the materials, so I=20 imagine that will mean processes in each of the communities to come up with various proposals. Contacting a representative makes sense, but not to carry your views as much as find our the process in that community for participating and sharing your views therein. > Let's assume that you belong to the numbers community and you have an = interest in names. I guess that you could contact a representative from = https://www.icann.org/resources/pages/coordination-group-2014-06-17-en = for advice. That's probably a fine starting point, but it would be even better if=20 there were processes for each of the various communities to work on=20 proposals. You could then get involved in each of the communities that you felt you had interest in. > One definition of conflict of interest is "when a person has separate = duties to act in the best interest of two or more clients in relation to = the same or related matter, and those duties conflict, or there is a = significant risk that those duties may conflict". I would be increasing = the risk by getting involved in a discussion about the numbers process. Strange; many folks that I know are involved in multiple communities, and I'd expect to see them involved in each of the processes to the=20 extent that they are interested in such... This is no different than regular participants in IETF working groups; they participate as=20 individuals (not representatives of any particular community) and=20 their ideas are evaluated on merit rather than origin or imprimatur.=20 I can understand a concern in clarity of participation by those on=20 the ITG, but I do not know why it would be an issue for anyone else, (unless they somehow have been given a duty to formally represent=20 one of these communities) /John Disclaimer: My views alone. From nobody Tue Jul 22 22:19:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED031B289E for ; Tue, 22 Jul 2014 22:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id malSegag0HgR for ; Tue, 22 Jul 2014 22:19:03 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28921B28E6 for ; Tue, 22 Jul 2014 22:19:03 -0700 (PDT) Received: from [192.168.1.65] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 1AB2C22BE5; Wed, 23 Jul 2014 07:19:01 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_098ED299-3E17-4D90-8D1A-01FEEDFE6324"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3768DA89-A937-4A8A-8412-002C7C4374AA@istaff.org> Date: Wed, 23 Jul 2014 07:18:59 +0200 Message-Id: <08184EFF-581F-4EC9-9D67-BBF15B13953D@frobbit.se> References: <53CD1E8A.1060804@acm.org> <6.2.5.6.2.20140721232728.0cc67788@resistor.net> <6.2.5.6.2.20140722143525.0c0363d8@elandnews.com> <3768DA89-A937-4A8A-8412-002C7C4374AA@istaff.org> To: John Curran X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/f9edz29Rhqm3SUhGpKG3-Xz3U18 Cc: internetgovtech@iab.org, Seun Ojedeji , S Moonesamy Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 05:19:05 -0000 --Apple-Mail=_098ED299-3E17-4D90-8D1A-01FEEDFE6324 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 jul 2014, at 03:12, John Curran wrote: >> Let's assume that you belong to the numbers community and you have an = interest in names. I guess that you could contact a representative from = https://www.icann.org/resources/pages/coordination-group-2014-06-17-en = for advice. >=20 > That's probably a fine starting point, but it would be even better if=20= > there were processes for each of the various communities to work on=20 > proposals. You could then get involved in each of the communities = that > you felt you had interest in. This is btw also what (we in) the Coordination Group encourage. =46rom our statement = : > We encourage all interested parties to engage early and often in the = community discussions now underway. Patrik --Apple-Mail=_098ED299-3E17-4D90-8D1A-01FEEDFE6324 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTz0XDrMabGguI180RAv3SAJ9P8TgI7BQAo5D/2AEYgkytEd7lywCfbTv3 30eSETbLGAFHaNgZZpuCA+s= =gwHw -----END PGP SIGNATURE----- --Apple-Mail=_098ED299-3E17-4D90-8D1A-01FEEDFE6324-- From nobody Wed Jul 23 01:36:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F611A0266 for ; Wed, 23 Jul 2014 01:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8XywMwg7zt9 for ; Wed, 23 Jul 2014 01:36:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C26781A0198 for ; Wed, 23 Jul 2014 01:36:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6N8a5xN019281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 01:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406104579; x=1406190979; bh=UcOzkOXgeO6CM78N0yZIkIRZHvUTZgXCGbSqjfljQGY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f+3aVD2ESil3zYuton4k9s4gWpif2ERy4gXHR6fNQwuqvpnB7xVl/VTTF2ma3KFHl AR/5xYU9Ry5Gf5MOrfnpmM/KC33k6XXLrQOZL5naMlssSP46qA27OzM4pABeu86aV6 why3CbPj+uXsO9j/47USH90IIuPchcgUzCXnllqY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406104579; x=1406190979; i=@elandsys.com; bh=UcOzkOXgeO6CM78N0yZIkIRZHvUTZgXCGbSqjfljQGY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ayMd6RZTjvG/LHIjxD5isntP5/w1XlwpYTkaiqeZb3pyYzOnlo5r2DSTCBZLKh1Oa KitS5/UtwBaSXaxULg3WxBMarXQwUQH2QxZrcx7jDM35zLPoutk3r6iBT7siQ1BJS7 BB0YvMKUnH1pxPmAGETq1CnW18BtervV+SfLbEko= Message-Id: <6.2.5.6.2.20140722211518.0c10faf8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 23 Jul 2014 00:19:55 -0700 To: John Curran From: S Moonesamy In-Reply-To: <3768DA89-A937-4A8A-8412-002C7C4374AA@istaff.org> References: <53CD1E8A.1060804@acm.org> <6.2.5.6.2.20140721232728.0cc67788@resistor.net> <6.2.5.6.2.20140722143525.0c0363d8@elandnews.com> <3768DA89-A937-4A8A-8412-002C7C4374AA@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/XkVRtyQEBkEeZGypZlFteQ-R-v4 Cc: internetgovtech@iab.org, Seun Ojedeji Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 08:36:27 -0000 Hi John, At 18:12 22-07-2014, John Curran wrote: >I don't see anything to support that theory in any of the materials; >as I understand it, the coordinating group acts as liaisons for the >solicitation of proposals, assembly of a complete proposal, and the >related communications. Ok. >Relevant community processes are mentioned in the materials, so I >imagine that will mean processes in each of the communities to come >up with various proposals. Contacting a representative makes sense, >but not to carry your views as much as find our the process in that >community for participating and sharing your views therein. Ok. >That's probably a fine starting point, but it would be even better if >there were processes for each of the various communities to work on >proposals. You could then get involved in each of the communities that >you felt you had interest in. Ok. I prefer not to be involved in discussions about the transition in the other communities as the issues are too controversial. >Strange; many folks that I know are involved in multiple communities, >and I'd expect to see them involved in each of the processes to the >extent that they are interested in such... This is no different than >regular participants in IETF working groups; they participate as >individuals (not representatives of any particular community) and >their ideas are evaluated on merit rather than origin or imprimatur. I'll comment about the second sentence (above). I have participated in several IETF working groups in several Areas; I am the only person from my region who used to send Last Call comments to ietf@ietf.org. My personal experience has been that I was held to a higher standard compared to other regular participants. I don't wish that newcomers, irrespective of origin, go through the same experience as I did. >I can understand a concern in clarity of participation by those on >the ITG, but I do not know why it would be an issue for anyone else, >(unless they somehow have been given a duty to formally represent >one of these communities) It is a personal decision. I'll cite some words from the Supreme Court of Texas: "The needs of the many outweigh ... the needs of the few" I don't know the right answer for the above. I do know that there are three words missing in the above [1][2]. Regards, S. Moonesamy 1. http://www.youtube.com/watch?v=MhRmlV0aaDg 2. http://www.youtube.com/watch?v=dhcR-w-56tA From nobody Wed Jul 23 13:10:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55461A0537 for ; Wed, 23 Jul 2014 13:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iteu1ynr__m for ; Wed, 23 Jul 2014 13:10:31 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2a00:19e8:10:5::b]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B320D1A01D9 for ; Wed, 23 Jul 2014 13:10:30 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 1DBDD18F3CF for ; Wed, 23 Jul 2014 21:10:28 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=CJgSCWcXk b3KofpLIp/4fnSiRe0=; b=c1tt/BbU+sFvD/zAL2giJpKRXmsEfPCT2JNr+GWpI Rm7It2iJQhBOZu6kJih6P4L8tm92iDuqKNPtWuqu5n+QmUJyEJH62bPQCG4hPoz9 ESEwE+FRgNrvYZv39y5y85dkWp2YASEqkgo5OqeY9+FBNWFnWetZ0VjdQIplw9aa LA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=SQ9 pC1ZLlvAIFstDw4jKMXZF8EtVNzd1G8gLMv1fY+87fqhh4rQ77hvp6Fl1fI6Rkgh LPxBfHOIcBVUQOcCwaBSGO3Fx20X+4O1mc8R1f0foX4EMCiszwqlJMlTZboq8v6d 3pLXP4d/bfJxY7GYl5c4mkoxB2hn/KrfZM1fwHzM= Received: from [IPv6:2a02:120b:2c79:4e00:7809:205f:c01e:19bd] (unknown [IPv6:2a02:120b:2c79:4e00:7809:205f:c01e:19bd]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 835DD18F3CE for ; Wed, 23 Jul 2014 21:10:27 +0100 (BST) Message-ID: <53D016B6.2020000@gih.com> Date: Wed, 23 Jul 2014 22:10:30 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> In-Reply-To: <53CE4B39.1090202@acm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ublr6IR7i4MXFHJIOFBydJXnPOQ Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:10:33 -0000 I'd just like to register my agreement with Avri on this. Please be so kind to review the table in this document: https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr14-en.pdf I clearly points to new accountability mechanisms needed for *all* functions. Kindest regards, Olivier (own views) On 22/07/2014 13:30, Avri Doria wrote: > > On 22-Jul-14 06:00, Suzanne Woolf wrote: >> NTIA today has nothing to do with "accountability mechanisms for each >> of the parties administering each parameter space" under IETF policy >> management, and touches only a very small handful of general purpose >> parameter spaces associated with IETF protocols (DNS and IP). > I disagree. NTIA provides a giant accountability function. > > Just about everyone goes running to NTIA whenever something they don't > like happens. And the fine folks at NTIA finesse the situation and get > things back on the right track. I believe it happens all the time. > > NTIA are the adults in the room and we better have adequate > accountability all around when they step out of their role. > > avri > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > From nobody Wed Jul 23 13:43:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91BA1B2AE8 for ; Wed, 23 Jul 2014 13:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd-k8On82U9m for ; Wed, 23 Jul 2014 13:43:20 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0C01A03A8 for ; Wed, 23 Jul 2014 13:43:19 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so1747834wgg.0 for ; Wed, 23 Jul 2014 13:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pqPMjwjVRgFqGAP4qdXegykiAoRLHmcE2PZYxbCBrik=; b=D8Mqgs2DA/wZ9kyijX3Vo87cY9rEO2GAIBg0Gv9dZh4QfjMLiCufV50Sa9jCcMVp64 drVmYaCS446O4cz+HPjxv3Hp4W/HgvFHpka9SfG4/aVvjjl5PtBOo4Mnnclah2Cwq++S 0n07ECyJOVtgi841oYAna/YhcISkdr7FPWUQ8+qQKprB9vMzDEV2UfsvUz00CEJ1McT/ cvP+pvkMqQYn1LsT/MQOcovK71BH/y2jqGw5BgaEdzPsi7g6bkA01XA8fUiwpPLgB01O hNl8/n7O15nON+d11BwPHwVHFyHriJCAYamR3WS4Ibq1mi1BPeRh1nTOR+qwDNjl1v9Y 9xiA== X-Received: by 10.181.9.104 with SMTP id dr8mr6684424wid.26.1406148198403; Wed, 23 Jul 2014 13:43:18 -0700 (PDT) Received: from [31.133.177.122] (dhcp-b17a.meeting.ietf.org. [31.133.177.122]) by mx.google.com with ESMTPSA id xn12sm13647857wib.13.2014.07.23.13.43.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:43:17 -0700 (PDT) Message-ID: <53D01E6B.8020606@gmail.com> Date: Thu, 24 Jul 2014 08:43:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Olivier MJ Crepin-Leblond References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> In-Reply-To: <53D016B6.2020000@gih.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/rVMBopfMLfsbjIndl1TArtyzQP0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:43:21 -0000 Olivier, On 24/07/2014 08:10, Olivier MJ Crepin-Leblond wrote: > I'd just like to register my agreement with Avri on this. > > Please be so kind to review the table in this document: > https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr14-en.pdf > > I clearly points to new accountability mechanisms needed for *all* > functions. It would be absurd to define new mechanisms if the existing ones are fully satisfactory. Brian > > Kindest regards, > > Olivier > (own views) > > On 22/07/2014 13:30, Avri Doria wrote: >> On 22-Jul-14 06:00, Suzanne Woolf wrote: >>> NTIA today has nothing to do with "accountability mechanisms for each >>> of the parties administering each parameter space" under IETF policy >>> management, and touches only a very small handful of general purpose >>> parameter spaces associated with IETF protocols (DNS and IP). >> I disagree. NTIA provides a giant accountability function. >> >> Just about everyone goes running to NTIA whenever something they don't >> like happens. And the fine folks at NTIA finesse the situation and get >> things back on the right track. I believe it happens all the time. >> >> NTIA are the adults in the room and we better have adequate >> accountability all around when they step out of their role. >> >> avri >> >> _______________________________________________ >> Internetgovtech mailing list >> Internetgovtech@iab.org >> https://www.iab.org/mailman/listinfo/internetgovtech >> > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > From nobody Wed Jul 23 13:56:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D44D1B2B7F for ; Wed, 23 Jul 2014 13:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuCf5uQL-m0s for ; Wed, 23 Jul 2014 13:56:16 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1671A035A for ; Wed, 23 Jul 2014 13:56:16 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XA3aB-000C5M-IM; Wed, 23 Jul 2014 20:56:15 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/3sjUD4eVEAUPAbia2Z6pD Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53D016B6.2020000@gih.com> Date: Wed, 23 Jul 2014 16:56:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96042C9F-CFBD-434D-990D-F931DEA587AB@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> To: Olivier MJ Crepin-Leblond X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RK1rg4wllDkiVqP7IDfZJnbxb5s Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:56:18 -0000 On Jul 23, 2014, at 4:10 PM, Olivier MJ Crepin-Leblond = wrote: > I'd just like to register my agreement with Avri on this. >=20 > Please be so kind to review the table in this document: > = https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr1= 4-en.pdf >=20 > I clearly points to new accountability mechanisms needed for *all* > functions. The scoping document calls for "defining accountability mechanisms=20 that would serve to replace the current stewardship role played by=20 NTIA to ensure ICANN=92s performance of the IANA functions based on=20 the agreements and/or policies provided by the respective bodies=20 (IETF, GNSO, RIRs, ASO, ccTLDs, ccNSO)." In short, before one can meaningfully define any "new accountability=20 mechanisms" with respect to protocol parameters or IP addresses that would "replace the current stewardship role played by NTIA", you'll first want to confirm that there is an operative NTIA stewardship=20 role in these spaces to be replaced, i.e., some NTIA accountability=20 mechanisms aside from the referenced agreements with the IAB & RIRs. Otherwise, you stand to risk replacing the existing, well-functioning IANA accountability mechanisms to these communities with something=20 "new" and hence by definition unproven. Thanks! /John Disclaimer: My views alone. From nobody Wed Jul 23 14:15:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12761A0270 for ; Wed, 23 Jul 2014 14:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRNAqK-LMvNe for ; Wed, 23 Jul 2014 14:15:34 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB8BC1A00F9 for ; Wed, 23 Jul 2014 14:15:33 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6NLFWS2031629 for ; Wed, 23 Jul 2014 17:15:32 -0400 Received: (qmail 5319 invoked by uid 0); 23 Jul 2014 21:15:32 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 23 Jul 2014 21:15:32 -0000 Message-ID: <53D025F3.5050708@acm.org> Date: Wed, 23 Jul 2014 17:15:31 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> In-Reply-To: <53D01E6B.8020606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140722-1, 07/22/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pPBET32CV80Uah4GHQpOE9n1gN4 Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:15:35 -0000 Hi, On 23-Jul-14 16:43, Brian E Carpenter wrote: > It would be absurd to define new mechanisms if the existing ones are > fully satisfactory. ah the old 'if it ain't broke' conundrum. Thing is, while it is not broken for some, it is broken for others. For me, as an example at this point, I see breakage on things like the self established ability of the IETF to unilaterally decide that a protocol mandates removing labels from the list of available TLD labels. As a long time participant in the IETF, I see how natural this decision is for the the IETF and a part of me cheers at the simplicity of this solution for any number of issues. As a member of the ICANN GNSO Council I am outraged at the idea because it is a policy decision that the technical arm of the enterprise has no business making. To whom is the IETF accountable in making this decision? Just itself? This is breakage. Likewise if ICANN were to start making technical decisions and deciding to use protocols designed in places other than the IETF, or where to just start modifying IETF protocols without any consideration of IETF perogative of change control, I expect many in this group would be outraged. To whom is ICANN accountable in making this decisions? Just itself? (yes there are liaisons and that is part of the accountability structure, but it too exists between the silos being defined by the ICG) If we have no common accountability mechanisms, each of the groups can do what it pleases willy nilly without any support or buy in by other stakeholders. I am sure others from outside of the IETF and ICANN bubbles can come up with other scenarios where the policy decision made in the act of deciding between protocol trades off do not take sufficient account of the concerns of users or others. Though rarely if ever exercised, there is a current point of common accountability where everyone could run to. It is needed and I can't see how this process will get global buy in without one. If ain't broke ... doesn't work for most of the world, because most of the world see breakage, even if insiders normally don't. avri From nobody Wed Jul 23 14:24:56 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCC31A0AAA for ; Wed, 23 Jul 2014 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGPfVofeJzLx for ; Wed, 23 Jul 2014 14:24:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57BC1A038E for ; Wed, 23 Jul 2014 14:24:52 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so8513874wiw.12 for ; Wed, 23 Jul 2014 14:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=e30CWLBmjNwLicGwfTIIHiq0FlkGVTxWVhyJepXF4cg=; b=zySZQFI2lgPoUbci1AQTq3XMsbRitzhGvUX0i70pHGp03cBW4CtyFpHoD7YqSiRmvP L0Pme7ACLDwo9UE0RZtC4Ffg2izJAbTWiLhc7av1NisBvviiuhZZqt/J8d5HwZMN/F1i XHzgowiEo8NQyXSAnOIs2SwDvGhEUj45Q8IdS/eywEekjt24478xFZl54g+3SXPC//Or FAF5/hCsMT7BHvnNesShXf0f4p9ef9VFAkasKGmUTPJ3Hu772TW7YKRcarnrEQ1VutNN +kk97CrntCxzmrJppE/BOGEbMyLNE6BDOKNCUZEM0j2f65mko4krQISvq0r2XIIpb83H 2J6A== X-Received: by 10.180.85.101 with SMTP id g5mr28792289wiz.51.1406150690628; Wed, 23 Jul 2014 14:24:50 -0700 (PDT) Received: from [31.133.177.122] (dhcp-b17a.meeting.ietf.org. [31.133.177.122]) by mx.google.com with ESMTPSA id 20sm9520576wjt.42.2014.07.23.14.24.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 14:24:49 -0700 (PDT) Message-ID: <53D02828.1030805@gmail.com> Date: Thu, 24 Jul 2014 09:24:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Avri Doria References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> In-Reply-To: <53D025F3.5050708@acm.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3c_KNgvQCvEPv_wgXuFL3ouDvyo Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:24:54 -0000 On 24/07/2014 09:15, Avri Doria wrote: > Hi, > > On 23-Jul-14 16:43, Brian E Carpenter wrote: >> It would be absurd to define new mechanisms if the existing ones are >> fully satisfactory. > > ah the old 'if it ain't broke' conundrum. > > Thing is, while it is not broken for some, it is broken for others. > > For me, as an example at this point, I see breakage on things like the > self established ability of the IETF to unilaterally decide that a > protocol mandates removing labels from the list of available TLD labels. Can you be specific, since I really don't what you mean? > > As a long time participant in the IETF, I see how natural this decision > is for the the IETF and a part of me cheers at the simplicity of this > solution for any number of issues. > > As a member of the ICANN GNSO Council I am outraged at the idea because > it is a policy decision that the technical arm of the enterprise has no > business making. > > To whom is the IETF accountable in making this decision? Just itself? What does that have to do with ICANN or IANA accountability? Brian From nobody Wed Jul 23 14:47:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74471A030B for ; Wed, 23 Jul 2014 14:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwQIjAOIKgsH for ; Wed, 23 Jul 2014 14:47:02 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id C4FDA1A016F for ; Wed, 23 Jul 2014 14:47:01 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6NLl0KY016714 for ; Wed, 23 Jul 2014 17:47:00 -0400 Received: (qmail 1469 invoked by uid 0); 23 Jul 2014 21:47:00 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 23 Jul 2014 21:47:00 -0000 Message-ID: <53D02D53.6070501@acm.org> Date: Wed, 23 Jul 2014 17:46:59 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> In-Reply-To: <53D02828.1030805@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140722-1, 07/22/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/hyyII2dkOXLOREenv99seWho90c Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:47:03 -0000 Hi, On 23-Jul-14 17:24, Brian E Carpenter wrote: > On 24/07/2014 09:15, Avri Doria wrote: >> Hi, >> >> On 23-Jul-14 16:43, Brian E Carpenter wrote: >>> It would be absurd to define new mechanisms if the existing ones are >>> fully satisfactory. >> >> ah the old 'if it ain't broke' conundrum. >> >> Thing is, while it is not broken for some, it is broken for others. >> >> For me, as an example at this point, I see breakage on things like the >> self established ability of the IETF to unilaterally decide that a >> protocol mandates removing labels from the list of available TLD labels. > > Can you be specific, since I really don't what you mean? > RFC 6761 Special Use Domain Names https://tools.ietf.org/html/rfc6761 Allows for protocol that meet certain conditions to reserve TLDs. >> >> As a long time participant in the IETF, I see how natural this decision >> is for the the IETF and a part of me cheers at the simplicity of this >> solution for any number of issues. >> >> As a member of the ICANN GNSO Council I am outraged at the idea because >> it is a policy decision that the technical arm of the enterprise has no >> business making. >> >> To whom is the IETF accountable in making this decision? Just itself? > > What does that have to do with ICANN or IANA accountability? Well this and IETF act with regard to IANA entries in a area where ICANN might think it get a say. To whom is IANA accountable in making the reservation? the IETF. But ICANN is responsible for policy regarding TLDs. It gets to tell IANA what to do with TLDs. It seems to me that it is what could be called a cross-accountabilty example. IETF 'quite rightly' says it controls protocol parameters and it can do what it pleases with them despite any policy implications that may occur that it may or may not have considered. It tells IANA to make these changes. IANA arrangements with IETF says do what IETF says. As long as we stick to a single point of accountability for each function we have no way out of this problem. I therefore argue that there has to be accountability mechanisms that cross the 'jurisdictions'. And this is but one simple issue. avri From nobody Wed Jul 23 14:47:25 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E711B28B2 for ; Wed, 23 Jul 2014 14:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BiJ1jrz8qYz for ; Wed, 23 Jul 2014 14:47:24 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066CD1A0364 for ; Wed, 23 Jul 2014 14:47:24 -0700 (PDT) Received: from 21.104.14.81.rev.sfr.net ([81.14.104.21]:49555 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XA4Nf-0006QY-73; Wed, 23 Jul 2014 14:47:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Jul 2014 23:44:05 +0200 To: Avri Doria ,internetgovtech@iab.org From: JFC Morfin In-Reply-To: <53D025F3.5050708@acm.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RxuY_HPiK8blaSr9maM2Ro9LSZo Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:47:24 -0000 At 23:15 23/07/2014, Avri Doria wrote: >As a member of the ICANN GNSO Council I am outraged at the idea because >it is a policy decision that the technical arm of the enterprise has no >business making. > >To whom is the IETF accountable in making this decision? Just itself? > >This is breakage. This is the "BUG": as "Being Unillateraly Global". If this might be the way global communities (cf. RFC 6852) under influence may work, this is not the way the real world does. The IETF proposes its way to run the digisphere. ICANN to govern it. There are billions of others in a "people centered" information society. Sorry jfc From nobody Wed Jul 23 14:54:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B731B28B2 for ; Wed, 23 Jul 2014 14:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR-N_sAFYD9N for ; Wed, 23 Jul 2014 14:54:04 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4D71B2833 for ; Wed, 23 Jul 2014 14:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1797; q=dns/txt; s=iport; t=1406152444; x=1407362044; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=h6LXR/7VPHe/3S+5DoZgpnh8bYHmvJxSoYuHYCUZzCY=; b=ZjVfAQu0LSDmz7SWxVRR4QQuHqsmWcL2lYBp6TZ+h1SEVw4KAiDSiTBB QzwBnoPeOhNSIzw8NrOuCmYkBMeuoWmlwAI0RC+cVhqh3dpoGdoT9HfOG FHmXTeHun39RMKSBWZ4BiPBKwmX+6aI1YUVvIRaiakKzOmao7oeRU3N2M M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAOct0FNIo8UY/2dsb2JhbABZhy/NfQGBIXaEAwEBAQMBI1URCxgCAgUMCgsCAgkDAgECAUUGAQwIAQEQB4gfCKh0l1YXgSyOJgqCboFOAQSbLYcdjSODZCE X-IronPort-AV: E=Sophos;i="5.01,720,1400025600"; d="scan'208";a="43189664" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 23 Jul 2014 21:53:58 +0000 Received: from [10.86.253.44] ([10.86.253.44]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NLrtLq012343; Wed, 23 Jul 2014 21:53:56 GMT Message-ID: <53D02EF2.7030703@cisco.com> Date: Wed, 23 Jul 2014 17:53:54 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Avri Doria , internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> In-Reply-To: <53D025F3.5050708@acm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/iDXRO5VmO7trZHqVkiZef3h2bwM Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:54:05 -0000 Hi Avri, On 7/23/14, 5:15 PM, Avri Doria wrote: > Hi, > > On 23-Jul-14 16:43, Brian E Carpenter wrote: >> It would be absurd to define new mechanisms if the existing ones are >> fully satisfactory. > ah the old 'if it ain't broke' conundrum. > > Thing is, while it is not broken for some, it is broken for others. > > For me, as an example at this point, I see breakage on things like the > self established ability of the IETF to unilaterally decide that a > protocol mandates removing labels from the list of available TLD labels. "Unilaterally" implies that somehow the community isn't involved in the decision. > > As a long time participant in the IETF, I see how natural this decision > is for the the IETF and a part of me cheers at the simplicity of this > solution for any number of issues. > > As a member of the ICANN GNSO Council I am outraged at the idea because > it is a policy decision that the technical arm of the enterprise has no > business making. > > To whom is the IETF accountable in making this decision? Just itself? The community and through its leadership through the NOMCOM process, which also takes into account community views. But to be specific, when the IETF steps in and reserves a name, it should do so only to avoid technical breakage. Can you provide an example where the IETF got involved where that wasn't the case? Also, did you appeal any decision the IESG took in this regard? > > This is breakage. What would be breakage would be if the IETF entered such a debate without technical ground or if the IETF *didn't* enter the debate when there was technical breakage at risk. But even if the example you cited was broken, we have an appropriate means to fix it, complete with accountability. Eliot From nobody Wed Jul 23 15:04:24 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28B81B28A8 for ; Wed, 23 Jul 2014 15:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK1kIJfDjsuJ for ; Wed, 23 Jul 2014 15:04:21 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 88F5F1B27D3 for ; Wed, 23 Jul 2014 15:04:21 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4E6C8F240DC; Wed, 23 Jul 2014 18:04:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id JgnsNfwLwPsU; Wed, 23 Jul 2014 18:03:50 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 75D4AF240DD; Wed, 23 Jul 2014 18:03:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <53D025F3.5050708@acm.org> Date: Wed, 23 Jul 2014 18:03:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B4A9C47-A070-40EA-862E-B626CB193424@vigilsec.com> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/MGVAtTLBOKRSeXwocCuLff3lCq8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:04:23 -0000 Avri: > For me, as an example at this point, I see breakage on things like the > self established ability of the IETF to unilaterally decide that a > protocol mandates removing labels from the list of available TLD = labels. >=20 > As a long time participant in the IETF, I see how natural this = decision > is for the the IETF and a part of me cheers at the simplicity of this > solution for any number of issues. >=20 > As a member of the ICANN GNSO Council I am outraged at the idea = because > it is a policy decision that the technical arm of the enterprise has = no > business making. I cannot imagine such a thing happening without coordination. There was = coordination before ".local" was selected by the technical community. = The coordination turned out to be straightforward because ".local" was = on the list that ICANN was not allowed to use. I'd like to see a process for this coordination written down, but I am = not worried about "unilateral" decisions. Russ= From nobody Wed Jul 23 15:16:09 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3B1B27D3 for ; Wed, 23 Jul 2014 15:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APN17cagMidj for ; Wed, 23 Jul 2014 15:16:08 -0700 (PDT) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBBE1B27B2 for ; Wed, 23 Jul 2014 15:16:08 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6NMG7aR022456 for ; Wed, 23 Jul 2014 18:16:07 -0400 Received: (qmail 7268 invoked by uid 0); 23 Jul 2014 22:16:07 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 23 Jul 2014 22:16:06 -0000 Message-ID: <53D03426.6030400@acm.org> Date: Wed, 23 Jul 2014 18:16:06 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02EF2.7030703@cisco.com> In-Reply-To: <53D02EF2.7030703@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140722-1, 07/22/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/82Q_CKdzOF5AlfTaaKqLNbr_6ro Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:16:09 -0000 Hi, (Please remember I am only discussing this issue as an example) Yes, there are internal IETF mechanisms. And no I did not object, though I do remember thinking it was an entertaining work around to ICANN processes, but that is not the point. I happen to be nerdy enough to participate in both organizations and track the things I am interested in in both of them, more or less. That is a rare affliction. And counting on such individuals is not really an optimum cross-function accountability mechanism. Perhaps this was brought to the ICANN Board by the then Liaison as an issue, though i do not remember it being communicated to the GNSO at the time. If it was that is a good thing, but is that is a defined cross function accountability function. And even if it so defined, is it sufficient? And what about a year later when we all of a sudden notice that you have reserved a bunch of names for technical reasons we just don't see - remember, we do not universal agreement on the technical risks of things like collision (not to start that discussion here - just an example). So to whom is IANA accountable in terms of placing and removing such names from various lists? At this point, we could go running to NTIA and complain. What would come out it, who knows, but we could. And that is the point: they represent a common point of accountability for the IANA function. avri On 23-Jul-14 17:53, Eliot Lear wrote: > Hi Avri, > > On 7/23/14, 5:15 PM, Avri Doria wrote: >> Hi, >> >> On 23-Jul-14 16:43, Brian E Carpenter wrote: >>> It would be absurd to define new mechanisms if the existing ones are >>> fully satisfactory. >> ah the old 'if it ain't broke' conundrum. >> >> Thing is, while it is not broken for some, it is broken for others. >> >> For me, as an example at this point, I see breakage on things like the >> self established ability of the IETF to unilaterally decide that a >> protocol mandates removing labels from the list of available TLD labels. > > "Unilaterally" implies that somehow the community isn't involved in the > decision. >> >> As a long time participant in the IETF, I see how natural this decision >> is for the the IETF and a part of me cheers at the simplicity of this >> solution for any number of issues. >> >> As a member of the ICANN GNSO Council I am outraged at the idea because >> it is a policy decision that the technical arm of the enterprise has no >> business making. >> >> To whom is the IETF accountable in making this decision? Just itself? > > The community and through its leadership through the NOMCOM process, > which also takes into account community views. But to be specific, when > the IETF steps in and reserves a name, it should do so only to avoid > technical breakage. Can you provide an example where the IETF got > involved where that wasn't the case? Also, did you appeal any decision > the IESG took in this regard? > >> >> This is breakage. > > > What would be breakage would be if the IETF entered such a debate > without technical ground or if the IETF *didn't* enter the debate when > there was technical breakage at risk. > > But even if the example you cited was broken, we have an appropriate > means to fix it, complete with accountability. > Eliot > > > From nobody Wed Jul 23 15:24:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0101ABD19 for ; Wed, 23 Jul 2014 15:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chEUZZoSx-hY for ; Wed, 23 Jul 2014 15:23:57 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4141A040B for ; Wed, 23 Jul 2014 15:23:57 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XA4x2-000G2K-KU; Wed, 23 Jul 2014 22:23:56 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/E1GAPzBNuyU6rUsuK4+1o Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53D02D53.6070501@acm.org> Date: Wed, 23 Jul 2014 18:23:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/JB6Qx2y-TzU0g6AqEoUrtC5n-F8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:23:59 -0000 On Jul 23, 2014, at 5:46 PM, Avri Doria wrote: > On 23-Jul-14 17:24, Brian E Carpenter wrote: >> What does that have to do with ICANN or IANA accountability? >=20 > Well this and IETF act with regard to IANA entries in a area where = ICANN > might think it get a say. IANA accountability is about whether the IANA operator performs=20 in accordance with the supplied policies... that is it, i.e. does IANA perform registry updates as specified by the policy documents. It's a fairly straightforward question of contractual performance (or at least in the case of the RIRs and IAB which perform their policy development separate from ICANN/IANA) > To whom is IANA accountable in making the reservation? the IETF. IANA is accountable to the IAB/IETF for technical reservations in both the IP and DNS spaces (as per the ICANN/IAB/IETF MOU.) It is=20 accountable to the RIRs for adherence to global policy for general=20 purpose IP space (per ICANN/NRO MOU) and one presumes that it is=20 accountable to ICANN's guidance for following policy for the general=20 purpose DNS space (although it is unclear if that's to the ICANN=20 DNS policy body or to ICANN's Board) > But ICANN is responsible for policy regarding TLDs. It gets to tell > IANA what to do with TLDs. ICANN has the ability to make policy with respect to DNS names, but=20 that is still subject to its existing agreements, including the MOU=20 between ICANN and the IAB/IETF (RFC 2860)... That MOU is quite clear=20 about deference to IETF specifications for technical reservations=20 if ICANN wishes to continue serving as the IANA. > It seems to me that it is what could be called a cross-accountabilty > example. Not at all - IANA accountability is about operating the registry = accordingly=20 to the policy authority, whereas you are raising issues about the proper=20= policy authority. The IANA must know the proper policy authority for = each registry it administers, but that is set external to the IANA via = agreements between the parties. You _never_ want the IANA deciding to insert its own independent = judgement regarding dispute situations; the IANA is a set of interrelated = technical=20 recording functions, not an oversight or judicial role. > IETF 'quite rightly' says it controls protocol parameters and it can = do > what it pleases with them despite any policy implications that may = occur > that it may or may not have considered. It tells IANA to make these > changes. IANA arrangements with IETF says do what IETF says. As long > as we stick to a single point of accountability for each function we > have no way out of this problem. I therefore argue that there has to = be > accountability mechanisms that cross the 'jurisdictions'. Again, IANA accountability is about the IANA adherence to the supplied=20= policy; is it doing it promptly and accurately. You are asking a more=20= general issue about IETF and ICANN accountability for policy development=20= to their respective communities, and does not appear to be in scope for=20= the transition proposal. Specifically - "In discussions to date, a number of topics have arisen that are outside = the scope of this transition. To avoid any misunderstanding, there are a = range issues that, while important, are not appropriately part of a = transition proposal requested by NTIA, including: =95 Policy development related to the IANA functions. As NTIA = currently plays no unique role in the development of policies for the = coordination of the Internet=92s domain name system, the proposal is not = about how relevant policies are created, nor the relevant structures in = which they are created. The roles of all Internet registry policy bodies = (such as the RIRs, IAB, IETF, ASO, NRO, ccNSO, ccTLD Registry Operators, = and the GNSO) will stay unchanged. These bodies continue to represent = their respective communities and hold policy authority for the protocol = parameter, number, and name spaces, including responsibility to ensure = the faithful registry implementation by ICANN according to those = policies." = i.e. it is perfectly reasonable to specify how "RIRs, IAB, IETF, ASO, = NRO,=20 ccNSO, ccTLD Registry Operators, and the GNSO" will know that the IANA = is=20 performing faithful registry administration of the supplied policies, = but asking how those individual bodies are accountable to their communities = in policy development is out of scope. Thanks! /John Disclaimer: My views alone. From nobody Wed Jul 23 15:36:31 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726CE1B27A8 for ; Wed, 23 Jul 2014 15:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fKBXsxOu00E for ; Wed, 23 Jul 2014 15:36:28 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60511A004D for ; Wed, 23 Jul 2014 15:36:27 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so1919340wes.1 for ; Wed, 23 Jul 2014 15:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EU8tyCWdlePDPpTO6KX28Jwn9fCaDVPB5jwcHX+5F0Q=; b=UUKL/JLLRlSsYpVEHfuulCP1ZBJeDI8bF2SGuDrdHsHV0pDRShAmuRG1Jij2hF0nL0 bP+S8EpcAxLtKxgDQhxEs4uzpmSTGwhx8YwjUHuJRCcepBiye8aGHw56bK39cW0TAYwD d394dUUV/ptJMAIfzOEUgWNqk7zoEA8765Xl5gezamJcrKbYgixFK0fb5X9M6h+h11Bv 1wh+FAeMdlUOSaJVotA/6P+R7N8vKYS49r6uCxOkGavk3s3kT4TPKWDlju/YlADN86rM bdHZy3HD3LZfia5/mUKFhT0a5UjfFhRjfExYO+BEIEsvXyhJSVF9+t+PrNPcUfN3Reiv 0Vgw== X-Received: by 10.194.184.166 with SMTP id ev6mr3580026wjc.61.1406154985448; Wed, 23 Jul 2014 15:36:25 -0700 (PDT) Received: from [31.133.177.122] (dhcp-b17a.meeting.ietf.org. [31.133.177.122]) by mx.google.com with ESMTPSA id fu7sm14477168wib.2.2014.07.23.15.36.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 15:36:24 -0700 (PDT) Message-ID: <53D038EF.1000909@gmail.com> Date: Thu, 24 Jul 2014 10:36:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Avri Doria References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> In-Reply-To: <53D02D53.6070501@acm.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/LyutqSKlZ8jaqOzX9jMbPOHM7Ng Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:36:30 -0000 Hi Avri, On 24/07/2014 09:46, Avri Doria wrote: > Hi, > > On 23-Jul-14 17:24, Brian E Carpenter wrote: >> On 24/07/2014 09:15, Avri Doria wrote: >>> Hi, >>> >>> On 23-Jul-14 16:43, Brian E Carpenter wrote: >>>> It would be absurd to define new mechanisms if the existing ones are >>>> fully satisfactory. >>> ah the old 'if it ain't broke' conundrum. >>> >>> Thing is, while it is not broken for some, it is broken for others. >>> >>> For me, as an example at this point, I see breakage on things like the >>> self established ability of the IETF to unilaterally decide that a >>> protocol mandates removing labels from the list of available TLD labels. >> Can you be specific, since I really don't what you mean? >> > > RFC 6761 Special Use Domain Names > https://tools.ietf.org/html/rfc6761 > > Allows for protocol that meet certain conditions to reserve TLDs. Indeed, but this is a more precise instantiation of the exception to the policy exception in the IETF/ICANN MoU from 2000 - nothing new here in principle or in practice. It's been exercised a number of times since then, but quite rarely: "Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4." > >>> As a long time participant in the IETF, I see how natural this decision >>> is for the the IETF and a part of me cheers at the simplicity of this >>> solution for any number of issues. >>> >>> As a member of the ICANN GNSO Council I am outraged at the idea because >>> it is a policy decision that the technical arm of the enterprise has no >>> business making. Yes it does, because it was explicitly excepted from the agreement. It's unfortunate if that wasn't well understood when the GNSO Council was created. >>> >>> To whom is the IETF accountable in making this decision? Just itself? >> What does that have to do with ICANN or IANA accountability? > > Well this and IETF act with regard to IANA entries in a area where ICANN > might think it get a say. > > To whom is IANA accountable in making the reservation? the IETF. > > But ICANN is responsible for policy regarding TLDs. It gets to tell > IANA what to do with TLDs. Except for the exception signed off 14 years ago. > It seems to me that it is what could be called a cross-accountabilty > example. > > IETF 'quite rightly' says it controls protocol parameters and it can do > what it pleases with them despite any policy implications that may occur > that it may or may not have considered. It tells IANA to make these > changes. IANA arrangements with IETF says do what IETF says. As long > as we stick to a single point of accountability for each function we > have no way out of this problem. I therefore argue that there has to be > accountability mechanisms that cross the 'jurisdictions'. Oh, in the general case I certainly agree that the 3 major areas should consult with each other when there's an overlap issue. But I don't quite see how this impacts accountability as such. In the instance you mention, was the existence of the draft and the IETF last call etc. notified in any way to the ICANN TLG or (maybe indirectly) to the GNSO? If not, that was probably an omission IMHO, but I still don't see where accountability comes in. Brian > > > And this is but one simple issue. > > avri > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > From nobody Wed Jul 23 15:36:34 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604C31A004D for ; Wed, 23 Jul 2014 15:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.685 X-Spam-Level: * X-Spam-Status: No, score=1.685 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJqoYs28-Kbt for ; Wed, 23 Jul 2014 15:36:30 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 800641B27B9 for ; Wed, 23 Jul 2014 15:36:30 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6NMaTwb020858 for ; Wed, 23 Jul 2014 18:36:29 -0400 Received: (qmail 11429 invoked by uid 0); 23 Jul 2014 22:36:29 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 23 Jul 2014 22:36:28 -0000 Message-ID: <53D038EC.9010407@acm.org> Date: Wed, 23 Jul 2014 18:36:28 -0400 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <8B4A9C47-A070-40EA-862E-B626CB193424@vigilsec.com> In-Reply-To: <8B4A9C47-A070-40EA-862E-B626CB193424@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140722-1, 07/22/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZpxINtTlh9SQc4vPYzhQQFk6NSQ Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:36:31 -0000 Hi, As I say I do not remember coordination, but maybe. It is just an example. And it is not really defined. At the moment it works because we like and trust each other all around. But when speaking of cross-institutional accountability, these are not things we can just count on. I am not saying we need big heavy duty cross-accountability mechanisms that oppress us and keep us from doing the stuff we need to do. I am saying we need to formally consider the multistakeholder cross-accountability (or put another way the IANA aggregate function accountability) issues together with the multistakeholder IST process. avri On 23-Jul-14 18:03, Russ Housley wrote: > Avri: > >> For me, as an example at this point, I see breakage on things like the >> self established ability of the IETF to unilaterally decide that a >> protocol mandates removing labels from the list of available TLD labels. >> >> As a long time participant in the IETF, I see how natural this decision >> is for the the IETF and a part of me cheers at the simplicity of this >> solution for any number of issues. >> >> As a member of the ICANN GNSO Council I am outraged at the idea because >> it is a policy decision that the technical arm of the enterprise has no >> business making. > > I cannot imagine such a thing happening without coordination. There was coordination before ".local" was selected by the technical community. The coordination turned out to be straightforward because ".local" was on the list that ICANN was not allowed to use. > > I'd like to see a process for this coordination written down, but I am not worried about "unilateral" decisions. > > Russ > From nobody Wed Jul 23 15:47:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40DD1B28BA for ; Wed, 23 Jul 2014 15:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaS7WMNKK7f5 for ; Wed, 23 Jul 2014 15:47:06 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5151B2810 for ; Wed, 23 Jul 2014 15:47:06 -0700 (PDT) Received: from mx1.yitter.info (dhcp-bcbc.meeting.ietf.org [31.133.188.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1977D8A031 for ; Wed, 23 Jul 2014 22:47:05 +0000 (UTC) Date: Wed, 23 Jul 2014 18:47:03 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140723224703.GC21760@mx1.yitter.info> References: <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D02D53.6070501@acm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/xjib9VEU0I_2AYAOXbQaennnDtE Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:47:07 -0000 On Wed, Jul 23, 2014 at 05:46:59PM -0400, Avri Doria wrote: > But ICANN is responsible for policy regarding TLDs. It gets to tell > IANA what to do with TLDs. I think, actually, that's not precisely correct. ICANN has responsibility for the root zone. The things we put in the root zone are often called "TLDs", but not every domain name is in fact a name eligible to be in the DNS. The IETF has responsibility for the technical definition and consequences of protocols, and what RFC 6761 establishes is a way to reserve certain kinds of names for technical purposes when that is necessary. This is not new: RFC 2606, published in 1999, establishes some similar reservations. So, ICANN gets to tell IANA when to add an entry to the root zone, provided that is technically acceptable. ICANN cannot, for instance, create a new delegation for com. that is distinct from COM., at least not without violating STD13. That's a consequence of the way the protocols are defined. ICANN cannot, either, create a new delegation for zx--foo. without violating IDNA2008. Note that somewhere around 2000, that latter restriction wasn't the case. But new protocols come along, and they have new rules. RFC 6761 is intended to be used to identify names that need to be handled specially. In the case of such names that might be understood as "top-level domains" (i.e. that are one label plus the null label long), those are names that by definition should _not_ appear in the root. If they should, then part of the standards action or IESG approval needed to approve the entry in the special-purposes registry would detect that and likely reject the registration. RFC 6761 clearly says as much: The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied. If in all seven categories the answer is "none", then possibly no special treatment is required and requesting reservation of a Special-Use Domain Name may not be appropriate. There's no question that the special-use registry for names is a place of overlap, where a slow and careful job of co-ordination will be needed. But we actually have those relationships between the organizations, and this registry requires a fairly heavyweight registration procedure precisely _because_ of the potential for conflict. It just isn't true that RFC 6761 is a unilateral encroaching by IETF on ICANN's area of responsibility. ICANN is responsible for the root zone. It certainly should have policies itself for things that are not permitted to be registered. But I do not buy that ICANN's policy responsibility extends to all labels that could logically-possibly be in the root zone, just because of those cases where a protocol requires a special-use name for technical reasons. The IETF doesn't tread on ICANN's responsibilities when it reserves local. any more than it treads on Verisign's when it reserves example.com. At the same time, the RFC 6761 example militates in favour of leaving the different IANA functions together in a single IANA. It is logically possible, of course, to separate these functions, but it would be a bad idea because IANA is about technical co-ordination that turns out to be useful. It's not Internet Police, and neither are any of the policy bodies that feed it. It's a utility, and making arrangements that maximise that utility is the right thing to do. Quite apart from that, it's not like the adoption of RFC 6761 or the adoption of any future entry (were one to happen) in the special-use registry is going to happen under a barrel. One of the things I've been finding mystifying about this entire discussion is the apparent assumption that if someone is "in" one community that person can't also be "in" another one. We're not arranged with carefully-balanced powers, or spheres of influence, or things like that. I thought one of the supposed advantages of open, bottom-up, transparent, and even multi-stakeholder processes was supposed to be that cross-participation is easy. What have I missed? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 23 15:47:14 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C561B2A1E for ; Wed, 23 Jul 2014 15:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXdwlFZSoQzU for ; Wed, 23 Jul 2014 15:47:11 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA7F1B2A03 for ; Wed, 23 Jul 2014 15:47:11 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XA5JW-000P1O-Bx; Wed, 23 Jul 2014 22:47:10 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/gzkngEA50iTbZu3+8u/Y/ Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53D038EC.9010407@acm.org> Date: Wed, 23 Jul 2014 18:47:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11EA2D3D-919B-4F96-97DB-B83AE83FDE52@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <8B4A9C47-A070-40EA-862E-B626CB193424@vigilsec.com> <53D038EC.9010407@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/2dc2bAeTi9ydZ6V4dMkTXkRWzK0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:47:12 -0000 On Jul 23, 2014, at 6:36 PM, Avri Doria wrote: > I am saying we need to formally consider the multistakeholder > cross-accountability (or put another way the IANA aggregate function > accountability) issues together with the multistakeholder IST process. I also believe that it would be rather timely for all of the registry=20 policy development bodies to reexamine their accountability mechanisms=20= to the affected communities (and do believe that there will be quite a=20= bit of these reviews going on over the next year or so...) However, at least per the language in the scoping document, = accountability of the policy development bodies is independent to the development of = the requested proposal for transition of NTIA's stewardship of the IANA = functions. FYI, /John Disclaimer: My views alone. From nobody Thu Jul 24 03:42:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0621A01BD for ; Thu, 24 Jul 2014 03:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtO8JyQrWM5f for ; Thu, 24 Jul 2014 03:42:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7C21A01AF for ; Thu, 24 Jul 2014 03:42:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.232]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6OAfxBZ029604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 03:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406198531; x=1406284931; bh=HQ4F8KwaWY6mvjLeautJwBRublY5whFMoLBmSo3v6VA=; h=Date:To:From:Subject:In-Reply-To:References; b=un6ib1wBD+pfCYfVJLcTpaYmLF93GW4lSdStTbsLIXLVytGMSghf4hiaIHMIZQZay lhS3og8bmTHr5017gVCXbY2ePwz5gG2hM+G+KdDUH1iLdruUamwVM3nQ/m39ewGOaf E/r61eaXV9Dd899ShUG/D880qmYXUZyWlYhm0vJM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406198531; x=1406284931; i=@elandsys.com; bh=HQ4F8KwaWY6mvjLeautJwBRublY5whFMoLBmSo3v6VA=; h=Date:To:From:Subject:In-Reply-To:References; b=tSS7p1phoGhvu/9vhwQfqzqA1nZ/BSWK/sTIRq56+nLIE3xhpS3oBzxoHn2j2drUI bry6LSEAJnUqizn441+hG+hvnP6ZbkldyZLnLFJ/TuytqHpz/mu3XBTXqUqlEow57f qItgspHzeDsRnBS53k+v0dJoTNUwpxX2VlrbWU1I= Message-Id: <6.2.5.6.2.20140724012237.0ce22978@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 24 Jul 2014 03:31:05 -0700 To: Avri Doria , internetgovtech@iab.org From: S Moonesamy In-Reply-To: <53D02D53.6070501@acm.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Fhwe_-eOvzmqomih1PtCqo5SFO0 Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 10:42:15 -0000 Hi Avri, At 14:46 23-07-2014, Avri Doria wrote: >RFC 6761 Special Use Domain Names >https://tools.ietf.org/html/rfc6761 > >Allows for protocol that meet certain conditions to reserve TLDs. In my opinion there was, at most, rough consensus on that document. I did not like what the document was proposing as it could be argued in future that it was intruding into the policy side. The following paragraph is a technical opinion. Should .local be delegated to as a gTLD? My recommendation is no as public information collected from various points on the internet shows that the .local string is in use. Some of the computers used by the people reading this list contribute to that usage. What if some company insists on buying .local? That company will come back later and complain that the (purchased) string is not working because of technical problems; someone will suggest that the IETF has to find a solution to those technical problems. It is up to the policy side to assess this paragraph and the previous one to determine whether the .local string should be delegated. The reason not to have that document is that Person X will come and ask for a string as Company Y got a string. This is where one might have to consider whether the decision taken is arbitrary [1]. Anyway, the document has been published. In my opinion there is a valid concern. Regards, S. Moonesamy 1. Based on random choice or personal whim, rather than any reason or system. From nobody Thu Jul 24 07:16:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0759B1A0366 for ; Thu, 24 Jul 2014 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssUTsFdNkxVq for ; Thu, 24 Jul 2014 07:16:23 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217BD1A0368 for ; Thu, 24 Jul 2014 07:16:23 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XAJoj-000PSB-00; Thu, 24 Jul 2014 14:16:21 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18wJjUe70IHwmvku8NoCzLa Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <6.2.5.6.2.20140724012237.0ce22978@resistor.net> Date: Thu, 24 Jul 2014 10:16:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/bwi-in_d6zAhXzd0BLKL-8P9a-U Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:16:25 -0000 On Jul 24, 2014, at 6:31 AM, S Moonesamy wrote: > Hi Avri, > At 14:46 23-07-2014, Avri Doria wrote: >> RFC 6761 Special Use Domain Names >> https://tools.ietf.org/html/rfc6761 >>=20 >> Allows for protocol that meet certain conditions to reserve TLDs. >=20 > In my opinion there was, at most, rough consensus on that document. I = did not like what the document was proposing as it could be argued in = future that it was intruding into the policy side. You seem to believe that the IETF does not make "policy" for = identifiers,=20 but in fact, IANA registries are specifically required to have policies=20= (see RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs") so that the IANA knows what exactly to do in administration. Now it is true that these policies are generally technical in nature and=20= tend to avoid "public policy" positions, but that is not a hard = requirement=20 for either IETF protocols or the associated registries. For example, it=20= is possible for the IETF to define a protocol (e.g. an enhancement to = DNS)=20 whereby the protocol itself has some embedded rules for certain = identifiers=20 (e.g. the string "curran" shall always return empty set on any query...) = =20 Thankfully, the IETF doesn't generally engage in such things, and = instead=20 usually constrains itself to technical constraints on the protocols and=20= associated registries; thus the keeping the IETF protocols very popular=20= and enabling the success of the Internet that we've all come to enjoy. It's worth encouraging the IETF to work on predominantly technical = issues, and to delegate the public policy issues that come with general purpose registries to bodies which are supported by the affected community, but=20= at the end of the day, that is nothing more than a polite suggestion to = the IETF, and may or may not be followed. If the IETF were to make a = serious misstep, then it runs the risk of parties going elsewhere to work on = their protocol standard needs, and that's likely a reasonable deterrent with a=20= natural counterbalance. /John Disclaimer: my views alone. From nobody Thu Jul 24 11:17:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DDF1A00FA for ; Thu, 24 Jul 2014 11:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdhi5_NHJbnL for ; Thu, 24 Jul 2014 11:17:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F2E1A0353 for ; Thu, 24 Jul 2014 11:17:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6OIH2hR014003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 11:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406225836; x=1406312236; bh=i07lGx570qjUtTwgnSVtjjAIBFgsF08niyBqHILUH40=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Du2CvjNGxge9CKuM4v8lek3b23Kn0AWkmMyq4GJ4ZzUmnNjPCZSaubBw9J4rjmBDx CU6xgatFgQ5YZBXhqxOvdQVHSXyPYv6f246/UJJBUN4SSFroz2BgPUajfPbpyRvwWn bPSiYjE6ytx0N6sEhwRvdWd9/VUNgjgxg66oICz4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406225836; x=1406312236; i=@elandsys.com; bh=i07lGx570qjUtTwgnSVtjjAIBFgsF08niyBqHILUH40=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=poKef2vMvB0RVF/LawC8gwaGnHc3LHfCRRApRVXYt7Lnze2JmxDj+Mc946T+Um4Q+ FGJQcbrUPXXRRfEtdLzdCXHrVx5HS6VcowSThcIT5aI9lphkvWdykZL5g2wuUp6qgj PN7sys6xwCSUh3cgGAuJkmhNCFnR0roBcUab4pmY= Message-Id: <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 24 Jul 2014 10:08:33 -0700 To: John Curran From: S Moonesamy In-Reply-To: <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ee2zjQn6myv3eRLkw8hNLj5GeNk Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:17:21 -0000 Hi John, At 07:16 24-07-2014, John Curran wrote: >You seem to believe that the IETF does not make "policy" for identifiers, >but in fact, IANA registries are specifically required to have policies >(see RFC 5226, "Guidelines for Writing an IANA Considerations Section in >RFCs") so that the IANA knows what exactly to do in administration. My choice of words was incorrect. You explained it better in the paragraph quoted below. >Now it is true that these policies are generally technical in nature and >tend to avoid "public policy" positions, but that is not a hard requirement >for either IETF protocols or the associated registries. For example, it >is possible for the IETF to define a protocol (e.g. an enhancement to DNS) >whereby the protocol itself has some embedded rules for certain identifiers >(e.g. the string "curran" shall always return empty set on any query...) Ok. >Thankfully, the IETF doesn't generally engage in such things, and instead >usually constrains itself to technical constraints on the protocols and >associated registries; thus the keeping the IETF protocols very popular >and enabling the success of the Internet that we've all come to enjoy. > >It's worth encouraging the IETF to work on predominantly technical issues, >and to delegate the public policy issues that come with general purpose >registries to bodies which are supported by the affected community, but >at the end of the day, that is nothing more than a polite suggestion to the >IETF, and may or may not be followed. If the IETF were to make a serious >misstep, then it runs the risk of parties going elsewhere to work on their >protocol standard needs, and that's likely a reasonable deterrent with a >natural counterbalance. Yes. The problem is that it is not always clear at the time the decision was taken whether the misstep is serious. In addition, there are a handful of people who would bother to raise any objection if something is considered as a misstep as: (a) The person is not making or losing money because of the decision; or (b) The person will be labelled as querulous. (c) It is bad for the person's career. Regards, S. Moonesamy From nobody Thu Jul 24 16:23:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF821A0444 for ; Thu, 24 Jul 2014 16:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUAo4f5_3bsy for ; Thu, 24 Jul 2014 16:23:24 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4761A03E1 for ; Thu, 24 Jul 2014 16:23:24 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XASM7-000DQU-3y; Thu, 24 Jul 2014 23:23:23 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+q9dLnSZK0eYuLXD75FmEY Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> Date: Thu, 24 Jul 2014 16:52:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ywjKHeDu1NDG0wc8_UATL-ndFII Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:23:26 -0000 On Jul 24, 2014, at 1:08 PM, S Moonesamy wrote: > At 07:16 24-07-2014, John Curran wrote: >> You seem to believe that the IETF does not make "policy" for = identifiers, >> but in fact, IANA registries are specifically required to have = policies >> (see RFC 5226, "Guidelines for Writing an IANA Considerations Section = in >> RFCs") so that the IANA knows what exactly to do in administration. >=20 > My choice of words was incorrect. You explained it better in the = paragraph quoted below. Coolness. >> Now it is true that these policies are generally technical in nature = and >> tend to avoid "public policy" positions, but that is not a hard = requirement >> for either IETF protocols or the associated registries. For example, = it >> is possible for the IETF to define a protocol (e.g. an enhancement to = DNS) >> whereby the protocol itself has some embedded rules for certain = identifiers >> (e.g. the string "curran" shall always return empty set on any = query...) >=20 > Ok. i.e. technical registry policy is part of protocol specification; the = IETF can indeed make a mess of either, but is inclined to try and make it so = the=20 resulting protocol & registry useful for the Internet. >> It's worth encouraging the IETF to work on predominantly technical = issues, >> and to delegate the public policy issues that come with general = purpose >> registries to bodies which are supported by the affected community, = but >> at the end of the day, that is nothing more than a polite suggestion = to the >> IETF, and may or may not be followed. If the IETF were to make a = serious >> misstep, then it runs the risk of parties going elsewhere to work on = their >> protocol standard needs, and that's likely a reasonable deterrent = with a >> natural counterbalance. >=20 > Yes. >=20 > The problem is that it is not always clear at the time the decision = was taken whether the misstep is serious. A single misstep is unlikely to cause folks to go to another venue for their Internet standards development; it would probably take a pattern = of=20 decisions which impact others without reasonable opportunity for input = to cause such an outcome. This is very unlikely given the open nature of=20= IETF standards development, but does highlight the need for the various organizations (IETF, ICANN, RIRs) to keep each other apprised of any = policy or standards development that may be of cross interest. This has worked=20= very well between the RIRs and the IETF, okay with the RIRs and ICANN = from=20 what I can tell (and I do not know how well the IETF/ICANN communication=20= in this area has worked.) > In addition, there are a handful of people who would bother to raise = any objection if something is considered as a misstep as: >=20 > (a) The person is not making or losing money because of the decision; = or >=20 > (b) The person will be labelled as querulous. >=20 > (c) It is bad for the person's career. And such folks are free to write Internet Drafts which describe the = problem=20 (as they see it) with a given protocol or registry requirement, and = participate=20 in the IETF process to get things changed to something more pleasing. = If their=20 arguments have merit, they are likely to be picked up and advanced by = others=20 via the process, and if not, then the asserted misstep is actually a = non-issue. In any case, this is all handled via the existing IETF processes for = standards=20 and registry policy development; there is no evidence of any need for = new or=20 additional accountability mechanisms for these IETF processes, = particularly to=20 the extent that the IETF work predominantly covers technical matters = rather than=20 "public policy" issues. That aligns well with the IANA Stewardship = transition=20 proposal development effort, which is not scoped to include = accountability=20 mechanisms for "how relevant policies are created, nor the relevant = structures=20 in which they are created." FYI, /John Disclaimer: My views alone. From nobody Thu Jul 24 19:47:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B21A0ADA for ; Thu, 24 Jul 2014 19:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceOJQ1tdgZ0o for ; Thu, 24 Jul 2014 19:47:16 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 14EE71A0ACA for ; Thu, 24 Jul 2014 19:47:16 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id E97F132E52C; Fri, 25 Jul 2014 11:47:13 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7ed7_76ca_d67e0650_9163_4fb5_a345_ff8f6ae2d753; Fri, 25 Jul 2014 11:47:13 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 62666BF4BA; Fri, 25 Jul 2014 11:47:13 +0900 (JST) Message-ID: <53D1C521.3030809@it.aoyama.ac.jp> Date: Fri, 25 Jul 2014 11:46:57 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Curran , S Moonesamy References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> In-Reply-To: <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/FQC1zpS1y9JyTi0l08qdrJrnXuw Cc: internetgovtech@iab.org, Avri Doria Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 02:47:19 -0000 On 2014/07/25 05:52, John Curran wrote: > On Jul 24, 2014, at 1:08 PM, S Moonesamy wrote: >> At 07:16 24-07-2014, John Curran wrote: >>> Now it is true that these policies are generally technical in nature and >>> tend to avoid "public policy" positions, but that is not a hard requirement >>> for either IETF protocols or the associated registries. For example, it >>> is possible for the IETF to define a protocol (e.g. an enhancement to DNS) >>> whereby the protocol itself has some embedded rules for certain identifiers >>> (e.g. the string "curran" shall always return empty set on any query...) >> >> Ok. > > i.e. technical registry policy is part of protocol specification; the IETF > can indeed make a mess of either, but is inclined to try and make it so the > resulting protocol & registry useful for the Internet. I think that in general, IETF caring about the technical stuff, and ICANN about the political stuff, should work out fine, even where these overlap (i.e. TLDs). But imagine the following, somewhat imaginary but not totally improbable scenario: The IETF is working on some technology that requires a couple of TLDs to be reserved for a special purpose. The technology is already partially deployed, but not yet extremely widely, and the IETF is standardizing it and fixing some stuff that needs fixing for wider deployment. ICANN is working on a new round of gTLDs or some such. Of course they exclude already reserved TLDs, but not stuff that might be coming up (because they don't know it). Now assume that at some point rather late in the game, it gets discovered that some names on both sides clash. ICANN already has accepted a (significant) amount of money and made some firm promises. The IETF technology is already well deployed, and fixes may be costly and time-consuming. Each organization and its constituents thinks that they were first and therefore think they have priority, and provide ample material to support their claims. What, if any, provisions are there currently to avoid such a problem? What, if any, additional provisions would we need to avoid such a problem in the future. Please note that "we can talk to each other" doesn't work here; the example is explicitly constructed that way :-(. Regards, Martin. From nobody Thu Jul 24 21:13:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC541A0AD6 for ; Thu, 24 Jul 2014 21:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOvWRT_E6CVM for ; Thu, 24 Jul 2014 21:13:05 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE5C1A0AC9 for ; Thu, 24 Jul 2014 21:13:04 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XAWsR-0001S0-4n; Fri, 25 Jul 2014 04:13:03 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/fnHLy5Yjyhd81/rCatrSu Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Curran In-Reply-To: <53D1C521.3030809@it.aoyama.ac.jp> Date: Fri, 25 Jul 2014 00:12:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6C7547BD-9397-4957-B2D2-0C2BB314D350@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <"53D016B6.20200 00"@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/aTxZnNJ1MExcVjmbdShqNmDy1TU Cc: internetgovtech@iab.org, Avri Doria , S Moonesamy Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:13:06 -0000 On Jul 24, 2014, at 10:46 PM, Martin J. D=FCrst = wrote: > What, if any, provisions are there currently to avoid such a problem? = What, if any, additional provisions would we need to avoid such a = problem in the future. >=20 > Please note that "we can talk to each other" doesn't work here; the = example is explicitly constructed that way :-(. Inter-party communication and coordination is the key to avoiding such a = problem,=20 but avoiding such a conflict isn't an option for a pre-existing = condition as you=20 have specified. The short answer I expect is that the language in the = MOU between=20 ICANN and the IAB/ IETF would likely govern the outcome. FYI, /John Disclaimer: My views alone. From nobody Fri Jul 25 00:53:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BE51B2788 for ; Fri, 25 Jul 2014 00:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjUxtfWAQ5Sw for ; Fri, 25 Jul 2014 00:52:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4D1AD972 for ; Fri, 25 Jul 2014 00:52:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6P7qhXZ019621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 00:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406274776; x=1406361176; bh=tzl5wDWYZyNRJQ0pOkwXN0hPcR2nTevD2/V7yVG+RwU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Sm2wLcY+tiudAc4+AhKlYoXU+ClTKMwK1N9BgMmkgUS9o1/GphPABJm5kH0wRYHw4 NjnNp+AuxOUMkHsBfY44dqlkz0F3ZU6O3PnjOtniSpALpvB4BNjnPwlI/TzbS4EhkK +55iAbJ5ylvdkIiuWXYJbdHryY/1n52LTHrJnwdQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406274776; x=1406361176; i=@elandsys.com; bh=tzl5wDWYZyNRJQ0pOkwXN0hPcR2nTevD2/V7yVG+RwU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lvF86YgX/tpb6oIqzMrKD3HRSVNkRmOunbCrDZnIzNeMoRndF0/f/Csz/KjyMs0pA Y1NUiYeg/LNJxEnMdJE0C4x/hpSH+JL4zwLfEXLaiHkQmtaVyqi1YxcvKFfKH92TWV 9jnAVgw9TIjaZnXKF8YBYLEZZu6Qtu5v1efs2KaA= Message-Id: <6.2.5.6.2.20140724163149.0ea16280@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 24 Jul 2014 17:58:01 -0700 To: John Curran From: S Moonesamy In-Reply-To: <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/GjQ6_gQULglg9waryAuyq3ZuGs0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:52:59 -0000 Hi John, At 13:52 24-07-2014, John Curran wrote: >A single misstep is unlikely to cause folks to go to another venue for >their Internet standards development; it would probably take a pattern of >decisions which impact others without reasonable opportunity for input to >cause such an outcome. This is very unlikely given the open nature of >IETF standards development, but does highlight the need for the various >organizations (IETF, ICANN, RIRs) to keep each other apprised of any policy >or standards development that may be of cross interest. This has worked >very well between the RIRs and the IETF, okay with the RIRs and ICANN from >what I can tell (and I do not know how well the IETF/ICANN communication >in this area has worked.) I'll say ok to the above as I do not do the coordination. >And such folks are free to write Internet Drafts which describe the problem >(as they see it) with a given protocol or registry requirement, and >participate >in the IETF process to get things changed to something more >pleasing. If their >arguments have merit, they are likely to be picked up and advanced by others >via the process, and if not, then the asserted misstep is actually a >non-issue. A generally accepted theory or belief was that nothing could be done about 2050 as the previous attempts to update the document resulted in failure. I don't think that the move happened based on the merit of the arguments. There is a thread on ietf@ about something more pleasing. Some things are unsurprising. >In any case, this is all handled via the existing IETF processes for >standards >and registry policy development; there is no evidence of any need for new or >additional accountability mechanisms for these IETF processes, >particularly to >the extent that the IETF work predominantly covers technical matters >rather than >"public policy" issues. That aligns well with the IANA Stewardship >transition >proposal development effort, which is not scoped to include accountability >mechanisms for "how relevant policies are created, nor the relevant >structures >in which they are created." I have followed the non-IETF discussions about the word "accountability". In some ways it is about a clash of cultures and other considerations. The IETF can end up as collateral damage in all that. Regards, S. Moonesamy From nobody Fri Jul 25 00:53:10 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07691AD972 for ; Fri, 25 Jul 2014 00:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh5FW99UKP64 for ; Fri, 25 Jul 2014 00:53:08 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C581B278C for ; Fri, 25 Jul 2014 00:53:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6P7qhXb019621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 00:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406274781; x=1406361181; bh=dTCY6WYLgtzqknUjLZlaj5Id4FUFWuptXvovYov29RU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=db7l/GcUAZ2D8YQZbLOQX3vDedXP6HZIIL9ShVmD4Bcu0JzFNUOG4po+PQYxaUZfI LUdrI/5ppD1vm3rW8p7WmCfj56sLJ/3e4GaJK6cg8N7sl9QhR9t3ynUnEKeb/P7NY2 ELCxsM9gKzBFN7TFM87vfsI7crU1QQHwFa81H0b0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406274781; x=1406361181; i=@elandsys.com; bh=dTCY6WYLgtzqknUjLZlaj5Id4FUFWuptXvovYov29RU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XQwleq93hf7OUueVk0KqfybRGw/MAOxovN6LGV3JXSJE7grxzyq9PxK/7DglqgPke stU9dAT2HVx27UHtdTR46TY5UhwsDTKbsi0nkmPzqHETRTHy6cTU0KWF3KXxU7Am26 xqcQ5AeMaVmWs6FZ0/5QqaGLkZlW879NPPA8abj4= Message-Id: <6.2.5.6.2.20140724231216.0dedca00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 25 Jul 2014 00:26:58 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: S Moonesamy In-Reply-To: <53D1C521.3030809@it.aoyama.ac.jp> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/uoIs59q-Y3K9J8TLectYEXlDj-0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:53:08 -0000 Hi Martin, At 19:46 24-07-2014, Martin J. D=FCrst wrote: >I think that in general, IETF caring about the=20 >technical stuff, and ICANN about the political=20 >stuff, should work out fine, even where these overlap (i.e. TLDs). > >But imagine the following, somewhat imaginary=20 >but not totally improbable scenario: > >The IETF is working on some technology that=20 >requires a couple of TLDs to be reserved for a=20 >special purpose. The technology is already=20 >partially deployed, but not yet extremely=20 >widely, and the IETF is standardizing it and=20 >fixing some stuff that needs fixing for wider deployment. > >ICANN is working on a new round of gTLDs or some=20 >such. Of course they exclude already reserved=20 >TLDs, but not stuff that might be coming up (because they don't know it). > >Now assume that at some point rather late in the=20 >game, it gets discovered that some names on both=20 >sides clash. ICANN already has accepted a=20 >(significant) amount of money and made some firm=20 >promises. The IETF technology is already well=20 >deployed, and fixes may be costly and=20 >time-consuming. Each organization and its=20 >constituents thinks that they were first and=20 >therefore think they have priority, and provide=20 >ample material to support their claims. > >What, if any, provisions are there currently to=20 >avoid such a problem? What, if any, additional=20 >provisions would we need to avoid such a problem in the future. > >Please note that "we can talk to each other"=20 >doesn't work here; the example is explicitly constructed that way :-(. I find it difficult to provide a honest answer to=20 the above on a non-IETF mailing list. :-( Regards, S. Moonesamy=20 From nobody Fri Jul 25 00:59:09 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0A1B278D for ; Fri, 25 Jul 2014 00:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEoQuqkJCD51 for ; Fri, 25 Jul 2014 00:59:06 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E561A0097 for ; Fri, 25 Jul 2014 00:59:05 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so3785852wgh.11 for ; Fri, 25 Jul 2014 00:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kofnYJu7Y22sOWvAJzV/HcS81VLtwoFkGWj9fLU8vPk=; b=eld5zgOJmwsq/bP/G4JtgpvewPcSNHkBszfxxMNu1a0RLs26c27rieKofmhvbjeAA3 9titfW3Ke/mRKHyhMNfLOAESxlOESUxrzOPNaLKqxG9vE/i6LdmdVpV86/5NhGYZy8cP CSqewcsIE6koEqCQiMxW8DlJIO7OCEgy170JtmLQbmn0tqBUaRguRQYpaOkPK2289GLJ t46C924cJ69V+vZVgmrfh9TmmnI8YHdHZYvj94A1wMB43Aw8LnIZNX0WyhmzDRE3GZ46 6g78fjcJWlQIBU/VYcxE266+Gll4bxCVp0/IGwrQSuEhUhxFKgqKDS9ygDRNHktzLpKH /IcA== X-Received: by 10.194.174.66 with SMTP id bq2mr19465149wjc.96.1406275143591; Fri, 25 Jul 2014 00:59:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.162.195 with HTTP; Fri, 25 Jul 2014 00:58:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140724231216.0dedca00@elandnews.com> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <6.2.5.6.2.20140724231216.0dedca00@elandnews.com> From: Seun Ojedeji Date: Fri, 25 Jul 2014 08:58:33 +0100 Message-ID: To: S Moonesamy Content-Type: multipart/alternative; boundary=089e013d1e6863ec8f04fefff277 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/TXcugfh58vMVri_mYiKbOve2AZ0 Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:59:08 -0000 --089e013d1e6863ec8f04fefff277 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 25, 2014 at 8:26 AM, S Moonesamy wrote: > Hi Martin, > Please note that "we can talk to each other" doesn't work here; the > example is explicitly constructed that way :-(. > > I find it difficult to provide a honest answer to the above on a non-IETF > mailing list. :-( > > What difference does that make ;) Cheers! > Regards, > S. Moonesamy > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --089e013d1e6863ec8f04fefff277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 25, 2014 at 8:26 AM, S Moonesamy <sm+ietf@elandsys.com><= /span> wrote:
Hi Martin,
Please note that &= quot;we can talk to each other" doesn't work here; the example is = explicitly constructed that way :-(.

I find it difficult to provide a honest answer to the above on a non-IETF m= ailing list. :-(

What difference does that make ;)

C= heers!
Regards,
S. Moonesamy
_______________________________________________
Internetgovtech mailing list
Internetgovtec= h@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech



--
---------------------------------------------------------------------= ---
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--089e013d1e6863ec8f04fefff277-- From nobody Fri Jul 25 04:29:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240871A01A8 for ; Fri, 25 Jul 2014 04:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuoxcS6NlbAx for ; Fri, 25 Jul 2014 04:29:20 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666EF1A01A9 for ; Fri, 25 Jul 2014 04:29:20 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so4029305wgh.13 for ; Fri, 25 Jul 2014 04:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vCByLyamVqJJTzRVTxtsTbJUslrNqtiy7L3X6XFM4sE=; b=iaV3Hq3ZnZzr+SqGynuNZjY4j1h4w/rJhdlH36qCWEjNzSYrArBXlhjAkE8qfaKQUe drMFQetT4oJXYbkkYmWao3oJsWFX7p2xRysIAE88z9D0c6sTRUIa6LsD8EGSWJj0N5VF AqHL5zssR1l47b+oMiJQvwG8GwMQ89Utoa4Wz/4AF0VxwSSUYAeZVEnBTONm+RrUTo0P lO9JWhzibwRw6ih/CV2c6lG3JddV/swC9FFYFf2/F/gWTmFKYIBvJkisYI4SF9qzShPT w8nA0dHluGGx//k23dBcickUNlaOjA751B2SQBnzRU+oo5M2t3/fwJb13f3b2w9dWVEJ P+vQ== X-Received: by 10.194.60.35 with SMTP id e3mr21585716wjr.12.1406287757614; Fri, 25 Jul 2014 04:29:17 -0700 (PDT) Received: from [31.133.136.182] (dhcp-88b6.meeting.ietf.org. [31.133.136.182]) by mx.google.com with ESMTPSA id u10sm4850406wix.14.2014.07.25.04.29.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 04:29:16 -0700 (PDT) Message-ID: <53D23F93.4050002@gmail.com> Date: Fri, 25 Jul 2014 23:29:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> In-Reply-To: <53D1C521.3030809@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/iDChpIuukNaKI0OzDyNX6alLjR4 Cc: John Curran , Avri Doria , S Moonesamy , internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:29:22 -0000 > ICANN is working on a new round of gTLDs or some such. Of course they > exclude already reserved TLDs, but not stuff that might be coming up > (because they don't know it). That's already a failure of coordination. > Please note that "we can talk to each other" doesn't work here; the exa= mple is explicitly constructed that way :-(.=20 But that is in fact the only answer in any such situation; it will work because it has to work. The saying in English "We'll cross that bridge when we come to it" applies, in my opinion. We can't plan for every possible case. Regards Brian On 25/07/2014 14:46, Martin J. D=C3=BCrst wrote: > On 2014/07/25 05:52, John Curran wrote: >> On Jul 24, 2014, at 1:08 PM, S Moonesamy wrote:= >>> At 07:16 24-07-2014, John Curran wrote: >=20 >>>> Now it is true that these policies are generally technical in nature= >>>> and >>>> tend to avoid "public policy" positions, but that is not a hard >>>> requirement >>>> for either IETF protocols or the associated registries. For >>>> example, it >>>> is possible for the IETF to define a protocol (e.g. an enhancement >>>> to DNS) >>>> whereby the protocol itself has some embedded rules for certain >>>> identifiers >>>> (e.g. the string "curran" shall always return empty set on any >>>> query...) >>> >>> Ok. >> >> i.e. technical registry policy is part of protocol specification; the >> IETF >> can indeed make a mess of either, but is inclined to try and make it >> so the >> resulting protocol & registry useful for the Internet. >=20 > I think that in general, IETF caring about the technical stuff, and > ICANN about the political stuff, should work out fine, even where these= > overlap (i.e. TLDs). >=20 > But imagine the following, somewhat imaginary but not totally improbabl= e > scenario: >=20 > The IETF is working on some technology that requires a couple of TLDs t= o > be reserved for a special purpose. The technology is already partially > deployed, but not yet extremely widely, and the IETF is standardizing i= t > and fixing some stuff that needs fixing for wider deployment. >=20 > ICANN is working on a new round of gTLDs or some such. Of course they > exclude already reserved TLDs, but not stuff that might be coming up > (because they don't know it). >=20 > Now assume that at some point rather late in the game, it gets > discovered that some names on both sides clash. ICANN already has > accepted a (significant) amount of money and made some firm promises. > The IETF technology is already well deployed, and fixes may be costly > and time-consuming. Each organization and its constituents thinks that > they were first and therefore think they have priority, and provide > ample material to support their claims. >=20 > What, if any, provisions are there currently to avoid such a problem? > What, if any, additional provisions would we need to avoid such a > problem in the future. >=20 > Please note that "we can talk to each other" doesn't work here; the > example is explicitly constructed that way :-(. >=20 > Regards, Martin. >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > . >=20 From nobody Fri Jul 25 04:33:26 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490D1A01A9 for ; Fri, 25 Jul 2014 04:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJMNNGekbPzU for ; Fri, 25 Jul 2014 04:33:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E44891A01EF for ; Fri, 25 Jul 2014 04:33:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s6PBX4sr027016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 04:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1406287996; x=1406374396; bh=uepjWuydgT+dL4o36N6Ba/f9gmocedTBIVSl+dZl5nI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KGPP2UVfyFwy+CZRn9VrWAH/GcQewzLOPa6zhpP20qpeBK5DivSI/SxU8/2MXvl05 xO3t83+KFUlPff41sft1Kez2qvyK7Rx6rrfd/tSA28tVcFufUl/JIECFNaCnX89/pM omT1zwrCzehRh8yUEau943Vc7kcurP2KMx1+TzHE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1406287996; x=1406374396; i=@elandsys.com; bh=uepjWuydgT+dL4o36N6Ba/f9gmocedTBIVSl+dZl5nI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=weKnpA1am9eDuw9elJpo1kP2ymjJQQ65LAX+e71shYrIzg7WhnrIWZKY3AEnzKdz8 8duF0YbbAZoxjUSm7y3Y31JsOq5A26Y6J9mz4hiKW1fuLdsJaZPV2F4l4djJ/x5qDO pfIDGlawaEp9rBTPnPQFjlfw+/LIdmezZZ4zJIOc= Message-Id: <6.2.5.6.2.20140725042552.07760120@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 25 Jul 2014 04:31:46 -0700 To: Seun Ojedeji From: S Moonesamy In-Reply-To: References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <6.2.5.6.2.20140724231216.0dedca00@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/zailyqfs7ISWLnKHGBNfbz9bfMk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:33:25 -0000 Hi Seun, At 00:58 25-07-2014, Seun Ojedeji wrote: >What difference does that make ;) It would be an internal IETF discussion. I am familiar with the (IETF) process rules. Regards, S. Moonesamy From nobody Fri Jul 25 04:44:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583AC1B2801 for ; Fri, 25 Jul 2014 04:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij-Q-eURZVH6 for ; Fri, 25 Jul 2014 04:44:10 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A081B27B5 for ; Fri, 25 Jul 2014 04:44:09 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so4061566wes.29 for ; Fri, 25 Jul 2014 04:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GuAF1mpvHbJLDkH4cy+GY1JAK9XhM23wDvKE5mNz4oQ=; b=wiL4haLtHpuympzQufefnuuvzvsLupb9eBMJtFdiI0LVNvq6jG/n1wtWaa+oLbjkJU jGxi8PpGb/TlW6a+pP1d71c0zCUMnJncGOsc6jLtlkNZ8iN7Oc5sZemC9OO5q4o1gSZE uKkAaK5i1vT/8/KlzcXM0W4IHhLyang6njS/WEPsVXftub4JQl8zGvYa2wcPpzQegfwl b5ug7YxsjyDSsGcD6J6MYDbPyErTInfL2QQHUX8QI23AzHheWuisVjsvsGK25U7gnytl syMdZDThi/YHfckO9HLKt2mlcAwfcqSRx+r4oUqVtFbZ0ZGsdQpdqaFu9uavLiHziUHp d6NQ== X-Received: by 10.194.243.200 with SMTP id xa8mr20671736wjc.97.1406288647072; Fri, 25 Jul 2014 04:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.162.195 with HTTP; Fri, 25 Jul 2014 04:43:36 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140725042552.07760120@elandnews.com> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <6.2.5.6.2.20140724231216.0dedca00@elandnews.com> <6.2.5.6.2.20140725042552.07760120@elandnews.com> From: Seun Ojedeji Date: Fri, 25 Jul 2014 12:43:36 +0100 Message-ID: To: S Moonesamy Content-Type: multipart/alternative; boundary=089e01493e5442b2a104ff03175c Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/KqhuByTDq-rPIB8JSt5Br_wjvpc Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:44:14 -0000 --089e01493e5442b2a104ff03175c Content-Type: text/plain; charset=UTF-8 On Fri, Jul 25, 2014 at 12:31 PM, S Moonesamy wrote: > Hi Seun, > > At 00:58 25-07-2014, Seun Ojedeji wrote: > >> What difference does that make ;) >> > > It would be an internal IETF discussion. I am familiar with the (IETF) > process rules. > Didn't know it was a cabal settings ;) Could you perhaps point to that process url that restrict you as such? Cheers! > > Regards, > S. Moonesamy > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * The key to understanding is humility - my view ! --089e01493e5442b2a104ff03175c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 25, 2014 at 12:31 PM, S Moonesamy <sm+ietf@elandsys.com>= wrote:
Hi Seun,

At 00:58 25-07-2014, Seun Ojedeji wrote:
What difference does that make ;)

It would be an internal IETF discussion. =C2=A0I am familiar with the (IETF= ) process rules.

Didn't know it was= a cabal settings ;) Could you perhaps point to that process url that restr= ict you as such?

Cheers!

Regards,
S. Moonesamy



--
------= ------------------------------------------------------------------
Seun Ojedeji,
Federal University Oye-E= kiti
web:=C2=A0 =C2=A0 =C2=A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

The key to understanding is humility - my v= iew !

--089e01493e5442b2a104ff03175c-- From nobody Fri Jul 25 04:47:24 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007351B27CF for ; Fri, 25 Jul 2014 04:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAXDRdXuisEq for ; Fri, 25 Jul 2014 04:47:21 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 19BB61B27B5 for ; Fri, 25 Jul 2014 04:47:21 -0700 (PDT) Received: from dummy.name; Fri, 25 Jul 2014 11:47:20 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Steve Crocker In-Reply-To: <53D23F93.4050002@gmail.com> Date: Fri, 25 Jul 2014 07:47:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2FD26F0B-73B4-4D01-9FC8-F4351609435B@shinkuro.com> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <53D23F93.4050002@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ScKpU8-4upM_FRfu6wr2jIOmtvs Cc: Avri Doria , John Curran , S Moonesamy , internetgovtech@iab.org, "Stephen D. Crocker" , =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:47:23 -0000 On Jul 25, 2014, at 7:29 AM, Brian E Carpenter = wrote: >> ICANN is working on a new round of gTLDs or some such. Of course they >> exclude already reserved TLDs, but not stuff that might be coming up >> (because they don't know it). >=20 > That's already a failure of coordination. I don=92t understand the basis for the above statements. ICANN has not yet begun formulating the next round of gTLDs. As part of = the process, there will be consultation on what issues arose during the = first round. Consultation with the IETF re current and future reserved = names is definitely and obviously part of what needs to be included. There are multiple avenues of coordination between the IETF and ICANN. = The coordination is broad and deep. Some of it is structural and some = is pragmatic. It is ongoing and effective. The last important incident = of uncoordinated activity that I=92m aware was in another dimension = entirely, viz the scheduling of meetings, and that was dealt with quite = firmly. Steve From nobody Fri Jul 25 05:36:16 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393891A0271 for ; Fri, 25 Jul 2014 05:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoERNTC3igYu for ; Fri, 25 Jul 2014 05:36:11 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AC11A0028 for ; Fri, 25 Jul 2014 05:36:11 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so4271555wes.33 for ; Fri, 25 Jul 2014 05:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=J5lPNM2YFCtvLtihQGzq+k1bkBeX6RGB8sc8CJyaN3I=; b=yRSuL6+CtVBI1iIiyW9h+Hq4OBs0Hncl/Id1NQ1fSFqo0nAF30DFpy/2dU17HlARD1 wTMSB+t+iGkPrpG6Bd9m54+D93E5rv14PgGMvPuSJFxV7zOc+yTLaqzx027yWqJ9fN5w +s8CuCDy3kQGInbqn2V73V6k5FGwVbhdYhqDs8jQ70WGHT7/xnY1qrAgTa7rKWBFTWVE BecaoTwXLQooaLsF2YHw3j5aGTTDJm6QXMRpTDR2wfOgDMJugenLvVoPCCjN4c+QQMPc RZEnJRxEyn0W5lGwnHMVBE4vJI/DVg1R/aQ7+DPsTXwx/7nkYmmM5FQ7YdWR3ZXFx2cG G8zA== X-Received: by 10.180.182.131 with SMTP id ee3mr4661839wic.37.1406291769944; Fri, 25 Jul 2014 05:36:09 -0700 (PDT) Received: from [31.133.160.177] (dhcp-a0b1.meeting.ietf.org. [31.133.160.177]) by mx.google.com with ESMTPSA id hp6sm5459806wib.23.2014.07.25.05.36.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 05:36:09 -0700 (PDT) Message-ID: <53D24F41.7030006@gmail.com> Date: Sat, 26 Jul 2014 00:36:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Steve Crocker References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <53D23F93.4050002@gmail.com> <2FD26F0B-73B4-4D01-9FC8-F4351609435B@shinkuro.com> In-Reply-To: <2FD26F0B-73B4-4D01-9FC8-F4351609435B@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HG8HBe1Vq2bLnsnUtOfYWgQH5nw Cc: internetgovtech@iab.org, =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Avri Doria , John Curran , S Moonesamy Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:36:13 -0000 Steve, You're quoting from a discussion of a strawman hypothetical case as if were an assertion about the real world. I meant that if such a situation were to arise, it would mean that there had been a failure of coordinatio= n. We'd be better off having this conversation in French with correct use of the conditional subjunctive ;-). Regards Brian On 25/07/2014 23:47, Steve Crocker wrote: > On Jul 25, 2014, at 7:29 AM, Brian E Carpenter wrote: >=20 >>> ICANN is working on a new round of gTLDs or some such. Of course they= >>> exclude already reserved TLDs, but not stuff that might be coming up >>> (because they don't know it). >> That's already a failure of coordination. >=20 > I don=E2=80=99t understand the basis for the above statements. >=20 > ICANN has not yet begun formulating the next round of gTLDs. As part o= f the process, there will be consultation on what issues arose during the= first round. Consultation with the IETF re current and future reserved = names is definitely and obviously part of what needs to be included. >=20 > There are multiple avenues of coordination between the IETF and ICANN. = The coordination is broad and deep. Some of it is structural and some i= s pragmatic. It is ongoing and effective. The last important incident o= f uncoordinated activity that I=E2=80=99m aware was in another dimension = entirely, viz the scheduling of meetings, and that was dealt with quite f= irmly. >=20 > Steve >=20 >=20 From nobody Fri Jul 25 05:56:55 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFCE1B2831 for ; Fri, 25 Jul 2014 05:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APEYilbUQRAw for ; Fri, 25 Jul 2014 05:56:53 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id B15EB1B282A for ; Fri, 25 Jul 2014 05:56:53 -0700 (PDT) Received: from dummy.name; Fri, 25 Jul 2014 12:56:53 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Steve Crocker In-Reply-To: <53D24F41.7030006@gmail.com> Date: Fri, 25 Jul 2014 08:56:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <53D23F93.4050002@gmail.com> <2FD26F0B-73B4-4D01-9FC8-F4351609435B@shinkuro.com> <53D24F41.7030006@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/rd4iR2GI_HI9B_DS_aBD0S8d1VA Cc: Avri Doria , S Moonesamy , internetgovtech@iab.org, "Stephen D. Crocker" , =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , John Curran Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:56:54 -0000 :) Thanks. On Jul 25, 2014, at 8:36 AM, Brian E Carpenter = wrote: > Steve, >=20 > You're quoting from a discussion of a strawman hypothetical case as if > were an assertion about the real world. I meant that if such a = situation > were to arise, it would mean that there had been a failure of = coordination. >=20 > We'd be better off having this conversation in French with correct > use of the conditional subjunctive ;-). >=20 > Regards > Brian >=20 > On 25/07/2014 23:47, Steve Crocker wrote: >> On Jul 25, 2014, at 7:29 AM, Brian E Carpenter = wrote: >>=20 >>>> ICANN is working on a new round of gTLDs or some such. Of course = they >>>> exclude already reserved TLDs, but not stuff that might be coming = up >>>> (because they don't know it). >>> That's already a failure of coordination. >>=20 >> I don=92t understand the basis for the above statements. >>=20 >> ICANN has not yet begun formulating the next round of gTLDs. As part = of the process, there will be consultation on what issues arose during = the first round. Consultation with the IETF re current and future = reserved names is definitely and obviously part of what needs to be = included. >>=20 >> There are multiple avenues of coordination between the IETF and = ICANN. The coordination is broad and deep. Some of it is structural = and some is pragmatic. It is ongoing and effective. The last important = incident of uncoordinated activity that I=92m aware was in another = dimension entirely, viz the scheduling of meetings, and that was dealt = with quite firmly. >>=20 >> Steve >>=20 >>=20 >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Fri Jul 25 10:25:04 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107B81A03E7 for ; Fri, 25 Jul 2014 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyi7Us_eY-TL for ; Fri, 25 Jul 2014 10:25:02 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFF61A01E2 for ; Fri, 25 Jul 2014 10:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=zObx3hGnPxit5MF7q0dkmyNYz3EOT9L7GCBSptfDmQ8=; b=iqzWwOBDeE3giS1/UZ5lutl1bfcZGgVQ189CUpX6SzWdbmUStkRE07ltWzk/bMM2hVmOv+r0tkLErhaW970F6Yh9mN9ht1JONXuEAtINHj6r7KP66CicOpMwVWZ7AVywKGbiDQc1CvVUIokxCaHKPVlRlbAf38jYrVtZlRxuj1I=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:49628 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAjEl-0007oy-Pq for internetgovtech@iab.org; Fri, 25 Jul 2014 10:25:00 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_A95D4F28-2CD6-4892-AB28-89B76EA94440"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <3704DAB7-2748-45A6-8373-F606CE152390@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 25 Jul 2014 13:24:55 -0400 References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org> <53D1C521.3030809@it.aoyama.ac.jp> <53D23F93.4050002@gmail.com> <2FD26F0B-73B4-4D01-9FC8-F4351609435B@shinkuro.com> <079CDDE7-D1CF-4A7C-A413-395CEC4C100A@cs.georg etown.edu> To: internetgovtech@iab.org In-Reply-To: <079CDDE7-D1CF-4A7C-A413-395CEC4C100A@cs.georgetown.edu> X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 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 - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8KQ5uC4iz041ihkzKyIeweBdj9s Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:25:03 -0000 --Apple-Mail=_A95D4F28-2CD6-4892-AB28-89B76EA94440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would offer John=92s scenario is not totally made up, in that = something similar already happened. The real situation provides proof = that we can work with ICANN. What I am thinking of is the SLD block = list. That was a community effort, recognized reality, and brought = ICANN, IETF, manufacturers, ISP, etc. together to work through the = problem. So, I am not desirous of formalizing some sort of process that = might have worked for the last war (SLD=92s, or gTLD collisions) when = the next war is something completely different. I am OK with our = informal relationship, as ICANN has shown it can work with us, and we = have shown we can work with ICANN. On Jul 25, 2014, at 7:47 AM, Steve Crocker wrote: > On Jul 25, 2014, at 7:29 AM, Brian E Carpenter = wrote: >=20 >>> ICANN is working on a new round of gTLDs or some such. Of course = they >>> exclude already reserved TLDs, but not stuff that might be coming up >>> (because they don't know it). >>=20 >> That's already a failure of coordination. >=20 > I don=92t understand the basis for the above statements. >=20 > ICANN has not yet begun formulating the next round of gTLDs. As part = of the process, there will be consultation on what issues arose during = the first round. Consultation with the IETF re current and future = reserved names is definitely and obviously part of what needs to be = included. >=20 > There are multiple avenues of coordination between the IETF and ICANN. = The coordination is broad and deep. Some of it is structural and some = is pragmatic. It is ongoing and effective. The last important incident = of uncoordinated activity that I=92m aware was in another dimension = entirely, viz the scheduling of meetings, and that was dealt with quite = firmly. >=20 > Steve >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --Apple-Mail=_A95D4F28-2CD6-4892-AB28-89B76EA94440 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT0pLoAAoJEDY/T2tCIPW3oSIP/38dPkzPz5UlpXOSdquUNlgl 5lXP4N1kNNF99ZBxHwhSDrELEWEvTnyFCuP8yAu+Rgg8xU+GACKY/THlfUGAGmG3 iBXklcKeKvWsz1/N0a0OQrAaDhiZIjFw5L0Urihd6BgfRTuDSrkCw261TlX58kUc 66mPa3cuIRgTgvx/FXXzibaJNT70psaCzbSeoV+opJFHTRwrI3Th4+zL9YMAzOT2 ftFPPqJScsIOrcg/fLWtU2akClIxofKaOuZHsFyyeDZQzOlY2DRNS+uZ8x8tqYxY nd6L8Qqb6pcKKjK50oOyZUYas1RMZBlFGVcp9PXXFxhEP4DpchaKR5cuYrJiSlgj /7DgZxh9kn7qOxb2b8gDrhYX7e5VD0BPJmfJEzZ6AWIWn95LEnqkvAT5WtSvGmDj KZD0uTE2WrWreJm1A8Pf7ulRKtQVdmyBqcCWoX+69xu5H1EAVxnn9ju4tsi+WVxz s8TbB3AjvRU0V3bN72cYknGhod5MTBsig0sC/Ycvhz9Kv9Vejn6fLsfOwwbE8Q7z MSaHXaCWVWBxxid/FVDO95YN7LCyY10Xy0S2eWbDZQWL3y2XwE/xnS8rxzCEXNHM rvdDGpnYVgGrBy85i0y4KIwLYnKnYleb0H9lbYh2mUn0fH5ehoMFVSjPJ9hThGVb ydmMZaJ+BUg8oX5glyo0 =Ay35 -----END PGP SIGNATURE----- --Apple-Mail=_A95D4F28-2CD6-4892-AB28-89B76EA94440-- From nobody Sun Jul 27 16:18:54 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C292D1B2794 for ; Sun, 27 Jul 2014 16:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du7tylw00R8h for ; Sun, 27 Jul 2014 16:18:49 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DD41B2791 for ; Sun, 27 Jul 2014 16:18:49 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so7580728qge.24 for ; Sun, 27 Jul 2014 16:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WJJjx4UPJ3Ar2xFLIycWC9LIvIGilpisgRhbo2BdLJ0=; b=hvGoc27QaK357OQbsQj0ki+FKRcg7H5B59bKxAWowPGSAe77HLa0r4AEFMNixKe2nF AQFTZlWhmLCZgyCcrVIzgIvUjaemEt6m7RyBrKNmKrzK9Q3fgHR+0qNRvTvXOdSN1odE tz6ccnvnIQzLUN41mCpI+EfbI3FXVuR4fVMnu9I0icXHpPVGDbIOZjZk8jr56phIt3Gh 3LqYMIrbYXzVpy1R7MFMShgTop/hCPvLbQ+VSTvpvOvE5/2g121lCJlX84R81E37zkGA lkZvJjGACy4Ou7499KYvVvLqTAVdHNF9fy47s9cgiUIvgvA+wiVduM/9pG2WvB9p98lj PKVg== X-Received: by 10.140.51.172 with SMTP id u41mr48053858qga.69.1406503128344; Sun, 27 Jul 2014 16:18:48 -0700 (PDT) Received: from ?IPv6:2601:6:3a80:77e:31f8:a599:4a51:2780? ([2601:6:3a80:77e:31f8:a599:4a51:2780]) by mx.google.com with ESMTPSA id a6sm7503237qay.42.2014.07.27.16.18.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 16:18:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <53D016B6.2020000@gih.com> Date: Sun, 27 Jul 2014 19:18:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71C98EEB-A1CC-4CE6-86C2-F2370F6E9661@gmail.com> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> To: Olivier MJ Crepin-Leblond X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/444WVq6KgTCtAj5cxw5j2_adnjw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 23:18:51 -0000 Olivier, Avri, I'm not sure I agree that "new accountability mechanisms [are] needed = for *all* functions." It seems to me entirely possible that in examining = needs for the future, and analyzing how things might change in the = absence of NTIA, we will find that in some cases, the mechanisms we = already have are perfectly adequate.=20 I've reviewed the graphic Olivier refers to, and I'm not convinced that = whoever wrote it meant to force an assumption that "new accountability = mechanisms" are required for all the IANA functions, only that = accountability mechanisms need to be documented and understood. Given = also how hard ICANN has tried to avoid being prescriptive in this = process where it wasn't necessary, and how carefully the ICG is guarding = its self-determination so far, I'm not sure I'd regard such a view as = the last word on the subject.=20 I'm also reminded that ICANN is undertaking a discussion about replacing = NTIA's supposed general accountability role ("adults in the room") with = an "ICANN Accountability " examination process of some kind, which I'd = thought was intended to look at such global accountability concerns = separately from specifics of the day-to-day IANA functions. We can hope = to see that take more definite shape soon. best, Suzanne On Jul 23, 2014, at 4:10 PM, Olivier MJ Crepin-Leblond = wrote: > I'd just like to register my agreement with Avri on this. >=20 > Please be so kind to review the table in this document: > = https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr1= 4-en.pdf >=20 > I clearly points to new accountability mechanisms needed for *all* > functions. >=20 > Kindest regards, >=20 > Olivier > (own views) >=20 > On 22/07/2014 13:30, Avri Doria wrote: >>=20 >> On 22-Jul-14 06:00, Suzanne Woolf wrote: >>> NTIA today has nothing to do with "accountability mechanisms for = each >>> of the parties administering each parameter space" under IETF policy >>> management, and touches only a very small handful of general purpose >>> parameter spaces associated with IETF protocols (DNS and IP). >> I disagree. NTIA provides a giant accountability function. >>=20 >> Just about everyone goes running to NTIA whenever something they = don't >> like happens. And the fine folks at NTIA finesse the situation and = get >> things back on the right track. I believe it happens all the time. >>=20 >> NTIA are the adults in the room and we better have adequate >> accountability all around when they step out of their role. >>=20 >> avri >>=20 >> _______________________________________________ >> Internetgovtech mailing list >> Internetgovtech@iab.org >> https://www.iab.org/mailman/listinfo/internetgovtech >>=20 >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Sun Jul 27 20:11:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7B21A004A for ; Sun, 27 Jul 2014 20:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6K4F_geLNuE for ; Sun, 27 Jul 2014 20:11:14 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 59CD91A0016 for ; Sun, 27 Jul 2014 20:11:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B11CC2CCE4; Mon, 28 Jul 2014 06:11:12 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLOMnH0mY_fB; Mon, 28 Jul 2014 06:11:03 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id E2E872CC48; Mon, 28 Jul 2014 06:11:01 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <71C98EEB-A1CC-4CE6-86C2-F2370F6E9661@gmail.com> Date: Sun, 27 Jul 2014 23:10:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <569D16B2-DC42-4677-9681-A0CC4E75AC07@piuha.net> References: <53CD1E8A.1060804@acm.org> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <71C98EEB-A1CC-4CE6-86C2-F2370F6E9661@gmail.com> To: Suzanne Woolf X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8BEhSRHqu9RZ3dqhecxhQ_JswMs Cc: Olivier MJ Crepin-Leblond , internetgovtech@iab.org Subject: Re: [Internetgovtech] Cross community X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 03:11:19 -0000 I have not had time to review this thread or post when the IETF was = going on, however, I just wanted to echo the points Suzanne made. I am = in full agreement with them. Jari