From nobody Sat Mar 1 02:45: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 8EE131A0103 for ; Sat, 1 Mar 2014 02:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.492 X-Spam-Level: X-Spam-Status: No, score=-4.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FU_ENDS_2_WRDS=0.255, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 fe0kq45RaQjZ for ; Sat, 1 Mar 2014 02:45:02 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 36C7D1A0076 for ; Sat, 1 Mar 2014 02:45:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9EAF9D9302; Sat, 1 Mar 2014 11:44:58 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UKCoMY5u8P0n; Sat, 1 Mar 2014 11:44:58 +0100 (MET) Received: from [10.100.50.232] (unknown [158.230.100.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AEEA3D9300; Sat, 1 Mar 2014 11:44:57 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_908EF2B4-1FCF-4586-B9C6-04D9A25ACB3C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <53116F75.1050208@cis-india.org> Date: Sat, 1 Mar 2014 10:44:53 +0000 Message-Id: <25CC3F72-AD7E-418B-B9A4-3735AE1888FB@tik.ee.ethz.ch> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> To: Pranesh Prakash X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/26RuOK1Ywp7UgXy_SvdSw-OSMD0 Cc: Russ White , internetgovtech@iab.org, Andrea Glorioso , S Moonesamy Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 10:45:05 -0000 --Apple-Mail=_908EF2B4-1FCF-4586-B9C6-04D9A25ACB3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Mar 2014, at 5:26, Pranesh Prakash wrote: > Russ White [2014-02-26 15:12:56]: >>=20 >>> And this, I think, illustrates the main reason why the IETF's "show = up on >> the >>> list" policy _doesn't_ lead to increased input from policymakers: = the key >>> problem here seems to be to be the language barrier. We deal with >>> mechanisms, policy people with policy, and even then the = vocabularies for >>> the same concepts are often wildly different. >>>=20 >>> We (generally) try very hard in the IETF to define protocols which = are >>> "situation agnostic"; this comes from the fact that separation of >> mechanism >>> (how you do things) and policy (what exactly it is you want to do) = is good >>> engineering practice, not least because what I want to do may not be = what >>> you want to do, and what we both want to do may change over time. >>> Experience has shown that when we do embed policy, we create = protocols >>> that are less scalable, less capable, less successful. >>=20 >> +1 >>=20 >> Thanks for saying this, Brian -- you expressed it perfectly. >=20 > I couldn't disagree more strongly with this :) Thank you for perfectly illustrating my point about "wildly different = vocabularies" :) > Protocol decisions whether it is the trust system which underlies BGP, Not a member of the routing tribe so I can't answer questions about the = BGP trust model in any sort of detail, but I would characterize BGP's = trust model as "technically expedient" and "risk inconsiderate" rather = than "political".=20 > the CA system, My opinions about the mess the Web PKI has become preclude me from = speaking objectively about it, but you're right, I can't disagree. I'll = note that the IETF inherited most of the decisions there. > or the attempting to make all public XMPP servers use s2s and c2s = encryption by default, Decisions taken in reaction to the revelations about pervasive = surveillance are, agreed, inherently political. > or many other kinds of decisions, are inherently deeply political. > The decision to require all SMTP servers to only prepend to the = "received" header, has political ramifications. Indeed. As does the very decision to have a packet-switched network with = source _and_ destination addresses at the network layer. I'll point out = that the people who make all this stuff work day to day really like both = of these decision, because they make it not-impossible to fix things = when they break. > The attempt by so many people to "fix" what they see as the broken = system of e-mail (since until further changes are made[1] there is = neither metadata integrity (for the most part, discounting that which = DKIM covers) nor is there any possibility of concealing metadata) is = also deeply political. >=20 > The question of whether to allow for patent-encumbered standards is a = deeply political question.[2][3][4] Heh. I find myself forced to agree with you here. > It is, imho, futile to pretend that engineers don't make political = decisions all the time. "That engineers don't make decisions with political implications all the = time" I can agree with. Cheers, Brian > [1]: http://tools.ietf.org/html/draft-cailleux-secure-headers-04 > [2]: http://www.ietf.org/rfc/rfc3979.txt > [3]: = http://www.fosspatents.com/2013/03/nokia-comments-on-vp8-patent.html > [4]: http://www.ietf.org/mail-archive/web/ipr-wg/current/msg02436.html >=20 > --=20 > Pranesh Prakash > Policy Director, Centre for Internet and Society > T: +91 80 40926283 | W: http://cis-india.org > ------------------- > Access to Knowledge Fellow, Information Society Project, Yale Law = School > M: +1 520 314 7147 | W: http://yaleisp.org > PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech --Apple-Mail=_908EF2B4-1FCF-4586-B9C6-04D9A25ACB3C 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 iQEcBAEBCgAGBQJTEbomAAoJENt3nsOmbNJctdEH/icWlId23dSdvySGU277iwiL UTir3xizWEIq/JpmUaY5i4WBNe2MsJFQvx6w32QZBv0kiCc4c5ZB3/V1eQzo6Ez1 gPCL+0F+o3h5mcFXH8P3HPBXZ8oIDZ2lYzuErrp4ECHLwuXVGi1F1Q1QlForhenJ a503XXTD2vo3iriZsk9ASrIY/fytRgtiHnZuL4qE0b5KAynkuXVpk50JMH3IkaSr bjLr9OSQ44DzshLAIwU0t6JL2ALtOWDIkGFgewE9ownFETW5r3wbwZ/cifswg9/x bxHaDqpKvba4sDtlzG4IcI5i3PZKNcoufldC7N8PAj4zB2iqk6oCEnHpn54p4VI= =AkpS -----END PGP SIGNATURE----- --Apple-Mail=_908EF2B4-1FCF-4586-B9C6-04D9A25ACB3C-- From nobody Sat Mar 1 05:22: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 0C30B1A07C8 for ; Sat, 1 Mar 2014 05:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 Y1yE8jkJNLav for ; Sat, 1 Mar 2014 05:22:03 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id D6D5E1A0722 for ; Sat, 1 Mar 2014 05:22:02 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:51679 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WJjrS-00047d-EN; Sat, 01 Mar 2014 13:21:50 +0000 From: "Russ White" To: "'Pranesh Prakash'" , "'Brian Trammell'" , "'Andrea Glorioso'" References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> In-Reply-To: <53116F75.1050208@cis-india.org> Date: Sat, 1 Mar 2014 08:21:48 -0500 Message-ID: <016101cf3551$33df5090$9b9df1b0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJMFih2b/pqIL5HvUFCBvP9zfnmIAHwS+XUAcF8GWsC7qp9sgH+vKWhAszX6ToCRYMQCgN5j4kmAhEOGroCAPUEawCT+vThAbzUCscA55+McQIrSgWqAmzX6UoCGFPv7QHuQm2omMnOfeA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/h1RcamqEug3b6BrSwShspKkAqhQ Cc: internetgovtech@iab.org, 'S Moonesamy' Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 13:22:05 -0000 > > Thanks for saying this, Brian -- you expressed it perfectly. >=20 > I couldn't disagree more strongly with this :) >=20 > Protocol decisions whether it is the trust system which underlies BGP, = the CA > system, or the attempting to make all public XMPP servers use s2s and = c2s > encryption by default, or many other kinds of decisions, are = inherently > deeply political. So long as you define, "political," as "having anything to do with the = actual operation of a network," then you are right. In the same sense, = all laws are enactment of a moral system (you not only can't "not = legislate morality," you must always actually "legislate morality"). But = the point of engineering, particularly successful engineering, is to = remote politics and policies, as much as possible, from the equation, = and to focus on solving a specific set of technical problems at hand.=20 What you seem to be saying is that because there are implicit political = results from the standards making process, we should abandon the = pretense that standards have no political overtones, and hence we should = bring politics _explicitly_ into the process -- and not just the = politics of patents, or the politics of privacy, but the entire gamut of = politics. I don't see how widening the problem is going to help clarify = and inform the decision making around technical issues that should be = properly discussed in the IETF. Can you give me an example of where you think the injection of politics = at the level being discussed here (not patents, and not privacy), would = create a better technical standard? What specific "social impact," can = you point to that should be considered in BGP, for instance? :-) Russ From nobody Sat Mar 1 06:27: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 B9EA01A0AF3 for ; Sat, 1 Mar 2014 06:27:28 -0800 (PST) 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 7_A9bh_uuI26 for ; Sat, 1 Mar 2014 06:27:26 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2421A0AA7 for ; Sat, 1 Mar 2014 06:27:25 -0800 (PST) Received: from pool-108-45-30-69.washdc.fios.verizon.net ([108.45.30.69] helo=[192.168.1.9]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WJksn-000OFd-PT; Sat, 01 Mar 2014 14:27:17 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.45.30.69 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/5xLtyzR18GE1+ENHRLUtv Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Curran In-Reply-To: <016101cf3551$33df5090$9b9df1b0$@riw.us> Date: Sat, 1 Mar 2014 09:27:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33d f5090$9b9df1b0$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9E8GkXJrEzkGzk2BILaSBV9lpfE Cc: internetgovtech@iab.org, Andrea Glorioso , Pranesh Prakash , S Moonesamy , Brian Trammell Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 14:27:29 -0000 On Mar 1, 2014, at 8:21 AM, Russ White wrote: > So long as you define, "political," as "having anything to do with the = actual operation of a network," then you are right. In the same sense, = all laws are enactment of a moral system (you not only can't "not = legislate morality," you must always actually "legislate morality"). But = the point of engineering, particularly successful engineering, is to = remote politics and policies, as much as possible, from the equation, = and to focus on solving a specific set of technical problems at hand.=20 Focusing on the technical to the extent possible is a good goal and = matches=20 the expertise commonly present at the IETF. > What you seem to be saying is that because there are implicit = political results from the standards making process, we should abandon = the pretense that standards have no political overtones, and hence we = should bring politics _explicitly_ into the process -- and not just the = politics of patents, or the politics of privacy, but the entire gamut of = politics. I would hope that is not what Pranesh is suggesting; I believe he is=20 suggesting is that protocols often have certain political or social=20 values embedded in them, and we should not be blind to that possibility. I also believe that there can be implied social/economic values embedded in a policy (a common example include privacy, where many IETF folks = have=20 fairly consistent values and thus strive not to make = personally-identifiable=20 values visible globally, etc.) If the suggestion is to be explicitly adding discussions of economic or=20= social values into the process, I would also doubt that being a valuable=20= role for the IETF to serve. > I don't see how widening the problem is going to help clarify and = inform the decision making around technical issues that should be = properly discussed in the IETF. >=20 > Can you give me an example of where you think the injection of = politics at the level being discussed here (not patents, and not = privacy), would create a better technical standard? What specific = "social impact," can you point to that should be considered in BGP, for = instance? We have to face the fact that the remarkable success of the Internet = means=20 that it very difficult for a given government or community to _not_ use = IETF=20 protocols and still achieve global interoperability. This in turn only=20= reinforces the need for protocol development processes which are open to=20= all interested parties, and transparency in decision making. When we need to consider factors other than purely technical merit, it = may=20 result in social, political, or economic tradeoffs being integrated into = the=20 protocols, and it would be best to do so based on extremely widely held = norms=20 and values. To avoid the IETF having to specifically hold discussions = to=20 develop positions of economic or social values and norms, it would be = best to=20 rely instead on explicit statements developed elsewhere when available = (e.g.=20 the EU's personal data privacy directive, UN GA privacy rights on the = Internet with = respect to perpass), as the wide applicability helps in avoiding specifications = which=20 might be in conflict in a significant region and thus contrary to the = goal of=20 having prototols which facilitate global Internet communications. Mechanisms should be provided for promoting high-level awareness to all=20= interested parties (including governments and other stakeholders such as=20= civil society) of specification development which has significant = potential=20 for incorporating public policy tradeoffs in the final specifications;=20= not so that the political discussion can be brought to the IETF, but so=20= that parties that follow and potentially even point out any widely = endorsed statements of norms and values which the IETF should be aware of during = the protocol development activities. FYI, /John From nobody Sat Mar 1 07:05: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 3A66B1A1EF4 for ; Sat, 1 Mar 2014 07:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 9ciHDyjx8Aw7 for ; Sat, 1 Mar 2014 07:05:35 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7C1A1F1B for ; Sat, 1 Mar 2014 07:05:35 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:61444 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WJlTa-0004sM-7H; Sat, 01 Mar 2014 15:05:18 +0000 From: "Russ White" To: "'John Curran'" References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33d f5090$9b9df1b 0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> In-Reply-To: <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> Date: Sat, 1 Mar 2014 10:05:16 -0500 Message-ID: <020f01cf355f$a7f7bdb0$f7e73910$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJMFih2b/pqIL5HvUFCBvP9zfnmIAHwS+XUAcF8GWsC7qp9sgH+vKWhAszX6ToCRYMQCgN5j4kmAhEOGroCAPUEawCT+vThAbzUCscA55+McQIrSgWqAmzX6UoCGFPv7QHuQm2oAbnx4KMDFjYatZija+sg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/k-uPLb2zy902sOJpOmcYw6ynIzk Cc: internetgovtech@iab.org, 'Andrea Glorioso' , 'Pranesh Prakash' , 'Brian Trammell' , 'S Moonesamy' Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 15:05:39 -0000 > When we need to consider factors other than purely technical merit, it may > result in social, political, or economic tradeoffs being integrated into the > protocols, and it would be best to do so based on extremely widely held > norms and values. To avoid the IETF having to specifically hold discussions to > If the suggestion is to be explicitly adding discussions of economic or social > values into the process, I would also doubt that being a valuable role for the > IETF to serve. These two statements are contradictory. Either the IETF should avoid all but the most bare and obvious political issues that relate to the formation of standards directly (such as patents) and the operational qualities of the network (such as privacy), or the IETF should explicitly include politics in the process at a social level. We can't say, "the IETF has no expertise here, but it must inject itself into this debate." Privacy is a perfect example. Many folks are upset at pervasive monitoring efforts. Others are upset at the collection of information by large corporations. But we can resolve this to a simple usability issue -- trust -- and leave the other politics out of it. If users can't trust their information to be private, they won't (or shouldn't, since we've discovered that combining a few carrots with a large dose of obfuscation often works quite well in getting users to give up information they probably shouldn't be giving up) use the technology. Therefore, if the IETF intends for these internet protocols to be used, we must attend to the perception (real or not) that it is easy to monitor communications transmitted using these protocols. There may be a thousand policy reasons to support or oppose such efforts, but by distilling the political into the narrowest range possible and phrasing the problem in an operational way, the engineering problem can be examined and dealt with. Bringing as much of the political as possible back into the picture isn't going to clarify the process, it's going to make the process worse. In other words, of course standards have political implications -- but the point of the process is to remove the political implications as much as possible, so the problem becomes as close to a pure technical problem as possible. You might not be able to do this perfectly, but I've not seen an actual workable suggestion put forward as an alternative. > We have to face the fact that the remarkable success of the Internet means > that it very difficult for a given government or community to _not_ use IETF > protocols and still achieve global interoperability. This in turn only reinforces > the need for protocol development processes which are open to all > interested parties, and transparency in decision making. Can you point me to some specific part of the IETF process, as it exists today, which is "not open," to government participation? In what way is it "not open?" If the process is to be changed to "allow governments a seat at the table," we need much more than, "standards are political and the process isn't open." We need specific proposals to evaluate -- and hopefully the end goal, rather than just some intermediary "starting point." It's often the case in our world that we have a lot of "camels in the tent," problems; I would like to avoid the nose unless we know what the whole camel looks like. :-) Russ From nobody Sat Mar 1 07:29: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 0CDD81A02A2 for ; Sat, 1 Mar 2014 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 9NJkyFxUPdSY for ; Sat, 1 Mar 2014 07:29:48 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E01F41A0214 for ; Sat, 1 Mar 2014 07:29:47 -0800 (PST) Received: from mx1.yitter.info (unknown [130.129.153.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 03E218A031 for ; Sat, 1 Mar 2014 15:29:44 +0000 (UTC) Date: Sat, 1 Mar 2014 10:29:42 -0500 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140301152942.GF2941@mx1.yitter.info> References: <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/-eRfu5eWbk23c82czKsp4sl8uRA Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 15:29:49 -0000 On Sat, Mar 01, 2014 at 09:27:13AM -0500, John Curran wrote: > We have to face the fact that the remarkable success of the Internet means > that it very difficult for a given government or community to _not_ use IETF > protocols and still achieve global interoperability. That's not merely a "fact", it's a tautology. If you want global interoperability ("with the Internet" is implied in your original), then you have to use Internet protocols. > This in turn only reinforces the need for protocol development > processes which are open to all interested parties, and transparency > in decision making. I agree, but I think it's important to recognise that many of the people who appear to want the pony named "using the Internet without using IETF protocols" actually don't want a process that is open to all interested, or transparency in decision making. Many of them instead wish the decisions to be taken by treaty bodies in closed rooms. I think it is not surprising that people are suspicious of importing "political considerations" into the protocol-making discussion, because that looks like a Trojan horse for "takeover by treaty organizations". > When we need to consider factors other than purely technical merit, it may > result in social, political, or economic tradeoffs being integrated into the > protocols, I strongly disagree with this approach to describing the question. If we need to include certain social, political, or economic tradeoffs, then those are part of the use cases that the protocol is supposed to be addressing. Therefore, this is not some case of considering factors other than purely technical merit: there's no such thing as "pure technical merit" without the operational conditions expected of the protocol. This is engineering we're supposed to be doing, not mathematics. What we sometimes have to confront, however, is indeed the question of whether this or that tradeoff ought to be on the list. That is, to my way of thinking, the difficulty we're having, but it's not different in kind to the problem developers have always had in understanding what the product and sales people want. Getting the requirements right is hard, and it gets harder the further one gets from being the end user. In the early period of the Internet, approximately all the users _were_ the developers, so figuring out the requirements was probably easier in that you could talk to people and find out their problems. It gets harder the less representative of actual users our population gets. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Mar 1 07:30: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 E97031A02AC for ; Sat, 1 Mar 2014 07:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 EhnsLAU2yFVP for ; Sat, 1 Mar 2014 07:30:20 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id F16B71A0214 for ; Sat, 1 Mar 2014 07:30:19 -0800 (PST) Received: from pool-108-45-30-69.washdc.fios.verizon.net ([108.45.30.69] helo=[192.168.1.9]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WJlrl-000Bmp-Mf; Sat, 01 Mar 2014 15:30:17 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.45.30.69 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/y6S+lCsEuS0LpwvfazAls Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Curran In-Reply-To: <020f01cf355f$a7f7bdb0$f7e73910$@riw.us> Date: Sat, 1 Mar 2014 10:30:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5925BF6E-653E-4C98-B0F4-92F35A77138F@istaff.org> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <"016101cf 3551$3 3d f5090$9b9df1b 0$"@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <020f01cf355f$a7f7bdb0$f7e73910$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/-8UmmCCx8aY4DISjPWJQEmLImcg Cc: internetgovtech@iab.org, Andrea Glorioso , Pranesh Prakash , Brian Trammell , S Moonesamy Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 15:30:23 -0000 On Mar 1, 2014, at 10:05 AM, Russ White wrote: > These two statements are contradictory. Either the IETF should avoid = all but > the most bare and obvious political issues that relate to the = formation of > standards directly (such as patents) and the operational qualities of = the > network (such as privacy), or the IETF should explicitly include = politics in > the process at a social level. We can't say, "the IETF has no = expertise > here, but it must inject itself into this debate." Russ -=20 =20 The exact opposite - the IETF should realize that protocols can indeed=20= embed social/political values, but it should _not_ become a forum for=20= such discussions. Instead, it should strive to make Internet protocols=20= as globally useful as possible, and simply _reference_ those externally=20= developed statements values or norms that it decides to specifically=20 recognize as drivers for particular protocol decisions. > Privacy is a perfect example. Many folks are upset at pervasive = monitoring > efforts. Others are upset at the collection of information by large > corporations. But we can resolve this to a simple usability issue -- = trust > -- and leave the other politics out of it. If users can't trust their > information to be private, they won't (or shouldn't, since we've = discovered > that combining a few carrots with a large dose of obfuscation often = works > quite well in getting users to give up information they probably = shouldn't > be giving up) use the technology. Therefore, if the IETF intends for = these > internet protocols to be used, we must attend to the perception (real = or > not) that it is easy to monitor communications transmitted using these > protocols. There may be a thousand policy reasons to support or oppose = such > efforts, but by distilling the political into the narrowest range = possible > and phrasing the problem in an operational way, the engineering = problem can > be examined and dealt with. Bringing as much of the political as = possible > back into the picture isn't going to clarify the process, it's going = to make > the process worse. If a particular tradeoff is necessary to make the protocol desired by the user community, and that is the driver that the IETF wishes to=20 reference, then that's fine. does not refer to users or trust, and instead defines it has a=20 security problem. Personally, I'd prefer the approach you suggest or prefer referencing a widely accepted statement of human privacy being equally applicable to the Internet - either approach acknowledges the requirement without having the IETF developing its own position on =20 personal privacy applicability on the Internet (an undertaking would=20 indeed encourage having a political discussion at the IETF.) > In other words, of course standards have political implications -- but = the > point of the process is to remove the political implications as much = as > possible, so the problem becomes as close to a pure technical problem = as > possible. You might not be able to do this perfectly, but I've not = seen an > actual workable suggestion put forward as an alternative.=20 I think we're agreeing on the goal ("remove the political implications = as=20 much as possible"), but the question is what to do where it is = unavoidable. My suggestion would be to leverage widely held statements of such = social or political norms rather than having to debate them in the IETF. (and = this=20 is not much different than leveraging international consensus of two = letter=20 codes for reference to countries and subdivisions, another political = matter) > Can you point me to some specific part of the IETF process, as it = exists > today, which is "not open," to government participation? In what way = is it > "not open?" No, the IETF does very well in this respect. =20 > If the process is to be changed to "allow governments a seat at > the table," we need much more than, "standards are political and the = process > isn't open." The process doesn't have to be changed, but the IETF needs to have a = model for how governments engage with it when desired and spend some time = actually explaining that to governments (or run the risk that they'll decide on = other approaches to meet their needs) > We need specific proposals to evaluate -- and hopefully the end > goal, rather than just some intermediary "starting point." I describe an end point; governments should be able to engage in the = existing processes just as any other party; it would, however, be helpful when a = government expresses a particular social/economic requirement if the IETF could = consistently explain that it prefers not to twist the protocol development for one = countries view,=20 but if some widely-held statement of such a norm or value that can be = referenced, that might be worth considering since IETF standards intended to be = scope Internet, i.e. applicable globally. =20 > It's often the case in our world that we have a lot of "camels in the = tent," problems; > I would like to avoid the nose unless we know what the whole camel = looks like. See my prior paragraph for the entire camel I propose letting in; no = change to existing IETF processes, but potentially a clear approach to = responding to governments asking about how to "engage with the IETF" on their = particular social/political topic of interest. FYI, /John From nobody Sat Mar 1 07:36: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 5F7A21A02AC for ; Sat, 1 Mar 2014 07:36:02 -0800 (PST) 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 z2kU0QckBHl8 for ; Sat, 1 Mar 2014 07:36:00 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 61CD81A02EC for ; Sat, 1 Mar 2014 07:35:58 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id y6so4398204igj.0 for ; Sat, 01 Mar 2014 07:35:56 -0800 (PST) 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=1aehwsAV2XzMGNE2B2IRd2LE7NfnPpmWdlSgMfS6GPU=; b=Ot8T08QeCnclEjLNcdyOZayj1RBqWSXPsRtJydyQpePKfe4NOpT5MS+RGLnKqCvgo+ dQZpdiNjOpA1BLbB8WXCWGbzjXPpoGTN3Occ8GUfru28x+wM5gkCwkwlVJkzpq9xPfTG rTFeYvUFM9vcRDZcvxetruOoGucYdQwC23ZdhiMAr0uVbEILxE35I5i61HW5oFJ33RAJ hdWx+XPUmEj1m2CwFQWRguXmIaEaOQD5wu5hXI6T8WW5J/zqNFoN9zQaDE4IT8Y1y99Y /mvxEPA5A8yC/C+aj+n91dsD/ts+wdnUciA1pQSQPkW7fPx2wHtKhuLX3+J96/GT8o2Q lOXA== MIME-Version: 1.0 X-Received: by 10.50.79.234 with SMTP id m10mr11079857igx.47.1393688156039; Sat, 01 Mar 2014 07:35:56 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sat, 1 Mar 2014 07:35:55 -0800 (PST) In-Reply-To: <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> Date: Sat, 1 Mar 2014 16:35:55 +0100 X-Google-Sender-Auth: 8AbOJIrdbgy4u9bOgmBb-8drzOU Message-ID: From: Andrea Glorioso To: John Curran Content-Type: multipart/alternative; boundary=089e0122a59c77f17304f38d4f0d Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/GQNKDIWpi8ZFrUnTlp90S_arx2Q Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 15:36:02 -0000 --089e0122a59c77f17304f38d4f0d Content-Type: text/plain; charset=ISO-8859-1 Dear John, On Saturday, March 1, 2014, John Curran > wrote: > > > We have to face the fact that the remarkable success of the Internet means > that it very difficult for a given government or community to _not_ use > IETF > protocols and still achieve global interoperability. This in turn only > reinforces the need for protocol development processes which are open to > all interested parties, and transparency in decision making. > > When we need to consider factors other than purely technical merit, it may > result in social, political, or economic tradeoffs being integrated into > the > protocols, and it would be best to do so based on extremely widely held > norms > and values. To avoid the IETF having to specifically hold discussions to > develop positions of economic or social values and norms, it would be best > to > rely instead on explicit statements developed elsewhere when available > (e.g. > the EU's personal data privacy directive, UN GA privacy rights on the > Internet > with > respect > to perpass), as the wide applicability helps in avoiding specifications > which > might be in conflict in a significant region and thus contrary to the goal > of > having prototols which facilitate global Internet communications. > > Mechanisms should be provided for promoting high-level awareness to all > interested parties (including governments and other stakeholders such as > civil society) of specification development which has significant potential > for incorporating public policy tradeoffs in the final specifications; > not so that the political discussion can be brought to the IETF, but so > that parties that follow and potentially even point out any widely endorsed > statements of norms and values which the IETF should be aware of during the > protocol development activities. This is very well put, but could you clarify what you mean by "high-level" in this context? Best, Andrea -- -- I speak only for myself. Sometimes I do not even agree with myself. Keep it in mind. Twitter: @andreaglorioso Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=1749288&trk=tab_pro --089e0122a59c77f17304f38d4f0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear John,

On Saturday, March 1, 2014, John Curran <jcurran@istaff.org> wrote:
=A0
We have to face t= he fact that the remarkable success of the Internet means
that it very difficult for a given government or community to _not_ use IET= F
protocols and still achieve global interoperability. =A0This in turn only reinforces the need for protocol development processes which are open to all interested parties, and transparency in decision making.

When we need to consider factors other than purely technical merit, it may<= br> result in social, political, or economic tradeoffs being integrated into th= e
protocols, and it would be best to do so based on extremely widely held nor= ms
and values. =A0To avoid the IETF having to specifically hold discussions to=
develop positions of economic or social values and norms, it would be best = to
rely instead on explicit statements developed elsewhere when available (e.g= .
the EU's personal data privacy directive, UN GA privacy rights on the I= nternet
<http://www.un.org/en/ga/search/view_doc.asp?symbol= =3DA/RES/68/167> with respect
to perpass), as the wide applicability helps in avoiding specifications whi= ch
might be in conflict in a significant region and thus contrary to the goal = of
having prototols which facilitate global Internet communications.

Mechanisms should be provided for promoting high-level awareness to all
interested parties (including governments and other stakeholders such as civil society) of specification development which has significant potential=
for incorporating public policy tradeoffs in the final specifications;
not so that the political discussion can be brought to the IETF, but so
that parties that follow and potentially even point out any widely endorsed=
statements of norms and values which the IETF should be aware of during the=
protocol development activities.

This is ve= ry well put, but could you clarify what you mean by "high-level" = in this context?

Best,

Andrea=A0


--

--
I speak only for myself. Sometimes I do not even a= gree with myself. Keep it in mind.
Twitter: @andreaglorioso
Facebook:= htt= ps://www.facebook.com/andrea.glorioso
LinkedIn: http://www.linkedin.com/profile/view?id=3D= 1749288&trk=3Dtab_pro
--089e0122a59c77f17304f38d4f0d-- From nobody Sat Mar 1 07: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 1E89D1A04A3 for ; Sat, 1 Mar 2014 07:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.447 X-Spam-Level: X-Spam-Status: No, score=-4.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.547] 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 ISdHgdgQ4Wmk for ; Sat, 1 Mar 2014 07:50:57 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 320BA1A0367 for ; Sat, 1 Mar 2014 07:50:57 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:62856 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WJmBW-0005MI-Gp; Sat, 01 Mar 2014 15:50:42 +0000 From: "Russ White" To: "'John Curran'" References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <"016101cf 3551$3 3d f5090$9b9df 1b 0$"@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <020f01cf355f$a7f7bdb0$f7e73910$@riw.us> <5925BF6E-653E-4C98-B0F4-92F35A77138F@istaff.org> In-Reply-To: <5925BF6E-653E-4C98-B0F4-92F35A77138F@istaff.org> Date: Sat, 1 Mar 2014 10:50:40 -0500 Message-ID: <02aa01cf3565$ffc45660$ff4d0320$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJMFih2b/pqIL5HvUFCBvP9zfnmIAHwS+XUAcF8GWsC7qp9sgH+vKWhAszX6ToCRYMQCgN5j4kmAhEOGroCAPUEawCT+vThAbzUCscA55+McQIrSgWqAmzX6UoCGFPv7QHuQm2oAa8X4DwDFjYatQHswiTMAhQlXEmYg8lfUA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pIU5tjx8fTW8yWlzIykCqyJJm1M Cc: internetgovtech@iab.org, 'Andrea Glorioso' , 'Pranesh Prakash' , 'Brian Trammell' , 'S Moonesamy' Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 15:50:59 -0000 > I think we're agreeing on the goal ("remove the political implications as > much as possible"), but the question is what to do where it is unavoidable. > My suggestion would be to leverage widely held statements of such social > or political norms rather than having to debate them in the IETF. (and this is > not much different than leveraging international consensus of two letter > codes for reference to countries and subdivisions, another political matter) The problem is, in the end, that using consensus statements doesn't always actually guarantee correct (or moral?) action (or even acceptance). > The process doesn't have to be changed, but the IETF needs to have a model > for how governments engage with it when desired and spend some time > actually explaining that to governments (or run the risk that they'll decide on > other approaches to meet their needs) > I describe an end point; governments should be able to engage in the > existing processes just as any other party; it would, however, be helpful > when a government expresses a particular social/economic requirement if > the IETF could consistently explain that it prefers not to twist the protocol > development for one countries view, but if some widely-held statement of > such a norm or value that can be referenced, that might be worth > considering since IETF standards intended to be scope Internet, i.e. > applicable globally. So you would suggest... Perhaps a new IAB liaison effort, or a new IAB type group, or trying to get the ISOC to play a more active role here, or... ?? :-) Russ From nobody Sat Mar 1 08:02: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 326001A078D for ; Sat, 1 Mar 2014 08:02:44 -0800 (PST) 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 e0fQH57nJplT for ; Sat, 1 Mar 2014 08:02:42 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAB01A0763 for ; Sat, 1 Mar 2014 08:02:42 -0800 (PST) Received: from pool-108-45-30-69.washdc.fios.verizon.net ([108.45.30.69] helo=[192.168.1.9]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WJmN6-000CcK-1N; Sat, 01 Mar 2014 16:02:40 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.45.30.69 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19y8cqFXuPasKcNaBnVLQut Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Curran In-Reply-To: <20140301152942.GF2941@mx1.yitter.info> Date: Sat, 1 Mar 2014 11:02:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vx7eYiUT6ZHJBRVPRN6t19GN1ho Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 16:02:44 -0000 On Mar 1, 2014, at 10:29 AM, Andrew Sullivan = wrote: > That's not merely a "fact", it's a tautology. If you want global > interoperability ("with the Internet" is implied in your original), > then you have to use Internet protocols. Be very careful... If the governments don't realistically have any = choice=20 in the use of the Internet (i.e. participation is effectively mandatory=20= due to the social/economic benefits), and obtaining such benefits = requires=20 use of Internet protocols as proscribed by the IETF, then we're fairly=20= distant from the principle of "Standards are voluntarily adopted". (i.e. if the IETF wants to see itself overrun with governments and = lobbyists, simply make plain the proclamation that "IETF Standards are mandatory = for the=20 Internet" and then sit back and watch the fun...) >> When we need to consider factors other than purely technical merit, = it may=20 >> result in social, political, or economic tradeoffs being integrated = into the=20 >> protocols,=20 >=20 > I strongly disagree with this approach to describing the question. If > we need to include certain social, political, or economic tradeoffs, > then those are part of the use cases that the protocol is supposed to > be addressing. Therefore, this is not some case of considering > factors other than purely technical merit: there's no such thing as > "pure technical merit" without the operational conditions expected of > the protocol. This is engineering we're supposed to be doing, not > mathematics. If the IETF decides that some use cases are valid, and others are not valid, and the chosen use cases support particular social values in=20 them (e.g. individual privacy), then the protocol decisions based on those use cases is indeed embedding certain social/economic values. If you wish to say that "technical merit" means satisfying the use cases, then that is fine, but then deciding which use cases are valid=20 requirements is effectively making tradeoffs in supporting various=20 values that will make the protocol successful (and some of those=20 values are social/economic) > What we sometimes have to confront, however, is indeed the question of > whether this or that tradeoff ought to be on the list. That is, to my > way of thinking, the difficulty we're having, but it's not different > in kind to the problem developers have always had in understanding > what the product and sales people want. Getting the requirements > right is hard, and it gets harder the further one gets from being the > end user. In the early period of the Internet, approximately all the > users _were_ the developers, so figuring out the requirements was > probably easier in that you could talk to people and find out their > problems. It gets harder the less representative of actual users our > population gets.=20 Andrew - I actually agree very much with this, but am concerned that=20 the "near mandatory" nature of the Internet (and increasing government awareness of same) is going to result in one of two outcomes; either governments trying to figure out how and when the IETF is setting its requirements (to make sure that their views are considered in some = manner) or them going off completely independently and attempting to legislate=20= (either singly or jointly) various outcomes without any consideration=20 of the technical implications. =20 Is it possible for the IETF to be sufficiently open and understandable=20= to governments (particularly when they act in fairly large groups and stick predominantly to referring us to statements widely-held social, and economic principles) so that they'll support such an approach for=20 pragmatic engagement? I would like to think so; the alternatives are debates of such social and political issues taking place directly at IETF (not necessarily=20 helpful) or taking place elsewhere and likely going down into technical matters for which the expertise is at the IETF. FYI, /John From nobody Sat Mar 1 08:06: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 516E61A09D1 for ; Sat, 1 Mar 2014 08:06:04 -0800 (PST) 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 Y6opQO5xjSGq for ; Sat, 1 Mar 2014 08:05:59 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id E573C1A097B for ; Sat, 1 Mar 2014 08:05:57 -0800 (PST) Received: from pool-108-45-30-69.washdc.fios.verizon.net ([108.45.30.69] helo=[192.168.1.9]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WJmQF-000DnD-Iy; Sat, 01 Mar 2014 16:05:55 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.45.30.69 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19fncVbFIVatrs02nUTVOGr Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Curran In-Reply-To: <02aa01cf3565$ffc45660$ff4d0320$@riw.us> Date: Sat, 1 Mar 2014 11:05:50 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0A2C9A20-B088-43ED-AC5B-9047DBF25365@istaff.org> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <"016101cf 3551$3 3d f5090$9b9df 1b 0$"@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <020f01cf355f$a7f7bdb0$f7e73910$@riw.us> <5925BF6E-653E-4C98-B0F4-92F35A77138F@istaff.org> <02aa01cf3565$ffc45660$ff4d0320$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HKaqcHhIGQqG8PGRj394uLQ3vPw Cc: internetgovtech@iab.org, Andrea Glorioso , Pranesh Prakash , S Moonesamy , Brian Trammell Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 16:06:05 -0000 On Mar 1, 2014, at 10:50 AM, Russ White wrote: > The problem is, in the end, that using consensus statements doesn't always > actually guarantee correct (or moral?) action (or even acceptance). Correct. The IETF must be able to decide when/whether to reference any such statements in their determination of the protocol requirements. > ... > So you would suggest... Perhaps a new IAB liaison effort, or a new IAB type > group, or trying to get the ISOC to play a more active role here, or... ?? Please no... simply common understanding of how governments should engage with the IETF, and some documentation of same... e.g. an internet-draft. /John From nobody Sat Mar 1 08:06: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 54F261A09DA for ; Sat, 1 Mar 2014 08:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 enXGcY-UmsXc for ; Sat, 1 Mar 2014 08:06:45 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id A2B951A09D1 for ; Sat, 1 Mar 2014 08:06:45 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id h18so4133167igc.2 for ; Sat, 01 Mar 2014 08:06:43 -0800 (PST) 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=roJaMH6hol1KMhrayPtTMz+RRpwhaf1Y2kVeMDO/EVw=; b=CluqIH+5kKgjwm4bTKhXvRuZqkydkGsTFV+IMyHFxJ+1UZd7XNZzUFK1OrNIBwOGmR 3rjuWuo4YxIVnoKY1R1Z/jsI5h1ZYIVrXMExovFrQVzsowLXoc9vJU+NgmEanTq2tM/o ek+rhXIL5ZGNF5ICgHGD/f8Iig0CYODbqgPdqRcQK1aH0WEdNWe19n1gmgMxjbWy2F2N +gcJQ39PoPU/3wjHjMT+8xaWYKDLigDNN2BRCDRmsSYTMVXvJ1fdAsvAlGIhCFxzikEO NxihgOKE17oGvelzuI7jjLX++GBSZEELh/z2Isn3fOWfoMKJoP3DUJWDWwVk7XDrKduQ u4Gw== MIME-Version: 1.0 X-Received: by 10.50.253.12 with SMTP id zw12mr11507644igc.28.1393690003350; Sat, 01 Mar 2014 08:06:43 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sat, 1 Mar 2014 08:06:43 -0800 (PST) In-Reply-To: <20140301152942.GF2941@mx1.yitter.info> References: <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> Date: Sat, 1 Mar 2014 17:06:43 +0100 X-Google-Sender-Auth: TDXu9ItilsFTM5MTk1Lx87hVUh4 Message-ID: From: Andrea Glorioso To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11346e3c93ac1104f38dbd1b Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/DmtB8q8D5sQ_5CE0Hv8RX_H1LO4 Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 16:06:48 -0000 --001a11346e3c93ac1104f38dbd1b Content-Type: text/plain; charset=ISO-8859-1 On Saturday, March 1, 2014, Andrew Sullivan wrote: > On Sat, Mar 01, 2014 at 09:27:13AM -0500, John Curran wrote: > > > We have to face the fact that the remarkable success of the Internet > means > > that it very difficult for a given government or community to _not_ use > IETF > > protocols and still achieve global interoperability. > > That's not merely a "fact", it's a tautology. If you want global > interoperability ("with the Internet" is implied in your original), > then you have to use Internet protocols. > > > This in turn only reinforces the need for protocol development > > processes which are open to all interested parties, and transparency > > in decision making. > > I agree, but I think it's important to recognise that many of the > people who appear to want the pony named "using the Internet without > using IETF protocols" actually don't want a process that is open to > all interested, or transparency in decision making. Many of them > instead wish the decisions to be taken by treaty bodies in closed > rooms. I think it is not surprising that people are suspicious of > importing "political considerations" into the protocol-making > discussion, because that looks like a Trojan horse for "takeover by > treaty organizations". On the other hand, by being overly suspicious to people / organizations which are simply tying to make sure the range of "operational considerations" (as you very well put it in your message) is broad enough to avoid problems down the road, the risk is actually empowering those parties which are actually hiding in the Trojan horse. I don't have a problem with mistrust - a certain degree of it is unavoidable and might even be beneficial, if it forces everyone to speak their mind clearly in order to overcome it - but there are moments in which mistrust can become paralyzing. (I'm not talking specifically about you) > > When we need to consider factors other than purely technical merit, it > may > > result in social, political, or economic tradeoffs being integrated into > the > > protocols, > > I strongly disagree with this approach to describing the question. If > we need to include certain social, political, or economic tradeoffs, > then those are part of the use cases that the protocol is supposed to > be addressing. Therefore, this is not some case of considering > factors other than purely technical merit: there's no such thing as > "pure technical merit" without the operational conditions expected of > the protocol. This is engineering we're supposed to be doing, not > mathematics. As I said - this is very well put. What we sometimes have to confront, however, is indeed the question of > whether this or that tradeoff ought to be on the list. That is, to my > way of thinking, the difficulty we're having, but it's not different > in kind to the problem developers have always had in understanding > what the product and sales people want. Getting the requirements > right is hard, and it gets harder the further one gets from being the > end user. In the early period of the Internet, approximately all the > users _were_ the developers, so figuring out the requirements was > probably easier in that you could talk to people and find out their > problems. It gets harder the less representative of actual users our > population gets. > So would you agree that in order to make sure all the requirements are factored in, we need to make sure the number, but especially the range of expertise, sensitivities etc of those who participate in the definition of requirements should be enlarged? Please correct me if I misunderstood your thinking. Best, Andrea -- -- I speak only for myself. Sometimes I do not even agree with myself. Keep it in mind. Twitter: @andreaglorioso Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=1749288&trk=tab_pro --001a11346e3c93ac1104f38dbd1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Saturday, March 1, 2014, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Sat, Mar 01, 2014 at 09:27:13AM -0500, John Curran wrote:

> We have to face the fact that the remarkable success of the Internet m= eans
> that it very difficult for a given government or community to _not_ us= e IETF
> protocols and still achieve global interoperability.

That's not merely a "fact", it's a tautology. =A0If you w= ant global
interoperability ("with the Internet" is implied in your original= ),
then you have to use Internet protocols.

> This in turn only reinforces the need for protocol development
> processes which are open to all interested parties, and transparency > in decision making.

I agree, but I think it's important to recognise that many of the
people who appear to want the pony named "using the Internet without using IETF protocols" actually don't want a process that is open t= o
all interested, or transparency in decision making. =A0Many of them
instead wish the decisions to be taken by treaty bodies in closed
rooms. =A0I think it is not surprising that people are suspicious of
importing "political considerations" into the protocol-making
discussion, because that looks like a Trojan horse for "takeover by treaty organizations".

On the other ha= nd, by being overly suspicious to people / organizations which are simply t= ying to make sure=A0the range of "operational considerations" (as= you very well put it in your message) is broad enough to avoid problems do= wn the road, the risk is actually empowering those parties which are actual= ly hiding in the Trojan horse.=A0

I don't have a problem with mistrust - a certain de= gree of it is unavoidable and might even be=A0beneficial, if it forces ever= yone to speak their mind clearly in order to overcome it - but there are mo= ments in which mistrust can become paralyzing. (I'm not talking specifi= cally about you)
=A0
> When we need to consider factors other than purely technical merit, it= may
> result in social, political, or economic tradeoffs being integrated in= to the
> protocols,

I strongly disagree with this approach to describing the question. =A0If we need to include certain social, political, or economic tradeoffs,
then those are part of the use cases that the protocol is supposed to
be addressing. =A0Therefore, this is not some case of considering
factors other than purely technical merit: there's no such thing as
"pure technical merit" without the operational conditions expecte= d of
the protocol. =A0This is engineering we're supposed to be doing, not mathematics.

As I said - this is very well = put.=A0=A0

What we sometimes have to confront, however, is indeed the question of
whether this or that tradeoff ought to be on the list. =A0That is, to my way of thinking, the difficulty we're having, but it's not differen= t
in kind to the problem developers have always had in understanding
what the product and sales people want. =A0Getting the requirements
right is hard, and it gets harder the further one gets from being the
end user. =A0In the early period of the Internet, approximately all the
users _were_ the developers, so figuring out the requirements was
probably easier in that you could talk to people and find out their
problems. =A0It gets harder the less representative of actual users our
population gets.

So would you agree tha= t in order to make sure all the requirements are factored in, we need to ma= ke sure the number, but especially the range of=A0expertise, sensitivities = etc of those who participate in the definition of requirements should be en= larged? Please correct me if I misunderstood your thinking.=A0

Best,

Andrea=A0


-= -

--
I speak only for myself. Sometimes I do not even agree with= myself. Keep it in mind.
Twitter: @andreaglorioso
Facebook: https://www= .facebook.com/andrea.glorioso
LinkedIn: http://www.linkedin.com/profile/view?id=3D= 1749288&trk=3Dtab_pro
--001a11346e3c93ac1104f38dbd1b-- From nobody Sat Mar 1 12:17: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 061C01A034A for ; Sat, 1 Mar 2014 12:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 s_ts6a6Bzeic for ; Sat, 1 Mar 2014 12:17:38 -0800 (PST) Received: from mail.cis-india.org (mail.cis-india.org [202.190.125.68]) by ietfa.amsl.com (Postfix) with ESMTP id 47F001A02B3 for ; Sat, 1 Mar 2014 12:17:38 -0800 (PST) Received: from [10.0.2.217] (unknown [213.235.243.78]) by mail.cis-india.org (Postfix) with ESMTPSA id 31C7EA7C9BE; Sat, 1 Mar 2014 20:17:59 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20140228213401.0c15cb00@elandnews.com> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <6.2.5.6.2.20140228213401.0c15cb00@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Pranesh Prakash Date: Sat, 01 Mar 2014 21:08:16 +0100 To: S Moonesamy , Russ White , Brian Trammell , Andrea Glorioso Message-ID: <27d9aa7a-d28b-4668-b203-0072a178ca9e@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vbDEh1oreOeBwbTJDe0wQS0TpeQ Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 20:17:41 -0000 On 1 March 2014 7:34:45 am GMT+01:00, S Moonesamy wrote: >Hi Pranesh, >At 21:26 28-02-2014, Pranesh Prakash wrote: >>The decision to require all SMTP servers to only prepend to the >>"received" header, has political ramifications. >to list that under political ramifications or not. I made the >following argument some time ago [1]: > >"When a person sends an email the person consents to the transmission >of an > email address. The email address is necessary for the recipient >of the email > to be able to reply to it." > >I cannot think of another way for the technology to work if, for >example, I do not include an email address for you to send me a >reply. As I have not reviewed the S/MIME draft I prefer not to >comment about it. I wasn't clear. While there are privacy issues at multiple levels with email, the bit I was referring to with the "Received" header comment was the point that, AFAIK (and I'm quoting from memory here) the specs for SMTP require even the IP address of the originating computer to be there amongst the received headers. (AFAIK, Gmail violates this.) This is very useful for diagnostics when something goes wrong, but is not needs for message delivery. The folks behind the LEAP.se project list out what they see as privacy flaws with email (but don't list the above problem iirc), as does Adam Langley, implicitly, in his long initial blog post introducing the Pond protocol. >There can be political ramifications to BGPSEC, the CA system, and >maybe even email. It would require a lot of people to identify the >political ramifications [2]. Let's say that some entity is created >for all that. The open source people might have a higher barrier to >overcome [3]. > >A well-written technical standard would have minimized political >ramifications to an extent that it is not worth bothering >about. This is the bit with which I disagree. You can't separate them out that way. The "political" aspect is not dependent only on how the standard is written, but also on the topic that the standard covers, the assumptions that go into the formulation, and other factors that I should probably spend some time analysing and categorizing when I get some time. I believe it's impossible to separate out politics from standards. Sure there will be some some standards that have less of a political implication than others and some will have no discernable political impact at all. But that wouldn't be because that particular standard is somehow better written. Having a unitary root (to have globally unique addresses, rather than leaving the resolution of address conflict to users by design), the design of DNSSEC (including key splitting), all of these are political decisions that are embedded in the current structure of standards and practices. There's no escaping the political question. Standards-setting is politics and cannot be rid of its political consequences. Cheers, Pranesh > There is still the intellectual property question. Open >source people usually do not like technical standards which are >covered by patents. >Regards, >S. Moonesamy > >1. http://tools.ietf.org/html/draft-moonesamy-privacy-identifiers-01 >2. There are a lot of technical specifications and different >organizations involved. >3. There is already a high barrier as it is to stay involved. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From nobody Sat Mar 1 12:18: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 DBAF21A034A for ; Sat, 1 Mar 2014 12:18:23 -0800 (PST) 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 J-ul166P4w5H for ; Sat, 1 Mar 2014 12:18:22 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id BB17A1A02B3 for ; Sat, 1 Mar 2014 12:18:22 -0800 (PST) Received: from 169.69.176.95.rev.sfr.net ([95.176.69.169]:60856 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WJqMU-0007il-VP; Sat, 01 Mar 2014 12:18:19 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 01 Mar 2014 21:18:14 +0100 To: John Curran , Andrew Sullivan From: Jefsey In-Reply-To: References: <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> 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: 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/LNLZQCH5o1SnWXhR0eG0jVfZja4 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 20:18:24 -0000 At 17:02 01/03/2014, John Curran wrote: >(i.e. if the IETF wants to see itself overrun with governments and lobbyists, > simply make plain the proclamation that "IETF Standards are > mandatory for the > Internet" and then sit back and watch the fun...) John, there is also a difference of layers to consider. The internet and OSI pile have been influenced by the positions of the Telcos. Fadi Chehade has included them in the "family" for Sao Paulo. The real issue is what is the internet. If the internet is the end to end transport under IP, IETF standards are mandatory (otherwise is it not the Internet, it is something else). If ICANN is to insure the stability of the DNS class IN under contract of the NTIA, there is no objection that class UR is under contract of the Ruhitanian FCC. In this case why is ICANN alone to use its M$ 78 budget to represent VGNICs in Sao Paulo? The problem is when someone wants to establish a radical monopoly (cf. Yvan Illitch) on something common, i.e. hampering the VN (virtual network, partial or global) of a national, trade, regional, private, personal relational space. Its NIC manager (to keep a generic traditional name) feels colonized and opposes. The best to smooth this is to talk. But to talk you need to be two - this is what Russ did in authrozing the IUCG experimentation CS people are not using a lot as CS but that VGN people may want to use. We will see if ICANN subsidze VGNICS participations. jfc From nobody Sat Mar 1 15:44: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 DE5E31A0B36 for ; Sat, 1 Mar 2014 15:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 XlYICqLsJzT8 for ; Sat, 1 Mar 2014 15:44:27 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4745D1A0B03 for ; Sat, 1 Mar 2014 15:44:26 -0800 (PST) Received: from mx1.yitter.info (unknown [130.129.155.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id CC6178A031 for ; Sat, 1 Mar 2014 23:44:23 +0000 (UTC) Date: Sat, 1 Mar 2014 18:44:18 -0500 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140301234336.GA3277@mx1.yitter.info> References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> 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/_tgIDNGf6ISZKU4vn8W_K7h1rNc Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 23:44:29 -0000 Hi, On Sat, Mar 01, 2014 at 11:02:38AM -0500, John Curran wrote: > Be very careful... If the governments don't realistically have any choice > in the use of the Internet (i.e. participation is effectively mandatory > due to the social/economic benefits), and obtaining such benefits requires > use of Internet protocols as proscribed by the IETF, then we're fairly > distant from the principle of "Standards are voluntarily adopted". That feels like a pretty fast rhetorical move to me. Nobody is saying you must use any particular standard. Moreover, since the Internet is a network of networks, _by definition_ the partcipation in the internetworking is voluntary. If it were mandatory routing of packets across all participating networks, it wouldn't be an internet at all; it'd be one big network. > If the IETF decides that some use cases are valid, and others are not > valid, and the chosen use cases support particular social values in > them (e.g. individual privacy), then the protocol decisions based on > those use cases is indeed embedding certain social/economic values. Yes, of course. I agree with this. When you make a choice in favour or against some particular technology, you are thereby also making the choince in favour or against at least some of its consequences. I do think we should make that choice thoughtfully and with awareness. We better not left unsaid, however, that given some choices that have been made already, we are not simply free to anything we like. Many seem to think that, because this is technology, one could just make a rule to change the way it works. But technology isn't like that: once you have deployed a technology, it alters the world. We might wish we hadn't built North America with miles of highways, huge suburban tracts, and 1.5+ hour commutes for many people; tough. That's the world we've actually got, and the only way it could change is with massive social disruption. > governments trying to figure out how and when the IETF is setting its > requirements (to make sure that their views are considered in some manner) > or them going off completely independently and attempting to legislate > (either singly or jointly) various outcomes without any consideration > of the technical implications. > > Is it possible for the IETF to be sufficiently open and understandable > to governments (particularly when they act in fairly large groups and > stick predominantly to referring us to statements widely-held social, > and economic principles) so that they'll support such an approach for > pragmatic engagement? I sure hope so. Otherwise, we're wasting a lot of time, because answer number 2 is IMO unlikely actually to work, if by "work" we mean "deliver anything we can recognise as an internet". Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Mar 1 15:52: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 A03271A0B3F for ; Sat, 1 Mar 2014 15:52:15 -0800 (PST) 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 LA4NAYwAUQmK for ; Sat, 1 Mar 2014 15:52:14 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 761991A0B38 for ; Sat, 1 Mar 2014 15:52:14 -0800 (PST) Received: from mx1.yitter.info (unknown [130.129.155.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A00F78A031 for ; Sat, 1 Mar 2014 23:52:11 +0000 (UTC) Date: Sat, 1 Mar 2014 18:52:09 -0500 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140301235209.GB3277@mx1.yitter.info> References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> 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/A3wopADrccR6O5YjaNbEbB_qyCI Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 01 Mar 2014 23:52:15 -0000 On Sat, Mar 01, 2014 at 05:06:43PM +0100, Andrea Glorioso wrote: > > So would you agree that in order to make sure all the requirements are > factored in, we need to make sure the number, but especially the range > of expertise, sensitivities etc of those who participate in the definition > of requirements should be enlarged? Please correct me if I misunderstood > your thinking. I am not one who especially believes that representativity is the essential need, so getting the number or range of people -- "those who participate" -- is to me much less important than getting the range of views to take into consideration. Often, people can be effective advocates for a view they have, but sometimes people can be good advocates for something even if they don't especially agree with it. The key thing is to ensure that the different considerations -- for example whether people will build or deploy a thing, whether it adds positively to the networks, the kinds of uses to which it can be put, and even whether it contributes to or detracts from various other social values -- ought to be in the mix when figuring out how to describe a problem. This is why I think it is important especially that public policy types and so on be solicited for feedback in the run-up to a BoF or the chartering of a WG. I hope that makes it clearer. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Mar 1 16:07: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 154FB1A0316 for ; Sat, 1 Mar 2014 16:07:22 -0800 (PST) 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 5XXM5iAqpA09 for ; Sat, 1 Mar 2014 16:07:20 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 034311A02F8 for ; Sat, 1 Mar 2014 16:07:19 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so1772269wgh.31 for ; Sat, 01 Mar 2014 16:07:16 -0800 (PST) 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=6J344Xul/KGMotojLlenGzZXePl8aWjBaeI33+dPHAM=; b=HPvOElhsWXozeP6K7K2m6kYrJ2wuGyh7pLKkGYF1yICaprXCU5ZRoAvACLfm1V6jYY 4axOh16T230UiiBzXZvLI4k6+UWzu7RWWsNXK64PwEC5JPXu11IYxSFdfd4MW6Cfwg9N I1vb5rKAy8VndKxdth4K47s3UUhI6bpOno4ZiLmEhqdeh+x4kHwUVhcfkzEiEkD21Vtw pMIGBh+L7W+OVbfzvQTiMqJWjoHLc7jEUSR8DhciKNieRh7BsZ7Ki9OMm3beUt1wYWge X0k+CznYY3JaDMWqD6IgTGTCqTCuIbJ8HHj7oMaRUvOkVfih8ZgXRBGblT5Aw6Lj5Qvz rORQ== X-Received: by 10.180.93.74 with SMTP id cs10mr9232934wib.15.1393718836882; Sat, 01 Mar 2014 16:07:16 -0800 (PST) Received: from [130.129.155.141] ([130.129.155.141]) by mx.google.com with ESMTPSA id de3sm16103314wjb.8.2014.03.01.16.07.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 16:07:15 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <20140301235209.GB3277@mx1.yitter.info> Date: Sat, 1 Mar 2014 19:07:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/B6lWxhPcnQSGzSI7xOYfUwJWnZk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 00:07:22 -0000 On Mar 1, 2014, at 6:52 PM, Andrew Sullivan = wrote: > On Sat, Mar 01, 2014 at 05:06:43PM +0100, Andrea Glorioso wrote: >>=20 >> So would you agree that in order to make sure all the requirements = are >> factored in, we need to make sure the number, but especially the = range >> of expertise, sensitivities etc of those who participate in the = definition >> of requirements should be enlarged? Please correct me if I = misunderstood >> your thinking. >=20 > I am not one who especially believes that representativity is the > essential need, so getting the number or range of people -- "those who > participate" -- is to me much less important than getting the range of > views to take into consideration. =20 This may even be the key distinction between the modes of = decision-making most common and comfortable to the different = constituencies/groups we're talking about.=20 "Representativity" of constituents is neither necessary nor sufficient = as far as I can tell for representation of the most essential and useful = range of views. It is, however, often assumed and expected to be both. > The key thing is to ensure that the different considerations -- for > example whether people will build or deploy a thing, whether it adds > positively to the networks, the kinds of uses to which it can be put, > and even whether it contributes to or detracts from various other > social values -- ought to be in the mix when figuring out how to > describe a problem. This is why I think it is important especially > that public policy types and so on be solicited for feedback in the > run-up to a BoF or the chartering of a WG. =20 With that said, I think you're in agreement on the underlying point-- = "the range=85.of those who participate in the definition of requirements = should be enlarged."=20 It becomes tricky (but not impossible) to define and measure whether a = wider range of participants is contributing to different and better = outcomes.=20 Suzanne From nobody Sat Mar 1 23:09: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 192121A0BE9 for ; Sat, 1 Mar 2014 23:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, 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 gVP2MfQJWTjR for ; Sat, 1 Mar 2014 23:09:20 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2443A1A0BD3 for ; Sat, 1 Mar 2014 23:09:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.131.52]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2278dwJ020624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2014 23:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1393744139; bh=ErDg9xlK+kOKKqN7FGIJteIZdifPFg5zSPVtPA9IN8I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=N98BistWu+dLODkuG+xspk1T4TbW3h0C7IUAXGSOSl9iTnVNwpwbYMLd69SWzq0lE 1PIfiiXTjPfKOho8Naak/NZOOOwpN8CXqAHXstjIJbJtWIuzNvm+QVDh2G8bMbiMHp DOxkxhNTSJKTO4oG+ufijep2PaA0Yd2yeSl23Z9I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1393744139; i=@elandsys.com; bh=ErDg9xlK+kOKKqN7FGIJteIZdifPFg5zSPVtPA9IN8I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=V1mP/s5HahPQ+duUzdNyV5z/NA7PwRCSpxzKek9kom2K1AtQGnXYmz1h0Bbe6dabj z75ZGm4NCRqtMSKxYuNocn4KtmP8zhJlcYhVp5bUW3TojQugWrcuaipvYjaovlTiIs CNY3Ynydp4c0uCfHZWycSdPUXbd4vlLeiJfX76k0= Message-Id: <6.2.5.6.2.20140301215002.0b704130@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Mar 2014 22:55:12 -0800 To: John Curran , Russ White From: S Moonesamy In-Reply-To: <5925BF6E-653E-4C98-B0F4-92F35A77138F@istaff.org> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <01c601cf324b$d0fd9750$72f8c5f0$@riw.us> <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <"016101cf 3551$33d f5090$9b9df1b 0$"@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <020f01cf355f$a7f7bdb0$f7e73910$@riw.us> <5925BF6E-653E-4C98-B0F4-92F35A77138F@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RBWNURjyr7vJcYzK7PR7rX26lc0 Cc: internetgovtech@iab.org, Andrea Glorioso , Pranesh Prakash , Brian Trammell Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 07:09:22 -0000 Hi John, At 07:30 01-03-2014, John Curran wrote: > The exact opposite - the IETF should realize that protocols can indeed > embed social/political values, but it should _not_ become a forum for > such discussions. Instead, it should strive to make Internet protocols > as globally useful as possible, and simply _reference_ those externally > developed statements values or norms that it decides to specifically > recognize as drivers for particular protocol decisions. [snip] > If a particular tradeoff is necessary to make the protocol desired by > the user community, and that is the driver that the IETF wishes to > reference, then that's fine. > does not refer to users or trust, and instead defines it has a > security problem. Personally, I'd prefer the approach you suggest or > prefer referencing a widely accepted statement of human privacy being > equally applicable to the Internet - either approach acknowledges the > requirement without having the IETF developing its own position on > personal privacy applicability on the Internet (an undertaking would > indeed encourage having a political discussion at the IETF.) I have used non-technical references in some Internet-Drafts. There is what I would describe as the social context. It is very difficult to explain that. There are the political issues. These issues could be considered unimportant at the time the decision is taken. There isn't a widely accepted statement on, for example, privacy which could be used as a good reference. There is a view that encryption ensures privacy. That draft looks at the problem from a security perspective as it is what people could understand. :-) > The process doesn't have to be changed, but the IETF needs to have a model > for how governments engage with it when desired and spend some time actually > explaining that to governments (or run the risk that they'll decide on other > approaches to meet their needs) At 08:05 01-03-2014, John Curran wrote: >Please no... simply common understanding of how governments should engage >with the IETF, and some documentation of same... e.g. an internet-draft. It's not possible to evaluate that risk. It shouldn't be a problem to have some documentation as long as it is not a blueprint. Regards, S. Moonesamy From nobody Sat Mar 1 23:19: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 5CA291A0643 for ; Sat, 1 Mar 2014 23:19:02 -0800 (PST) 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 NglkjHJm3sOW for ; Sat, 1 Mar 2014 23:18:59 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id F2AF11A02CE for ; Sat, 1 Mar 2014 23:18:58 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id a1so1962050wgh.22 for ; Sat, 01 Mar 2014 23:18:56 -0800 (PST) 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=FUtZRdeIwfzvglpgUeKuPhtkvC/zbhKaUmOtN6k7o3Q=; b=TNjYEGeLVnHpqMdr+WdVOwlhLnFewowpYMbUCKWIL/lcLc3wjPC/5zas3UVCzoKjuu bgY6SjyVxmkFsnDlQlGi5huj9ps8PfTOa7YLP4EOlsjUPOh1FWLQrQGvjsrfwqvwrgHC lRLBhQ92iGip8J1f+ojADf6J4oRNdmGkdZByQ/OiIRf0ygYLxkqOkvhdP0vGJPNPgOIe LC4K+bi+oRUM/LOzSdis04j78uGepn2g5+2G+897JK5SAg6Yh0Gy+BzAMpNud8Eg6k+Z JhfcfUvMrdEPgL04qcWlermwQpezlBAuwkOfG+6R37W52t6zwMSZC90qbkBGsMPhQW13 rMPw== X-Received: by 10.180.221.68 with SMTP id qc4mr9194235wic.30.1393744736018; Sat, 01 Mar 2014 23:18:56 -0800 (PST) Received: from [130.129.62.20] ([130.129.62.20]) by mx.google.com with ESMTPSA id h9sm18451930wjz.16.2014.03.01.23.18.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 23:18:55 -0800 (PST) Message-ID: <5312DB56.2080706@gmail.com> Date: Sun, 02 Mar 2014 20:18:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> In-Reply-To: <20140301235209.GB3277@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/zVxslPHxq-GCakxEKzar3v9DH_E Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 07:19:02 -0000 > On Sat, Mar 01, 2014 at 05:06:43PM +0100, Andrea Glorioso wrote: >> So would you agree that in order to make sure all the requirements are >> factored in, we need to make sure the number, but especially the range >> of expertise, sensitivities etc of those who participate in the definition >> of requirements should be enlarged? Please correct me if I misunderstood >> your thinking. This is of course a fundmental reason why the IETF is open to all particpants, including those who can't afford to travel. We may be imperfect - we surely are - but in the end there is nothing we can do about people who don't tell us about their requirements. There's always scope for more outreach but more rules than "anyone can contribute" seem completely pointless. Brian From nobody Sun Mar 2 00:00: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 2B5501A0648 for ; Sun, 2 Mar 2014 00:00:12 -0800 (PST) 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 dmQbsLQzybl1 for ; Sun, 2 Mar 2014 00:00:11 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id D876E1A0012 for ; Sun, 2 Mar 2014 00:00:10 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id h18so5199722igc.2 for ; Sun, 02 Mar 2014 00:00:08 -0800 (PST) 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:content-type; bh=ORHTp5WS1RTLeevPhVvwouIp3AwWLIvyOz2b2HfbLZw=; b=EC0hsRZk2hGXxO8xxVyWd62EfJwLu6a0Kcvac82DumfQcyf8fv6bUj96sKUv3L677l ohKdAi1mevUwyFGQ5nteGh3zVdHcZT7rGSLISxwKF+ZrG+XPwQn/dRvEEndEun8f9APQ 2fqzC5XIaYm/qUWWRhtGjz2S+pg01N1lcvoQwZsfP9x9GY5JxWd9ogHMrXjXXHx4pvL8 8hNLh7Onc/3MGQ/ZDT4McUMEHhSmTU23DDds02CSKA5o+FL5G1pOYOrilxF6Za/Ogq+9 Fgf630nmsv0FidDOf/7knRaW0QQ3KJPRIYydMHgsRezESnf9FEHvqSYgd9A7PgWKOFid BrCw== MIME-Version: 1.0 X-Received: by 10.42.228.131 with SMTP id je3mr671113icb.59.1393747208243; Sun, 02 Mar 2014 00:00:08 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 00:00:08 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 00:00:08 -0800 (PST) In-Reply-To: <5312DB56.2080706@gmail.com> References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <5312DB56.2080706@gmail.com> Date: Sun, 2 Mar 2014 09:00:08 +0100 X-Google-Sender-Auth: 3NJQtcJkq7LOhYH5S5oEna_j9lc Message-ID: From: Andrea Glorioso To: Brian E Carpenter , internetgovtech@iab.org Content-Type: multipart/alternative; boundary=001a1133d45841102f04f39b0fa3 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Cvf1UzlPj8k0ABcCu73zzzvoR9k Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 08:00:12 -0000 --001a1133d45841102f04f39b0fa3 Content-Type: text/plain; charset=ISO-8859-1 Brian, On Mar 2, 2014 8:19 AM, "Brian E Carpenter" wrote: > There's always scope for more outreach but more rules than "anyone > can contribute" seem completely pointless. We might have a fundamental disagreement here. From my neck of the woods and with experience in different constituencies, the rule you mention is a necessary, but often not sufficient condition. Andrea --001a1133d45841102f04f39b0fa3 Content-Type: text/html; charset=ISO-8859-1

Brian,

On Mar 2, 2014 8:19 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

> There's always scope for more outreach but more rules than "anyone
> can contribute" seem completely pointless.

We might have a fundamental disagreement here. From my neck of the woods and with experience in different constituencies, the rule you mention is a necessary, but often not sufficient condition.

Andrea

--001a1133d45841102f04f39b0fa3-- From nobody Sun Mar 2 00:01: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 9281A1A042B for ; Sun, 2 Mar 2014 00:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 A58LDWtn9tuS for ; Sun, 2 Mar 2014 00:01:29 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 01D941A0C0D for ; Sun, 2 Mar 2014 00:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1076; q=dns/txt; s=iport; t=1393747286; x=1394956886; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lMKxTq0io4zDPJFeHOlbrc6hchiC4W91k68YuFYuVAk=; b=Sd//twUbvIlgOc5he3jhr/if4e0/honM4vVQVLIBShEC2SkX8qn7B3Pd RPm5N8DahJX1w2ogRZFsccgUjfrS6wpdNy2Cf2QiAC2qKhcl2Z0tSgorZ W/a2r9pC2UHPL2mPI/8K7zythS4KmkVvHHtnYPGryqzXYrzEvuE4T8ppP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANTkElOQ/khM/2dsb2JhbABagwaEFb4egRIWdIIlAQEBBCNIAwoBEAsYAgIFFgsCAgkDAgECASsaBgEMAQcBAYd1qyagMxeBKY0wB4JvgUkBA5RRg2uSK4MtPA X-IronPort-AV: E=Sophos;i="4.97,571,1389744000"; d="scan'208";a="6073399" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 02 Mar 2014 08:01:24 +0000 Received: from mctiny.local ([10.61.221.220]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2281O4u001335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Mar 2014 08:01:24 GMT Message-ID: <5312E553.8020600@cisco.com> Date: Sun, 02 Mar 2014 08:01:23 +0000 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Brian E Carpenter , Andrew Sullivan References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <5312DB56.2080706@gmail.com> In-Reply-To: <5312DB56.2080706@gmail.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/fx9HeEApTtwHm9_TFpjHcZMggNY Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 08:01:31 -0000 On 3/2/14, 7:18 AM, Brian E Carpenter wrote: >> On Sat, Mar 01, 2014 at 05:06:43PM +0100, Andrea Glorioso wrote: >>> So would you agree that in order to make sure all the requirements are >>> factored in, we need to make sure the number, but especially the range >>> of expertise, sensitivities etc of those who participate in the definition >>> of requirements should be enlarged? Please correct me if I misunderstood >>> your thinking. > This is of course a fundmental reason why the IETF is open to > all particpants, including those who can't afford to travel. > We may be imperfect - we surely are - but in the end there is > nothing we can do about people who don't tell us about their > requirements. I agree with this statement, but we should also recognize that there are difficulties in engaging only on mailing lists that we've been discussing elsewhere. Also, we can always do a better job to outreach to others so that they know they can join in the fun. ISOC has been working hard on that, but the job doesn't just fall to them. Eliot From nobody Sun Mar 2 00:36: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 659601A0864 for ; Sun, 2 Mar 2014 00:36:16 -0800 (PST) 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 kW1fn41vkIZ0 for ; Sun, 2 Mar 2014 00:36:15 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C91A03BC for ; Sun, 2 Mar 2014 00:36:15 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so3147416iec.1 for ; Sun, 02 Mar 2014 00:36:12 -0800 (PST) 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:content-type; bh=BBh0YUpPzWPkQB2u6RUQdnPGO9eyvCs2XyAFHJjZuKA=; b=IL4Dtjq0sNKDHULTvo/vdezWfIkpO5kfqS0PYNrZcb86M3912KkRkA0Bc529bDqgWh AU18sY4Ce8BwMtps27M+emu+vFpnxrKLiGWhmjA20lnuBeSsuRUhaCE7W42ZH4fFcXTU VjsJrAoiTnaVqpXf4PeZjFghd1tBlNpGY6V7nlO3nO+wRUKPTwxxEzXg/RugKkFpBDvb 87INyzOsWvW3am8m+ciQPrDMbQikw/WgC3FkEIJA55hc8a1BUNw+ZEQKsZpD/rdFQwjJ CAD3czcNf7I1HhISkU1ijevpDDrfvqGTKo/rvLUVDI00ccH4idenY5DKQDsspkVFAXpF F21w== MIME-Version: 1.0 X-Received: by 10.51.17.40 with SMTP id gb8mr15512485igd.18.1393749372674; Sun, 02 Mar 2014 00:36:12 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 00:36:12 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 00:36:12 -0800 (PST) In-Reply-To: <20140301235209.GB3277@mx1.yitter.info> References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> Date: Sun, 2 Mar 2014 09:36:12 +0100 X-Google-Sender-Auth: fEXBRrfY5h5pfryGENetrSzGfGQ Message-ID: From: Andrea Glorioso To: Andrew Sullivan , internetgovtech@iab.org Content-Type: multipart/alternative; boundary=001a1134c2e243c8d704f39b90b3 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/VL7bazrBAd-hCeURyONAneqBcz4 Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 08:36:16 -0000 --001a1134c2e243c8d704f39b90b3 Content-Type: text/plain; charset=ISO-8859-1 Andrew, This is helpful, but I still can't understand a logical step. On Mar 2, 2014 12:52 AM, "Andrew Sullivan" wrote: > I am not one who especially believes that representativity is the > essential need, so getting the number or range of people -- "those who > participate" -- is to me much less important than getting the range of > views to take into consideration. I suspect we might have a different understanding of the concept of "representativity". Perhaps because of this, I can't well understand how you would get the "range of views to take into consideration" without enlarging the range of participants. Best, Andrea --001a1134c2e243c8d704f39b90b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Andrew,

This is helpful, but I still can't understand a logical = step.

On Mar 2, 2014 12:52 AM, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote= :

> I am not one who especially believes that representativ= ity is the
> essential need, so getting the number or range of people -- "thos= e who
> participate" -- is to me much less important than getting the ran= ge of
> views to take into consideration. =A0

I suspect we might have a different understanding of the con= cept of "representativity". Perhaps because of this, I can't = well understand how you would get the "range of views to take into con= sideration" without enlarging the range of participants.

Best,

Andrea

--001a1134c2e243c8d704f39b90b3-- From nobody Sun Mar 2 01:02: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 2F55A1A0864 for ; Sun, 2 Mar 2014 01:02:34 -0800 (PST) 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 Vs0W5tnOixwq for ; Sun, 2 Mar 2014 01:02:32 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 441411A080B for ; Sun, 2 Mar 2014 01:02:32 -0800 (PST) Received: from mx1.yitter.info (unknown [130.129.155.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E46438A031 for ; Sun, 2 Mar 2014 09:02:27 +0000 (UTC) Date: Sun, 2 Mar 2014 04:02:26 -0500 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140302090225.GB3482@mx1.yitter.info> References: <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> 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/SwdcTPpczuzz27q5wZTkKcY9yeU Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 09:02:34 -0000 On Sun, Mar 02, 2014 at 09:36:12AM +0100, Andrea Glorioso wrote: > "representativity". Perhaps because of this, I can't well understand how > you would get the "range of views to take into consideration" without > enlarging the range of participants. Some think that there is an approximate 1:1 relationship between people and a view. I just don't believe that, because I know that I myself am able to contemplate things from more than one point of view. Often, in an area where I am sufficiently experienced, I can come up with the entire problem statement on my own without polling anyone, and it'll be close enough for the purposes of starting work. This does not rely on including more people, but rather on including more points of view. I suppose one could say that this is implicitly "enlarging the range of participants" by proxy: I happen to know a lot about certain areas, so I can put myself in the other's shoes and get the problem statement close enough that, at least in the early stages, it's possible to do useful work. That description makes me uncomfortable because of the importance it places on people rather than premises, but if it makes others happier I could live with it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Mar 2 01:07: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 EDE571A03BC for ; Sun, 2 Mar 2014 01:07:53 -0800 (PST) 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 H5TraGeBVZRy for ; Sun, 2 Mar 2014 01:07:51 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 92F341A0866 for ; Sun, 2 Mar 2014 01:07:51 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w61so1989379wes.32 for ; Sun, 02 Mar 2014 01:07:48 -0800 (PST) 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=KF+kN2XGHXs+6kT3VsC/ET2umFOtVdzLxazvr38tzIg=; b=XkgdSkRmmYN04W7GhdiKMRLRqP7noLVY/i1Tepnygc57RCOewAM9LUd4ZgCkG/0LRl 9OMTjNPTmVEhKGBkXyoIDHpPwrtnuWqm8qoXipSw2N77Nz1D44PIQwgwn3yISssomaHq vC4TLHmzgo+6loujuz7+oCl8VFHULS9wjGocksRZvFAHFAxnVeAyYdW0vYyZQLM7jwNj oRDmVjgrmQKRYwpLpvlFZYHTCvVKXipPi392aBlfISXet6hRXGG0MYXbjGeKS8eMb/6U 9zlymuJZVoBQfGwtNyQ+O1mYZ3iXIg7t9k1Sl5MF8K0Q1Qx0iTSNVq7p9V7Uh4FVihDm pKVA== X-Received: by 10.180.89.225 with SMTP id br1mr9679447wib.38.1393751268660; Sun, 02 Mar 2014 01:07:48 -0800 (PST) Received: from [130.129.62.20] ([130.129.62.20]) by mx.google.com with ESMTPSA id de3sm19111635wjb.8.2014.03.02.01.07.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 01:07:47 -0800 (PST) Message-ID: <5312F4E3.10907@gmail.com> Date: Sun, 02 Mar 2014 22:07:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrea Glorioso References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/dYwleGf63TGJ1yAud1oXedwQO34 Cc: internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 09:07:54 -0000 Andrea, On 02/03/2014 21:36, Andrea Glorioso wrote: > Andrew, > > This is helpful, but I still can't understand a logical step. > > On Mar 2, 2014 12:52 AM, "Andrew Sullivan" wrote: > >> I am not one who especially believes that representativity is the >> essential need, so getting the number or range of people -- "those who >> participate" -- is to me much less important than getting the range of >> views to take into consideration. > > I suspect we might have a different understanding of the concept of > "representativity". Perhaps because of this, I can't well understand how > you would get the "range of views to take into consideration" without > enlarging the range of participants. You will really have to explain what range is larger than "anyone". Sorry to appear abrupt but this discussion is as old as the hills in IETF circles, and nobody has ever answered the question. Given that anyone may participate, it's legitimate to ask how to encourage wider participation but there is no need to change any of the formalities (because there aren't any). This argument does not, of course, apply to other SDOs that have some kind of membership rules. I suspect that the IETF is close to unique in this respect. Brian Brian From nobody Sun Mar 2 02:05: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 DB1811A0C71 for ; Sun, 2 Mar 2014 02:05:22 -0800 (PST) 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 sbrLQ2EMlDNL for ; Sun, 2 Mar 2014 02:05:21 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AD4551A0C6E for ; Sun, 2 Mar 2014 02:05:21 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so3177808iec.1 for ; Sun, 02 Mar 2014 02:05:19 -0800 (PST) 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=lrTOsqHqXNcp/ZbyumMr8bm64nEQY1MagZaqDFddSNg=; b=dx7BDOZDbsrRq3TJTfyfq9ii2AxQad0F4Og/dMWzdqzt42gnv+x7SQwYZcB/gqN0Y0 2xrYvxAC7QggKSF6IurbTD39CelSJ9eqEa1O1JkoHK+PX4+RaTfIGkJKz69JydLjmiFG hei+Y8Fy34Bqzmd58mJ+zWXpoX1omc4Pf0xB1/gAyDTl/C70oOtLNrajXbFZVkMrU7uo 63WaIdyUnKRmKx9mtYXXJdesHDMJXV7ULeRtUdhcNRkeU5EnQhFV8TsH1zbf1Ujp4aYx 55hEd1vGEdc0/Itqud5eW4wuR61oSIZch7Krfbjs/n9ixY9A7WC229H2i0pSxpar+XjP lfDA== MIME-Version: 1.0 X-Received: by 10.50.79.234 with SMTP id m10mr15220163igx.47.1393754719052; Sun, 02 Mar 2014 02:05:19 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 02:05:18 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 02:05:18 -0800 (PST) In-Reply-To: <5312F4E3.10907@gmail.com> References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <5312F4E3.10907@gmail.com> Date: Sun, 2 Mar 2014 11:05:18 +0100 X-Google-Sender-Auth: j3nOWYGLxnmwak1VlSDv2wfrGh0 Message-ID: From: Andrea Glorioso To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0122a59ceeed6f04f39cce43 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/_Q0e-3D-DnfMdl_tpT6wZF1v-MM Cc: internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 10:05:23 -0000 --089e0122a59ceeed6f04f39cce43 Content-Type: text/plain; charset=ISO-8859-1 Brian, On Mar 2, 2014 10:07 AM, "Brian E Carpenter" wrote: > You will really have to explain what range is larger than "anyone". So, any human being whose life is impacted by the technical decisions taken (among other places) within the IETF can participate? Even if s/he doesn't speak English? Note that I'm not suggesting a regime of translation for the IETF. (Working in the European Commission I'm well aware of the difficulties involved. I'm also aware of the practical and symbolic advantages.) Even if s/he doesn't have an Internet connection? Even if s/he comes from a cultural background that makes it exceptionally hard to adapt to the standard norms of behaviour within the IETF? The IETF is actually much better than many other SDOs I'm aware of; but let's just keep in mind that the notion of "anyone" is not as clear cut as it might seem. As I have also said many times on this list, there is a difference between being open and being inclusive; or between the potential and the actual involvement of a broader range of persons and views. > Sorry to appear abrupt but this discussion is as old as the hills > in IETF circles, and nobody has ever answered the question. Actually, the discussion on formal v practical conditions for active participation in social groups is way older than the IETF. And while no easy, universal answers to reducing the gap between formal and actual breadth of participation exist, the assumption that mere "openness" is a sufficient condition has been shown time and again to be, let's say, optimistic. > Given that anyone may participate, it's legitimate to ask how to > encourage wider participation but there is no need to change > any of the formalities (because there aren't any). I don't think anyone is asking this, but I'm not entirely sure what you mean by "formalities" in this context. Best, Andrea --089e0122a59ceeed6f04f39cce43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Brian,

On Mar 2, 2014 10:07 AM, "Brian E Carpenter" <<= a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com> wrote:

> You will really have to explain what range is larger th= an "anyone".

So, any human being whose life is impacted by the technical = decisions taken (among other places) within the IETF can participate?

Even if s/he doesn't speak English?

Note that I'm not suggesting a regime of translation for= the IETF. (Working in the European Commission I'm well aware of the di= fficulties involved. I'm also aware of the practical and symbolic advan= tages.)

Even if s/he doesn't have an Internet connection?

Even if s/he comes from a cultural background that makes it = exceptionally hard to adapt to the standard norms of behaviour within the I= ETF?

The IETF is actually much better than many other SDOs I'= m aware of; but let's just keep in mind that the notion of "anyone= " is not as clear cut as it might seem.

As I have also said many times on this list, there is a diff= erence between being open and being inclusive; or between the potential and= the actual involvement of a broader range of persons and views.

> Sorry to appear abrupt but this discussion is as old as= the hills
> in IETF circles, and nobody has ever answered the question.

Actually, the discussion on formal v practical conditions fo= r active participation in social groups is way older than the IETF. And whi= le no easy, universal answers to reducing the gap between formal and actual= breadth of participation exist, the assumption that mere "openness&qu= ot; is a sufficient condition has been shown time and again to be, let'= s say, optimistic.

> Given that anyone may participate, it's legitimate = to ask how to
> encourage wider participation but there is no need to change
> any of the formalities (because there aren't any).

I don't think anyone is asking this, but I'm not ent= irely sure what you mean by "formalities" in this context.

Best,

Andrea

--089e0122a59ceeed6f04f39cce43-- From nobody Sun Mar 2 02:07: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 5E51C1A0C9B for ; Sun, 2 Mar 2014 02:07:47 -0800 (PST) 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 oxYsUzculaD0 for ; Sun, 2 Mar 2014 02:07:46 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 78D111A0C67 for ; Sun, 2 Mar 2014 02:07:46 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id h3so2835531igd.1 for ; Sun, 02 Mar 2014 02:07:44 -0800 (PST) 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=SBzrxOwURhqFUkD0AxbZkjMrOvwovud2sRC4MAq2cUE=; b=pD8tVxLD7kNzrmAG9cWkv8o2KiLgr8rPQWupk18ZNbubypLeNFKpi2/WRX4pgiWDgN Z6wpSqglitXYDDKxswKUgUUssWWRDNARoBh0ELeZ4XF/TNPkwuRwUduNTBLwTVvi+4In xEJOIzEch6lDZd8bKGDYkHB8vE47aE7HVe6UlR81Nmu3wZGuoy+9Y4J5NTqN47yT8AKf HCpx0d/qcxEEXGKkTUAKr++53SGUZEBLZHhniLf93GTZb6qgt7Oo74yDZXb90eFFUbmv RdzX+aflryL7cQoMhTnkb5qXNHVjKl572UEQ6Lofdq1f15Q+lPdqxlgifTfiFif8Brft Dzvw== MIME-Version: 1.0 X-Received: by 10.42.97.193 with SMTP id p1mr20440994icn.32.1393754863958; Sun, 02 Mar 2014 02:07:43 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 02:07:43 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 02:07:43 -0800 (PST) In-Reply-To: <20140302090225.GB3482@mx1.yitter.info> References: <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <20140302090225.GB3482@mx1.yitter.info> Date: Sun, 2 Mar 2014 11:07:43 +0100 X-Google-Sender-Auth: J0KHWB0ELwFlKFlH_vyuBNqg5Pk Message-ID: From: Andrea Glorioso To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf3036396591ff1f04f39cd753 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Hcd-wnoS7kbZwistKGM90JR-20I Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 10:07:47 -0000 --20cf3036396591ff1f04f39cd753 Content-Type: text/plain; charset=ISO-8859-1 Andrew, On Mar 2, 2014 10:02 AM, "Andrew Sullivan" wrote: > > On Sun, Mar 02, 2014 at 09:36:12AM +0100, Andrea Glorioso wrote: > > > "representativity". Perhaps because of this, I can't well understand how > > you would get the "range of views to take into consideration" without > > enlarging the range of participants. > > Some think that there is an approximate 1:1 relationship between > people and a view. I just don't believe that, because I know that I > myself am able to contemplate things from more than one point of view. > Often, in an area where I am sufficiently experienced, I can come up > with the entire problem statement on my own without polling anyone, > and it'll be close enough for the purposes of starting work. This > does not rely on including more people, but rather on including more > points of view. Thanks. But at which point does this become an untested assumption that you "know better" that other people with completely different expertise, background, motivations, priorities etc? Best, Andrea --20cf3036396591ff1f04f39cd753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Andrew,

On Mar 2, 2014 10:02 AM, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote= :
>
> On Sun, Mar 02, 2014 at 09:36:12AM +0100, Andrea Glorioso wrote:
>
> > "representativity". Perhaps because of this, I can'= t well understand how
> > you would get the "range of views to take into consideration= " without
> > enlarging the range of participants.
>
> Some think that there is an approximate 1:1 relationship between
> people and a view. =A0I just don't believe that, because I know th= at I
> myself am able to contemplate things from more than one point of view.=
> Often, in an area where I am sufficiently experienced, I can come up > with the entire problem statement on my own without polling anyone, > and it'll be close enough for the purposes of starting work. =A0Th= is
> does not rely on including more people, but rather on including more > points of view.

Thanks. But at which point does this become an untested assu= mption that you "know better" that other people with completely d= ifferent expertise, background, motivations, priorities etc?

Best,

Andrea

--20cf3036396591ff1f04f39cd753-- From nobody Sun Mar 2 02:22: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 3653E1A0C54 for ; Sun, 2 Mar 2014 02:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 KRKnBVCOhBgt for ; Sun, 2 Mar 2014 02:22:07 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E91EC1A0C2A for ; Sun, 2 Mar 2014 02:22:06 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm4so2267461wib.8 for ; Sun, 02 Mar 2014 02:22:03 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=QOhX7aZRCA1mp7v5qhETzrIzz7J983M5k0iQFMUa7jc=; b=Eb0KPtJXFloI/uW4vGwSCKyr3AW0yQjTng9P01stXKMwZ1u2YXgZ0ZZ5AEcYj6hjLA LDiQ3I1i4bU70DxddBZIQYMs41dxSUR0Agfl1ZXCsPnzPqReRoLchOmY+hhK6qd+1dF8 D/VHK9gEJATXuf0VcmiWT90N9QLVjUuPymyJfQpSkWjeOEEOtSX1LwMwJ2VlXuQsKDBL tCLDIhmcb+sjsil54UqEZ7DBgYb11kAlrBAd6Yipr0DpiAn67c8mrs3K29n2ddvx7+sJ 2sXR3bgzDf4+yeQsCBcOH/UL9HylOo7ZHPSlTBy77q/K4OIh+deehLXv8PvWVmiHg7Dt WNew== X-Received: by 10.194.6.106 with SMTP id z10mr497815wjz.1.1393755723704; Sun, 02 Mar 2014 02:22:03 -0800 (PST) Received: from dhcp-a59a.meeting.ietf.org (dhcp-a59a.meeting.ietf.org. [31.133.165.154]) by mx.google.com with ESMTPSA id fs4sm22535545wib.11.2014.03.02.02.22.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 02:22:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <20140301234336.GA3277@mx1.yitter.info> Date: Sun, 2 Mar 2014 05:22:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301234336.GA3277@mx1.yitter.info> To: "internetgovtech@iab.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/6_4EdEMMsN8cX_S92GJ5JcNUtoM Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 10:22:09 -0000 On Mar 1, 2014, at 6:44 PM, Andrew Sullivan = wrote: > Hi, >=20 > On Sat, Mar 01, 2014 at 11:02:38AM -0500, John Curran wrote: >> Be very careful... If the governments don't realistically have any = choice=20 >> in the use of the Internet (i.e. participation is effectively = mandatory=20 >> due to the social/economic benefits), and obtaining such benefits = requires=20 >> use of Internet protocols as proscribed by the IETF, then we're = fairly=20 >> distant from the principle of "Standards are voluntarily adopted". >=20 > That feels like a pretty fast rhetorical move to me. Nobody is saying > you must use any particular standard. Moreover, since the Internet is > a network of networks, _by definition_ the partcipation in the > internetworking is voluntary. If it were mandatory routing of packets > across all participating networks, it wouldn't be an internet at all; > it'd be one big network. =20 As may be, I think that John's point was along the lines that there can = be significant social and economic pressures that can look a lot like an = imperative to a government. "If your network doesn't enable access to = content and applications currently available only via TCP/IP-based = interconnection, your economic and social development as part of the = rest of the world will be subject to serious negative impacts" is not a = requirement to use any particular standard, but it's a pretty strong set = of constraints in some pretty common circumstances. >> If the IETF decides that some use cases are valid, and others are not >> valid, and the chosen use cases support particular social values in=20= >> them (e.g. individual privacy), then the protocol decisions based on >> those use cases is indeed embedding certain social/economic values. >=20 > Yes, of course. I agree with this. When you make a choice in favour > or against some particular technology, you are thereby also making the > choince in favour or against at least some of its consequences. I do > think we should make that choice thoughtfully and with awareness. >=20 > We better not left unsaid, however, that given some choices that have > been made already, we are not simply free to anything we like. Many > seem to think that, because this is technology, one could just make a > rule to change the way it works. But technology isn't like that: once > you have deployed a technology, it alters the world. We might wish we > hadn't built North America with miles of highways, huge suburban > tracts, and 1.5+ hour commutes for many people; tough. That's the > world we've actually got, and the only way it could change is with > massive social disruption. This is a critical point that we don't see raised much. IME people whose = primary frame of reference is policy tend to think of technology as = rather malleable, while people who start from engineering-based thinking = tend to regard policy as arbitrary and engineering constructs as far = more rigidly deterministic. Neither tends to systematically account for = the impact of the others' choices. We may have to settle for simply recognizing that both sets of = constraints are complex and likely to evolve over time, which would = still be a step forward. Suzanne From nobody Sun Mar 2 02:54: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 BEA8A1A0CC9 for ; Sun, 2 Mar 2014 02:54:46 -0800 (PST) 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 tjp3KRbxCrAD for ; Sun, 2 Mar 2014 02:54:44 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A532A1A0C72 for ; Sun, 2 Mar 2014 02:54:44 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi5so3348616wib.3 for ; Sun, 02 Mar 2014 02:54:41 -0800 (PST) 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=SroZh5dYbDN3u04ir7uGIZSUnaaGFCxfsI0vGL6Ia4E=; b=AtsNJkbJ6gy6V7LtT6YPs/SU7NV3H06W2PWCPEhMxl+hz5iIRWWS4q/KQpo1pU3kxi yAKH5hsUzzfEFp00MS5rd1DQtjN85QLA4C9NNis7iLRl09y93oG4AoxYfbmDWEh5AQRZ a5742W13ROaS0Ou+s18MSUu+wL261t7bOXGm5KC4V7m9N8n/XwGdNNr+Ql4eoHOSttyF 4sd9557sIihiZMVpv6qjVJR5prcoVG7NlpCUbgBxy18V/+lFwJJY+kuABbxMqZ4l1SMc 4y1lvcJ/nldkikcjVrRrMtLVjW3f8px/nVhI+n5yXTChMY30zMfcI+qHuDAFX6gXbai8 lfHw== X-Received: by 10.194.77.7 with SMTP id o7mr10340785wjw.35.1393757681722; Sun, 02 Mar 2014 02:54:41 -0800 (PST) Received: from [31.133.165.224] (dhcp-a5e0.meeting.ietf.org. [31.133.165.224]) by mx.google.com with ESMTPSA id hy8sm19780762wjb.2.2014.03.02.02.54.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 02:54:41 -0800 (PST) Message-ID: <53130DF1.2090401@gmail.com> Date: Sun, 02 Mar 2014 23:54:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrea Glorioso References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <5312F4E3.10907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/iMxFQCKJ-cyAJdympXWUlhRig9k Cc: internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 10:54:47 -0000 Andrea, Below... On 02/03/2014 23:05, Andrea Glorioso wrote: > Brian, > > On Mar 2, 2014 10:07 AM, "Brian E Carpenter" > wrote: > >> You will really have to explain what range is larger than "anyone". > > So, any human being whose life is impacted by the technical decisions taken > (among other places) within the IETF can participate? > > Even if s/he doesn't speak English? > > Note that I'm not suggesting a regime of translation for the IETF. (Working > in the European Commission I'm well aware of the difficulties involved. I'm > also aware of the practical and symbolic advantages.) > > Even if s/he doesn't have an Internet connection? > > Even if s/he comes from a cultural background that makes it exceptionally > hard to adapt to the standard norms of behaviour within the IETF? > > The IETF is actually much better than many other SDOs I'm aware of; but > let's just keep in mind that the notion of "anyone" is not as clear cut as > it might seem. > > As I have also said many times on this list, there is a difference between > being open and being inclusive; or between the potential and the actual > involvement of a broader range of persons and views. > >> Sorry to appear abrupt but this discussion is as old as the hills >> in IETF circles, and nobody has ever answered the question. > > Actually, the discussion on formal v practical conditions for active > participation in social groups is way older than the IETF. And while no > easy, universal answers to reducing the gap between formal and actual > breadth of participation exist, the assumption that mere "openness" is a > sufficient condition has been shown time and again to be, let's say, > optimistic. > >> Given that anyone may participate, it's legitimate to ask how to >> encourage wider participation but there is no need to change >> any of the formalities (because there aren't any). > > I don't think anyone is asking this, but I'm not entirely sure what you > mean by "formalities" in this context. On the contrary, I believe that the IETF has been asking itself this for many years. In 1992 when I first showed up, it was still Europeans who were having the difficulties you mention; after that it was Japanese and Korean participants; more recently it has been (e.g.) Chinese colleagues; there are still other regions to go. That's why we have things like the ISOC fellowships, the newcomers mentoring program(me), an IETF education team, and so on. I say "formalities" because you seem to be asking for some kind of formal change to fix these problems. I regard them as properties of human society that we have to deal with pragmatically. Brian From nobody Sun Mar 2 03:16: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 CAF7F1A0D33 for ; Sun, 2 Mar 2014 03:16:11 -0800 (PST) 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 6QDCUF5DzqYx for ; Sun, 2 Mar 2014 03:16:10 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 23FF81A01B7 for ; Sun, 2 Mar 2014 03:16:10 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so579573iec.37 for ; Sun, 02 Mar 2014 03:16:07 -0800 (PST) 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=1ggLRQxk9jRJOvvFImtdFY6US2QuEFMU8aRiypGVB7s=; b=y7VyZ43dr8Rr+o4cihcQaIQT0GvgLGsILNeV/khGUdac0VtX2yWEEvu8DHSckzj5oH OeSES5AKyy3Skp0ORkqUMgBIumxSTGU204yHpUuKfdUod0ZZ5Zhw5QaLc++jqsL67bmt oYOPra48rtLYllBKWuf4nefDzUIp4AMwqbBpJVd+0s2mK9CTTmr5HLC6IK3FQAk5ISrt UjGVRNCQmsUaC8PgWgSS4rJ2XP4vx7yZnkxyFZwurD6GcQfwJBUKUy/arMAWdf7wZ5Nw MD77tulI7tPHJ8BknqFZSdgFQIHCi+CE5RuKBZfBiB7g62/rk146eO/QBctx/96W78ir qfcw== MIME-Version: 1.0 X-Received: by 10.50.253.70 with SMTP id zy6mr15916292igc.28.1393758967409; Sun, 02 Mar 2014 03:16:07 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 03:16:07 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 03:16:07 -0800 (PST) In-Reply-To: <53130DF1.2090401@gmail.com> References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <5312F4E3.10907@gmail.com> <53130DF1.2090401@gmail.com> Date: Sun, 2 Mar 2014 12:16:07 +0100 X-Google-Sender-Auth: sOnD90wsY9ecNeaqhtk-mWBHviI Message-ID: From: Andrea Glorioso To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113475f427b3a804f39dccc8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ydcf4lO1KzAgcppvmnmaJNJD8oM Cc: internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 11:16:12 -0000 --001a113475f427b3a804f39dccc8 Content-Type: text/plain; charset=ISO-8859-1 Brian, On Mar 2, 2014 11:54 AM, "Brian E Carpenter" wrote: > On the contrary, I believe that the IETF has been asking itself this > for many years. In 1992 when I first showed up, it was still Europeans > who were having the difficulties you mention; after that it was Japanese > and Korean participants; more recently it has been (e.g.) Chinese > colleagues; there are still other regions to go. That's why we have things > like the ISOC fellowships, the newcomers mentoring program(me), an > IETF education team, and so on. I'm not sure why you opened this passage with "on the contrary". I don't think (and I didn't say) that the IETF hasn't done anything to ensure more / better / broader participation. I said that the debates on formal v real inclusiveness and the ways / tools to achieve the latter are older than the IETF. Whether people wants to consider different experiences in the broader problem space is another question. > I say "formalities" because you seem to be asking for some kind of formal > change to fix these problems. I regard them as properties of human society > that we have to deal with pragmatically. I agree that dealing with these issues in a pragmatic manner (which doesn't mean "purely reactive and ad hoc") is a good approach. We need first to agree whether there is an issue at all, though. I'm not sure we do agree on this. Best, Andrea --001a113475f427b3a804f39dccc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Brian,

On Mar 2, 2014 11:54 AM, "Brian E Carpenter" <<= a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com> wrote:

> On the contrary, I believe that the IETF has been askin= g itself this
> for many years. In 1992 when I first showed up, it was still Europeans=
> who were having the difficulties you mention; after that it was Japane= se
> and Korean participants; more recently it has been (e.g.) Chinese
> colleagues; there are still other regions to go. That's why we hav= e things
> like the ISOC fellowships, the newcomers mentoring program(me), an
> IETF education team, and so on.

I'm not sure why you opened this passage with "on t= he contrary". I don't think (and I didn't say) that the IETF h= asn't done anything to ensure more / better / broader participation. I = said that the debates on formal v real inclusiveness and the ways / tools t= o achieve the latter are older than the IETF. Whether people wants to consi= der different experiences in the broader problem space is another question.=

> I say "formalities" because you seem to be as= king for some kind of formal
> change to fix these problems. I regard them as properties of human soc= iety
> that we have to deal with pragmatically.

I agree that dealing with these issues in a pragmatic manner= (which doesn't mean "purely reactive and ad hoc") is a good = approach. We need first to agree whether there is an issue at all, though. = I'm not sure we do agree on this.

Best,

Andrea

--001a113475f427b3a804f39dccc8-- From nobody Sun Mar 2 03: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 F1CC51A0909 for ; Sun, 2 Mar 2014 03:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.231 X-Spam-Level: ** X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=0.6, 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 G-w9xdtl2ofP for ; Sun, 2 Mar 2014 03:20:50 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id DA7FD1A01B7 for ; Sun, 2 Mar 2014 03:20:50 -0800 (PST) Received: from [85.159.233.116] (port=23650 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WK4Rq-0004iy-PF; Sun, 02 Mar 2014 03:20:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Mar 2014 12:20:43 +0100 To: Andrea Glorioso , Brian E Carpenter From: Jefsey In-Reply-To: References: <6.2.5.6.2.20140225114956.0db9bf88@resistor.net> <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <5312F4E3.10907@gmail.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: 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/fHgkLqX4t0SFgGmKr5kBgb7Pv_I Cc: internetgovtech@iab.org, Andrew Sullivan Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 11:20:52 -0000 At 11:05 02/03/2014, Andrea Glorioso wrote: >So, any human being whose life is impacted by the technical >decisions taken (among other places) within the IETF can participate? >Even if s/he doesn't speak English? >Note that I'm not suggesting a regime of translation for the IETF. >(Working in the European Commission I'm well aware of the >difficulties involved. I'm also aware of the practical and symbolic >advantages.) >Even if s/he doesn't have an Internet connection? >Even if s/he comes from a cultural background that makes it >exceptionally hard to adapt to the standard norms of behaviour within the IETF? >The IETF is actually much better than many other SDOs I'm aware of; >but let's just keep in mind that the notion of "anyone" is not as >clear cut as it might seem. These points are certainly correct. I have suffered from these difficulties due to language, to perspective (I am considering the network from a "cosmological" point of view where each user is the center of its own network), and to a different architectural culture. Nevertheless I always considered the IETF as a particular human successful achievement (aside of its deliverables). This is why I oppose(d?) to the OpenStand unballance, removing the existence of an ultimate referent (assumed by the IAB until now to the benefit of an unclear reading of markets economics). On another hand, OpenStand may be a step ahead if an MS referential practice develops. This would be another contribution of the IETF model. Anyway, considering these points I pleaded for a way to welcome internet informed users (IUsers) out of tune with IETF practices or motivations, and permit them to contribute. I drafted a charter that the IETF chair reviewed (http://iucg.org/wiki/IUCG_Charter which should now be reviewed), the non-WG IUCG@IETF (informed users contributing group) mailing list was started, and a site was created along the expressed suggestions received. It was accepted that (1) people could contribute in their own language, in the hope that at least one person could report the debate in English/French, and (2) that English and French would be used for documenting. The interest was certainly the multilinguistics issues (as the cybernetics of languages) that initiators had positively faught for at the WG/IDNAbis, but more importantly the advantage of a multicultural thinking when adapting one single culture (IETF) deliverables to users of many cultures. The fault is probably mine, but the result is very mitigated. I do not think the problem is the outreach capacity (there are around 60 members on the list, so there could be some viral effect). Nor the momentum (different works inititated by IUCG members are developping in e-linguistic or VGNs). My evaluation is more a fundamental difference of motivation and technical layer between engineers and users. It is quite impossible to start a debate and keep it on the list: the debates become private (I have in parallel a French list with more than 200 people who could qualify as IUsers, politicians, R&D, academics, etc. where debate can be started/continued and sometimes sustained at high architectincal layers). However, most important imputs are by copied mails to small groups. I am in the process of trying to formalise this as "a center of expertise" to see if one can stabilize this kind of process among accepted peers. My experience completes what Andrew Sullivan explained. People are not so much interested in being represented or in discussing details (they have their own business to mind). They are interested that their needs and contributions are defended. So, they want to make sure that a "champion" (or a "rod ligthning") represents them. One important point is that they do not mind the number (they do not believe in kings and votes either) they are interested in coherent pertinence with what they think, to check if they are consistently correct and then that good idea proceeds. However, they are not ready to fight for a technical opinion, they mostly demand a result they can adhere to because it makes sense (i.e. it works and look stable enough for them to learn it and build atop). On the countrary they are are ready to support very tough fights (via a competent champion) for ethical or anthropic motive (in the case of lang-tags saga, I was proposed several times a crowd budget for an IETF DoT [denial of thinking]) My 2 cents. jfc >As I have also said many times on this list, there is a difference >between being open and being inclusive; or between the potential and >the actual involvement of a broader range of persons and views. > > > Sorry to appear abrupt but this discussion is as old as the hills > > in IETF circles, and nobody has ever answered the question. > >Actually, the discussion on formal v practical conditions for active >participation in social groups is way older than the IETF. And while >no easy, universal answers to reducing the gap between formal and >actual breadth of participation exist, the assumption that mere >"openness" is a sufficient condition has been shown time and again >to be, let's say, optimistic. > > > Given that anyone may participate, it's legitimate to ask how to > > encourage wider participation but there is no need to change > > any of the formalities (because there aren't any). > >I don't think anyone is asking this, but I'm not entirely sure what >you mean by "formalities" in this context. > >Best, > >Andrea >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech From nobody Sun Mar 2 03:49: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 94DAF1A0D58 for ; Sun, 2 Mar 2014 03:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ao9U86B8EWER for ; Sun, 2 Mar 2014 03:49:30 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 702171A0D6A for ; Sun, 2 Mar 2014 03:49:08 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id uy17so5411247igb.3 for ; Sun, 02 Mar 2014 03:49:05 -0800 (PST) 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:content-type; bh=L0RA+oxWlJ/KO/ur3v4dcTMxU8BpE3mGnanNRIHKklc=; b=kXdnTUwv527TtLXA3YVwUg0GprB4QudsV4422kPYBw900+kGxSAwbacnG6tMOYlZNu K9vxi9WLr2F9gJ4xTrprTsILn8n56F+eMkceWZnWNs9JKhZo0Aj6m6dvX10LPmMRP9/e DRpauAbEFyxAxpuAf3Y/8Myrk1rIuUsZvUk8lbWKOoQvBv/WzRV1Eo9JqsTNPfj7Cqtt 4ujMv2gA4Fs7uuAdgwApqgp1caQco1ty8v3Ja5DB3c6aOZD1u4iHQnPl1DnGWFgcaDiv WBOw4i1BDaJ67cfz8wKPo9FCmvHdXxvNqkjNdsltC6n0s8FpJjy8hFcOCR+ll1ZyM2Sx PlZQ== MIME-Version: 1.0 X-Received: by 10.43.81.196 with SMTP id zz4mr1325427icb.61.1393760945824; Sun, 02 Mar 2014 03:49:05 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 03:49:05 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 03:49:05 -0800 (PST) In-Reply-To: <018d01cf32f6$eca825a0$c5f870e0$@riw.us> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> Date: Sun, 2 Mar 2014 12:49:05 +0100 X-Google-Sender-Auth: 9DHLOsvu63UFLbXOPGoLbnOPy80 Message-ID: From: Andrea Glorioso To: Russ White , internetgovtech@iab.org Content-Type: multipart/alternative; boundary=bcaec517c7a413eac304f39e42c6 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/gJMyZi8RD_N2_gFxL-w1kb19ZZc Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 11:49:32 -0000 --bcaec517c7a413eac304f39e42c6 Content-Type: text/plain; charset=ISO-8859-1 Dear Russ, dear all, On Feb 26, 2014 2:30 PM, "Russ White" wrote: > The internet standards system is not based on "market acceptance." While > standards are ultimately judged by the market (just as GM foods will be, for > better or worse, because you ultimately can't _make_ people eat them), Actually you can, since many people eat GM foods without realising they are doing it. But let's not go too much off topic... > "the > market" doesn't design these standards. Engineers do. In a sense, then, > there already is an "oversight committee," that looks after internet > standards. Sorry, but... "oversight" (your word, not mine) of what precisely? > We aren't discussing total chaos verses government control here, > we're discussing how governments should influence the standards process that > already exists. Let's not devolve into a false dichotomy. I agree - but the dichotomy is certainly not proposed by the European Commission, which is calling for broader, upstream, timely etc involvement of *all* stakeholders. > So what you seem to be saying is: "Governments should assess the political > and social impact of technology choices, and have some way to input these > impacts into the standards setting process." Can you verify this is what you > are saying, or correct my misunderstanding? If you replace "Governments" with "all stakeholders" that's a reasonable approximation of what the European Commission is saying. > From an engineering perspective, the question that matters is where the > rubber meets the road. What do you (or the commission), think this > interaction will look like? More involvement from government stakeholders in > the process as it stands? Or an additional step someplace along the way to > ensure any new protocol choices meet some sort of social standards setting > (and by whom)? If this is what you're saying -- on what basis should > governments evaluate the social and political impact of technologies? And > how can governments have this sort of input without de facto overruling any > and all technical considerations, in the end? It's not easy to answer your questions because you (wrongly) limit the scope of the parties to be better involved, only to governments. I'd also expect, IF there is agreement on the desirability of the goal (which I'm not sure is there) THEN the persons with a better understanding of the organisation (the IETF in this case - and no, I'm not using the term "organisation" as a formal entity) would come up with some initial options. But having said this - I'll try to follow up on this point separately, as soon as possible. > My answer is -- governments should influence the standards like everyone > else does, through providing technical expertise and determining which > standards are applicable to specific technical problems. Not through any > form of "formal oversight." Noted, although I don't see the European Commission proposing this. > I don't see the value in adding some further layer to the > standards process to get some form of government approval. Again noted, and again I don't see the European Commission proposing this. Andrea PS: since you clearly meant the passage on "would be a pity if something happened to the IETF" as a joke, I don't want to dwell too much on it or make it bigger than it is. But please be aware that my family comes from Sicily and I have first-hand experience of that kind of sentences being the start of pain, misery and in certain cases death of innocent people. So I'm not particularly thrilled when I see my sincere attempts at ensuring the long-term sustainability of the Internet (with all possible disagreements on the ways to do so) being framed in the way you did. I'm trying to be liberal in what I accept, but I hope people will try to be conservative in what they send. --bcaec517c7a413eac304f39e42c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Russ, dear all,

On Feb 26, 2014 2:30 PM, "Russ White" <russw@riw.us> wrote:

> The internet standards system is not based on "mar= ket acceptance." While
> standards are ultimately judged by the market (just as GM foods will b= e, for
> better or worse, because you ultimately can't _make_ people eat th= em),

Actually you can, since many people eat GM foods without rea= lising they are doing it. But let's not go too much off topic...

> "the
> market" doesn't design these standards. Engineers do. In a se= nse, then,
> there already is an "oversight committee," that looks after = internet
> standards.

Sorry, but... "oversight" (your word, not mine) of= what precisely?

> We aren't discussing total chaos verses government = control here,
> we're discussing how governments should influence the standards pr= ocess that
> already exists. Let's not devolve into a false dichotomy.

I agree - but the dichotomy is certainly not proposed by the= European Commission, which is calling for broader, upstream, timely etc in= volvement of *all* stakeholders.

> So what you seem to be saying is: "Governments sho= uld assess the political
> and social impact of technology choices, and have some way to input th= ese
> impacts into the standards setting process." Can you verify this = is what you
> are saying, or correct my misunderstanding?

If you replace "Governments" with "all stakeh= olders" that's a reasonable approximation of what the European Com= mission is saying.

> From an engineering perspective, the question that matt= ers is where the
> rubber meets the road. What do you (or the commission), think this
> interaction will look like? More involvement from government stakehold= ers in
> the process as it stands? Or an additional step someplace along the wa= y to
> ensure any new protocol choices meet some sort of social standards set= ting
> (and by whom)? If this is what you're saying -- on what basis shou= ld
> governments evaluate the social and political impact of technologies? = And
> how can governments have this sort of input without de facto overrulin= g any
> and all technical considerations, in the end?

It's not easy to answer your questions because you (wron= gly) limit the scope of the parties to be better involved, only to governme= nts.

I'd also expect, IF there is agreement on the desirabili= ty of the goal (which I'm not sure is there) THEN the persons with a be= tter understanding of the organisation (the IETF in this case - and no, I&#= 39;m not using the term "organisation" as a formal entity) would = come up with some initial options.

But having said this - I'll try to follow up on this poi= nt separately, as soon as possible.

> My answer is -- governments should influence the standa= rds like everyone
> else does, through providing technical expertise and determining which=
> standards are applicable to specific technical problems. Not through a= ny
> form of "formal oversight."

Noted, although I don't see the European Commission prop= osing this.

> I don't see the value in adding some further layer = to the
> standards process to get some form of government approval.

Again noted, and again I don't see the European Commissi= on proposing this.

Andrea

PS: since you clearly meant the passage on "would be a = pity if something happened to the IETF" as a joke, I don't want to= dwell too much on it or make it bigger than it is. But please be aware tha= t my family comes from Sicily and I have first-hand experience of that kind= of sentences being the start of pain, misery and in certain cases death of= innocent people. So I'm not particularly thrilled when I see my sincer= e attempts at ensuring the long-term sustainability of the Internet (with a= ll possible disagreements on the ways to do so) being framed in the way you= did. I'm trying to be liberal in what I accept, but I hope people will= try to be conservative in what they send.

--bcaec517c7a413eac304f39e42c6-- From nobody Sun Mar 2 03:56: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 E8A8C1A0D47 for ; Sun, 2 Mar 2014 03:56:45 -0800 (PST) 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 N59PqLdNTKV5 for ; Sun, 2 Mar 2014 03:56:44 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A903B1A0D37 for ; Sun, 2 Mar 2014 03:56:44 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id to1so5151396ieb.30 for ; Sun, 02 Mar 2014 03:56:42 -0800 (PST) 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=Iz8pVoMdfGfROWevMjbbUnpZvjjrOganPQSi3l4CoOU=; b=zyySaFW3WBRIy7O2Ms/26lE6e3XGesTFPgIu3zKH3Y4nn5zjLef9MY9RjZXpxuRQFx 7V6Df932DmP06mGhExAx5wxiUU3C6bVSMSKBM7jT40wqXdHIS7yYAl0EzGe2kZkVnooP 0eZLDWXS/ulLAyJnQgsOzDqDyjJ1JkBSKRiu1QmeDLno9c8EFisYYdUzp+fWnBA43ADg OhCaLGpFdhS0o+yoRbVHF3jXy0f5o4FSl6lT7qLYtb8wGh+qp6lK/TZNPPJWiGeX5nUJ CgPsNb/0E/Is/ieIWA/OnuL+93wEHUlZHHRv8mapIwv5TK5ovrc2/wSd+P7KdgiRiZje Xgpg== MIME-Version: 1.0 X-Received: by 10.50.79.166 with SMTP id k6mr15764628igx.47.1393761402083; Sun, 02 Mar 2014 03:56:42 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 03:56:41 -0800 (PST) Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 03:56:41 -0800 (PST) In-Reply-To: <01f001cf32f8$ba891d20$2f9b5760$@riw.us> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <530CFB19.3080607@joelhalpern.com> <01f001cf32f8$ba891d20$2f9b5760$@riw.us> Date: Sun, 2 Mar 2014 12:56:41 +0100 X-Google-Sender-Auth: Hd7Szw2UC9WDLzZXS9kgdI38jYw Message-ID: From: Andrea Glorioso To: Russ White Content-Type: multipart/alternative; boundary=089e013a114e45df5b04f39e5df8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3zz197TP2diuZCO4OxPjPaHOXnA Cc: internetgovtech@iab.org, "Joel M. Halpern" Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 11:56:46 -0000 --089e013a114e45df5b04f39e5df8 Content-Type: text/plain; charset=ISO-8859-1 Dear Russ, dear all, On Feb 26, 2014 2:43 PM, "Russ White" wrote: > But this is precisely where I'm confused. The two statements: > > "We don't want a formal process, just strengthening the ones that are > already there." > > And > > "We want to create structured mechanisms to allow regular, early, and truly > inclusive upstream participation..." First of all "we" (by which I assume you mean "the European Commission") don't want to create anything by ourselves alone. We might not even have any role besides raising the question and, if useful, participate in the discussions. In any case, I fail to see the contradiction. IF processes to involve in a structured, upstream, etc manner *all* stakeholders DO NOT exist, they should be created; IF they DO exist but are not performing well enough, they should be strengthened; IF they DO exist and are already performing so well that nothing else is needed, then don't do anything. I'm aware many of the assessments above are inherently subjective and work is needed to develop shared criteria, but I hope the logic is clear enough. Best, Andrea --089e013a114e45df5b04f39e5df8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Russ, dear all,

On Feb 26, 2014 2:43 PM, "Russ White" <russw@riw.us> wrote:

> But this is precisely where I'm confused. The two s= tatements:
>
> "We don't want a formal process, just strengthening the ones = that are
> already there."
>
> And
>
> "We want to create structured mechanisms to allow regular, early,= and truly
> inclusive upstream participation..."

First of all "we" (by which I assume you mean &quo= t;the European Commission") don't want to create anything by ourse= lves alone. We might not even have any role besides raising the question an= d, if useful, participate in the discussions.

In any case, I fail to see the contradiction.
IF processes to involve in a structured, upstream, etc manner *all* stakeho= lders DO NOT exist, they should be created; IF=A0 they DO exist but are not= performing well enough, they should be strengthened; IF they DO exist and = are already performing so well that nothing else is needed, then don't = do anything.

I'm aware many of the assessments above are inherently s= ubjective and work is needed to develop shared criteria, but I hope the log= ic is clear enough.

Best,

Andrea

--089e013a114e45df5b04f39e5df8-- From nobody Sun Mar 2 04:30: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 13E761A0CB8 for ; Sun, 2 Mar 2014 04:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 txBRDA3eBJqr for ; Sun, 2 Mar 2014 04:30:29 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id C480E1A0C85 for ; Sun, 2 Mar 2014 04:30:28 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:60185 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WK5X5-0001gh-Qc; Sun, 02 Mar 2014 12:30:15 +0000 From: "Russ White" To: "'Andrea Glorioso'" , References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> In-Reply-To: Date: Sun, 2 Mar 2014 07:30:13 -0500 Message-ID: <013e01cf3613$293b89c0$7bb29d40$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJMFih2b/pqIL5HvUFCBvP9zfnmIAHwS+XUAcF8GWsC7qp9sgH+vKWhAszX6ToCRYMQCgJb3hQGAdISwhECnP4jHwI/k6oSAc9P27sBuA+1HwIH1RQWAbzX6ZiY47H+QA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/81UQEIuYHYBpbxluHZTjWDd0UBc Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 12:30:32 -0000 > > The internet standards system is not based on "market acceptance." > > Actually you can, since many people eat GM foods without realising they are > doing it. But let's not go too much off topic... Sure, if you lie to people, you can get them to do anything you want. Since the IETF is a transparent process, however, there's not much of a chance of that here. > > there already is an "oversight committee," that looks after internet > > standards. > > Sorry, but... "oversight" (your word, not mine) of what precisely? Internet standards within the IETF. The IETF, itself, has several layers of oversight built in. There is a process of building a problem statement, which leads to building use cases, which then lead to requirements, which then lead to proposed standards, which are then discussed by a working group over a long period of time, which then leads to approval/nonapproval by a pair of carefully chosen working group chairs, which then leads to approval/disapproval by a pair of area directors chosen by a randomly selected representative committee for their technical and organizational skills, which then leads to approval/disapproval by the full set of area directors and others, which leads to a discussion among another technical committee that is carefully chosen, which then leads to a final call through the entire IETF, and can lead to the discuss process or individual objections which can be brought to the attention of the IETF at large and discussed again, which finally leads to the publication of a draft that can be modified through other drafts going through the same process, and possible implementation (if the market decides), but cannot become a "standard" until it is actually implemented on multiple platforms and proven to interoperate. So there are at least five or six layers where anyone -- _anyone_ -- can get involved in the process. Any representative of any government can work in the use cases or requirements space without even worrying about the technical processes, and can then work in the final call space to raise objections to any proposed standard. Other than showing various government representatives how this process works, so they can jump into it, I don't see how or why we need any sort of additional level of oversight and review. The process is open. People should use it. > I agree - but the dichotomy is certainly not proposed by the European > Commission, which is calling for broader, upstream, timely etc involvement > of *all* stakeholders. Universities, operators (though not enough IHMO), vendors, and various internet governance organizations are already represented within the IETF process. The only "stakeholder," I see being mentioned as needing a larger role is governments from a policy perspective (some governments are already involved from a technical perspective through research and standards organizations). > > So what you seem to be saying is: "Governments should assess the > political > > and social impact of technology choices, and have some way to input > these > > impacts into the standards setting process." Can you verify this is > what you > > are saying, or correct my misunderstanding? > > If you replace "Governments" with "all stakeholders" that's a reasonable > approximation of what the European Commission is saying. Again, the only "stakeholder," I see being specifically mentioned is governments. If you'd like to broaden the term, please feel free to provide an actual example of someone other than a government, and more specifically, someone who cannot participate in the process as it stands for some reason, and you believe would provide valuable input. > It's not easy to answer your questions because you (wrongly) limit the scope > of the parties to be better involved, only to governments. Because governments are the only "stakeholder," mentioned to this point. > I'd also expect, IF there is agreement on the desirability of the goal (which > I'm not sure is there) THEN the persons with a better understanding of the > organisation (the IETF in this case - and no, I'm not using the term > "organisation" as a formal entity) would come up with some initial options. Honestly, I don't see an actual goal on which to agree in anything you've written so far. "We'd like to see all the stakeholders (undefined) to somehow better participate (undefined) through an upstream process (undefined) to better take policy (undefined) into account when writing technical standards." There are too many "undefined" bits in there for me to parse the actual proposal and determine if I agree with the goal or not. What I'm trying to do is to get you to define the "undefined's," so we can actually figure out what you're proposing in specific, concrete terms. Without an actual proposal, or rather an actual goal, it's impossible to agree or disagree. Again, I like to see the camel before letting the nose in. In principle, the process is already open, so I don't understand what problem is being addressed. The goal hasn't been stated -- to what end would these undefined stakeholders like to participate in a way that isn't already open to public participation? > Noted, although I don't see the European Commission proposing this. Then what does "involving more stakeholders to ensure social policies are correctly addressed," actually mean, from your (or the Commission's) perspective? If social concerns are not meant to override technical ones, or a consensus of government's view isn't meant to override technical considerations, then what specific input will be made by these undefined "stakeholders," and what sorts of undefined "policy results" are being projected onto the process? > > I don't see the value in adding some further layer to the standards > > process to get some form of government approval. > > Again noted, and again I don't see the European Commission proposing this. Then what, precisely, is being proposed? To have more stakeholders involved, but not having those stakeholders have any sort of say over the final outcome? And if these government stakeholders do have more "involvement," then what would that involvement look like other than saying, "we don't agree with this technical direction for social or political reasons, and therefore we expect the IETF to redirect its technical efforts?" > PS: since you clearly meant the passage on "would be a pity if something > happened to the IETF" as a joke, I don't want to dwell too much on it or make > it bigger than it is. But please be aware that my family comes from Sicily and I Yes, it was a joke. But when someone says, "We need to do something before the governments of the world decide to take matters into their own hands in some other way," that's precisely the impression I get. I was trying to make light of that impression, but I'm sorry if it has some sort of personal connection for you. Russ From nobody Sun Mar 2 04: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 B39471A0C99 for ; Sun, 2 Mar 2014 04:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.547] 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 xQ_QTNSycxTg for ; Sun, 2 Mar 2014 04:42:58 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id F2A8C1A0C46 for ; Sun, 2 Mar 2014 04:42:57 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:60385 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WK5jB-0001qg-U2; Sun, 02 Mar 2014 12:42:46 +0000 From: "Russ White" To: "'Andrea Glorioso'" , "'Andrew Sullivan'" References: <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <20140302090225.GB3482@mx1.yitter.info> In-Reply-To: Date: Sun, 2 Mar 2014 07:42:43 -0500 Message-ID: <015701cf3614$e854c870$b8fe5950$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIrSgWq3khbT/Np762orhlBSgg6HAJs1+lKAhhT7+0B7kJtqAIe8uIrAxY2GrUBpyFwOgIWkJF2AVXr1yACkhr7KwIfKjBoAiEtPguZWR1Z0A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/bna2CgNKwbMXq_PUtGHpVV_Fcok Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 12:43:32 -0000 > > Often, in an area where I am sufficiently experienced, I can come up > > with the entire problem statement on my own without polling anyone, > > and it'll be close enough for the purposes of starting work. This > > does not rely on including more people, but rather on including more > > points of view. > > Thanks. But at which point does this become an untested assumption that > you "know better" that other people with completely different expertise, > background, motivations, priorities etc? "And it'll be close enough for the purposes of a starting work." That's the key point. There are many layers of discussion and vetting before even the problem statement is taken as "final," and even then, most problem statements are never taken as "complete," or "final," in the IETF context. And all the discussion around acceptance or rejection of this "starting point," is open to public view. There are no closed or classified meetings here. This process was designed to be as open and fair as possible, focused on finding technical solutions to clearly defined problem sets. The process must take into account the competitive nature of vendors, researchers, and operators. What you seem to be saying is that it's not open to government (or some other undefined stakeholder) participation. What I'd like to understand is how and where, specifically, you think it's not, and what specific proposal you'd like to make to change what you perceive as a shortcoming. :-) Russ From nobody Sun Mar 2 05:26: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 4869F1A0732 for ; Sun, 2 Mar 2014 05:26:33 -0800 (PST) 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 D-cKThGVdWnO for ; Sun, 2 Mar 2014 05:26:29 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9FF1A0389 for ; Sun, 2 Mar 2014 05:26:29 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so3298127iec.29 for ; Sun, 02 Mar 2014 05:26:27 -0800 (PST) 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=7KkQG/sHsSx9DPLZ5LvRxV9GPzU0Buv6+tsN+/ghDoo=; b=0aEFMEfjogkD9KDU7pX2VZj73Gbr7nlpZMatYQ/LvxJeYEQ6LBDqiYhk57/PaXDALq S3kageBHvMkIGuNq3BQHZqFJsL4xFw4dGr+xPVbjDZFn7LXJUb6+Vr0JK7mKcBaBXWCK CN0NqZUMs+gL+qyvVzsKgRt++MC1xRE5A7wzL31l+YtynpeBNYrH3dhh1ipm3O+jpctr N6JEbJzHKZKsD5nMbooOjcgylO5nsf1riDZOVqBgkSezFlqkGaxQbskaVG9mBaRlK7Zm nieY26v3tEnpCeaPG/j2I/zFNycvwu6ckoFIzu+GL8U1LNf1XjFMpUay2GPcHBQzaUk4 VA/Q== MIME-Version: 1.0 X-Received: by 10.43.52.65 with SMTP id vl1mr310608icb.86.1393766786857; Sun, 02 Mar 2014 05:26:26 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 05:26:26 -0800 (PST) In-Reply-To: <013e01cf3613$293b89c0$7bb29d40$@riw.us> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> Date: Sun, 2 Mar 2014 14:26:26 +0100 X-Google-Sender-Auth: 6ErCC4nBldmRSo1DC7N_cjx9eq8 Message-ID: From: Andrea Glorioso To: Russ White Content-Type: multipart/alternative; boundary=bcaec52e5f413b02d104f39f9eb6 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vWc1FIUwNdKoiYfWW_HAtmvkyKI Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 13:26:33 -0000 --bcaec52e5f413b02d104f39f9eb6 Content-Type: text/plain; charset=ISO-8859-1 Dear Russ, dear all, first of all, I'd like to reiterate that we happen to be discussing the IETF process because this is an IAB mailing list. But the Communication on Internet Policy and Governance does *not* target specifically the IETF. It is possible, as I think I already said, that among the various SDOs (and more generally organisations / processes in which the Internet technical community gathers and deliberates) the processes of the IETF are already inclusive enough to take care of all necessary considerations, including the social impact (to simplify) of technical choices. I do have myself some doubts, on the basis of my own experience and of various conversations I have had throughout the years (including, frankly, discussions within the IETF itself). So, having clarified this... On Sun, Mar 2, 2014 at 1:30 PM, Russ White wrote: > > > > > The internet standards system is not based on "market acceptance." > > > > Actually you can, since many people eat GM foods without realising they > are > > doing it. But let's not go too much off topic... > > Sure, if you lie to people, you can get them to do anything you want. Since > the IETF is a transparent process, however, there's not much of a chance of > that here. > > > > there already is an "oversight committee," that looks after internet > > > standards. > > > > Sorry, but... "oversight" (your word, not mine) of what precisely? > > Internet standards within the IETF. The IETF, itself, has several layers of > oversight built in. There is a process of building a problem statement, > which leads to building use cases, which then lead to requirements, which > then lead to proposed standards, which are then discussed by a working > group > over a long period of time, which then leads to approval/nonapproval by a > pair of carefully chosen working group chairs, which then leads to > approval/disapproval by a pair of area directors chosen by a randomly > selected representative committee for their technical and organizational > skills, which then leads to approval/disapproval by the full set of area > directors and others, which leads to a discussion among another technical > committee that is carefully chosen, which then leads to a final call > through > the entire IETF, and can lead to the discuss process or individual > objections which can be brought to the attention of the IETF at large and > discussed again, which finally leads to the publication of a draft that can > be modified through other drafts going through the same process, and > possible implementation (if the market decides), but cannot become a > "standard" until it is actually implemented on multiple platforms and > proven > to interoperate. > > So there are at least five or six layers where anyone -- _anyone_ -- can > get > involved in the process. Any representative of any government can work in > the use cases or requirements space without even worrying about the > technical processes, and can then work in the final call space to raise > objections to any proposed standard. Other than showing various government > representatives how this process works, so they can jump into it, I don't > see how or why we need any sort of additional level of oversight and > review. > > The process is open. People should use it. > Although I agree that it would desirable if more people participated in the process, and that there are no *formal* obstacles to such participation (except perhaps the language, but I'm not sure you would consider that as a "formal" obstacle) I don't think we'll ever get around to agreeing that "openness" and "inclusiveness" are two different things. That's the basis of the position of the European Commission. So we'll have to agree to disagree on this point. > > > I agree - but the dichotomy is certainly not proposed by the European > > Commission, which is calling for broader, upstream, timely etc > involvement > > of *all* stakeholders. > > Universities, operators (though not enough IHMO), vendors, and various > internet governance organizations are already represented within the IETF > process. The only "stakeholder," I see being mentioned as needing a larger > role is governments from a policy perspective (some governments are already > involved from a technical perspective through research and standards > organizations). > How many sociologists participate in IETF processes? How many economists? How many scholars of international private / public law? How many psychologists? How many human rights NGOs / activists? How many philosophers? How many anthropologists? I could go on and on. And you will appreciate that none of the examples above refer to "governments" (which is in and by itself a too generic category, but that's stuff for another discussion I guess). Perhaps the answer will be "plenty" (I'd love to see that!). And perhaps the answer will be "we don't need these people to achieve the goals of the IETF" (again, please note that I'm focusing on the IETF because this is an IAB list, but it's not the purpose of the Commission to "single out" the IETF in any way or form). As I repeated multiple times, the answer "the process is open, so they could participate if they wanted to" is from my perspective simplistic and unsatisfactory. As I said, we'll probably have to agree to disagree on this point. > Again, the only "stakeholder," I see being specifically mentioned is > governments. If you'd like to broaden the term, please feel free to provide > an actual example of someone other than a government, and more > specifically, > someone who cannot participate in the process as it stands for some reason, > and you believe would provide valuable input. > Sorry, but "specifically mentioned" by whom? Certainly not by the European Commission is its Communication on Internet Policy and Governance, as I repeated many times. If people choose themselves to narrow the focus of the conversation that's their choice. > > I'd also expect, IF there is agreement on the desirability of the goal > (which > > I'm not sure is there) THEN the persons with a better understanding of > the > > organisation (the IETF in this case - and no, I'm not using the term > > "organisation" as a formal entity) would come up with some initial > options. > > Honestly, I don't see an actual goal on which to agree in anything you've > written so far. "We'd like to see all the stakeholders (undefined) to > somehow better participate (undefined) through an upstream process > (undefined) to better take policy (undefined) into account when writing > technical standards." There are too many "undefined" bits in there for me > to > parse the actual proposal and determine if I agree with the goal or not. > Fair enough. I don't see why it is not possible to agree on the general goal, but it is certainly necessary to develop the idea in more detail for some people to engage in the conversation. > What I'm trying to do is to get you to define the "undefined's," so we can > actually figure out what you're proposing in specific, concrete terms. > Without an actual proposal, or rather an actual goal, it's impossible to > agree or disagree. Again, I like to see the camel before letting the nose > in. In principle, the process is already open, so I don't understand what > problem is being addressed. The goal hasn't been stated -- to what end > would > these undefined stakeholders like to participate in a way that isn't > already > open to public participation? > The view of the European Commission is that by making it easier for different kinds of people to participate in the discussion, the end result would be better - at the very least in the sense that it would have analysed more "use cases" and assessed more in-depth the mid- and long-term "operational considerations" of any particular IETF specification. > > Noted, although I don't see the European Commission proposing this. > > Then what does "involving more stakeholders to ensure social policies are > correctly addressed," actually mean, from your (or the Commission's) > perspective? If social concerns are not meant to override technical ones, > or > a consensus of government's view isn't meant to override technical > considerations, then what specific input will be made by these undefined > "stakeholders," and what sorts of undefined "policy results" are being > projected onto the process? > Perhaps simply letting other IETF participants know that there are different views out there? Let me put it another way. If you were developing an IETF specification which defines how "personal data" (or, to use the US term, "personally identifiable information") should be shared between Internet hosts; and that specification did not allow for the end-user to express his/her consent to such sharing; would it help the drafters of the specification if a privacy lawyer pointed out that in a very large number of jurisdictions around the globe, this is probably going to make implementations of that specification illegal? I'm using on purpose a very simplistic example and I'm perfectly aware of the existence of the IETF-privacy mailing list, as well as of the fact that RFC normally include considerations related to privacy. I'm also aware that not allowing a user to express his/her consent would probably be incompatible with the end-to-end principle and other basic architectural / design characteristics of the Internet. But I hope this helps understand the logic. "Overriding" the technical concerns is not the only possible result of a conversation. > > > I don't see the value in adding some further layer to the standards > > > process to get some form of government approval. > > > > Again noted, and again I don't see the European Commission proposing > this. > > Then what, precisely, is being proposed? To have more stakeholders > involved, > but not having those stakeholders have any sort of say over the final > outcome? And if these government stakeholders do have more "involvement," > then what would that involvement look like other than saying, "we don't > agree with this technical direction for social or political reasons, and > therefore we expect the IETF to redirect its technical efforts?" > Already making sure that such a statement can be made on the basis of a proper debate would be an improvement over a situation in which no social, legal, cultural or political consideration / reason is factored in. Again, we can - and it seems to me, most certainly will - disagree whether the current processes of the IETF are already "good enough" to allow this. It happens. Best, -- I speak only for myself. Sometimes I do not even agree with myself. Keep it in mind. Twitter: @andreaglorioso Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=1749288&trk=tab_pro --bcaec52e5f413b02d104f39f9eb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Russ, dear all,

first of all, I'= ;d like to reiterate that we happen to be discussing the IETF process becau= se this is an IAB mailing list. But the Communication on Internet Policy an= d Governance does *not* target specifically the IETF. It is possible, as I = think I already said, that among the various SDOs (and more generally organ= isations / processes in which the Internet technical community gathers and = deliberates) the processes of the IETF are already inclusive enough to take= care of all necessary considerations, including the social impact (to simp= lify) of technical choices. I do have myself some doubts, on the basis of m= y own experience and of various conversations I have had throughout the yea= rs (including, frankly, discussions within the IETF itself).

So, having clarified this...

On Sun, Mar 2, 2014 at 1:30 PM, Russ White <russw@riw.us= > wrote:


> > The internet standards system is not based on "market accept= ance."
>
> Actually you can, since many people eat GM foods= without realising they
are
> doing it. But let's not go too much off topic...

Sure, if you lie to people, you can get them to do anything you want.= Since
the IETF is a transparent process, however, there's not much of a chanc= e of
that here.

> > there already is an "oversight committee," that looks a= fter internet
> > standards.
>
> Sorry, but... "oversight" (your word, not mine) of what prec= isely?

Internet standards within the IETF. The IETF, itself, has several lay= ers of
oversight built in. There is a process of building a problem statement,
which leads to building use cases, which then lead to requirements, which then lead to proposed standards, which are then discussed by a working grou= p
over a long period of time, which then leads to approval/nonapproval =A0by = a
pair of carefully chosen working group chairs, which then leads to
approval/disapproval by a pair of area directors chosen by a randomly
selected representative committee for their technical and organizational skills, which then leads to approval/disapproval by the full set of area directors and others, which leads to a discussion among another technical committee that is carefully chosen, which then leads to a final call throug= h
the entire IETF, and can lead to the discuss process or individual
objections which can be brought to the attention of the IETF at large and discussed again, which finally leads to the publication of a draft that can=
be modified through other drafts going through the same process, and
possible implementation (if the market decides), but cannot become a
"standard" until it is actually implemented on multiple platforms= and proven
to interoperate.

So there are at least five or six layers where anyone -- _anyone_ -- can ge= t
involved in the process. Any representative of any government can work in the use cases or requirements space without even worrying about the
technical processes, and can then work in the final call space to raise
objections to any proposed standard. Other than showing various government<= br> representatives how this process works, so they can jump into it, I don'= ;t
see how or why we need any sort of additional level of oversight and review= .

The process is open. People should use it.

<= div>Although I agree that it would desirable if more people participated in= the process, and that there are no *formal* obstacles to such participatio= n (except perhaps the language, but I'm not sure you would consider tha= t as a "formal" obstacle) I don't think we'll ever get ar= ound to agreeing that "openness" and "inclusiveness" ar= e two different things. That's the basis of the position of the Europea= n Commission. So we'll have to agree to disagree on this point.
=A0

> I agree - but the dichotomy is certainly not proposed by the European<= br> > Commission, which is calling for broader, upstream, timely etc involve= ment
> of *all* stakeholders.

Universities, operators (though not enough IHMO), vendors, and variou= s
internet governance organizations are already represented within the IETF process. The only "stakeholder," I see being mentioned as needing= a larger
role is governments from a policy perspective (some governments are already=
involved from a technical perspective through research and standards
organizations).

H= ow many sociologists participate in IETF processes?
How many economists?=
How many scholars of international private / public law?
How many psychologists?
How many human rights NGOs / activists?
How m= any philosophers?
How many anthropologists?

I could go on and on. And you will appreciate that none of the examples ab= ove refer to "governments" (which is in and by itself a too gener= ic category, but that's stuff for another discussion I guess).

Perhaps the answer will be "plenty" (I'd love to see that= !). And perhaps the answer will be "we don't need these people to = achieve the goals of the IETF" (again, please note that I'm focusi= ng on the IETF because this is an IAB list, but it's not the purpose of= the Commission to "single out" the IETF in any way or form).

As I repeated multiple times, the answer "the process i= s open, so they could participate if they wanted to" is from my perspe= ctive simplistic and unsatisfactory. As I said, we'll probably have to = agree to disagree on this point.
=A0
Again, the = only "stakeholder," I see being specifically mentioned is
governments. If you'd like to broaden the term, please feel free to pro= vide
an actual example of someone other than a government, and more specifically= ,
someone who cannot participate in the process as it stands for some reason,=
and you believe would provide valuable input.

Sorry, but "specifically mentioned" by whom? Certainly not= by the European Commission is its Communication on Internet Policy and Gov= ernance, as I repeated many times. If people choose themselves to narrow th= e focus of the conversation that's their choice.
=A0
> I'd also expect, IF there is agreement on the desirability of the = goal
(which
> I'm not sure is there) THEN the persons with a better understandin= g of the
> organisation (the IETF in this case - and no, I'm not using the te= rm
> "organisation" as a formal entity) would come up with some i= nitial
options.

Honestly, I don't see an actual goal on which to agree in anythin= g you've
written so far. "We'd like to see all the stakeholders (undefined)= to
somehow better participate (undefined) through an upstream process
(undefined) to better take policy (undefined) into account when writing
technical standards." There are too many "undefined" bits in= there for me to
parse the actual proposal and determine if I agree with the goal or not.

Fair enough. I don't see why it is no= t possible to agree on the general goal, but it is certainly necessary to d= evelop the idea in more detail for some people to engage in the conversatio= n.
=A0
What I'm trying to do is to get you to define the "undefined's= ," so we can
actually figure out what you're proposing in specific, concrete terms.<= br> Without an actual proposal, or rather an actual goal, it's impossible t= o
agree or disagree. Again, I like to see the camel before letting the nose in. In principle, the process is already open, so I don't understand wh= at
problem is being addressed. The goal hasn't been stated -- to what end = would
these undefined stakeholders like to participate in a way that isn't al= ready
open to public participation?

The view = of the European Commission is that by making it easier for different kinds = of people to participate in the discussion, the end result would be better = - at the very least in the sense that it would have analysed more "use= cases" and assessed more in-depth the mid- and long-term "operat= ional considerations" of any particular IETF specification.
=A0
> = Noted, although I don't see the European Commission proposing this.
=

Then what does "involving more stakeholders to ensure social pol= icies are
correctly addressed," actually mean, from your (or the Commission'= s)
perspective? If social concerns are not meant to override technical ones, o= r
a consensus of government's view isn't meant to override technical<= br> considerations, then what specific input will be made by these undefined "stakeholders," and what sorts of undefined "policy results&= quot; are being
projected onto the process?

Perhaps sim= ply letting other IETF participants know that there are different views out= there?

Let me put it another way. If you were developin= g an IETF specification which defines how "personal data" (or, to= use the US term, "personally identifiable information") should b= e shared between Internet hosts; and that specification did not allow for t= he end-user to express his/her consent to such sharing; would it help the d= rafters of the specification if a privacy lawyer pointed out that in a very= large number of jurisdictions around the globe, this is probably going to = make implementations of that specification illegal?

I'm using on purpose a very simplistic example and I'= ;m perfectly aware of the existence of the IETF-privacy mailing list, as we= ll as of the fact that RFC normally include considerations related to priva= cy. I'm also aware that not allowing a user to express his/her consent = would probably be incompatible with the end-to-end principle and other basi= c architectural / design characteristics of the Internet. But I hope this h= elps understand the logic. "Overriding" the technical concerns is= not the only possible result of a conversation.
=A0
> > I don't see the value in adding some further layer to the sta= ndards
> > process to get some form of government approval.
>
> Again noted, and again I don't see the European Commission proposi= ng this.

Then what, precisely, is being proposed? To have more stakeholders in= volved,
but not having those stakeholders have any sort of say over the final
outcome? And if these government stakeholders do have more "involvemen= t,"
then what would that involvement look like other than saying, "we don&= #39;t
agree with this technical direction for social or political reasons, and therefore we expect the IETF to redirect its technical efforts?"

Already making sure that such a statement ca= n be made on the basis of a proper debate would be an improvement over a si= tuation in which no social, legal, cultural or political consideration / re= ason is factored in.

Again, we can - and it seems to me, most certainly will - disagree whet= her the current processes of the IETF are already "good enough" t= o allow this. It happens.
=A0
Best,

--
I speak= only for myself. Sometimes I do not even agree with myself. Keep it in min= d.
Twitter: @andreaglorioso
Facebook: https://www.facebook.com/andrea.glorioso<= /a>
LinkedIn: http://www.linkedin.com/profile/vie= w?id=3D1749288&trk=3Dtab_pro
--bcaec52e5f413b02d104f39f9eb6-- From nobody Sun Mar 2 05:33: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 E36861A0732 for ; Sun, 2 Mar 2014 05:33:54 -0800 (PST) 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 TcQEF6VWfimd for ; Sun, 2 Mar 2014 05:33:53 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E93521A0389 for ; Sun, 2 Mar 2014 05:33:52 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id ur14so247731igb.2 for ; Sun, 02 Mar 2014 05:33:50 -0800 (PST) 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:content-type; bh=NtkacCZ8IcJvBJOGaGOPmHVNtAV4XzI6R04asxdsR8s=; b=G0Taaof1yEN6GnfKIFFP7/glhEfmLKiNdq/l7g2XwGlP/JtSeg9jdtRJ2mWpYJZLpx skU0HnFpZlN7n1oDCmrhk/7iXVzRgd4RzThTQW4hgYAyzU4nK1Xv5E0LhQWlbcn3KfK6 8o+c2BWxoEpu8AL5yq2qRxFgwoAPD9cJ7X3ATa3KVuJmZqZbvhkfYqSmyE2ipMRMWSEj s7qVMGyHe1OdKCaiLvv/c4lWBKmv2GxvJYYelBF/IHvaxfedGljxZXbUrK0lMLQlvGsp ucQzqjO4YFxMYSynZxr2xollh10K9nVZnLGZ/gS68zfL+eLi3J9Hh2Tb7ngvOAKguk1y y8Kg== MIME-Version: 1.0 X-Received: by 10.50.66.136 with SMTP id f8mr16887521igt.18.1393767230308; Sun, 02 Mar 2014 05:33:50 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 05:33:50 -0800 (PST) In-Reply-To: <015701cf3614$e854c870$b8fe5950$@riw.us> References: <02c101cf32fc$d92287e0$8b6797a0$@riw.us> <53116F75.1050208@cis-india.org> <016101cf3551$33df5090$9b9df1b0$@riw.us> <633B4C82-35A6-40EE-9313-6F549D125463@istaff.org> <20140301152942.GF2941@mx1.yitter.info> <20140301235209.GB3277@mx1.yitter.info> <20140302090225.GB3482@mx1.yitter.info> <015701cf3614$e854c870$b8fe5950$@riw.us> Date: Sun, 2 Mar 2014 14:33:50 +0100 X-Google-Sender-Auth: ro0O3y6xpjwZd8RtwhffP5CKXzA Message-ID: From: Andrea Glorioso To: "internetgovtech@iab.org" Content-Type: multipart/alternative; boundary=047d7bdca620a9ba7d04f39fb8a1 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/5QG0fp5BuL31mjEwnLre5-orWys Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 13:33:55 -0000 --047d7bdca620a9ba7d04f39fb8a1 Content-Type: text/plain; charset=ISO-8859-1 Dear Russ, I have the distinct impression that we are running in circles. On Sun, Mar 2, 2014 at 1:42 PM, Russ White wrote: > > > > Often, in an area where I am sufficiently experienced, I can come up > > > with the entire problem statement on my own without polling anyone, > > > and it'll be close enough for the purposes of starting work. This > > > does not rely on including more people, but rather on including more > > > points of view. > > > > Thanks. But at which point does this become an untested assumption that > > you "know better" that other people with completely different expertise, > > background, motivations, priorities etc? > > "And it'll be close enough for the purposes of a starting work." > > That's the key point. There are many layers of discussion and vetting > before > even the problem statement is taken as "final," and even then, most problem > statements are never taken as "complete," or "final," in the IETF context. > And all the discussion around acceptance or rejection of this "starting > point," is open to public view. There are no closed or classified meetings > here. > I never said there was. I said that being open and ensuring inclusiveness are two distinct things. I think the IETF is extremely open. I think the IETF could do better in terms of inclusiveness of other perspectives, although it is - in no small part thanks to its institutional design and procedures - better than other SDOs I know. Frankly, I'm not sure what else I can say on this without starting to sound like a broken record. > This process was designed to be as open and fair as possible, focused on > finding technical solutions to clearly defined problem sets. The process > must take into account the competitive nature of vendors, researchers, and > operators. What you seem to be saying is that it's not open to government > (or some other undefined stakeholder) participation. What I'd like to > understand is how and where, specifically, you think it's not, and what > specific proposal you'd like to make to change what you perceive as a > shortcoming. > I don't want this to become confrontational, but I don't like words being put in my mouth. For the sake of my own understanding, could you please point me at where I said that the process is not open to the participation - as in, "you can participate if you want to" - of everyone? Best, -- I speak only for myself. Sometimes I do not even agree with myself. Keep it in mind. Twitter: @andreaglorioso Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=1749288&trk=tab_pro --047d7bdca620a9ba7d04f39fb8a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Russ,

I have the distinct impression that we a= re running in circles.

On Sun, Mar 2, 2014 at 1:42 PM, Russ White <<= a href=3D"mailto:russw@riw.us" target=3D"_blank">russw@riw.us> wrote:

> > Often, in an area where I am sufficiently experienced, I can come= up
> > with the entire problem statement on my own without polling anyon= e,
> > and it'll be close enough for the purposes of starting work. = =A0This
> > does not rely on including more people, but rather on including m= ore
> > points of view.
>
> Thanks. But at which point does this become an untested assumption tha= t
> you "know better" that other people with completely differen= t expertise,
> background, motivations, priorities etc?

"And it'll be close enough for the purposes of a starting wo= rk."

That's the key point. There are many layers of discussion and vetting b= efore
even the problem statement is taken as "final," and even then, mo= st problem
statements are never taken as "complete," or "final," i= n the IETF context.
And all the discussion around acceptance or rejection of this "startin= g
point," is open to public view. There are no closed or classified meet= ings
here.

I never said there was. I said th= at being open and ensuring inclusiveness are two distinct things. I think t= he IETF is extremely open. I think the IETF could do better in terms of inc= lusiveness of other perspectives, although it is - in no small part thanks = to its institutional design and procedures - better than other SDOs I know.=

Frankly, I'm not sure what else I can say on this without starting = to sound like a broken record.
=A0
This process was designed to be as open and fair as possible, focused on finding technical solutions to clearly defined problem sets. The process must take into account the competitive nature of vendors, researchers, and<= br> operators. What you seem to be saying is that it's not open to governme= nt
(or some other undefined stakeholder) participation. What I'd like to understand is how and where, specifically, you think it's not, and what=
specific proposal you'd like to make to change what you perceive as a shortcoming.

I don't want this to b= ecome confrontational, but I don't like words being put in my mouth. Fo= r the sake of my own understanding, could you please point me at where I sa= id that the process is not open to the participation - as in, "you can= participate if you want to" - of everyone?

Best,
=A0
--
I speak only for myself. Somet= imes I do not even agree with myself. Keep it in mind.
Twitter: @andreag= lorioso
Facebook: https://www.facebook.com/andrea.glorioso
LinkedIn: http://www.linkedin.com/profile/view?id=3D= 1749288&trk=3Dtab_pro
--047d7bdca620a9ba7d04f39fb8a1-- From nobody Sun Mar 2 05: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 B9DF71A0757 for ; Sun, 2 Mar 2014 05:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 6tUZG57_hMlg for ; Sun, 2 Mar 2014 05:53:26 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id C3AAF1A070D for ; Sun, 2 Mar 2014 05:53:26 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:61824 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WK6pU-0002Rz-T7; Sun, 02 Mar 2014 13:53:21 +0000 From: "Russ White" To: "'Andrea Glorioso'" References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> In-Reply-To: Date: Sun, 2 Mar 2014 08:53:18 -0500 Message-ID: <001501cf361e$c4a944a0$4dfbcde0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJMFih2b/pqIL5HvUFCBvP9zfnmIAHwS+XUAcF8GWsC7qp9sgH+vKWhAszX6ToCRYMQCgJb3hQGAdISwhECnP4jHwI/k6oSAc9P27sBuA+1HwIH1RQWAbzX6ZgBr/6RfAF63dubmMpzakA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/yXGdm-f1UlMq1CuC21PJ2U7gAsk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 13:53:28 -0000 > How many sociologists participate in IETF processes? > How many economists? > How many scholars of international private / public law? > How many psychologists? > How many human rights NGOs / activists? > How many philosophers? > How many anthropologists? Three points: I would bet the numbers are higher than you suspect, because engineers tend to be a very diverse bunch with a lot of "secondary" interests. In fact, in some cases, engineering is their "secondary" interest. For instance, I have a degree in theology as well as a degree in information technology, and I'm currently pursuing a PhD in philosophy. I know of another person here who has a "double masters" (MDiv) in theology, a PhD in organizational management, and is pursuing a PhD in philosophy. I know of others who have law degrees, and many who are small business owners, and... The IETF is a rather diverse group -- there are few people here who have a sole interest in engineering. I don't think it's so simple as "one person == one perspective." Beyond this, what specific things would any of these people, working purely as economists, etc., bring to the table in building a technical standard? Finally, what's stopping them from participating today? Is it that they don't understand the process? Is it that they don't understand the importance of the process? If there's an education problem, then let's address it, I'm game! For instance, I'm currently working with Pearson to get a general overview of the operation of the Internet into a "video mentor." I blog about the IETF constantly in various venues. We're trying to keep the IPJ afloat because I believe it's a great educational platform and an important part of the overall ecosystem. We're working on white papers, etc., all the time... I've no problem with putting energy into education. If you think there's a specific place we should take this educational effort, I don't think anyone here would object. We might be too busy individually to help with every specific proposal, but I don't think anyone would say, "no, don't do that." > As I repeated multiple times, the answer "the process is open, so they could > participate if they wanted to" is from my perspective simplistic and > unsatisfactory. As I said, we'll probably have to agree to disagree on this > point. Why is this an unsatisfactory answer, specifically? The only alternatives I see are: 1. Make a special place for folks outside the engineering world to participate, giving them some sort of "overriding veto" on the proceedings. 2. Educate folks on the importance of their participation. #1 I don't agree with. #2 I've been trying to do for a long long time. > Fair enough. I don't see why it is not possible to agree on the general goal, > but it is certainly necessary to develop the idea in more detail for some > people to engage in the conversation. In summary, because: 1. The processes are already open, and built around a multi-stakeholder model 2. Given the process is already built this way, it's not enough to say, "the IETF needs a more multi-staker holder model" If the IETF were built on a narrow process designed to allow vendors only to participate, then I would agree with you. As it is, the IETF isn't, so we must go deeper than, "there's a problem that needs to be fixed," when the only definition of the problem I see already agrees with the operating principles of the IETF. > The view of the European Commission is that by making it easier for different > kinds of people to participate in the discussion, the end result would be > better - at the very least in the sense that it would have analysed more "use > cases" and assessed more in-depth the mid- and long-term "operational > considerations" of any particular IETF specification. Can you point to a specific instance where the IETF has not made it easy for people of any sort to participate? Again, I, personally, reach out to many folks on a regular basis attempting to bring more people into the process. There is a constant drive to get enterprise operators into the IETF. I, personally, wish someone other than the US government were deeply involved in some specific working groups, as well, as I think the narrow range of use cases is driving a technically unsound solution. But I can't force people. And I don't see how the process can be changed in any way that would not end up ultimately damaging the technical excellence of the final product, nor simply inject more politics into the process than already exists. > Perhaps simply letting other IETF participants know that there are different > views out there? Education is always a good thing. > Let me put it another way. If you were developing an IETF specification which > defines how "personal data" (or, to use the US term, "personally identifiable > information") should be shared between Internet hosts; and that > specification did not allow for the end-user to express his/her consent to > such sharing; would it help the drafters of the specification if a privacy lawyer > pointed out that in a very large number of jurisdictions around the globe, this > is probably going to make implementations of that specification illegal? Yes, it would. But there's nothing stopping lawyers (and there are some in the IETF community who hold law degrees) from making such a point. > Again, we can - and it seems to me, most certainly will - disagree whether the > current processes of the IETF are already "good enough" to allow this. It > happens. Sure, but putting more processes into place isn't going to stop it from happening in the future. The most the IETF can do is to be as open and transparent as possible, and make the process open to as wide of participation as possible. Most of the work here is done "on list," rather than "in meetings," and the IETF intentionally tries to space meetings such that the cost and work of going to a meeting is spread as evenly as possible. It's the most "open" organization I know of. If anyone has more specific suggestions, I'm certain we're all open to at least discussing them. :-) Russ From nobody Sun Mar 2 05:56: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 6861D1A070D for ; Sun, 2 Mar 2014 05:56:04 -0800 (PST) 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 gP4WwPTLY_Xn for ; Sun, 2 Mar 2014 05:56:03 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1C81A06D1 for ; Sun, 2 Mar 2014 05:56:03 -0800 (PST) Received: from mx1.yitter.info (dhcp-bc3f.meeting.ietf.org [31.133.188.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EB3D58A031 for ; Sun, 2 Mar 2014 13:55:59 +0000 (UTC) Date: Sun, 2 Mar 2014 08:55:52 -0500 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140302135552.GA4234@mx1.yitter.info> References: <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> 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/WYWlD2qbPRXa_-G5aW3ybW4wnlQ Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 13:56:04 -0000 On Sun, Mar 02, 2014 at 02:26:26PM +0100, Andrea Glorioso wrote: > How many philosophers? On this particular question, the answer is, "More than you'd think." On a more serious note, though, why do you think that philosophers or sociologists or biochemists needs to _participate_ for the relevant point of view/considerations to be included in the requirements for protocol development? This is the point I've been trying to make upthread. All people willing to contribute to standardization are somehow interested in the deployment and therefore the utility of the resulting standard. Therefore, they have an important incentive to go and find out those interests and integrate them in the requirements for what they're working on. Can various SDOs do a better job at this? Sure. I think the IETF can do a better job at it for sure. But I am not convinced that the answer to this is to go out and find representative samples of all possible users in the world and survey them, or get them to join IETF mailing lists or something like that. That would almost certainly be as great a waste of time as having automotive engineers ask drivers whether they want the shape of the camshaft changed. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Mar 2 06:07: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 A12A61A0721 for ; Sun, 2 Mar 2014 06:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 1OMFU1bCPqBL for ; Sun, 2 Mar 2014 06:07:19 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id E4C7B1A0168 for ; Sun, 2 Mar 2014 06:07:18 -0800 (PST) Received: from [65.216.251.59] (helo=[10.5.32.33]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WK72w-000Fwj-JE; Sun, 02 Mar 2014 14:07:14 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 65.216.251.59 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18/AeJyKmcE7zMRGrCFxeRl Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Curran In-Reply-To: <001501cf361e$c4a944a0$4dfbcde0$@riw.us> Date: Sun, 2 Mar 2014 09:07:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <40B0840E-2228-4A94-8240-0F2158022466@istaff.org> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <001501cf361e$c4a944a0$4dfbcde 0$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/NTFUrmh0p58kCmFsyITV-_VhbHk Cc: internetgovtech@iab.org, Andrea Glorioso Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 14:07:22 -0000 On Mar 2, 2014, at 8:53 AM, Russ White wrote: > The most the IETF can do is to be as open and > transparent as possible, and make the process open to as wide of > participation as possible. That is not "the most the IETF can do"; it can also recognize that at = least=20 one community of stakeholders (governments) might need particular = outreach on how to work with the IETF in a collaborative manner. One can claim = that stakeholders are all the same, but a community of stakeholders that has = the ability to proscribe/legislate particular outcomes (which may not even = be=20 technically viable) warrants some additional help and attention on how = to=20 engage on the exact same process as all other IETF participants. > Most of the work here is done "on list," rather > than "in meetings," and the IETF intentionally tries to space meetings = such > that the cost and work of going to a meeting is spread as evenly as > possible. It's the most "open" organization I know of. If anyone has = more > specific suggestions, I'm certain we're all open to at least = discussing > them. Specific suggestions have been made - see attached. /John =3D=3D=3D On Mar 1, 2014, at 10:05 AM, Russ White wrote: > These two statements are contradictory. Either the IETF should avoid = all but > the most bare and obvious political issues that relate to the = formation of > standards directly (such as patents) and the operational qualities of = the > network (such as privacy), or the IETF should explicitly include = politics in > the process at a social level. We can't say, "the IETF has no = expertise > here, but it must inject itself into this debate." Russ -=20 The exact opposite - the IETF should realize that protocols can indeed=20= embed social/political values, but it should _not_ become a forum for=20 such discussions. Instead, it should strive to make Internet protocols=20= as globally useful as possible, and simply _reference_ those externally=20= developed statements values or norms that it decides to specifically=20 recognize as drivers for particular protocol decisions. > Privacy is a perfect example. Many folks are upset at pervasive = monitoring > efforts. Others are upset at the collection of information by large > corporations. But we can resolve this to a simple usability issue -- = trust > -- and leave the other politics out of it. If users can't trust their > information to be private, they won't (or shouldn't, since we've = discovered > that combining a few carrots with a large dose of obfuscation often = works > quite well in getting users to give up information they probably = shouldn't > be giving up) use the technology. Therefore, if the IETF intends for = these > internet protocols to be used, we must attend to the perception (real = or > not) that it is easy to monitor communications transmitted using these > protocols. There may be a thousand policy reasons to support or oppose = such > efforts, but by distilling the political into the narrowest range = possible > and phrasing the problem in an operational way, the engineering = problem can > be examined and dealt with. Bringing as much of the political as = possible > back into the picture isn't going to clarify the process, it's going = to make > the process worse. If a particular tradeoff is necessary to make the protocol desired by the user community, and that is the driver that the IETF wishes to=20 reference, then that's fine. does not refer to users or trust, and instead defines it has a=20 security problem. Personally, I'd prefer the approach you suggest or prefer referencing a widely accepted statement of human privacy being equally applicable to the Internet - either approach acknowledges the requirement without having the IETF developing its own position on =20 personal privacy applicability on the Internet (an undertaking would=20 indeed encourage having a political discussion at the IETF.) > In other words, of course standards have political implications -- but = the > point of the process is to remove the political implications as much = as > possible, so the problem becomes as close to a pure technical problem = as > possible. You might not be able to do this perfectly, but I've not = seen an > actual workable suggestion put forward as an alternative.=20 I think we're agreeing on the goal ("remove the political implications = as=20 much as possible"), but the question is what to do where it is = unavoidable. My suggestion would be to leverage widely held statements of such social or political norms rather than having to debate them in the IETF. (and = this=20 is not much different than leveraging international consensus of two = letter=20 codes for reference to countries and subdivisions, another political = matter) > Can you point me to some specific part of the IETF process, as it = exists > today, which is "not open," to government participation? In what way = is it > "not open?" No, the IETF does very well in this respect. =20 > If the process is to be changed to "allow governments a seat at > the table," we need much more than, "standards are political and the = process > isn't open." The process doesn't have to be changed, but the IETF needs to have a = model for how governments engage with it when desired and spend some time = actually explaining that to governments (or run the risk that they'll decide on = other approaches to meet their needs) > We need specific proposals to evaluate -- and hopefully the end > goal, rather than just some intermediary "starting point." I describe an end point; governments should be able to engage in the = existing processes just as any other party; it would, however, be helpful when a = government expresses a particular social/economic requirement if the IETF could = consistently explain that it prefers not to twist the protocol development for one = countries view,=20 but if some widely-held statement of such a norm or value that can be = referenced, that might be worth considering since IETF standards intended to be = scope Internet, i.e. applicable globally. =20 > It's often the case in our world that we have a lot of "camels in the = tent," problems; > I would like to avoid the nose unless we know what the whole camel = looks like. See my prior paragraph for the entire camel I propose letting in; no = change to existing IETF processes, but potentially a clear approach to = responding to governments asking about how to "engage with the IETF" on their = particular social/political topic of interest. FYI, /John _______________________________________________ Internetgovtech mailing list Internetgovtech@iab.org https://www.iab.org/mailman/listinfo/internetgovtech= From nobody Sun Mar 2 06:21: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 034961A0250 for ; Sun, 2 Mar 2014 06:21:35 -0800 (PST) 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 gGul8R9aXatb for ; Sun, 2 Mar 2014 06:21:33 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75F1A024A for ; Sun, 2 Mar 2014 06:21:33 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id h3so5541864igd.5 for ; Sun, 02 Mar 2014 06:21:30 -0800 (PST) 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=LE2IglrNXUptR6arJu7tJBSbA15z/gJP636PsTxDwOE=; b=XDNhCxOsO3rjRTCN+0Hw95Ad62OHL/PK+ymO6dU/IiM6fltV+AM1nETVQOpWf96zQC wjnqWt9OCy46TGAKlOuri3aHfI1EYfSigeMgCs2Gvc5Ymobzfi6grqmtnXlRTQNl+NEg /fIL0bfq7b19p6L9K10+RqoVKx4nOYeAIMC2DHLMIEH8Ijvo8Om0TWGoXqyADbIVJDxc SqDVjibzMezo5BxMQ2lR/f8b8HMQV0AJlIgKKDSspDxVoU0UQ7+sYh/o+wXx/OExcaDL 2y2l+EqzV1CeImrzrrh/vvkxDIPONvbXGVr4TzXDJyEhfgzA1MX+xY4KBnAOxmHFBtGf e/+w== MIME-Version: 1.0 X-Received: by 10.43.153.138 with SMTP id la10mr21627995icc.10.1393770090690; Sun, 02 Mar 2014 06:21:30 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 06:21:30 -0800 (PST) In-Reply-To: <20140302135552.GA4234@mx1.yitter.info> References: <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <20140302135552.GA4234@mx1.yitter.info> Date: Sun, 2 Mar 2014 15:21:30 +0100 X-Google-Sender-Auth: 1oOhKLerHlL-yzsBNpGz_nYXg0o Message-ID: From: Andrea Glorioso To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c1d7f4277e4a04f3a063ab Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/qBWKj6Ps62AQAtNOt1rpUVHOhug Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 14:21:35 -0000 --001a11c1d7f4277e4a04f3a063ab Content-Type: text/plain; charset=ISO-8859-1 Dear Andrew, On Sun, Mar 2, 2014 at 2:55 PM, Andrew Sullivan wrote: > On Sun, Mar 02, 2014 at 02:26:26PM +0100, Andrea Glorioso wrote: > > How many philosophers? > > On this particular question, the answer is, "More than you'd think." > Possibly - it would be nice if there were some data. > On a more serious note, though, why do you think that philosophers or > sociologists or biochemists needs to _participate_ for the relevant > point of view/considerations to be included in the requirements for > protocol development? This is the point I've been trying to make > upthread. All people willing to contribute to standardization are > somehow interested in the deployment and therefore the utility of the > resulting standard. Therefore, they have an important incentive to go > and find out those interests and integrate them in the requirements > for what they're working on. > So, what you are saying is that the IETF works best in a "pull" mode (where those who work on specifications go out and ask different folks from various paths of life how to integrate their concerns in the specifications) rather than in a "push" mode (where said folks make sure their perspectives are known as early as possible in the process). Do I understand you correctly? > Can various SDOs do a better job at this? Sure. I think the IETF can > do a better job at it for sure. But I am not convinced that the > answer to this is to go out and find representative samples of all > possible users in the world and survey them, or get them to join IETF > mailing lists or something like that. That would almost certainly be > as great a waste of time as having automotive engineers ask drivers > whether they want the shape of the camshaft changed. I don't know much about cars, so I apologise if the question is stupid. But would the shape of the camshaft have an impact on the way in which drivers "experience" their car (how easy is it to use it, how long it can stay without going to the mechanic, etc)? If so, I think automotive engineers should actually ask drivers. Best, Andrea --001a11c1d7f4277e4a04f3a063ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Andrew,

On Sun, Mar 2, 2014 at 2:55 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Sun, Mar 02, 2014 at 02:26:26PM +0100, An= drea Glorioso wrote:
> How many philosophers?

On this particular question, the answer is, "More than you'd think= ."

Possibly - it would be nice if = there were some data.
=A0
On a more serious note, though, why do you think that philosophers or
sociologists or biochemists needs to _participate_ for the relevant
point of view/considerations to be included in the requirements for
protocol development? =A0This is the point I've been trying to make
upthread. =A0All people willing to contribute to standardization are
somehow interested in the deployment and therefore the utility of the
resulting standard. =A0Therefore, they have an important incentive to go and find out those interests and integrate them in the requirements
for what they're working on.

So, wh= at you are saying is that the IETF works best in a "pull" mode
(where those who work on specifications go out and ask differen= t folks
from various paths of life how to integrate their concerns in the
specif= ications) rather than in a "push" mode (where said folks make
= sure their perspectives are known as early as possible in the process).

Do I understand you correctly?
=A0
Can various SDOs do a better job at this? =A0Sure. =A0I think the IETF can<= br> do a better job at it for sure. =A0But I am not convinced that the
answer to this is to go out and find representative samples of all
possible users in the world and survey them, or get them to join IETF
mailing lists or something like that. =A0That would almost certainly be
as great a waste of time as having automotive engineers ask drivers
whether they want the shape of the camshaft changed.

<= /div>
I don't know much about cars, so I apologise if the question = is stupid.
But would the shape of the camshaft have an impact on the way= in which
drivers "experience" their car (how easy is it to use it, how lon= g it can
stay without going to the mechanic, etc)? If so, I t= hink automotive
engineers should actually ask drivers.

Best,

Andrea
--001a11c1d7f4277e4a04f3a063ab-- From nobody Sun Mar 2 06:26: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 AD09B1A0250 for ; Sun, 2 Mar 2014 06:26:29 -0800 (PST) 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 5pac3kqDLOIx for ; Sun, 2 Mar 2014 06:26:27 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8171A024A for ; Sun, 2 Mar 2014 06:26:27 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so1046658igi.0 for ; Sun, 02 Mar 2014 06:26:25 -0800 (PST) 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=qhBWTIuIEe3Ad1lhl6Gbq+meUOyl8bDBJ+2z4y+9mTk=; b=EG7/Mj4zwjTQa/zNCzuQVU2Ct+sFxINTCOQqib/1zdbEqk/Pib9nEIurBAw2n9McDA JaSZbltmYpUpr60r0pR8wxi52S8+OVbGGnIFt6WQ6UzKadwPz+bwcvs5kCCXi5tgegZi rP7TJSkZ6+uomUouVONAxZVoLmrHYbNVmwYb4t7jrJYltMyC6JkkVyh3pytsgaL3SRER M+5LskvjsmuxoMTaYpc269rTQGOZQUi4DY2YoPwcN4/jRtQ8Wiw0SKCBclAPm6EqNlqv EbirudCnSes2LOv0VTMgl5xluioUfmBlCI1w4qMmKC1fTSWcshClUdDIcd42HYthoFm6 JvwA== MIME-Version: 1.0 X-Received: by 10.50.79.166 with SMTP id k6mr16494339igx.47.1393770384956; Sun, 02 Mar 2014 06:26:24 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 06:26:24 -0800 (PST) In-Reply-To: <001501cf361e$c4a944a0$4dfbcde0$@riw.us> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <001501cf361e$c4a944a0$4dfbcde0$@riw.us> Date: Sun, 2 Mar 2014 15:26:24 +0100 X-Google-Sender-Auth: jYWMRVQ2Yh8xYmsQqYnYfQTOYvk Message-ID: From: Andrea Glorioso To: Russ White Content-Type: multipart/alternative; boundary=089e013a114eb1a61104f3a0742d Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/sZrozPLpGrExWWmEahSdDGoN7xA Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 14:26:29 -0000 --089e013a114eb1a61104f3a0742d Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 2, 2014 at 2:53 PM, Russ White wrote: > > > How many sociologists participate in IETF processes? > > How many economists? > > How many scholars of international private / public law? > > How many psychologists? > > How many human rights NGOs / activists? > > How many philosophers? > > How many anthropologists? > > Three points: > > I would bet the numbers are higher than you suspect, because engineers tend > to be a very diverse bunch with a lot of "secondary" interests. Do we have any kind of data? The only source I am aware of is Jari's "Document Statistics" page (http://www.arkko.com/tools/docstats.html). > Beyond this, what specific things would any of these people, working purely > as economists, etc., bring to the table in building a technical standard? > Uhm... for example, help in assessing / modelling the economic impact of a technical standard? If the IETF were built on a narrow process designed to allow vendors only to > participate, then I would agree with you. As it is, the IETF isn't, so we > must go deeper than, "there's a problem that needs to be fixed," when the > only definition of the problem I see already agrees with the operating > principles of the IETF. > But the thing is - the Commission is not saying that there is a problem that needs to be fixed with the IETF. I might have my personal opinion, but that's a different matter. As I wrote elsewhere - if the IETF community concludes that there is no problem at all in terms of inclusiveness and early engagement, fine. I don't agree and I don't think it's going to help the Internet in the long-term, but hey - we have no power to tell IETF people what to do (and even if we had, I somehow doubt we'd use it, but I'm sure you'll be to disagree on this point). > But I can't force people. And I don't see how the process can be changed > in > any way that would not end up ultimately damaging the technical excellence > of the final product, nor simply inject more politics into the process than > already exists. I'm curious - what's your definition of "politics"? Best, Andrea -- I speak only for myself. Sometimes I do not even agree with myself. Keep it in mind. Twitter: @andreaglorioso Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=1749288&trk=tab_pro --089e013a114eb1a61104f3a0742d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 2, 2014 at 2:53 PM, Russ White <russw@riw.us&g= t; wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

> How many sociologists participate in IETF processes?
> How many economists?
> How many scholars of international private / public law?
> How many psychologists?
> How many human rights NGOs / activists?
> How many philosophers?
> How many anthropologists?

Three points:

I would bet the numbers are higher than you suspect, because engineers tend=
to be a very diverse bunch with a lot of "secondary" interests. <= /blockquote>

Do we have any kind of data? The only sourc= e I am aware of is Jari's "Document Statistics" page (http://www.= arkko.com/tools/docstats.html).
=A0
Beyon= d this, what specific things would any of these people, working purely
as economists, etc., bring to the table in building a technical standard?

Uhm... for example, help in assessing / = modelling the economic impact of a technical standard?

If the IETF were buil= t on a narrow process designed to allow vendors only to
participate, then I would agree with you. As it is, the IETF isn't, so = we
must go deeper than, "there's a problem that needs to be fixed,&qu= ot; when the
only definition of the problem I see already agrees with the operating
principles of the IETF.

But the thing i= s - the Commission is not saying that there is a problem that
needs to b= e fixed with the IETF. I might have my personal opinion, but that's
a different matter.

As I wrote elsewhere - if the IETF community con= cludes that there is no
problem at all in terms of inclusiveness and ear= ly engagement, fine. I
don't agree and I don't think = it's going to help the Internet in the long-term,
but hey - we have no power to tell IETF people what to do (and even if
w= e had, I somehow doubt we'd use it, but I'm sure you'll be to d= isagree on
this point).
=A0
But I can't force people. And I don't see how the process can be ch= anged in
any way that would not end up ultimately damaging the technical excellence<= br> of the final product, nor simply inject more politics into the process than=
already exists.

I'm curious - what'= s your definition of "politics"?
=A0
Best= ,

Andrea

--
I speak only for mysel= f. Sometimes I do not even agree with myself. Keep it in mind.
Twitter: @andreaglorioso
Facebook: https://www.facebook.com/andrea.glorioso<= /a>
LinkedIn: http://www.linkedin.com/profile/vie= w?id=3D1749288&trk=3Dtab_pro
--089e013a114eb1a61104f3a0742d-- From nobody Sun Mar 2 06:47: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 0103A1A04A8 for ; Sun, 2 Mar 2014 06:47:11 -0800 (PST) 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 QUxfGUQj7waI for ; Sun, 2 Mar 2014 06:47:09 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 545871A0495 for ; Sun, 2 Mar 2014 06:47:09 -0800 (PST) Received: from [12.230.92.4] (helo=[10.1.130.66]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WK7fW-000NU1-Or; Sun, 02 Mar 2014 14:47:06 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 12.230.92.4 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+cev8Lsi+F/Dv/X7xG5jjp Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Curran In-Reply-To: <20140302135552.GA4234@mx1.yitter.info> Date: Sun, 2 Mar 2014 09:47:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8345ADF5-2C9B-4D84-9595-EC7EBC6239F1@istaff.org> References: <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <20140302135552.GA4234@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ItCMhbnETy4O4_wX8euZmleo_Dk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 14:47:11 -0000 On Mar 2, 2014, at 8:55 AM, Andrew Sullivan = wrote: > That would almost certainly be > as great a waste of time as having automotive engineers ask drivers > whether they want the shape of the camshaft changed. What might not be a waste of time is when the automotive companies note = to=20 governments (who assert to be representative the interests of their = people)=20 that it would be quite a bit easier for everyone to the extent that = there are=20 more shared goals among many of them regarding fuel efficiency and = emissions, so that the automotive engineers don't have to quite as many different = engines=20 and exhaust systems solely to comply with diverse requirements when = presented=20 uncoordinated and after the fact...=20 The auto companies may or may not decide to consider the input received = (after=20 all, they are just suggestions at that point) but it is probably still = helpful=20 to know what these expectations. FYI, /John Disclaimer: My views alone - no automobile companies were consulted in = writing this email.= From nobody Sun Mar 2 06:56: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 722ED1A0766 for ; Sun, 2 Mar 2014 06:56:32 -0800 (PST) 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 77Gd7YSDx6ue for ; Sun, 2 Mar 2014 06:56:31 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3B11C1A027D for ; Sun, 2 Mar 2014 06:56:31 -0800 (PST) Received: from mx1.yitter.info (dhcp-bc3f.meeting.ietf.org [31.133.188.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 21E648A031 for ; Sun, 2 Mar 2014 14:56:28 +0000 (UTC) Date: Sun, 2 Mar 2014 09:56:26 -0500 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140302145625.GE4234@mx1.yitter.info> References: <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <20140302135552.GA4234@mx1.yitter.info> 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/6pmQbo0mv0ssh-Detwlm87Qt3io Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 14:56:32 -0000 On Sun, Mar 02, 2014 at 03:21:30PM +0100, Andrea Glorioso wrote: > > Possibly - it would be nice if there were some data. I know half a dozen people who have been or are currently on the IAB or IESG and who have either undergraduate or graduate degrees in philosophy, just off the top of my head. But I don't actually think it _would_ be nice if there were some data. You seem to have an essentialist view about identity, and I don't. > Do I understand you correctly? It appears not, but I don't know what more to say than what I've already said to make myself clearer. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Mar 2 07:12: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 B83A81A0796 for ; Sun, 2 Mar 2014 07:12:07 -0800 (PST) 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 aIHRcLYkZWc9 for ; Sun, 2 Mar 2014 07:12:06 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 77EF01A07BA for ; Sun, 2 Mar 2014 07:12:06 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rl12so5157955iec.22 for ; Sun, 02 Mar 2014 07:12:03 -0800 (PST) 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=Lv//hjo1qk7wGehhZ3WJ0dKOQGF9o5AB/NFHP1PqX1o=; b=lBhiUgg0ksPzbTWcNak0mtk6eG3dMm+ibr4aaEyWtxF3alcSjsDX7nwf3IQUtkyI3W Aq1wdhYd3Z+H+hrRHGUZAJFHP3z33fztvTV8Q+vJVjOFkiIY1lMP/BgJG70LYrIa7eSo 0OCfQpXYUdrXUFYbQudOlN9Ci6oqF/62LyjTTxv4P4GZiDxVI2EPpaOwkJDGPnj2qB3O FiESR5AtoN1b3Ri3pSD2MSNbhAysM0uX8V9xFff2Kbeg7dPOH2a+8m6+q1lrmC8JtG9O K+t53VA3IiTfjsop30rOVcSlv+O6yqm9sz2nNcr6XgVh1ByFw1w40SFDnui0MZLz4yBu ZUkg== MIME-Version: 1.0 X-Received: by 10.42.118.14 with SMTP id v14mr1334760icq.73.1393773123790; Sun, 02 Mar 2014 07:12:03 -0800 (PST) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Sun, 2 Mar 2014 07:12:03 -0800 (PST) In-Reply-To: <20140302145625.GE4234@mx1.yitter.info> References: <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <20140302135552.GA4234@mx1.yitter.info> <20140302145625.GE4234@mx1.yitter.info> Date: Sun, 2 Mar 2014 16:12:03 +0100 X-Google-Sender-Auth: FzIowmjqe-r5ZzP5XaWqtiYgHAs Message-ID: From: Andrea Glorioso To: Andrew Sullivan Content-Type: multipart/alternative; boundary=90e6ba613ea2f0ee9504f3a1172c Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/RlLtZVr2i3z6NvRgWQfYV_k6xiY Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 15:12:07 -0000 --90e6ba613ea2f0ee9504f3a1172c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 2, 2014 at 3:56 PM, Andrew Sullivan wrote: > On Sun, Mar 02, 2014 at 03:21:30PM +0100, Andrea Glorioso wrote: > > > > Possibly - it would be nice if there were some data. > > I know half a dozen people who have been or are currently on the IAB > or IESG and who have either undergraduate or graduate degrees in > philosophy, just off the top of my head. But I don't actually think > it _would_ be nice if there were some data. You seem to have an > essentialist view about identity, and I don't. > I don't think my or your view about identity are the point here. If people tell me that there are folks with plenty of expertise in X (for various values of X) within the IETF, it seems just normal to ask "how do we know that" (considering that not everyone is familiar with the past or present membership of the IAB or the IESG, which by the way are not the IETF as you know much better than me). (This is also the first time when discussing in an *engineering* environment where "having data" is not considered a priority). > > Do I understand you correctly? > > It appears not, but I don't know what more to say than what I've > already said to make myself clearer. Pity, but I understand the feeling. Best, Andrea --90e6ba613ea2f0ee9504f3a1172c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 2, 2014 at 3:56 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Sun, Mar 02, 2014 at 03:2= 1:30PM +0100, Andrea Glorioso wrote:
>
> Possibly - it would be nice if there were some data.

I know half a dozen people who have been or are currently on the IAB<= br> or IESG and who have either undergraduate or graduate degrees in
philosophy, just off the top of my head. =A0But I don't actually think<= br> it _would_ be nice if there were some data. =A0You seem to have an
essentialist view about identity, and I don't.
I don't think my or your view about identity are the point here.= If
people tell me that there are folks with plenty of expertise in X (for various values of X) within the IETF, it seems just normal to
ask &= quot;how do we know that" (considering that not everyone is familiar <= br>with the past or present membership of the IAB or the IESG, which
by the way are not the IETF as you know much better than me).

=
(This is also the first time when discussing in = an *engineering*
environment where &quo= t;having data" is not considered a priority).
=A0
> Do I understand you correctly?

It appears not, but I don't know what more to say than what I'= ;ve
already said to make myself clearer.

Pity, = but I understand the feeling.

Best,

Andrea
<= /div> --90e6ba613ea2f0ee9504f3a1172c-- From nobody Sun Mar 2 08:49: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 ACEF81A07BE for ; Sun, 2 Mar 2014 08:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.043 X-Spam-Level: * X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Yp_FKDJMgUwD for ; Sun, 2 Mar 2014 08:49:34 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4800E1A078D for ; Sun, 2 Mar 2014 08:49:34 -0800 (PST) Received: (qmail 22692 invoked from network); 2 Mar 2014 16:49:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 2 Mar 2014 16:49:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5313611d.xn--hew.k1403; i=johnl@user.iecc.com; bh=IaEw30k+vvNDpApbQsXbO4UcXZyoyC4nTAftAsYg6bA=; b=R68UrxqTTIg9L6M5TCbkSNdfgCFev45PxwssY/SC8sLJuGCIwFx43KC4RGFFC6OMAKRSCDQwqqYSqSuqzlK3FI8zcVPowcVGh6FVr8B6+JaYh0mqvrnwpyB6HwkWFXc6Mx4EYj2ztWY9/AAxTy/XRAEHqBNaK1v3ObJmTiSiCCEGmexJtuy8LwexfFT3dtxVH6mA748c05WKXRtMYMI5GqCMSPuF4rg62DbzbQLpWYT77+WOKynIVuvlzthPVxlV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5313611d.xn--hew.k1403; bh=IaEw30k+vvNDpApbQsXbO4UcXZyoyC4nTAftAsYg6bA=; b=Dltv7uez0/nSUyyBpi863CDGN/iBrSDEUhXbwDfNYa5D4MUNeL+HrXVcxpgilH344bFNXkdcJFgUmwRdiodhZoP671w41WwaCZsIYZA7U8g8tcCMUBVKtS9IudTsZyRB/2DdL1pILvxJofFY8oThmlEI/DbMIlJT1a8UJ89HboVujnnI5yKuZWpx6AK7XyBAbeEmAXz9w7K+2kOikfxV9Wk5+kYxD1/xa8mEoIPwpFERmakRifZPxEQe59BZANqY Date: 2 Mar 2014 16:49:11 -0000 Message-ID: <20140302164911.3600.qmail@joyce.lan> From: "John Levine" To: internetgovtech@iab.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vW0KQgIlQG49qIlSd1PiWIzsaho Cc: andrea@digitalpolicy.it Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 16:49:35 -0000 >> You will really have to explain what range is larger than "anyone". > >So, any human being whose life is impacted by the technical decisions taken >(among other places) within the IETF can participate? > >Even if s/he doesn't speak English? > >Note that I'm not suggesting a regime of translation for the IETF. (Working >in the European Commission I'm well aware of the difficulties involved. I'm >also aware of the practical and symbolic advantages.) > >Even if s/he doesn't have an Internet connection? > >Even if s/he comes from a cultural background that makes it exceptionally >hard to adapt to the standard norms of behaviour within the IETF? If she's sufficiently motivated, yes. We're not claiming that there is no effort required to participate in the IETF. We are saying that there the IETF doesn't have any institutional barriers beyond the reality that the work happens in English via e-mail. R's, John From nobody Sun Mar 2 14:13: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 7C2511A0B51 for ; Sun, 2 Mar 2014 14:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 31-DlE4yX0s4 for ; Sun, 2 Mar 2014 14:13:44 -0800 (PST) Received: from nic-naa.net (abenaki.wabanaki.net [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 310401A0B4E for ; Sun, 2 Mar 2014 14:13:43 -0800 (PST) Received: from frog.local ([67.42.198.93]) by nic-naa.net (8.14.8/8.14.8) with ESMTP id s22MD4iJ000151 for ; Sun, 2 Mar 2014 17:13:20 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <5313ACE5.7000803@abenaki.wabanaki.net> Date: Sun, 02 Mar 2014 14:12:53 -0800 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040304070307020602070103" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/cbsBosPGCbfyqjQxWUYKBXCBlJM Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 02 Mar 2014 22:13:47 -0000 This is a multi-part message in MIME format. --------------040304070307020602070103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit No Hat. My two beads worth is that three decades ago, when Jon Postel wanted to respond to the growth of registrations, Jon erred in missing the fact that network prefixes associated with urban areas provided addresses to the overwhelming majority of resources associated with persistent mnemonics. I discussed with Jon the absence of accommodation in iso3166-1 for stateless populations directly after the publication of rfc1591, and I too erred in not realizing that urban density offered an alternative to territorial jurisdiction when attempting to scale the "assignments czar" functions to the decline in network adapter prices. Overlooking the vested interest of the then-monopoly dns operator, now merely the operator with 85% market share, it is difficult to find a rational interest in the policy of restricting access by stateless populations to the US DoC root. The responsibility for this policy appears to lie squarely with "government". While I spoke with Jon, and others spoke with Michael St. Johns, and our concerns were partially addressed by the addition of the NSN SLD to the US ccTLD, the concerns of Catalan speakers were not addressed until 2004, and the concerns of some autonomous regions, chiefly in Europe, have only just been addressed, at exceptional fee and contractual encumbrances, the concerns of populations such as the European Rom and European speakers of Yiddish and Arabic remain frustrated by the exclusive access claims of national governments. So, every request by government(s), of cities, urban agglomerations, of indigenous polities, linguistic and cultural communities, even iso3166-3 regions, for access, as public governments to the US DoC root, present a problem in "internet governance" created by "government" and maintained to the present by "governments". It would be nice if government fixed this government-caused problem in "internet governance" by recourse to less absurd means than tasking a private contractor to treat these as speculative, for-profit exploits. Now the second bead. The "how many {sociologists,...} participate in IETF processes?" laundry list manages to miss one area of work by "governments" which might have, and still may, inform the IETF. Governments have been quite successful in establishing language encoding standards in which text data is created, transmitted, and stored. One government, and its contractor, chose one national standard for all text-associated network addressable resources, restricting script choices to US-ASCII, and encodings over US-ASCII, for glyphs present in a repertoire produced by an consortium of printer vendors. At no point in time have "governments" initiated work necessary to reconcile multiple, diverse character set standards, with a single resource location mechanism, nor has the IRTF followed up on the recommendation of the IAB Character Set Workshop of April, 1997, "to create a research group to explore the open issues of character sets on the Internet ". The observation has been made frequently, and by many, that language is an "internet governance" issue, and in fact, the need for correct resolution of resources "named" in the Han script, encoded in UTF-8, lead to the illumination of a second root server constellation, leading immediately to a consistency of publications problem -- a first order problem in "internet governance", yet both "governments" and "the technical community" treat this as a solved problem, overlooking the distinction between the corpus of text associated with resources, and the corpora of texts which comprise text resources. From my perspective there are actual failures of both "government" and "the technical community" to conduct "internet governance" effectively, for which remedial work would be of measurable utility. Eric Brunner-Williams Eugene, Oregon former-hats=={sri, .biz/.us co-author, .cat co-author, cto core, primary author, xpg1, xpg4.2 (single unix standard), {solaris|hp-ux} i18n/l10n implementor, etc.} --------------040304070307020602070103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
No Hat.

My two beads worth is that three decades ago, when Jon Postel wanted to respond to the growth of registrations, Jon erred in missing the fact that network prefixes associated with urban areas provided addresses to the overwhelming majority of resources associated with persistent mnemonics. I discussed with Jon the absence of accommodation in iso3166-1 for stateless populations directly after the publication of rfc1591, and I too erred in not realizing that urban density offered an alternative to territorial jurisdiction when attempting to scale the "assignments czar" functions to the decline in network adapter prices.

Overlooking the vested interest of the then-monopoly dns operator, now merely the operator with 85% market share, it is difficult to find a rational interest in the policy of restricting access by stateless populations to the US DoC root. The responsibility for this policy appears to lie squarely with "government". While I spoke with Jon, and others spoke with Michael St. Johns, and our concerns were partially addressed by the addition of the NSN SLD to the US ccTLD, the concerns of Catalan speakers were not addressed until 2004, and the concerns of some autonomous regions, chiefly in Europe, have only just been addressed, at exceptional fee and contractual encumbrances, the concerns of populations such as the European Rom and European speakers of Yiddish and Arabic remain frustrated by the exclusive access claims of national governments.

So, every request by government(s), of cities, urban agglomerations, of indigenous polities, linguistic and cultural communities, even iso3166-3 regions, for access, as public governments to the US DoC root, present a problem in "internet governance" created by "government" and maintained to the present by "governments". It would be nice if government fixed this government-caused problem in "internet governance" by recourse to less absurd means than tasking a private contractor to treat these as speculative, for-profit exploits.

Now the second bead.

The "how many {sociologists,...} participate in IETF processes?" laundry list manages to miss one area of work by "governments" which might have, and still may, inform the IETF.  Governments have been quite successful in establishing language encoding standards in which text data is created, transmitted, and stored. One government, and its contractor, chose one national standard for all text-associated network addressable resources, restricting script choices to US-ASCII, and encodings over US-ASCII, for glyphs present in a repertoire produced by an consortium of printer vendors. At no point in time have "governments" initiated work necessary to reconcile multiple, diverse character set standards, with a single resource location mechanism, nor has the IRTF followed up on the recommendation of the IAB Character Set Workshop of April, 1997, "to create a research group to explore the open issues of character sets on the Internet ".

The observation has been made frequently, and by many, that language is an "internet governance" issue, and in fact, the need for correct resolution of resources "named" in the Han script, encoded in UTF-8, lead to the illumination of a second root server constellation, leading immediately to a consistency of publications problem -- a first order problem in "internet governance", yet both "governments" and "the technical community" treat this as a solved problem, overlooking the distinction between the corpus of text associated with resources, and the corpora of texts which comprise text resources.

From my perspective there are actual failures of both "government" and "the technical community" to conduct "internet governance" effectively, for which remedial work would be of measurable utility.

Eric Brunner-Williams
Eugene, Oregon
former-hats=={sri, .biz/.us co-author, .cat co-author, cto core, primary author, xpg1, xpg4.2 (single unix standard), {solaris|hp-ux} i18n/l10n implementor, etc.}
--------------040304070307020602070103-- From nobody Sun Mar 2 14:37: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 1B3BA1A096D for ; Sun, 2 Mar 2014 14:37:12 -0800 (PST) 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 d_jEJLh1xPwb for ; Sun, 2 Mar 2014 14:37:10 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D61A07DF for ; Sun, 2 Mar 2014 14:37:10 -0800 (PST) Received: from [85.159.233.116] (port=47894 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WKF0M-0005ky-DU; Sun, 02 Mar 2014 14:37:06 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Mar 2014 23:37:01 +0100 To: "John Levine" ,internetgovtech@iab.org From: Jefsey In-Reply-To: <20140302164911.3600.qmail@joyce.lan> References: <20140302164911.3600.qmail@joyce.lan> 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: 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/GDXSYk64WY_L2rHiFjaeaRluo7o Cc: andrea@digitalpolicy.it Subject: Re: [Internetgovtech] Involvement from other constituencies 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, 02 Mar 2014 22:37:12 -0000 At 17:49 02/03/2014, John Levine wrote: > the IETF doesn't have any institutional barriers beyond the > reality that the work happens in English what does not require English mother tongue participants to be fluent in another language, depriving them from an experience which might be necessary when having to standardize a networking architecture for a multilingual and multicultural world. An impact? the lack of presentation layer six in the internet architecture (probably an advantage as its implementation now will be on the fringe, but this lead to the "status quo" strategies and innovation delays). jfc From nobody Mon Mar 3 09:31: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 90D701A02E8; Mon, 3 Mar 2014 09:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 tgZjOLzJoGw5; Mon, 3 Mar 2014 09:31:00 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 00B031A02E4; Mon, 3 Mar 2014 09:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9411; q=dns/txt; s=iport; t=1393867857; x=1395077457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YwLrCewIG7QW1Y7H8IVGfYVl4Z34vTllwQlVdGB7YdI=; b=PNB2qZJzUEkH+sZ1aesOTwWeKQJeIHSaQS7oi92Fc3pOza9WEgChwgbU T//qmcmcTAFwf405gwvW7GpPUGq0bPfMYovqJGJSCcYerrFw5UCYIo7+g LCONWkdWmxUWIUp/VCkyc6vd0OzY0nBrmFOLxi50kC4OOzVkoU06AIUtr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAK27FFOtJV2d/2dsb2JhbABagwY7V8BRgSQWdIIlAQEBAgEBOi0SBQsCAQgSJBAyFw4CBA4FCQuHXQgNzDIXjF6BSDMHgySBFASOR4VGhC+SK4FvgT6CKg X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208";a="307794847" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 03 Mar 2014 17:30:56 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s23HUuB5027904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 17:30:56 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.76]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 11:30:56 -0600 From: "Chip Sharp (chsharp)" To: IAB Chair Thread-Topic: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries Thread-Index: AQHPMYZo9awCYbsddUK6gkjnmfIztprQDi+A Date: Mon, 3 Mar 2014 17:30:55 +0000 Message-ID: <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.153.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <1AC2AB3DD7EBE142BE3476A57FF018CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/kL1GQYXeYIroPuVQW2NrTHijkio Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 03 Mar 2014 17:31:03 -0000 Dear Russ, Thank you for sharing for review. I will not be at IETF, but have some com= ments below for consideration. I've noticed that a number of people involved in various discussions on thi= s issue don't seem to understand the connection between the IETF and the IA= NA. I'm concerned that this could result in collateral damage to functions= important to IETF and IETF's role. Therefore I support efforts at educati= ng those involved in the current Internet Governance debate regarding the I= ETF's role and position regarding the IANA. =20 In general I believe the principles below need to be strengthened to assert= IETF's role regarding managing the Protocol Parameter registry. The princ= iples below seem to leave open the possibility that the IANA's operation of= the Protocol Parameter Registry could be modified without the involvement = of the IETF (or IRTF). Question for clarification, is the Time Zone database operated under RFC286= 0? I think so, but want to check. Other comments below.=20 Consider moving item 6 up to at least item 2=20 On Feb 24, 2014, at 12:28 PM, IAB Chair wrote: > Existing IETF and IAB consensus concerning Internet registry functions > and IANA are documented in a variety of RFCs and IAB communications > [RFC2860,RFC6220,IAB1,IAB2]. Since registry functions and IANA are > likely to be the subject of discussion in a number of venues outside the > IETF over the coming months and years, the IAB is seeking community > feedback about operating principles to use when they find themselves > involved in those discussions. >=20 > While dealing with these issues the IAB has consistently approached the > issues from a set of (implicit) principles. Since the registry functions > are subject of discussion in various fora, the IAB has tried to make > these operating principles explicit and seeks to confirm these with the > community. >=20 > The IAB are planning to use part of the time in the IGOVUPDATE session at > IETF 89 (6 March 2014, 17:00-18:30 GMT) for a discussion of such operatin= g > principles. But we wanted to kick-start that discussion with a few > thoughts about principles that the IAB and IETF have articulated in > various documents already and some that have emerged over time but may > not have been written down. What we are interested in is an articulation > of what the IETF community values. What other parties (ICANN, RIRs, > governments, etc.) value when they think about registry functions is > interesting, but we want to focus this discussion on the IETF and not > those other parties. >=20 > This is a first cut of making the principles more explicit for which we > seek your views. >=20 > Some of these might seem a bit generic, but it is difficult to predict > the nature of future discussions in which IETF and IAB leaders might find > themselves, so generality helps in that regard. >=20 > On behalf of the IAB, > Russ Housley > IAB Chair >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 > Principles Guiding the Evolution of the IANA Protocol Parameter Registrie= s Item 6 and Item 4 with proposed modifications should be moved to the top of= this list. The principles should start out with a clear statement of the = controlling documents and process for any changes. > 1. The IETF protocol parameters function has been and continues to be > capably provided by the Internet community. Here and through the rest of the principles I recommend using the term "Pro= tocol Parameters Registries" or "Protocol Parameter Registry functions" ins= tead of "protocol parameters function". This maps more closely to the term= inology in RFC6220 and on IANA's web site and emphasizes the role as a regi= stry. >=20 > The strength and stability of the function and its foundation within the > Internet community are both important given how critical protocol > parameters are to the proper functioning of IETF protocols. >=20 > We think the structures that sustain the protocol parameters function > needs be strong enough that they can be offered independently by the > Internet community, without the need for backing from external parties. > And we believe we largely are there already, although the system can be > strengthened further, and continuous improvements are being made. >=20 > 2. The administration of the protocol parameters function by ICANN is > working well for the Internet and the IETF. >=20 > We are pleased with the publication and maintenance of the protocol > parameter function and the coordination of the evaluation of > registration requests through the IANA function provided by ICANN. >=20 > 3. The IETF protocol parameters function requires openness, > transparency, and accountability. >=20 > Existing documentation of how the function is administered and overseen > is good [RFC2860,RFC6220], but further articulation and clarity may be > beneficial. It is important that the whole Internet community can > understand how the function works, and that the processes for > registering parameters and holding those who oversee the protocol > parameter function accountable for following those processes are > understood by all interested parties. We are committed to making > improvements here if necessary. >=20 > 4. Any contemplated changes to the protocol parameters function should > use the current RFCs and model as the starting point. >=20 > The protocol parameters function is working well, and as a result > wholesale changes to the role of the IETF vis a vis the function are not > warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good > model to work from in the event that other parties do want to contemplate > changes. Put quite simply: evolution, not revolution. This statement should be strengthened to be more assertive and should be mo= ved to the top. RFC2860 is not just a "good model to work from", it is the controlling docu= ment for the IANA's Protocol Parameter Registry operation along with RFC622= 0. Item 4 should state that any contemplated changes to the IANA functions= should respect current RFCs and agreements with the IETF (especially RFC 2= 860) and any changes to the operation of the Protocol Parameter Registry sh= ould be done through the IETF as per RFC 2860 and RFC 6220. And don't forg= et about the IRTF. Below is possible replacement text: 4. Contemplated changes to the protocol parameters registry function should= respect agreements between IETF, IRTF and ICANN as per RFC2860, the IETF's= processes and the relevant RFCs (e.g., RTF 6220). The IANA protocol parameters registry function is working well, and as a re= sult wholesale changes to the role of the IETF, IRTF [and the IANA] vis a vis th= e function are not warranted. The Memorandum of Understanding between IETF, IRTF and IANA [RFC= 2860] defines "the technical work to be carried out by the Internet Assigne= d Numbers Authority on behalf of the Internet Engineering Task Force and th= e Internet Research Task Force." Modifications to the protocol parameters r= egistry function should be made via the IETF process updating RFC 6220 and = other relevant RFCs. Put quite simply: evolution, not revolution. >=20 > 5. The Internet architecture requires and receives capable service by=20 > Internet registries. >=20 > The stability of the Internet depends on capable provision of not just > IETF protocol parameters, but IP numbers, domain names, and other > registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. > Thus we expect the role of the IETF in standards development, architectur= al > guidance, and allocation of certain name/number parameters to continue. > IP multicast addresses and special-use DNS names are two examples where > close coordination is needed. The IETF will continue to coordinate with > ICANN, the RIRs, and other parties that are mutually invested in the > continued smooth operation of the Internet registries. We fully > understand the need to work together. I don't disagree with this statement, but it mixes the DNS and IP address f= unctions with the Protocol Parameter Registry functions and could be confus= ing. >=20 > 6. The IETF will continue its direction and stewardship of the protocol > parameters function as an integral component of the IETF standards > process and the use of resulting protocols. >=20 > RFC 6220 specifies the role and function of the protocol parameters > registry, which is critical to IETF standards processes and IETF > protocols. We see no need to revisit or reconsider our current approach > with regard to protocol parameters, including the ability to delegate > operational responsibility for registries to other organizations. As mentioned previously, I recommend moving this up to the top. >=20 > [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt > [RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt > [IAB1] http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-N= TIA-NOI-final.pdf > [IAB2] http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-20= 11.pdf Thanks, Chip ** I am employed by Cisco Systems, Inc, but these comments reflect my own o= pinion and not any position of Cisco. ** From nobody Mon Mar 3 09:42: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 E08EC1A030F for ; Mon, 3 Mar 2014 09:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.232 X-Spam-Level: ** X-Spam-Status: No, score=2.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, 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 zrMWu3bD_yAE for ; Mon, 3 Mar 2014 09:42:30 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id D46EE1A0256 for ; Mon, 3 Mar 2014 09:42:30 -0800 (PST) Received: from [85.159.233.116] (port=11923 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WKWsk-0008CA-SJ; Mon, 03 Mar 2014 09:42:27 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Mar 2014 18:42:23 +0100 To: Eric Brunner-Williams ,internetgovtech@iab.org From: JFC Morfin In-Reply-To: <5313ACE5.7000803@abenaki.wabanaki.net> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <5313ACE5.7000803@abenaki.wabanaki.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_280420205==.ALT" 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/nQNr_YDelZQEidamN1IgEmDohrc Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 03 Mar 2014 17:42:35 -0000 --=====================_280420205==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 23:12 02/03/2014, Eric Brunner-Williams wrote: >My two beads worth is that three decades ago, when Jon Postel wanted >to respond to the growth of registrations, Jon erred in missing the >fact that network prefixes associated with urban areas provided >addresses to the overwhelming majority of resources associated with >persistent mnemonics. Eric, I deeply agree with your two beads. We made the choice of ISO 3166-1 in 1978 because in 1978 the international communications world was made of monopolies. Domestically, it was made of cities, the economic/communicational importance of which was measured by the capacity to sustain the return on the investment of an access point. We then turned the world into the *additional* capacity of X121, which is attached to the legal topology of the networks (DNICs) while monopolies started being transferred to local law. When, in 1983, the internet was created, the DNS permitted 35,635 different visions of the catenet internetting project (Classes). This accommodated one vision per government and many visions by kind of populations, trades, cultures, languages, cities, urban agglomerations, indigenous polities, linguistic and cultural communities, even iso3166-3 regions and within that vision by as many units as you could wish (TLDs). This was culturally opposed by the IETF monolectic culture. This confused the US point of view (of the IP internetting project of the catenet) with a single unique "technically correct" perspective. This restricted the whole digisphere catenet to the sole ICANN/NTIA "IN" Class, the NICs to the sole INTERNIC, and the world to a single Virtual Global Network. This is what one calls "the BUG" for "being unipolarly global". The blessing of that BUG is that it is not in the technology, but rather in some people minds. It is not in the technology because it is not in the internet project of Vint Cerf (EIN 48). It is actually an opposition to the completion of the EIN 48 that has two motivations: the proof of the catenet concept and the capacity for the resulting internetting to be transparent (and, therefore, neutral) to other communication technologies. The most used communication technology is human languages, then trade jargons, etc. >Now the second bead. > >The "how many {sociologists,...} participate in IETF processes?" >laundry list manages to miss one area of work by "governments" which >might have, and still may, inform the IETF. Governments have been >quite successful in establishing language encoding standards in >which text data is created, transmitted, and stored. One government, >and its contractor, chose one national standard for all >text-associated network addressable resources, restricting script >choices to US-ASCII, and encodings over US-ASCII, for glyphs present >in a repertoire produced by an consortium of printer vendors. At no >point in time have "governments" initiated work necessary to >reconcile multiple, diverse character set standards, with a single >resource location mechanism, nor has the IRTF followed up on the >recommendation of the IAB Character Set Workshop of April, 1997, "to >create a research group to explore the open issues of character sets >on the Internet ". That character set exists. It is ISO 10646. Its maintenance agency is Unicode. This works pretty well except at the IETF where it now nearly works pretty well due to Vint Cerf (Chair of the WG/IDNAbis), Patrik Falsftm, and John Klensin. The IETF difficulty results again from the BUG that nearly blocked IDNA2008 until Pete Resnick and Paul Hoffmann came with an IETF worded response to our French language related opposition. French language is a typical representative of the need, in a non-typographic context, of non-ISO 10646 supported orthotypographic features. Their RFC 5895 permitted the WG/IDNAbis consensus, but it was only accepted by the IESG as a private contribution for information. >The observation has been made frequently, and by many, that language >is an "internet governance" issue, and in fact, the need for correct >resolution of resources "named" in the Han script, encoded in UTF-8, >lead to the illumination of a second root server constellation, >leading immediately to a consistency of publications problem -- a >first order problem in "internet governance", yet both "governments" >and "the technical community" treat this as a solved problem, >overlooking the distinction between the corpus of text associated >with resources, and the corpora of texts which comprise text resources. The problem is the BUG, i.e. the supposed monopolarity of the quasi-infinitely multipolar name spaces (the DNS is not the sole naming system). > From my perspective there are actual failures of both "government" > and "the technical community" to conduct "internet governance" > effectively, for which remedial work would be of measurable utility. Yes and no. They are delayed in understanding and implementing the Vint Cerf EIN 48 project. Its first motivation has been met by the US Government that sponsored it. There is a global internetting of the world's catenet. The network of the networks. Now, the technical community must understand how it actually *has* fully addressed the second motivation; and the governments, the industry, the academics, and informed users must be given the technical "go-ahead" to use it. For the virtual networks of the network of networks. This is a big issue and a big responsibility because it might lead to a total mess if, when opening the throttle of the full implementation of the IETF technology, it does not work. So, concerned leaders did three things: - the first thing IAB and IETF completed was to assemble together with ISOC, IEEE, and W3C. - then they delegated the ultimate responsibility to the economy (not them, not the governments) through the OpenStand paradigmatic statement. I appealed RFC 6852 because the IESG did not inform the community of the real nature of the decision. Then, I appealed the IAB for relinquishing its responsibilities of the ultimate referent. I, this way, prepared an appeal for the ISOC in order to force it to be that referent, at least one time: to tell who was the referent of the OpenStand, or to open this digital global governance issue. Who ultilmately addresses technical conflicts? - the ICANN also wished to relinquish its responsibilities in the possible fiasco and dilute them in a "globalization" - whatever it may mean as long as it is solemnly sponsored by Governments. They joined the technology leaders in Montevideo and transfered the problem to Govs, to be discussed in Sao Paulo. The appealing proposition, for everyone to discuss it, is that the decision is made on an undefined MS basis. The problem is that being authorized by the IETF, ICANN, or Govs or not, the throttle is leaking. It must be progressively opened before it blows-up. This has to be made in order, as per the IETF proven experience of testing running codes. In order to provoke it, I chose one limited and progressive way (that can develop by itself, if it works; and prevent false hopes in an ambitious project, if it does not). This is the "HomeRoot", fringe to fringe layer, experimentation project based upon the VGN concept. It will lead to a polycratic experimental decision, to be documented at the proper layer SDO if it was adopted. - HomeRoot means that participating users will use and exchange their own root data, from their exploration of the Classes' top zones. - fringe to fringe means that end to end IETF technology will be 100% respected and used as per RFC 1958 (at the fringe) and RFC 5895 (on the user side). - VGN means that every participating user will consider the global catenet as its own virtual global space through his personal NIC (the same way as Govs are to deal with their digital space sovereignty) participating in the catenet global metadata registry system (MDRS) - polycracy means the effective globalization of the MS decision emergence by mutual information and individual decisions. - the proper layer (fringe) is the presentation layer six in OSI terms. However, the lack of an Internet presentation layer in its initial phase turns out to be a wise approach, as it happens that a presentation layer on the user side (PLUS) at an intelligent use interface (IUI) under the user's computer assisted supervision can be far more secure, rewarding, and robust. To concert those issues between users and IETF participants is the IUCG@IETF non-WG purpose. This represents, therefore, the experimentation of a progressive possible shift (under the terms of the ICANN ICP-3 currently effective policy) from a limited set of VGNICs (mainly ICANN, China, ORSN) to an emergence of many of them. Such a possible emergence souhld (as per the WSIS resolutions) be discussed at the IGF (and possibly multilaterally among Telcos and Govs (Sao Paulo) as part of their patch of the WCIT Dubai disagreement). The VGNICS (http://vgnics.net) perspective is, therefore, in line with subsidiarity/substitution to be used to address the diversity in the RFC 5895 response. There is no centralized responsibility to take, no solemn decision in order to open the throttle: this has been already decided. The interest to participate or pursue is not to be multilaterally or multistakeholderly sustained: in a people centered desired information society (Geneva declaration) people will decide if they are interested. Everyone, Gov, corporate, CS NGO, individual user is welcome to help, consider and deploy the supervision of his/her/its own VGN. And see if it works, and if he/she/it is pleased with it or not. The current idea, based upon the past community dot-root project (as per ICP-3), the description of the ORSN experience, and the Chinese solution leads to focus on five proposed initial steps, as seen from the complementary point of view of a VGN manager: 1. EzoP (exploration des zones primaires/exploration of the top zones) 2. HomeRoot (documentation of the implementation of a local resolution capacity based on the EZoP outputs). 3. MDRS (extended IANA information, adapted to each kind of VGN, for the organization of VGNICs) 4. I*Book (consolidation of the RFCs and other standards to give VGN administrators, operators and developers a maintained common reference and training book). 5. Netix (an integrated network oriented Posix commands extension) for InterPLUS (inter+) operations and interapplications development. Last but not the least, the VGN concept addresses the accountability issue in a polycratic manner: users will be able to select their VGNIC on a competition basis, along with the ICANN by-laws, and the OpenStand principles. jfc --=====================_280420205==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 23:12 02/03/2014, Eric Brunner-Williams wrote:
My two beads worth is that three decades ago, when Jon Postel wanted to respond to the growth of registrations, Jon erred in missing the fact that network prefixes associated with urban areas provided addresses to the overwhelming majority of resources associated with persistent mnemonics.

Eric,

I deeply agree with your two beads.

We made the choice of ISO 3166-1 in 1978 because in 1978 the international communications world was made of monopolies. Domestically, it was made of cities, the economic/communicational importance of which was measured by the capacity to sustain the return on the investment of an access point. We then turned the world into the *additional* capacity of X121, which is attached to the legal topology of the networks (DNICs) while monopolies started being transferred to local law. When, in 1983, the internet was created, the DNS permitted 35,635 different visions of the catenet internetting project (Classes). This accommodated one vision per government and many visions by kind of populations, trades, cultures, languages, cities, urban agglomerations, indigenous polities, linguistic and cultural communities, even iso3166-3 regions and within that vision by as many units as you could wish (TLDs).

This was culturally opposed by the IETF monolectic culture. This confused the US point of view (of the IP internetting project of the catenet) with a single unique  "technically correct" perspective. This restricted the whole digisphere catenet to the sole ICANN/NTIA "IN" Class, the NICs to the sole INTERNIC, and the world to a single Virtual Global Network. This is what one calls "the BUG" for "being unipolarly global".

The blessing of that BUG is that it is not in the technology, but rather in some people minds. It is not in the technology because it is not in the internet project of Vint Cerf (EIN 48). It is actually an opposition to the completion of the EIN 48 that has two motivations: the proof of the catenet concept and the capacity for the resulting internetting to be transparent (and, therefore, neutral) to other communication technologies.

The most used communication technology is human languages, then trade jargons, etc.

Now the second bead.

The "how many {sociologists,...} participate in IETF processes?" laundry list manages to miss one area of work by "governments" which might have, and still may, inform the IETF.  Governments have been quite successful in establishing language encoding standards in which text data is created, transmitted, and stored. One government, and its contractor, chose one national standard for all text-associated network addressable resources, restricting script choices to US-ASCII, and encodings over US-ASCII, for glyphs present in a repertoire produced by an consortium of printer vendors. At no point in time have "governments" initiated work necessary to reconcile multiple, diverse character set standards, with a single resource location mechanism, nor has the IRTF followed up on the recommendation of the IAB Character Set Workshop of April, 1997, "to create a research group to explore the open issues of character sets on the Internet ".

That character set exists.

It is ISO 10646. Its maintenance agency is Unicode. This works pretty well except at the IETF where it now nearly works pretty well due to Vint Cerf (Chair of the WG/IDNAbis), Patrik Falsftm, and John Klensin.

The IETF difficulty results again from the BUG that nearly blocked IDNA2008 until Pete Resnick and Paul Hoffmann came with an IETF worded response to our French language related opposition. French language is a typical representative of the need, in a non-typographic context, of non-ISO 10646 supported orthotypographic features. Their RFC 5895 permitted the WG/IDNAbis consensus, but it was only accepted by the IESG as a private contribution for information.

The observation has been made frequently, and by many, that language is an "internet governance" issue, and in fact, the need for correct resolution of resources "named" in the Han script, encoded in UTF-8, lead to the illumination of a second root server constellation, leading immediately to a consistency of publications problem -- a first order problem in "internet governance", yet both "governments" and "the technical community" treat this as a solved problem, overlooking the distinction between the corpus of text associated with resources, and the corpora of texts which comprise text resources.

The problem is the BUG, i.e. the supposed monopolarity of the quasi-infinitely multipolar name spaces (the DNS is not the sole naming system).

From my perspective there are actual failures of both "government" and "the technical community" to conduct "internet governance" effectively, for which remedial work would be of measurable utility.

Yes and no.

They are delayed in understanding and implementing the Vint Cerf EIN 48 project. Its first motivation has been met by the US Government that sponsored it. There is a global internetting of the world's catenet. The network of the networks.

Now, the technical community must understand how it actually *has* fully addressed the second motivation; and the governments, the industry, the academics, and informed users must be given the technical "go-ahead" to use it. For the virtual networks of the network of networks.

This is a big issue and a big responsibility because it might lead to a total mess if, when opening the throttle of the full implementation of the IETF technology, it does not work. So, concerned leaders did three things:

- the first thing IAB and IETF completed was to assemble together with ISOC, IEEE, and W3C.

- then they delegated the ultimate responsibility to the economy (not them, not the governments) through the OpenStand paradigmatic statement. I appealed RFC 6852 because the IESG did not inform the community of the real nature of the decision. Then, I appealed the IAB for relinquishing its responsibilities of the ultimate referent. I, this way, prepared an appeal for the ISOC in order to force it to be that referent, at least one time: to tell who was the referent of the OpenStand, or to open this digital global governance issue. Who ultilmately addresses technical conflicts?

- the ICANN also wished to relinquish its responsibilities in the possible fiasco and dilute them in a "globalization" - whatever it may mean as long as it is solemnly sponsored by Governments. They joined the technology leaders in Montevideo and transfered the problem to Govs, to be discussed in Sao Paulo. The appealing proposition, for everyone to discuss it, is that the decision is made on an undefined MS basis.


The problem is that being authorized by the IETF, ICANN, or Govs or not,  the throttle is leaking. It must be progressively opened before it blows-up. This has to be made in order, as per the IETF proven experience of testing running codes.

In order to provoke it, I chose one limited and progressive way (that can develop by itself, if it works; and prevent false hopes in an ambitious project, if it does not). This is the "HomeRoot", fringe to fringe layer, experimentation project based upon the VGN concept. It will lead to a polycratic experimental decision, to be documented at the proper layer SDO if it was adopted.

- HomeRoot means that participating users will use and exchange their own root data, from their exploration of the Classes' top zones.
- fringe to fringe means that end to end IETF technology will be 100% respected and used as per RFC 1958 (at the fringe) and RFC 5895 (on the user side).
- VGN means that every participating user will consider the global catenet as its own virtual global space through his personal NIC (the same way as Govs are to deal with their digital space sovereignty) participating in the catenet global metadata registry system (MDRS)
- polycracy means the effective globalization of the MS decision emergence by mutual information and individual decisions.
- the proper layer (fringe) is the presentation layer six in OSI terms. However, the lack of an Internet presentation layer in its initial phase turns out to be a wise approach, as it happens that a presentation layer on the user side (PLUS) at an intelligent use interface (IUI) under the user's computer assisted supervision can be far more secure, rewarding, and robust. To concert those issues between users and IETF participants is the IUCG@IETF non-WG purpose.

This represents, therefore, the experimentation of a progressive possible shift (under the terms of the ICANN ICP-3 currently effective policy) from a limited set of VGNICs (mainly ICANN, China, ORSN) to an emergence of many of them. Such a possible emergence souhld (as per the WSIS resolutions) be discussed at the IGF (and possibly multilaterally among Telcos and Govs (Sao Paulo)  as part of their patch of the WCIT Dubai disagreement).

The VGNICS (http://vgnics.net) perspective is, therefore, in line with subsidiarity/substitution to be used to address the diversity in the RFC 5895 response. There is no centralized responsibility to take, no solemn decision in order to open the throttle: this has been already decided. The interest to participate or pursue is not to be multilaterally or multistakeholderly sustained: in a people centered desired information society (Geneva declaration) people will decide if they are interested. Everyone, Gov, corporate, CS NGO, individual user is welcome to help, consider and deploy the supervision of his/her/its own VGN. And see if it works, and if he/she/it is pleased with it or not.

The current idea, based upon the past community dot-root project (as per ICP-3), the description of the ORSN experience, and the Chinese solution leads to focus on five proposed initial steps, as seen from the complementary point of view of a VGN manager:

1. EzoP (exploration des zones primaires/exploration of the top zones)

2. HomeRoot (documentation of the implementation of a local resolution capacity based on the EZoP outputs).

3. MDRS (extended IANA information, adapted to each kind of VGN, for the organization of VGNICs)

4. I*Book (consolidation of the RFCs and other standards to give VGN administrators, operators and developers a maintained common reference and training book). 

5. Netix (an integrated network oriented Posix commands extension) for InterPLUS (inter+) operations and interapplications development.
 
Last but not the least, the VGN concept addresses the accountability issue in a polycratic manner: users will be able to select their VGNIC on a competition basis, along with the ICANN by-laws, and the OpenStand principles.

jfc
--=====================_280420205==.ALT-- From nobody Mon Mar 3 10: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 956881A0331; Mon, 3 Mar 2014 10:09:34 -0800 (PST) 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 wiDNQuRldIao; Mon, 3 Mar 2014 10:09:30 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 45A441A016C; Mon, 3 Mar 2014 10:09:14 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t61so1165913wes.30 for ; Mon, 03 Mar 2014 10:09:11 -0800 (PST) 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=LHArmfd7BlmwRn/+GTZcgi9+65SYuPyaZQyJIx1HoNE=; b=Izo6K+3ilL5Qw0lIXXzGRwfUEN5g/WpL3oaxeb9ckkvs3Jhi4ETvkJadrFC90xOP+i X12njZe3ox9X2iup1HhJDeFvk2fYjMhyt9GMqR0PYOwjdWDs4ivHNwYovkG5x3gF9O20 NoJ6mByRq4A4OU4zpkGZmiNlMcpfzLdiZEoHc8tK13AUjC0ugigIVIEueJwBHZPlGqWF um+9yi4wZ5nr5CBFh82ne0SYuF2ww1pAnLRT25+0uAXRgxN6gjwD/4qRIXLrW0wWiFmh 4s7LucFj7ujP7xC6yLU95q57+q2WduI+DHnLfyqKMoyhEXAtxBt4coe+efkJfEn5PDlV Wv8A== X-Received: by 10.194.82.35 with SMTP id f3mr19266922wjy.36.1393870150905; Mon, 03 Mar 2014 10:09:10 -0800 (PST) Received: from [31.133.165.224] (dhcp-a5e0.meeting.ietf.org. [31.133.165.224]) by mx.google.com with ESMTPSA id r3sm38777350wjw.0.2014.03.03.10.09.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 10:09:10 -0800 (PST) Message-ID: <5314C53F.4020009@gmail.com> Date: Tue, 04 Mar 2014 07:09:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IAB Chair References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> In-Reply-To: <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/-dNd2rv4DAQDOc1fSLrmqK7mk_4 Cc: "Chip Sharp \(chsharp\)" , "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 03 Mar 2014 18:09:36 -0000 X-List-Received-Date: Mon, 03 Mar 2014 18:09:36 -0000 I agree with Chip's comments, and in particular: On 04/03/2014 06:30, Chip Sharp (chsharp) wrote: ... >> 4. Any contemplated changes to the protocol parameters >> function should use the current RFCs and model as the >> starting point. >> >> The protocol parameters function is working well, and as a >> result wholesale changes to the role of the IETF vis a vis >> the function are not warranted. The IETF/IANA Memorandum of >> Understanding [RFC2860] is a good model to work from in the >> event that other parties do want to contemplate changes. >> Put quite simply: evolution, not revolution. > > This statement should be strengthened to be more assertive > and should be moved to the top. RFC2860 is not just a "good > model to work from", it is the controlling document for the > IANA's Protocol Parameter Registry operation along with > RFC6220. Agreed; it's a binding document today and should remain so. In fact, no changes to the IETF's IANA function that we delegated to ICANN can be made without IETF consent; that is an intended side-effect of the existing MoU. If other SDOs wanted to contract with ICANN-IANA for services it would be a model for *them* to work from, but as far as the IETF is concerned it's a done deal. Maybe that was the intended meaning, but that isn't clear from the text. Brian From nobody Mon Mar 3 12:04: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 E620C1A0368 for ; Mon, 3 Mar 2014 12:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.547] 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 ugOiWiv3_Oyz for ; Mon, 3 Mar 2014 12:04:49 -0800 (PST) Received: from nic-naa.net (abenaki.wabanaki.net [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB311A0321 for ; Mon, 3 Mar 2014 12:04:47 -0800 (PST) Received: from frog.local ([67.42.198.93]) by nic-naa.net (8.14.8/8.14.8) with ESMTP id s23K3qGS004979; Mon, 3 Mar 2014 15:04:14 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <5314E01E.7030002@abenaki.wabanaki.net> Date: Mon, 03 Mar 2014 12:03:42 -0800 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: JFC Morfin , internetgovtech@iab.org References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <5313ACE5.7000803@abenaki.wabanaki.net> <201403031743.s23Hghfw004600@nic-! naa.net> In-Reply-To: <201403031743.s23Hghfw004600@nic-naa.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/qwiUyxm6FJ4nbl0IulDUjuHEThE Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 03 Mar 2014 20:04:55 -0000 On 3/3/14 9:42 AM, JFC Morfin wrote: > Eric, > > I deeply agree with your two beads. i doubt it. From nobody Tue Mar 4 15:48: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 02D451A00D7 for ; Tue, 4 Mar 2014 15:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.223 X-Spam-Level: *** X-Spam-Status: No, score=3.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, 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 MwXt05FRt9Yc for ; Tue, 4 Mar 2014 15:48:02 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 850A61A00F2 for ; Tue, 4 Mar 2014 15:47:45 -0800 (PST) Received: from 169.69.176.95.rev.sfr.net ([95.176.69.169]:32331 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WKz3l-0006jg-9L; Tue, 04 Mar 2014 15:47:41 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2014 21:29:13 +0100 To: Eric Brunner-Williams ,internetgovtech@iab.org From: Jefsey In-Reply-To: <5314E01E.7030002@abenaki.wabanaki.net> References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org> <73481820-F228-434C-814A-070F6A2C1F93@gmail.com> <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com> <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local> <52FD9183.8090101@gmail.com> <01a701cf3248$fac2ac90$f04805b0$@riw.us> <018d01cf32f6$eca825a0$c5f870e0$@riw.us> <013e01cf3613$293b89c0$7bb29d40$@riw.us> <5313ACE5.7000803@abenaki.wabanaki.net> <201403031743.s23Hghfw004600@nic-! naa.net> <5314E01E.7030002@abenaki.wabanaki.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: 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/-P3hfkegxMX_4-AqMt8sDGK2Vwc Subject: Re: [Internetgovtech] US Government response to the European Commission statement 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, 04 Mar 2014 23:48:04 -0000 At 21:03 03/03/2014, Eric Brunner-Williams wrote: >On 3/3/14 9:42 AM, JFC Morfin wrote: >>Eric, >> >>I deeply agree with your two beads. > >i doubt it. I am sur we agree on symptom, probably not on the diagnosys, and aparently not on the prescription. Future of the patient will tell. jfc From nobody Wed Mar 5 10:40: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 20A741A0072; Wed, 5 Mar 2014 10:40:00 -0800 (PST) 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 emuZntzgahwK; Wed, 5 Mar 2014 10:39:57 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4521A0183; Wed, 5 Mar 2014 10:39:57 -0800 (PST) Received: from [85.159.233.116] (port=2098 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WLGjR-0001Q8-Ci; Wed, 05 Mar 2014 10:39:54 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Mar 2014 19:39:51 +0100 To: IAB Chair From: JFC Morfin In-Reply-To: References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.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: 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/w9DFEfHjkXJgAUeF3qWpnn9h6CI Cc: internetgovtech@iab.org, agora@vgnics.net, iucg@ietf.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 05 Mar 2014 18:40:00 -0000 Dear Russ, I thank you for this confirmation of the IAB/IETF determination irt. the Internet end to end parameters after the ambiguous publication of the OpenStand RFC 6852 which does not define a common referent after the inclusion of ISOC, IEEE and W3C as a common readers of the economic requirements of the global communities. As personnally trying to clarify the terms of the multistakeholder governance of global information both for IUsers and multitechnology VGN individual, private and public operators I understand that there is a consensus of my interlocutors to trust, rely on, respect, and enforce the IETF structural parameters, and the IETF repartition of operational parameters. The intent is to channel the technical concerns via the IUCG and cooperate through the VGNICS experimental enhanced cooperation proposition under formalization (http://vgnics.net) and its MDRS (http://vgnics.net/mdrs) for the collection, validation and diffusion of fringe to fringe information made avaliable to VGNIC managers and DNS services operators. The intent is also to keep IAB informed of the efforts of documentation consolidation and/or translation. We certainly understand the importance - up to now illustrated by the US and a few other Governements - to be able to organize the Internet operations both in global continuity and in taking into account national needs, in particular in case of catastrophe or critical situations. The strategy wich seems to be demanded is a neutrality of information on a neutral end to end global network, of which the higher layers will be kept transparent to any fringe to fringe technology. Best regards. jfc At 18:28 24/02/2014, IAB Chair wrote: >Existing IETF and IAB consensus concerning Internet registry functions >and IANA are documented in a variety of RFCs and IAB communications >[RFC2860,RFC6220,IAB1,IAB2]. Since registry functions and IANA are >likely to be the subject of discussion in a number of venues outside the >IETF over the coming months and years, the IAB is seeking community >feedback about operating principles to use when they find themselves >involved in those discussions. > >While dealing with these issues the IAB has consistently approached the >issues from a set of (implicit) principles. Since the registry functions >are subject of discussion in various fora, the IAB has tried to make >these operating principles explicit and seeks to confirm these with the >community. > >The IAB are planning to use part of the time in the IGOVUPDATE session at >IETF 89 (6 March 2014, 17:00-18:30 GMT) for a discussion of such operating >principles. But we wanted to kick-start that discussion with a few >thoughts about principles that the IAB and IETF have articulated in >various documents already and some that have emerged over time but may >not have been written down. What we are interested in is an articulation >of what the IETF community values. What other parties (ICANN, RIRs, >governments, etc.) value when they think about registry functions is >interesting, but we want to focus this discussion on the IETF and not >those other parties. > >This is a first cut of making the principles more explicit for which we >seek your views. > >Some of these might seem a bit generic, but it is difficult to predict >the nature of future discussions in which IETF and IAB leaders might find >themselves, so generality helps in that regard. > >On behalf of the IAB, > Russ Housley > IAB Chair > >= = = = = = = = > >Principles Guiding the Evolution of the IANA Protocol Parameter Registries > >1. The IETF protocol parameters function has been and continues to be >capably provided by the Internet community. > >The strength and stability of the function and its foundation within the >Internet community are both important given how critical protocol >parameters are to the proper functioning of IETF protocols. > >We think the structures that sustain the protocol parameters function >needs be strong enough that they can be offered independently by the >Internet community, without the need for backing from external parties. >And we believe we largely are there already, although the system can be >strengthened further, and continuous improvements are being made. > >2. The administration of the protocol parameters function by ICANN is >working well for the Internet and the IETF. > >We are pleased with the publication and maintenance of the protocol >parameter function and the coordination of the evaluation of >registration requests through the IANA function provided by ICANN. > >3. The IETF protocol parameters function requires openness, >transparency, and accountability. > >Existing documentation of how the function is administered and overseen >is good [RFC2860,RFC6220], but further articulation and clarity may be >beneficial. It is important that the whole Internet community can >understand how the function works, and that the processes for >registering parameters and holding those who oversee the protocol >parameter function accountable for following those processes are >understood by all interested parties. We are committed to making >improvements here if necessary. > >4. Any contemplated changes to the protocol parameters function should >use the current RFCs and model as the starting point. > >The protocol parameters function is working well, and as a result >wholesale changes to the role of the IETF vis a vis the function are not >warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good >model to work from in the event that other parties do want to contemplate >changes. Put quite simply: evolution, not revolution. > >5. The Internet architecture requires and receives capable service by >Internet registries. > >The stability of the Internet depends on capable provision of not just >IETF protocol parameters, but IP numbers, domain names, and other >registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. >Thus we expect the role of the IETF in standards development, architectural >guidance, and allocation of certain name/number parameters to continue. >IP multicast addresses and special-use DNS names are two examples where >close coordination is needed. The IETF will continue to coordinate with >ICANN, the RIRs, and other parties that are mutually invested in the >continued smooth operation of the Internet registries. We fully >understand the need to work together. > >6. The IETF will continue its direction and stewardship of the protocol >parameters function as an integral component of the IETF standards >process and the use of resulting protocols. > >RFC 6220 specifies the role and function of the protocol parameters >registry, which is critical to IETF standards processes and IETF >protocols. We see no need to revisit or reconsider our current approach >with regard to protocol parameters, including the ability to delegate >operational responsibility for registries to other organizations. > >[RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt >[RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt >[IAB1] >http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf >[IAB2] >http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf > >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech From nobody Thu Mar 6 11:34: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 71FAD1A00B1 for ; Thu, 6 Mar 2014 11:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 HVVOCxgPAVCU for ; Thu, 6 Mar 2014 11:34:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 792D61A00E9 for ; Thu, 6 Mar 2014 11:34:11 -0800 (PST) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DF9CF40382 for ; Thu, 6 Mar 2014 14:34:06 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5725BE45-106D-4129-A28B-AD6257861BEE@viagenie.ca> Date: Thu, 6 Mar 2014 19:34:05 +0000 To: internetgovtech@iab.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/1NSZOCxkDX8tqDrQZDTvJrFs7HE Subject: [Internetgovtech] igovupdate minutes 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, 06 Mar 2014 19:34:21 -0000 Please find the minutes of today's igovupdate session. http://www.ietf.org/proceedings/89/minutes/minutes-89-igovupdate Thanks to Heather Flanagan for scribing. Please send mods to me. Regards, Marc. From nobody Fri Mar 7 04:26: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 471E71A0259 for ; Fri, 7 Mar 2014 04:26:01 -0800 (PST) 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 J0EYFn2atDLZ for ; Fri, 7 Mar 2014 04:25:59 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id B65501A0257 for ; Fri, 7 Mar 2014 04:25:59 -0800 (PST) Received: from 5.66.176.95.rev.sfr.net ([95.176.66.5]:31323 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WLtqc-0006KT-RR; Fri, 07 Mar 2014 04:25:55 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Mar 2014 13:25:53 +0100 To: "discuss@1net.org List" , "discuss@0net.org List" From: Jefsey 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/K2ZztUCk5FNx5FwEIxlEP2wMoy0 Cc: internetgovtech@iab.org, iucg@ietf.org Subject: [Internetgovtech] IETF 89 - IGOV update. 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, 07 Mar 2014 12:26:01 -0000 http://iucg.org/wiki/IETF_89_London_-_igovupdate I quote some parts and interspred comments: >In this discussion: > >Steve Crocker summarized: > >There is a complex and poorly understood trio of globalization efforts >underway. >- One is, globalization of IANA function. >- Second, globalization of ICANN function. >- Third, broader discussion of Internet Governance which is broader >than ICANN and IANA. Correct. This is a difficulty the /1net mailing list seems to meet. The matter is broader than ICANN and IANA. Achitecturaly and architectonically one cannot avoid that neutral transparency to VGN (Virtual Global Network) technologies and governance is the ultimate target of the Internetting project. This target is technically within reach, but is curbed by political stands and economical interests that oppose the status-quo. >Patrik Falstrm noted: > >You are not conflicting with the Tunis agenda, which means you are not >requesting or supporting an initiative to have a full WSIS in 2015. It >is important that you verify that the principles cannot be used in >favor of having a new WSIS. [this was confirmed]. This implicitely means that the IAB stands by the WSIS principles and believes that they are fully compatible with OpenStand, what is questionnable. >Russ Housley concluded reviewing the Principles Guiding the Evolution >of the IANA Protocol Parameter Registries > >1. The IETF protocol parameters function has been and continues to be >capably provided by the Internet community. > >The strength and stability of the function and its foundation within the >Internet community are both important given how critical protocol >parameters are to the proper functioning of IETF protocols. > >We think the structures that sustain the protocol parameters function >needs be strong enough that they can be offered independently by the >Internet community, without the need for backing from external parties. >And we believe we largely are there already, although the system can be >strengthened further, and continuous improvements are being made. > > >> review: needs clarification about what we mean by the Internet Community ditto for: internet and globalization. >2. The administration of the protocol parameters function by ICANN is >working well for the Internet and the IETF. > >We are pleased with the publication and maintenance of the protocol >parameter function and the coordination of the evaluation of >registration requests through the IANA function provided by ICANN. > > >> this isn't a principle at all just a statement of fact, and maybe >that belongs elsewhere This is true because the Linguistic tables are not extensively accessed what might be the case if the Unicode langtags routine were upgraded to better operationnally support a multilinguistic environment. The load on the IANA could then becom tremendous due to the size of the table and the lack of an interrogation/update system. >3. The IETF protocol parameters function requires openness, >transparency, and accountability. > >Existing documentation of how the function is administered and overseen >is good [RFC2860,RFC6220], but further articulation and clarity may be >beneficial. It is important that the whole Internet community can >understand how the function works, and that the processes for >registering parameters and holding those who oversee the protocol >parameter function accountable for following those processes are >understood by all interested parties. We are committed to making >improvements here if necessary. > > >> remove "but" (but further articulation ...) This applies to the VGNICS as well. I have committed to IAB Chair that we will follow the RFC 2860 principles. >4. Any contemplated changes to the protocol parameters function should >use the current RFCs and model as the starting point. > >The protocol parameters function is working well, and as a result >wholesale changes to the role of the IETF vis a vis the function are not >warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good >model to work from in the event that other parties do want to contemplate >changes. Put quite simply: evolution, not revolution. > > >> "this is a service to IETF, and that the IETF selects the service >provider, not the other way around" This is correct in the case of a unique authoritative VGN default. The MDRS (MetaReferential Distributed System) is to extend the IANA default to the VGNICs with others inputs related to layer six, multiple technology, interapplications, VGN governance information and parameters. Since VGNs form an interplus stratum above the internet, the basic principle should however be that IETF inputs are to be strictly respected. The idea is that MAY, SHOULD, MUST apply withing a stratum, and that inputs from other strata are ARE. So there should not be any conflict by vertue of the layered model. Difficulties will be dealt at the IAB liaison level. However, discrepancies might occur among VGN implementations due to their different contexts. This case seems to have been considered when "coordination" is proposed to be explored for an added principle. >5. The Internet architecture requires and receives capable service by >Internet registries. > >The stability of the Internet depends on capable provision of not just >IETF protocol parameters, but IP numbers, domain names, and other >registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. >Thus we expect the role of the IETF in standards development, architectural >guidance, and allocation of certain name/number parameters to continue. >IP multicast addresses and special-use DNS names are two examples where >close coordination is needed. The IETF will continue to coordinate with >ICANN, the RIRs, and other parties that are mutually invested in the >continued smooth operation of the Internet registries. We fully >understand the need to work together. > > >> no comment This extends to the stratum above (fringe to fringe) as to the stratum below (existing relations with the plug to plus ITU). >6. The IETF will continue its direction and stewardship of the protocol >parameters function as an integral component of the IETF standards >process and the use of resulting protocols. > >RFC 6220 specifies the role and function of the protocol parameters >registry, which is critical to IETF standards processes and IETF >protocols. We see no need to revisit or reconsider our current approach >with regard to protocol parameters, including the ability to delegate >operational responsibility for registries to other organizations > > >> "use exactly the language of RFC 6220, and be more clear than just >the bold text at the top that this is not about names and numbers This is probably to explore further on experience depending on the requirements of the interfaced technologies. > >>> add an additional principle to talk about content of registries In the MDRS case this is going to depend from acquired exploration and experience but it is like that many new issues in the active/specific/etc. content. > >>> and think about an additional principle to deal with the coordination It is likely that coordination above (VGNs) will be equivalent in its structure to coordination below (ITU) if the VGN stratum can be coordinated through one governance (http://vgnics.net attempt) and one technical forum (interfaced through IUCG?). jfc From nobody Fri Mar 7 06:02: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 D86271A0073 for ; Fri, 7 Mar 2014 06:02:07 -0800 (PST) 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 5OIh_9B4fzPG for ; Fri, 7 Mar 2014 06:02:04 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 68A151A0164 for ; Fri, 7 Mar 2014 06:02:04 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id F24349A4380; Fri, 7 Mar 2014 09:01:50 -0500 (EST) 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 WpCJ-ohqxfcw; Fri, 7 Mar 2014 09:01:49 -0500 (EST) Received: from dhcp-b45b.meeting.ietf.org (dhcp-b45b.meeting.ietf.org [31.133.180.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1327C9A4381; Fri, 7 Mar 2014 09:01:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> Date: Fri, 7 Mar 2014 07:58:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68BD93CF-4767-4FBA-9E7A-F5B98D566513@vigilsec.com> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> To: Chip Sharp (chsharp) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZZhWyrxV8h8enQihhEpBQuKUZ_s Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 07 Mar 2014 14:02:08 -0000 Chip: > Question for clarification, is the Time Zone database operated under = RFC2860? I think so, but want to check. The Time Zone database does fall under RFC 2860, but it have a special = set of policies that govern updates. Much is delegated; however, the = IESG is the body that would handle an appeal if someone felt that the = processes were not being followed. Russ From nobody Fri Mar 7 06:51: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 CE6EB1A01EC for ; Fri, 7 Mar 2014 06:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 ZXfQ0nLaQxky for ; Fri, 7 Mar 2014 06:51:42 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id C49B21A0118 for ; Fri, 7 Mar 2014 06:51:41 -0800 (PST) Received: from ix-2.local (unknown [IPv6:2001:67c:370:152:e89a:a0f:69be:996b]) by mail.frobbit.se (Postfix) with ESMTPSA id DD12C21E9D; Fri, 7 Mar 2014 15:51:35 +0100 (CET) Message-ID: <5319DCF6.9000600@frobbit.se> Date: Fri, 07 Mar 2014 14:51:34 +0000 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Russ Housley , "Chip Sharp (chsharp)" References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> <68BD93CF-4767-4FBA-9E7A-F5B98D566513@vigilsec.com> In-Reply-To: <68BD93CF-4767-4FBA-9E7A-F5B98D566513@vigilsec.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jK7lT7bDjFP712ncASsdxFgnuIxQAmRKq" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/qMMjH8jGXh2dKA3p1uIcCb4e7aI Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 07 Mar 2014 14:51:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jK7lT7bDjFP712ncASsdxFgnuIxQAmRKq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-03-07 12:58, Russ Housley wrote: > Chip: >=20 >> > Question for clarification, is the Time Zone database operated under= RFC2860? I think so, but want to check. > The Time Zone database does fall under RFC 2860, but it have a special = set of policies that govern updates. Much is delegated; however, the IES= G is the body that would handle an appeal if someone felt that the proces= ses were not being followed. There are, I think, a few other parameters that are sort of "corner cases", like "IDN Practices Repository" that IANA list under "Domain Names" but if I understand correctly is operated on direct request from ICANN (I might be completely wrong here on how that registry was set up). Patrik --jK7lT7bDjFP712ncASsdxFgnuIxQAmRKq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTGdz2rMabGguI180RAocQAJ4psm1m5XTnxIenmqXoH7YIwejxngCdEGGY O1FFSWAxc7e7TrE7VWG8IB0= =jvdZ -----END PGP SIGNATURE----- --jK7lT7bDjFP712ncASsdxFgnuIxQAmRKq-- From nobody Fri Mar 7 07:13: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 CF1CD1A01F5 for ; Fri, 7 Mar 2014 07:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.748 X-Spam-Level: X-Spam-Status: No, score=-9.748 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.547, 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 kPHApJEZdbtw for ; Fri, 7 Mar 2014 07:13:33 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id B30EE1A01FC for ; Fri, 7 Mar 2014 07:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1441; q=dns/txt; s=iport; t=1394205209; x=1395414809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+6FQwh/E1kKRZgG1wKFoZf9SXm9Okg8RGUXAdkRKwHk=; b=JM7dn/cIduAa6cwhJc4Hs8bszNkIQZ+6SVfDPcLEiuUf87AIVm0D4i29 70gzBZhALmLWKHxftRIfN4BIw5YP7DNKRYsy+kJLlhV3a9XwolA0qcpnm JTwXq2YN3E4KDJldNTb2/EqiWgxBJVitWGpPI57wszcJvRARNg6GRzH3b 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAD/hGVOtJXG9/2dsb2JhbABagwY7V8BWT4ESFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQBDQUJh2gIDdAKF44oMweDJIEUBIkYjyuSK4FvgT6CKw X-IronPort-AV: E=Sophos;i="4.97,608,1389744000"; d="scan'208";a="25709402" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-2.cisco.com with ESMTP; 07 Mar 2014 15:13:28 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s27FDSWK011478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 15:13:28 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.70]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 09:13:28 -0600 From: "Chip Sharp (chsharp)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Russ Housley Thread-Topic: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries Thread-Index: AQHPOg3Xgok2Nn15iU2TBWzRcDGyxJrWGfAAgAAGJ4A= Date: Fri, 7 Mar 2014 15:13:27 +0000 Message-ID: <4821B126-6E53-4296-A946-51E359EDAA3B@cisco.com> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> <68BD93CF-4767-4FBA-9E7A-F5B98D566513@vigilsec.com> <5319DCF6.9000600@frobbit.se> In-Reply-To: <5319DCF6.9000600@frobbit.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <474EB4125DA1014C9E6DE6997BF9C602@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/kWPUJu56Yed5IHS0lZe6czdHXTc Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 07 Mar 2014 15:13:36 -0000 Patrik, Russ, Thanks for your clarifications. I'm sure there are things like the IDN stu= ff that I'm not aware of. Another thing I don't hear mentioned in this discussion is IRTF. I believe RFC2860 and supplements cover the IRTF as well. BTW, is it possible to publish the supplement to RFC2860 as an RFC? That would make it a lot cleaner and easier to reference. Chip On Mar 7, 2014, at 9:51 AM, Patrik F=E4ltstr=F6m wrote: > On 2014-03-07 12:58, Russ Housley wrote: >> Chip: >>=20 >>>> Question for clarification, is the Time Zone database operated under R= FC2860? I think so, but want to check. >> The Time Zone database does fall under RFC 2860, but it have a special s= et of policies that govern updates. Much is delegated; however, the IESG i= s the body that would handle an appeal if someone felt that the processes w= ere not being followed. >=20 > There are, I think, a few other parameters that are sort of "corner > cases", like "IDN Practices Repository" that IANA list under "Domain > Names" but if I understand > correctly is operated on direct request from ICANN (I might be > completely wrong here on how that registry was set up). >=20 > Patrik >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Fri Mar 7 23:53: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 CCE2E1A021A for ; Fri, 7 Mar 2014 23:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 4RobUgxaEaLF for ; Fri, 7 Mar 2014 23:53:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 956111A0238 for ; Fri, 7 Mar 2014 23:53:03 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.151.247]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s287qY0v010783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Mar 2014 23:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1394265167; bh=DCwTj6MbZ9DTVAO51Ml4q9a3/tufQKSgzr4lF7jXKaI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W7sssSLcQBRj5AKWuhgasbLMimHUM0GwF+dDKpL1hOdCFbxZ3mg+DOIWpX6Hb/JBn Z64DeINp8uGcvfWX7CaWpUYyIcArK2JAI6IDjOQ4Zx8e0R5ZCBSWOlMgzNVyeE+VGI xMQgKaRa2obL6oqq3RmwoxSTckK1vVUNiDMG+vc4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1394265167; i=@elandsys.com; bh=DCwTj6MbZ9DTVAO51Ml4q9a3/tufQKSgzr4lF7jXKaI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zQNuvadCS5IWQIFzZVZRscyjw3Zb1WAhW8tgcu0xH9xOb/eNbwDQEIil3cIwb1qXG BGjvK4hZDD9NVTMfL1oCh9iHS43dBTmjtVsftZ/TO43f35ggYpta4XBgQMSK7bZhYX Bkp6tezpLyXVaGL6MiU3tMQY1rWCIqcWDOiA0Vcc= Message-Id: <6.2.5.6.2.20140307233132.07d7de40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Mar 2014 23:50:29 -0800 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Russ Housley , "Chip Sharp (chsharp)" From: S Moonesamy In-Reply-To: <5319DCF6.9000600@frobbit.se> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> <68BD93CF-4767-4FBA-9E7A-F5B98D566513@vigilsec.com> <5319DCF6.9000600@frobbit.se> 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/hmP0S9PMMcARM7l7ziNUVPyopRc Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 08 Mar 2014 07:53:05 -0000 Hi Patrik, At 06:51 07-03-2014, Patrik F=E4ltstr=F6m wrote: >There are, I think, a few other parameters that are sort of "corner >cases", like "IDN Practices Repository" that IANA list under "Domain >Names" but if I understand >correctly is operated on direct request from ICANN (I might be >completely wrong here on how that registry was set up). It is not part of the IETF Protocol Parameter Registry. There is the "Special People Numbers Registry" (=20 http://www.iana.org/assignments/special-registry=20 ). It is mentioned that it is not operated by the IETF. Regards, S. Moonesamy From nobody Sat Mar 8 08:07: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 B20821A029C for ; Sat, 8 Mar 2014 08:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 yrgSfpWJd5Ma for ; Sat, 8 Mar 2014 08:07:00 -0800 (PST) Received: from nic-naa.net (abenaki.wabanaki.net [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0146F1A0297 for ; Sat, 8 Mar 2014 08:06:59 -0800 (PST) Received: from frog.local ([67.42.198.93]) by nic-naa.net (8.14.8/8.14.8) with ESMTP id s28G6Jpc055997 for ; Sat, 8 Mar 2014 11:06:34 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <531B3FF0.8060109@abenaki.wabanaki.net> Date: Sat, 08 Mar 2014 08:06:08 -0800 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <2BBB3E29-9405-48A1-B467-D7981ED7D040@cisco.com> <68BD93CF-4767-4FBA-9E7A-F5B98D566513@vigilsec.com> <5319DCF6.9000600@frobbit.se> <6.2.5.6.2.20140307233132.07d7de40@resistor.net> In-Reply-To: <6.2.5.6.2.20140307233132.07d7de40@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/95-n2Ps45dCWoj41oAbIfLB2oxE Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 08 Mar 2014 16:07:02 -0000 Had a recommendation of the of the IAB Character Set Workshop of April, 1997, "to create a research group to explore the open issues of character sets on the Internet " resulted in work product, or had the request of the authors of the tsconf draft been adopted (for intermediate tables) achieved "hum" in the affirmative sense resulting in work product, or similar, then there could be one or more entries in the IETF Protocol Parameter Registry corresponding to character sets. As others have noted, the IDN (in applications) Practices Repository arises from third-party acts. Eric On 3/7/14 11:50 PM, S Moonesamy wrote: > Hi Patrik, > At 06:51 07-03-2014, Patrik Fltstrm wrote: >> There are, I think, a few other parameters that are sort of "corner >> cases", like "IDN Practices Repository" that IANA list under "Domain >> Names" but if I understand >> correctly is operated on direct request from ICANN (I might be >> completely wrong here on how that registry was set up). > > It is not part of the IETF Protocol Parameter Registry. > > There is the "Special People Numbers Registry" ( > http://www.iana.org/assignments/special-registry ). It is mentioned > that it is not operated by the IETF. > > Regards, > S. Moonesamy > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > > From nobody Mon Mar 10 06:45: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 57A241A044A for ; Mon, 10 Mar 2014 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 3AQhhuV6vJp4 for ; Mon, 10 Mar 2014 06:45:27 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B0D961A0434 for ; Mon, 10 Mar 2014 06:45:27 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id to1so6916394ieb.6 for ; Mon, 10 Mar 2014 06:45:22 -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:content-type; bh=enYj93i0L4pEEo3LxxJCmczooyO577XPFdcC8TQ6vPw=; b=RpE6t8mdQQXyOzLPnG/glae/3LbI0oqb9VxGO8GuTl0rqKSIbYyGMFnP/XfCyrG99Q FKk6fKJtvrBRjczYyz0v+8kRg+q9uQkQ7Xz5kvJgmduINcFdAcmC/XEq7m2BgI3PD5YY cjUx/u7TL2ubOgf6BbjwWwi54H3Ho9rizgA3xeuKS7rsJqwWkKNRbrajPItqE/gq6fz+ oJ3PqECwYkjRpEUG+dX+TrOezpXm/DrYG1p6SBOrHG9cvombvfyDCWXgEY9Qmr3VbB7I uA/HhhadCxmOQaIURvEXXTgyIBryg5R2VeSvhgAdK73R80+1lXxakQZlYAfmJZGUtlT0 No6Q== MIME-Version: 1.0 X-Received: by 10.43.52.65 with SMTP id vl1mr638258icb.86.1394459122285; Mon, 10 Mar 2014 06:45:22 -0700 (PDT) Sender: sama.digitalpolicy@gmail.com Received: by 10.50.178.235 with HTTP; Mon, 10 Mar 2014 06:45:22 -0700 (PDT) Date: Mon, 10 Mar 2014 14:45:22 +0100 X-Google-Sender-Auth: L1wfV1QubiS_2S9C7iK8I5Kyhdo Message-ID: From: Andrea Glorioso To: "internetgovtech@iab.org" Content-Type: multipart/alternative; boundary=bcaec52e5f41a3446504f440d0a7 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/XkWw4n31LF_JI6r5_SxbBE1v05c Subject: [Internetgovtech] Contributions of the European Commission to the NETmundial 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: Mon, 10 Mar 2014 13:45:29 -0000 --bcaec52e5f41a3446504f440d0a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, of possible interest to the members of this list, the European Commission has submitted two contributions to the NETmundial meeting, which will take place on 23-24 April 2014 in Sao Paulo, Brazil. They are available at: =B7 Principles: http://content.netmundial.br/contribution/internet-governance-principles/17= 6 =B7 Roadmap: http://content.netmundial.br/contribution/roadmap-for-the-further-evolution= -of-the-internet-governance-ecosystem/177 Best regards, Andrea -- I speak only for myself. Sometimes I do not even agree with myself. Keep it in mind. Twitter: @andreaglorioso Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=3D1749288&trk=3Dtab_pro --bcaec52e5f41a3446504f440d0a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

of possible interest to the mem= bers of this=20 list, the European Commission has submitted two contributions to the=20 NETmundial meeting, which will take place on 23-24 April 2014 in Sao=20 Paulo, Brazil.

They are available at:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Principles: =A0=A0= =A0=A0=A0=A0=A0=A0=A0 http://content.netmundial.br/con= tribution/internet-governance-principles/176

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 Roadmap: =A0=A0=A0=A0=A0=A0=A0= =A0=A0 http://= content.netmundial.br/contribution/roadmap-for-the-further-evolution-of-the= -internet-governance-ecosystem/177


Best regards,

Andrea

--
I speak only for m= yself. Sometimes I do not even agree with myself. Keep it in mind.
Twitt= er: @andreaglorioso
Facebook: https://www.facebook.com/andrea.glorioso LinkedIn: http://www.linkedin.com/profile/view?id=3D= 1749288&trk=3Dtab_pro
--bcaec52e5f41a3446504f440d0a7-- From nobody Tue Mar 11 14:47: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 A79C61A081F for ; Tue, 11 Mar 2014 14:47:18 -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=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 fy4b2nAIW9Lf for ; Tue, 11 Mar 2014 14:47:16 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id D3E601A081D for ; Tue, 11 Mar 2014 14:47:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8C6D81E4039; Tue, 11 Mar 2014 14:46:10 -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 yb24_hc4KEF6; Tue, 11 Mar 2014 14:46:10 -0700 (PDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) by c8a.amsl.com (Postfix) with ESMTPSA id E63C01E12A8; Tue, 11 Mar 2014 14:46:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: IAB Chair In-Reply-To: Date: Tue, 11 Mar 2014 17:47:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> To: IETF Announce , internetgovtech@iab.org X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 11 Mar 2014 21:47:19 -0000 Existing IETF and IAB consensus concerning protocol parameter registry functions and IANA are documented in a variety of RFCs and IAB communications [RFC2860,RFC6220,IAB1,IAB2]. Since these functions and IANA are likely to be the subject of discussion in a number of venues outside the IETF over the coming months and years, the IAB sought community feedback about operating principles to use in these discussions. This note incorporates the comments from the mail list discussion and the IGOVUPDATE session at IETF 89. The IAB recognizes significant community support for these principles. Some of these principles might seem a bit generic, but it is difficult = to predict the nature of future discussions in which IETF and IAB leaders might find themselves, so generality helps in that regard. On behalf of the IAB, Russ Housley IAB Chair =3D =3D =3D =3D =3D =3D =3D =3D Principles Guiding the Evolution of the IANA Protocol Parameter = Registries These principles must be taken together. Ordering is not significant. 1. The IETF protocol parameter registry function has been and continues to be capably provided by the Internet technical community. The strength and stability of the function and its foundation within the Internet technical community are both important given how critical protocol parameters are to the proper functioning of IETF protocols. We think the structures that sustain the protocol parameter registry function needs be strong enough that they can be offered independently = by the Internet technical community, without the need for backing from external parties. And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made. 2. The protocol parameter registry function requires openness, transparency, and accountability. Existing documentation of how the function is administered and overseen is good [RFC2860,RFC6220]. Further articulation and clarity may be beneficial. It is important that the whole Internet community can understand how the function works, and that the processes for = registering parameters and holding those who oversee the protocol parameter function accountable for following those processes are understood by all interested parties. We are committed to making improvements here if necessary. 3. Any contemplated changes to the protocol parameter registry function should respect existing Internet community agreements. The protocol parameter registry is working well. The existing = Memorandum of Understanding [RFC2860] defines "the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force." Any modifications to the protocol parameter registry function should be made using the IETF process to update RFC 6220 and other relevant RFCs. Put quite simply: evolution, not revolution. 4. The Internet architecture requires and receives capable service by=20 Internet registries. The stability of the Internet depends on capable provision of not just IETF protocol parameters, but IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in standards development, = architectural guidance, and allocation of certain name/number parameters to continue. IP multicast addresses and special-use DNS names are two examples where close coordination is needed. The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. We fully understand the need to work together. 5. The IETF will continue management of the protocol parameter registry function as an integral component of the IETF standards process and the use of resulting protocols. RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. The IAB, on behalf of the IETF, has the responsibility to define and manage the relationship with the protocol registry operator role. This responsibility includes the selection and management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation. 6. The protocol parameters registries are provided as a public service. Directions for the creation of protocol parameter registries and the policies for subsequent additions and updates are specified in RFCs. The protocol parameters registries are available to everyone, and they are published in a form that allows their contents to be included in other works without further permission. These works include, but are not limited to, implementations of Internet protocols and their associated documentation. An important observation: The administration of the protocol parameter registry functions by ICANN is working well for the Internet and the IETF. We are pleased with the publication and maintenance of the protocol parameter registries and the coordination of the evaluation of registration requests through the IANA function provided by ICANN. [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt [RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt [IAB1] = http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-= final.pdf [IAB2] = http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf From nobody Wed Mar 12 13:01: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 C317A1A0473 for ; Wed, 12 Mar 2014 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 5w6Lnve5pZIZ for ; Wed, 12 Mar 2014 12:51:58 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 2DC701A0493 for ; Wed, 12 Mar 2014 12:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=6Xg7Bvl2OyMyjlZJyHudWPWXyVD/zcdCydHARz/mexA=; b=gJcFCHAw4jR3gt+Gh/TU7Xe0whZbbee5H6XbFKl6SILErEY0lUO7Ibhi1S1hDxYXiSWzlHtbO+gio s7yFcFxagjktvXhol5XR+V9X2v7nkcGaUwHYdTZXOgldzGrXdJyFQG/nJ1tM+f9whdV5StbXicORx6 IhTDex8iimYUAV68= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 13 Mar 2014 05:47:22 +1000 (EST) Received: from [192.168.100.144] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Mar 2014 05:51:43 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: Date: Thu, 13 Mar 2014 06:51:31 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> To: X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/azluu8SBPkntB0W8FV5Ap5kwaEo X-Mailman-Approved-At: Wed, 12 Mar 2014 13:01:04 -0700 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 19:52:01 -0000 Hi, In reading this was was interested to understand what changed from the = presentation at the ietf = (http://www.ietf.org/proceedings/89/slides/slides-89-igovupdate-0.pdf) = and what stayed (more or less) the same? So what follows below is my = take on the edits following the IETF session in order to understand how = the feedback from the meeting was incorporated into this announcement. Principle 6 is almost there, but I still find myself voicing a note of = dissent - in so far as it avoids mentioning copyright or any similar = term relating to intellectual property but instead states their = availability and the ability to include registry contents into other = works without permission. My concern rests in observations related to previous handovers of this = function in past times. Relating this to today, in my understanding were = the IAB to exercise its ability under RFC6220 and re-designate a = protocol parameter registry operator it is logically necessary for the = previous registry operator to cooperate and synchronise the movement of = registry to the new operator. It's hard to set this out this obligation = as a principle, but any observer of the first few months of operation of = Network Solutions taking over the registry role from the previous = operator back then in the early 90's would've been painfully aware of a = certain hiatus in service.=20 Now all this could be finessed (in my view) by a stronger statement in = principle 6 about the intellectual property of the contents of the = protocol parameter registries, and the principle that while the registry = operator is given license to modify these registries in line with the = directions from the IETF, the contents of these (modified) registries = remains the intellectual property of the IETF and not the property of = the registry operator.=20 But I have the sense that assertions of copyright and intellectual = property appear to be concepts that are too "strong" for this = enumeration of principles. Why is this? Kind regards, Geoff >=20 > Principles Guiding the Evolution of the IANA Protocol Parameter = Registries >=20 > These principles must be taken together. Ordering is not significant. >=20 > 1. The IETF protocol parameter registry function has been and = continues > to be capably provided by the Internet technical community. >=20 > The strength and stability of the function and its foundation within = the > Internet technical community are both important given how critical > protocol parameters are to the proper functioning of IETF protocols. >=20 > We think the structures that sustain the protocol parameter registry > function needs be strong enough that they can be offered independently = by > the Internet technical community, without the need for backing from > external parties. And we believe we largely are there already, = although > the system can be strengthened further, and continuous improvements = are > being made. >=20 unchanged removed: The administration of the protocol parameters function by ICANN is = working well for the Internet and the IETF. We are pleased with the publication and maintenance of the protocol = parameter function and the coordination of the evaluation of = registration requests through the IANA function provided by ICANN. > 2. The protocol parameter registry function requires openness, > transparency, and accountability. >=20 > Existing documentation of how the function is administered and = overseen > is good [RFC2860,RFC6220]. Further articulation and clarity may be > beneficial. It is important that the whole Internet community can > understand how the function works, and that the processes for = registering > parameters and holding those who oversee the protocol parameter = function > accountable for following those processes are understood by all > interested parties. We are committed to making improvements here if > necessary. unchanged >=20 > 3. Any contemplated changes to the protocol parameter registry = function > should respect existing Internet community agreements. (was: ... should use the current RFCs and model as the starting point.) >=20 > The protocol parameter registry is working well. The existing = Memorandum > of Understanding [RFC2860] defines "the technical work to be carried = out > by the Internet Assigned Numbers Authority on behalf of the Internet > Engineering Task Force and the Internet Research Task Force." Any > modifications to the protocol parameter registry function should be = made > using the IETF process to update RFC 6220 and other relevant RFCs. = Put > quite simply: evolution, not revolution. >=20 more or less the same > 4. The Internet architecture requires and receives capable service by=20= > Internet registries. >=20 > The stability of the Internet depends on capable provision of not just > IETF protocol parameters, but IP numbers, domain names, and other > registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined = protocols. > Thus we expect the role of the IETF in standards development, = architectural > guidance, and allocation of certain name/number parameters to = continue. > IP multicast addresses and special-use DNS names are two examples = where > close coordination is needed. The IETF will continue to coordinate = with > ICANN, the RIRs, and other parties that are mutually invested in the > continued smooth operation of the Internet registries. We fully > understand the need to work together. >=20 unchanged > 5. The IETF will continue management of the protocol parameter = registry > function as an integral component of the IETF standards process and = the > use of resulting protocols. change "its direction and stewardship" to "management" >=20 > RFC 6220 specifies the role and function of the protocol parameters > registry, which is critical to IETF standards processes and IETF > protocols. The IAB, on behalf of the IETF, has the responsibility to > define and manage the relationship with the protocol registry operator > role. This responsibility includes the selection and management of = the > protocol parameter registry operator, as well as management of the > parameter registration process and the guidelines for parameter > allocation. >=20 this is altered wording (used to read: "RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. We see no need to revisit or reconsider our current approach with regard to protocol parameters, including the ability to delegate operational responsibility for registries to other organizations."_ > 6. The protocol parameters registries are provided as a public = service. >=20 > Directions for the creation of protocol parameter registries and the > policies for subsequent additions and updates are specified in RFCs. > The protocol parameters registries are available to everyone, and they > are published in a form that allows their contents to be included in > other works without further permission. These works include, but are > not limited to, implementations of Internet protocols and their > associated documentation. >=20 unchanged > An important observation: The administration of the protocol parameter > registry functions by ICANN is working well for the Internet and the > IETF. We are pleased with the publication and maintenance of the > protocol parameter registries and the coordination of the evaluation = of > registration requests through the IANA function provided by ICANN. >=20 this was the second principle > [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt > [RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt > [IAB1] = http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-= final.pdf > [IAB2] = http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf >=20 From nobody Wed Mar 12 13:07:44 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 D86F51A0754 for ; Wed, 12 Mar 2014 13:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.547, 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 068_Dug1_Zii for ; Wed, 12 Mar 2014 13:07:39 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD81A0653 for ; Wed, 12 Mar 2014 13:07:39 -0700 (PDT) Received: from dummy.name; Wed, 12 Mar 2014 20:07:33 +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: <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> Date: Wed, 12 Mar 2014 16:07:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/eQOImpFWe-umTZje0_3Ih8-XtGU Cc: "Stephen D. Crocker" , internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 20:07:42 -0000 Geoff, et al, I made a statement in the igovupdate session and I=92ll reiterate here = in the spirit of using the list as the definitive record and not the = face to face session. ICANN has NO intellectual property interests in the material it = publishes. My understanding of copyright law is that copyright attaches = to the creator of content, irrespective of whether they register that = copyright. (There is utility in registering copyrights I am not enough = of expert to expound on those details, nor do I think they=92re relevant = to this discussion.) During the discussion in the igovupdate session I heard brief mention of = possible issues regarding various RFCs and registries over the years. = These pertained to various government agencies and others, but did not = involve ICANN. If the community desires a formal document saying what I=92ve said = above, I will personally shepherd it through our system. Let me address two other points, one that is mentioned below and one = that is entirely separate. I believe the scenario of moving the protocol parameter registries to = another operator has already been explored. I am given to understand = that the IETF has conducted exercises that mirror these registries. I = am not familiar with the details. The IAOC is probably the best group = to say more about this. In any case, I don=92t think would be = problematic and as a matter of good business practice we will cooperate = with any reasonable exercise or demonstration to provide that assurance. Something that occurred to me during the discussion which I have not = seen mentioned before is the following. All of us follow the principle = that the information created by the IETF is available to anyone, = anywhere, without cost. What would happen if the IETF changes its = position and requires IANA to either restrict its distribution of = information and/or charge for it? I think we=92d have to think = carefully about that. Would the IETF be willing to assert as part of = its principles that it won=92t do such a thing? Thanks, Steve Crocker Chair, ICANN Board of Directors On Mar 12, 2014, at 3:51 PM, Geoff Huston wrote: > Hi, >=20 > In reading this was was interested to understand what changed from the = presentation at the ietf = (http://www.ietf.org/proceedings/89/slides/slides-89-igovupdate-0.pdf) = and what stayed (more or less) the same? So what follows below is my = take on the edits following the IETF session in order to understand how = the feedback from the meeting was incorporated into this announcement. >=20 > Principle 6 is almost there, but I still find myself voicing a note of = dissent - in so far as it avoids mentioning copyright or any similar = term relating to intellectual property but instead states their = availability and the ability to include registry contents into other = works without permission. >=20 > My concern rests in observations related to previous handovers of this = function in past times. Relating this to today, in my understanding were = the IAB to exercise its ability under RFC6220 and re-designate a = protocol parameter registry operator it is logically necessary for the = previous registry operator to cooperate and synchronise the movement of = registry to the new operator. It's hard to set this out this obligation = as a principle, but any observer of the first few months of operation of = Network Solutions taking over the registry role from the previous = operator back then in the early 90's would've been painfully aware of a = certain hiatus in service.=20 >=20 > Now all this could be finessed (in my view) by a stronger statement in = principle 6 about the intellectual property of the contents of the = protocol parameter registries, and the principle that while the registry = operator is given license to modify these registries in line with the = directions from the IETF, the contents of these (modified) registries = remains the intellectual property of the IETF and not the property of = the registry operator.=20 >=20 > But I have the sense that assertions of copyright and intellectual = property appear to be concepts that are too "strong" for this = enumeration of principles. Why is this? >=20 > Kind regards, >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >>=20 >> Principles Guiding the Evolution of the IANA Protocol Parameter = Registries >>=20 >> These principles must be taken together. Ordering is not = significant. >>=20 >> 1. The IETF protocol parameter registry function has been and = continues >> to be capably provided by the Internet technical community. >>=20 >> The strength and stability of the function and its foundation within = the >> Internet technical community are both important given how critical >> protocol parameters are to the proper functioning of IETF protocols. >>=20 >> We think the structures that sustain the protocol parameter registry >> function needs be strong enough that they can be offered = independently by >> the Internet technical community, without the need for backing from >> external parties. And we believe we largely are there already, = although >> the system can be strengthened further, and continuous improvements = are >> being made. >>=20 >=20 > unchanged >=20 >=20 > removed: > The administration of the protocol parameters function by ICANN is = working well for the Internet and the IETF. >=20 > We are pleased with the publication and maintenance of the protocol = parameter function and the coordination of the evaluation of = registration requests through the IANA function provided by ICANN. >=20 >=20 >=20 >> 2. The protocol parameter registry function requires openness, >> transparency, and accountability. >>=20 >> Existing documentation of how the function is administered and = overseen >> is good [RFC2860,RFC6220]. Further articulation and clarity may be >> beneficial. It is important that the whole Internet community can >> understand how the function works, and that the processes for = registering >> parameters and holding those who oversee the protocol parameter = function >> accountable for following those processes are understood by all >> interested parties. We are committed to making improvements here if >> necessary. >=20 > unchanged >=20 >>=20 >> 3. Any contemplated changes to the protocol parameter registry = function >> should respect existing Internet community agreements. >=20 > (was: ... should use the current RFCs and model as the starting = point.) >=20 >>=20 >> The protocol parameter registry is working well. The existing = Memorandum >> of Understanding [RFC2860] defines "the technical work to be carried = out >> by the Internet Assigned Numbers Authority on behalf of the Internet >> Engineering Task Force and the Internet Research Task Force." Any >> modifications to the protocol parameter registry function should be = made >> using the IETF process to update RFC 6220 and other relevant RFCs. = Put >> quite simply: evolution, not revolution. >>=20 >=20 > more or less the same >=20 >=20 >> 4. The Internet architecture requires and receives capable service by=20= >> Internet registries. >>=20 >> The stability of the Internet depends on capable provision of not = just >> IETF protocol parameters, but IP numbers, domain names, and other >> registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined = protocols. >> Thus we expect the role of the IETF in standards development, = architectural >> guidance, and allocation of certain name/number parameters to = continue. >> IP multicast addresses and special-use DNS names are two examples = where >> close coordination is needed. The IETF will continue to coordinate = with >> ICANN, the RIRs, and other parties that are mutually invested in the >> continued smooth operation of the Internet registries. We fully >> understand the need to work together. >>=20 >=20 > unchanged >=20 >> 5. The IETF will continue management of the protocol parameter = registry >> function as an integral component of the IETF standards process and = the >> use of resulting protocols. >=20 > change "its direction and stewardship" to "management" >=20 >>=20 >> RFC 6220 specifies the role and function of the protocol parameters >> registry, which is critical to IETF standards processes and IETF >> protocols. The IAB, on behalf of the IETF, has the responsibility to >> define and manage the relationship with the protocol registry = operator >> role. This responsibility includes the selection and management of = the >> protocol parameter registry operator, as well as management of the >> parameter registration process and the guidelines for parameter >> allocation. >>=20 >=20 >=20 > this is altered wording >=20 > (used to read: "RFC 6220 specifies the role and function of the = protocol > parameters registry, which is critical to IETF standards processes > and IETF protocols. We see no need to revisit or reconsider our > current approach with regard to protocol parameters, including the > ability to delegate operational responsibility for registries to other > organizations."_ >=20 >=20 >=20 >> 6. The protocol parameters registries are provided as a public = service. >>=20 >> Directions for the creation of protocol parameter registries and the >> policies for subsequent additions and updates are specified in RFCs. >> The protocol parameters registries are available to everyone, and = they >> are published in a form that allows their contents to be included in >> other works without further permission. These works include, but are >> not limited to, implementations of Internet protocols and their >> associated documentation. >>=20 >=20 > unchanged >=20 >=20 >> An important observation: The administration of the protocol = parameter >> registry functions by ICANN is working well for the Internet and the >> IETF. We are pleased with the publication and maintenance of the >> protocol parameter registries and the coordination of the evaluation = of >> registration requests through the IANA function provided by ICANN. >>=20 >=20 > this was the second principle >=20 >> [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt >> [RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt >> [IAB1] = http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-= final.pdf >> [IAB2] = http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf >>=20 >=20 >=20 From nobody Wed Mar 12 13:51: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 8CEFD1A077C for ; Wed, 12 Mar 2014 13:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 Nt-Df2sLMeRd for ; Wed, 12 Mar 2014 13:51:02 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id AC4B01A0664 for ; Wed, 12 Mar 2014 13:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=sm5HwP+sQHUY7vuiCJy1RZ0M/dKe/IVQ+cwXsMzObZA=; b=tImhia0pepayu9urlFBDzRfzYmbYUDV9jr5pzLRYqCoGmMt1K6ZPt0/2Cca0H/+/y3zUBH/zeZxLf RswHz1mNgSm/Rxkw4fS4t8nC6H2uX5M1kBa/eRbNoIGAioonSj3nQul0/BL/WivcozyWqL41kj1T2s jpW7auodD+15Bwh8= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 13 Mar 2014 06:49:23 +1000 (EST) Received: from [192.168.100.144] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Mar 2014 06:50:49 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: Date: Thu, 13 Mar 2014 07:50:28 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> To: Steve Crocker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/6rMsSQ9hDKozZLpQ5DhkEtnWD2w Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 20:51:04 -0000 Hi Steve, Firstly I should reiterate that this is not about ICANN. I agree = wholeheartedly with the "important observation" in Russ's posting, and I = am very heartened to read your undertaking relating to ICANN having no = intellectual property interests in the material it publishes in this = role as protocol parameter registry operator. For me, it was very = welcome as a statement at the meeting, and equally welcome as a = statement here, and, while I can only speak personally, I would like to = sincerely extend my thanks for making this undertaking. My posting was not about the specific, but about the principle. I = believe it to be incumbent on the IETF to clearly state the principle, = namely that the operator of a protocol parameter registry is doing so at = the specific behest of the IETF, and as an agent of the IETF. All = intellectual property rights in the content of the registries remains = that of the IETF, and does not vest with the registry operator. This is = desire that I believe is entirely consistent with your undertaking that = ICANN as a protocol parameter registry operator makes no such claim, = however I suppose I am wanting this to be a principle that applies = generally. As to folk changing their mind in the future, its true that the future = is a constant source of surprise to us, and statements that include = terms such as "never" or "forever" are constantly being mocked by the = unfolding of time. But I don't think we need to cross every bridge here = - we can at best set forth our values and principles on the day and hope = that our successors at least consider what we were trying to achieve and = why we thought it to be important as they make their changes to suit = their world. These principles appear to be an earnest effort in that = direction. kind regards, Geoff On 13 Mar 2014, at 7:07 am, Steve Crocker wrote: > Geoff, et al, >=20 > I made a statement in the igovupdate session and I=92ll reiterate here = in the spirit of using the list as the definitive record and not the = face to face session. >=20 > ICANN has NO intellectual property interests in the material it = publishes. My understanding of copyright law is that copyright attaches = to the creator of content, irrespective of whether they register that = copyright. (There is utility in registering copyrights I am not enough = of expert to expound on those details, nor do I think they=92re relevant = to this discussion.) >=20 > During the discussion in the igovupdate session I heard brief mention = of possible issues regarding various RFCs and registries over the years. = These pertained to various government agencies and others, but did not = involve ICANN. >=20 > If the community desires a formal document saying what I=92ve said = above, I will personally shepherd it through our system. >=20 > Let me address two other points, one that is mentioned below and one = that is entirely separate. >=20 > I believe the scenario of moving the protocol parameter registries to = another operator has already been explored. I am given to understand = that the IETF has conducted exercises that mirror these registries. I = am not familiar with the details. The IAOC is probably the best group = to say more about this. In any case, I don=92t think would be = problematic and as a matter of good business practice we will cooperate = with any reasonable exercise or demonstration to provide that assurance. >=20 > Something that occurred to me during the discussion which I have not = seen mentioned before is the following. All of us follow the principle = that the information created by the IETF is available to anyone, = anywhere, without cost. What would happen if the IETF changes its = position and requires IANA to either restrict its distribution of = information and/or charge for it? I think we=92d have to think = carefully about that. Would the IETF be willing to assert as part of = its principles that it won=92t do such a thing? >=20 > Thanks, >=20 > Steve Crocker > Chair, ICANN Board of Directors >=20 From nobody Wed Mar 12 13:56: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 A6B621A0754 for ; Wed, 12 Mar 2014 13:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.547, 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 GMk2OQA9kaW1 for ; Wed, 12 Mar 2014 13:56:20 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8301A076A for ; Wed, 12 Mar 2014 13:56:16 -0700 (PDT) Received: from dummy.name; Wed, 12 Mar 2014 20:56:10 +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: <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> Date: Wed, 12 Mar 2014 16:56:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/7lmOVUi_cue_2cmv0lM2-lq_wq0 Cc: "Stephen D. Crocker" , internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 20:56:21 -0000 Geoff, Thanks. No argument. It was interesting to me as I was speaking during = the session and asserting that we have no claim to the intellectual = property that we (ICANN) might find ourselves having quite strong = feelings if we were told we had to implement restrictive policies. It=92s= not a scenario that, to my knowledge, has ever come up before, but I = think it fits into your general framework of espousing principles. Steve On Mar 12, 2014, at 4:50 PM, Geoff Huston wrote: > Hi Steve, >=20 > Firstly I should reiterate that this is not about ICANN. I agree = wholeheartedly with the "important observation" in Russ's posting, and I = am very heartened to read your undertaking relating to ICANN having no = intellectual property interests in the material it publishes in this = role as protocol parameter registry operator. For me, it was very = welcome as a statement at the meeting, and equally welcome as a = statement here, and, while I can only speak personally, I would like to = sincerely extend my thanks for making this undertaking. >=20 > My posting was not about the specific, but about the principle. I = believe it to be incumbent on the IETF to clearly state the principle, = namely that the operator of a protocol parameter registry is doing so at = the specific behest of the IETF, and as an agent of the IETF. All = intellectual property rights in the content of the registries remains = that of the IETF, and does not vest with the registry operator. This is = desire that I believe is entirely consistent with your undertaking that = ICANN as a protocol parameter registry operator makes no such claim, = however I suppose I am wanting this to be a principle that applies = generally. >=20 > As to folk changing their mind in the future, its true that the future = is a constant source of surprise to us, and statements that include = terms such as "never" or "forever" are constantly being mocked by the = unfolding of time. But I don't think we need to cross every bridge here = - we can at best set forth our values and principles on the day and hope = that our successors at least consider what we were trying to achieve and = why we thought it to be important as they make their changes to suit = their world. These principles appear to be an earnest effort in that = direction. >=20 > kind regards, >=20 > Geoff >=20 >=20 > On 13 Mar 2014, at 7:07 am, Steve Crocker wrote: >=20 >> Geoff, et al, >>=20 >> I made a statement in the igovupdate session and I=92ll reiterate = here in the spirit of using the list as the definitive record and not = the face to face session. >>=20 >> ICANN has NO intellectual property interests in the material it = publishes. My understanding of copyright law is that copyright attaches = to the creator of content, irrespective of whether they register that = copyright. (There is utility in registering copyrights I am not enough = of expert to expound on those details, nor do I think they=92re relevant = to this discussion.) >>=20 >> During the discussion in the igovupdate session I heard brief mention = of possible issues regarding various RFCs and registries over the years. = These pertained to various government agencies and others, but did not = involve ICANN. >>=20 >> If the community desires a formal document saying what I=92ve said = above, I will personally shepherd it through our system. >>=20 >> Let me address two other points, one that is mentioned below and one = that is entirely separate. >>=20 >> I believe the scenario of moving the protocol parameter registries to = another operator has already been explored. I am given to understand = that the IETF has conducted exercises that mirror these registries. I = am not familiar with the details. The IAOC is probably the best group = to say more about this. In any case, I don=92t think would be = problematic and as a matter of good business practice we will cooperate = with any reasonable exercise or demonstration to provide that assurance. >>=20 >> Something that occurred to me during the discussion which I have not = seen mentioned before is the following. All of us follow the principle = that the information created by the IETF is available to anyone, = anywhere, without cost. What would happen if the IETF changes its = position and requires IANA to either restrict its distribution of = information and/or charge for it? I think we=92d have to think = carefully about that. Would the IETF be willing to assert as part of = its principles that it won=92t do such a thing? >>=20 >> Thanks, >>=20 >> Steve Crocker >> Chair, ICANN Board of Directors >>=20 >=20 > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Wed Mar 12 14:14: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 41D641A078A for ; Wed, 12 Mar 2014 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 RWexBwe3bFR2 for ; Wed, 12 Mar 2014 14:13:59 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 235991A0784 for ; Wed, 12 Mar 2014 14:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1239; q=dns/txt; s=iport; t=1394658833; x=1395868433; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IBQp23Lb+Lkk6oRIOwYNPnOODGnr2suq2sbWDF9qQ/o=; b=hko8/dtEosbAVurMeFb8IzTn9DFYK06BF+k7LYvB+mVsbi50NLNUWrTc A8/AwaDzkgWYuXv0hNpW0Zc4RXmG80cj4EWBgqKV154jR2GLqq6PpO33C q2aD2EKqC9AIth8xGVg1LMV0b7dDbFSf9NOdPYfSN/G6fL/MapM2W+tB9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAJvNIFOQ/khN/2dsb2JhbABZgwaEGL5SgSAWdIIlAQEBAwEjVQEFCwsODAIFFgsCAgkDAgECASsaBgEMAQcBAYdtCLFKoUgXgSmMW1gHgm+BSQEDmEWSLYFvgT88gSw X-IronPort-AV: E=Sophos;i="4.97,641,1389744000"; d="scan'208";a="8572320" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 12 Mar 2014 21:13:52 +0000 Received: from mctiny.local ([10.61.222.48]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2CLDpGi032636; Wed, 12 Mar 2014 21:13:52 GMT Message-ID: <5320CE0F.1050003@cisco.com> Date: Wed, 12 Mar 2014 22:13:51 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Geoff Huston , Steve Crocker References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> In-Reply-To: <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> 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/gpT2m4AsDl2o86EsnVkAxQenYUg Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 21:14:03 -0000 Geoff, Thanks for your comments. so that we understand what we are talking about, here is the principle in question: > The protocol parameters registries are provided as a public service. > > Directions for the creation of protocol parameter registries and the > policies for subsequent additions and updates are specified in RFCs. > The protocol parameters registries are available to everyone, and they > are published in a form that allows their contents to be included in > other works without further permission. These works include, but are > not limited to, implementations of Internet protocols and their > associated documentation. Your specific complaint is that we mention neither copyright or trademark. To me those two legal points are implementation of the above principle. We should do what is necessary to see that the parameters are published so that all are free to use them. Whether that implies copyrights, trademarks, contracts, or what have you is for the lawyers to sort. What I like is that Steve is carrying forward in his words and actions this idea that anyone can access this stuff, a point that he worked with others to establish in the RFC series. That's leadership! Eliot From nobody Wed Mar 12 14:44: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 8FDE41A0733 for ; Wed, 12 Mar 2014 14:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 MVeoVnoQkx47 for ; Wed, 12 Mar 2014 14:44:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 531B41A076F for ; Wed, 12 Mar 2014 14:44:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CA4DF2CC95; Wed, 12 Mar 2014 23:44:30 +0200 (EET) 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 pYsXJ3GdL4P6; Wed, 12 Mar 2014 23:44:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 43C022CC48; Wed, 12 Mar 2014 23:44:30 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: <5320CE0F.1050003@cisco.com> Date: Wed, 12 Mar 2014 23:44:30 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0FE8AC7F-8331-4F41-8BF3-349A04BDFC91@piuha.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <5320CE0F.1050003@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/BWfn5Wjdo46BeYqtLh6LpCkfLyQ Cc: Steve Crocker , internetgovtech@iab.org, Geoff Huston , "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 21:44:42 -0000 > Your specific complaint is that we mention neither copyright or > trademark. To me those two legal points are implementation of the above > principle. This is how I read it as well. Jari From nobody Wed Mar 12 15:07: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 602341A0795 for ; Wed, 12 Mar 2014 15:03:09 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DPveJBkwcTVb for ; Wed, 12 Mar 2014 15:03:06 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE321A078D for ; Wed, 12 Mar 2014 15:03:06 -0700 (PDT) Received: from [85.158.137.99:60144] by server-3.bemta-3.messagelabs.com id 88/FE-05289-399D0235; Wed, 12 Mar 2014 22:02:59 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-217.messagelabs.com!1394661778!12370888!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6214 invoked from network); 12 Mar 2014 22:02:58 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 12 Mar 2014 22:02:58 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 12 Mar 2014 22:02:58 +0000 From: To: , Date: Wed, 12 Mar 2014 21:59:47 +0000 Thread-Topic: Guiding the Evolution of the IANA Protocol Parameter Registries Thread-Index: Ac8+NNpxeJWn/KrmTQiqC7rU6I9GTAACYdaI Message-ID: <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> , <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> In-Reply-To: <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/eQTyOX7twC2NREHboaweQBOkDsA X-Mailman-Approved-At: Wed, 12 Mar 2014 15:07:50 -0700 Cc: internetgovtech@iab.org, ietf@ietf.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 22:03:09 -0000 > All intellectual property rights in the content of the registries remains= that of the IETF, Since IETF is an ISOC activity, and ISOC is the organisation that will be i= nvolved in intellectual property disputes (see RFC2031) isn't that really I= SOC ownership? Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Geoff Huston [gih@apnic.net= ] Sent: 12 March 2014 20:50 To: Steve Crocker Cc: internetgovtech@iab.org; ietf@ietf.org Mailing List Subject: Re: Guiding the Evolution of the IANA Protocol Parameter Registrie= s Hi Steve, Firstly I should reiterate that this is not about ICANN. I agree wholeheart= edly with the "important observation" in Russ's posting, and I am very hear= tened to read your undertaking relating to ICANN having no intellectual pro= perty interests in the material it publishes in this role as protocol param= eter registry operator. For me, it was very welcome as a statement at the m= eeting, and equally welcome as a statement here, and, while I can only spea= k personally, I would like to sincerely extend my thanks for making this un= dertaking. My posting was not about the specific, but about the principle. I believe i= t to be incumbent on the IETF to clearly state the principle, namely that t= he operator of a protocol parameter registry is doing so at the specific be= hest of the IETF, and as an agent of the IETF. All intellectual property ri= ghts in the content of the registries remains that of the IETF, and does no= t vest with the registry operator. This is desire that I believe is entirel= y consistent with your undertaking that ICANN as a protocol parameter regis= try operator makes no such claim, however I suppose I am wanting this to be= a principle that applies generally. As to folk changing their mind in the future, its true that the future is a= constant source of surprise to us, and statements that include terms such = as "never" or "forever" are constantly being mocked by the unfolding of tim= e. But I don't think we need to cross every bridge here - we can at best se= t forth our values and principles on the day and hope that our successors a= t least consider what we were trying to achieve and why we thought it to be= important as they make their changes to suit their world. These principles= appear to be an earnest effort in that direction. kind regards, Geoff On 13 Mar 2014, at 7:07 am, Steve Crocker wrote: > Geoff, et al, > > I made a statement in the igovupdate session and I=92ll reiterate here in= the spirit of using the list as the definitive record and not the face to = face session. > > ICANN has NO intellectual property interests in the material it publishes= . My understanding of copyright law is that copyright attaches to the crea= tor of content, irrespective of whether they register that copyright. (The= re is utility in registering copyrights I am not enough of expert to expou= nd on those details, nor do I think they=92re relevant to this discussion.) > > During the discussion in the igovupdate session I heard brief mention of = possible issues regarding various RFCs and registries over the years. Thes= e pertained to various government agencies and others, but did not involve = ICANN. > > If the community desires a formal document saying what I=92ve said above,= I will personally shepherd it through our system. > > Let me address two other points, one that is mentioned below and one that= is entirely separate. > > I believe the scenario of moving the protocol parameter registries to ano= ther operator has already been explored. I am given to understand that the= IETF has conducted exercises that mirror these registries. I am not famil= iar with the details. The IAOC is probably the best group to say more abou= t this. In any case, I don=92t think would be problematic and as a matter = of good business practice we will cooperate with any reasonable exercise or= demonstration to provide that assurance. > > Something that occurred to me during the discussion which I have not seen= mentioned before is the following. All of us follow the principle that th= e information created by the IETF is available to anyone, anywhere, without= cost. What would happen if the IETF changes its position and requires IAN= A to either restrict its distribution of information and/or charge for it? = I think we=92d have to think carefully about that. Would the IETF be will= ing to assert as part of its principles that it won=92t do such a thing? > > Thanks, > > Steve Crocker > Chair, ICANN Board of Directors > From nobody Wed Mar 12 16:16: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 9BEFF1A07AD for ; Wed, 12 Mar 2014 16:16:41 -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 A2M9HFFbsJJf for ; Wed, 12 Mar 2014 16:16:37 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8AF1A07AF for ; Wed, 12 Mar 2014 16:16:36 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so175926wgh.35 for ; Wed, 12 Mar 2014 16:16: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=Y565p5KrmAqdc8y7vkjVpLaa40ZDe5/LDAp4uJA2M6w=; b=FFFVeECR8f5wH/JTyIszstSatfwos9Jd8SDaT9N/ognV8y3g9+8hwaYh6UafjH5RXp IVBkGFIelgvhJxMgJY6ZZa9e/+7rZsG7CXUsMkMwzqIdEkcj79whS99ap4JqeqWTfYPd ZiJeibY3apouITy9LC6u0PCK5Fbb6KI8NKSQAkeH/zYRCie74ebtq6cjG13ls1ct6uhu ueBDk3rJLu2PCc9ckBTjuZH1D3nfYy5UYHCLXYb4oL3Q5AOfYTJvhwuJYvSUywgDWYnv tcdgYPBWKkUi+vugZwPDjaCxOksg7TAxLQ2J4ByIBHeyKdevESPbDDqt6t7ed6R8RDnb nMjA== MIME-Version: 1.0 X-Received: by 10.180.72.239 with SMTP id g15mr9832798wiv.45.1394666189313; Wed, 12 Mar 2014 16:16:29 -0700 (PDT) Received: by 10.194.0.228 with HTTP; Wed, 12 Mar 2014 16:16:29 -0700 (PDT) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> Date: Thu, 13 Mar 2014 07:16:29 +0800 Message-ID: From: Pindar Wong To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=f46d043d6729cb5c7c04f471069b Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3OS-U1pdAxBxa09r1jo9yjqb-_k Cc: Steve Crocker , internetgovtech@iab.org, Geoff Huston , ietf@ietf.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 23:16:41 -0000 --f46d043d6729cb5c7c04f471069b Content-Type: text/plain; charset=ISO-8859-1 see http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf p. On Thu, Mar 13, 2014 at 5:59 AM, wrote: > > All intellectual property rights in the content of the registries > remains that of the IETF, > > Since IETF is an ISOC activity, and ISOC is the organisation that will be > involved in intellectual property disputes (see RFC2031) isn't that really > ISOC ownership? > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Geoff Huston [ > gih@apnic.net] > Sent: 12 March 2014 20:50 > To: Steve Crocker > Cc: internetgovtech@iab.org; ietf@ietf.org Mailing List > Subject: Re: Guiding the Evolution of the IANA Protocol Parameter > Registries > > Hi Steve, > > Firstly I should reiterate that this is not about ICANN. I agree > wholeheartedly with the "important observation" in Russ's posting, and I am > very heartened to read your undertaking relating to ICANN having no > intellectual property interests in the material it publishes in this role > as protocol parameter registry operator. For me, it was very welcome as a > statement at the meeting, and equally welcome as a statement here, and, > while I can only speak personally, I would like to sincerely extend my > thanks for making this undertaking. > > My posting was not about the specific, but about the principle. I believe > it to be incumbent on the IETF to clearly state the principle, namely that > the operator of a protocol parameter registry is doing so at the specific > behest of the IETF, and as an agent of the IETF. All intellectual property > rights in the content of the registries remains that of the IETF, and does > not vest with the registry operator. This is desire that I believe is > entirely consistent with your undertaking that ICANN as a protocol > parameter registry operator makes no such claim, however I suppose I am > wanting this to be a principle that applies generally. > > As to folk changing their mind in the future, its true that the future is > a constant source of surprise to us, and statements that include terms such > as "never" or "forever" are constantly being mocked by the unfolding of > time. But I don't think we need to cross every bridge here - we can at best > set forth our values and principles on the day and hope that our successors > at least consider what we were trying to achieve and why we thought it to > be important as they make their changes to suit their world. These > principles appear to be an earnest effort in that direction. > > kind regards, > > Geoff > > > On 13 Mar 2014, at 7:07 am, Steve Crocker wrote: > > > Geoff, et al, > > > > I made a statement in the igovupdate session and I'll reiterate here in > the spirit of using the list as the definitive record and not the face to > face session. > > > > ICANN has NO intellectual property interests in the material it > publishes. My understanding of copyright law is that copyright attaches to > the creator of content, irrespective of whether they register that > copyright. (There is utility in registering copyrights I am not enough of > expert to expound on those details, nor do I think they're relevant to this > discussion.) > > > > During the discussion in the igovupdate session I heard brief mention of > possible issues regarding various RFCs and registries over the years. > These pertained to various government agencies and others, but did not > involve ICANN. > > > > If the community desires a formal document saying what I've said above, > I will personally shepherd it through our system. > > > > Let me address two other points, one that is mentioned below and one > that is entirely separate. > > > > I believe the scenario of moving the protocol parameter registries to > another operator has already been explored. I am given to understand that > the IETF has conducted exercises that mirror these registries. I am not > familiar with the details. The IAOC is probably the best group to say more > about this. In any case, I don't think would be problematic and as a > matter of good business practice we will cooperate with any reasonable > exercise or demonstration to provide that assurance. > > > > Something that occurred to me during the discussion which I have not > seen mentioned before is the following. All of us follow the principle > that the information created by the IETF is available to anyone, anywhere, > without cost. What would happen if the IETF changes its position and > requires IANA to either restrict its distribution of information and/or > charge for it? I think we'd have to think carefully about that. Would the > IETF be willing to assert as part of its principles that it won't do such a > thing? > > > > Thanks, > > > > Steve Crocker > > Chair, ICANN Board of Directors > > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > --f46d043d6729cb5c7c04f471069b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 13, 2014 at 5:59 AM, <l.wood@surrey.ac.uk> wr= ote:
> All intellectual property rights in the content of the= registries remains that of the IETF,

Since IETF is an ISOC activity, and ISOC is the organisation that wil= l be involved in intellectual property disputes (see RFC2031) isn't tha= t really ISOC ownership?

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: ietf [ietf-bounces@ietf.org<= /a>] On Behalf Of Geoff Huston [gih@apnic.= net]
Sent: 12 March 2014 20:50
To: Steve Crocker
Cc: internetgovtech@iab.org;= ietf@ietf.org Mailing List
Subject: Re: Guiding the Evolution of the IANA Protocol Parameter Registrie= s

Hi Steve,

Firstly I should reiterate that this is not about ICANN. I agree wholeheart= edly with the "important observation" in Russ's posting, and = I am very heartened to read your undertaking relating to ICANN having no in= tellectual property interests in the material it publishes in this role as = protocol parameter registry operator. For me, it was very welcome as a stat= ement at the meeting, and equally welcome as a statement here, and, while I= can only speak personally, I would like to sincerely extend my thanks for = making this undertaking.

My posting was not about the specific, but about the principle. I believe i= t to be incumbent on the IETF to clearly state the principle, namely that t= he operator of a protocol parameter registry is doing so at the specific be= hest of the IETF, and as an agent of the IETF. All intellectual property ri= ghts in the content of the registries remains that of the IETF, and does no= t vest with the registry operator. This is desire that I believe is entirel= y consistent with your undertaking that ICANN as a protocol parameter regis= try operator makes no such claim, however I suppose I am wanting this to be= a principle that applies generally.

As to folk changing their mind in the future, its true that the future is a= constant source of surprise to us, and statements that include terms such = as "never" or "forever" are constantly being mocked by = the unfolding of time. But I don't think we need to cross every bridge = here - we can at best set forth our values and principles on the day and ho= pe that our successors at least consider what we were trying to achieve and= why we thought it to be important as they make their changes to suit their= world. These principles appear to be an earnest effort in that direction.<= br>
kind regards,

   Geoff


On 13 Mar 2014, at 7:07 am, Steve Crocker <steve@shinkuro.com> wrote:

> Geoff, et al,
>
> I made a statement in the igovupdate session and I’ll reiterate = here in the spirit of using the list as the definitive record and not the f= ace to face session.
>
> ICANN has NO intellectual property interests in the material it publis= hes.  My understanding of copyright law is that copyright attaches to = the creator of content, irrespective of whether they register that copyrigh= t.  (There is utility in registering copyrights  I am not enough = of expert to expound on those details, nor do I think they’re relevan= t to this discussion.)
>
> During the discussion in the igovupdate session I heard brief mention = of possible issues regarding various RFCs and registries over the years. &n= bsp;These pertained to various government agencies and others, but did not = involve ICANN.
>
> If the community desires a formal document saying what I’ve said= above, I will personally shepherd it through our system.
>
> Let me address two other points, one that is mentioned below and one t= hat is entirely separate.
>
> I believe the scenario of moving the protocol parameter registries to = another operator has already been explored.  I am given to understand = that the IETF has conducted exercises that mirror these registries.  I= am not familiar with the details.  The IAOC is probably the best grou= p to say more about this.  In any case, I don’t think would be p= roblematic and as a matter of good business practice we will cooperate with= any reasonable exercise or demonstration to provide that assurance.
>
> Something that occurred to me during the discussion which I have not s= een mentioned before is the following.  All of us follow the principle= that the information created by the IETF is available to anyone, anywhere,= without cost.  What would happen if the IETF changes its position and= requires IANA to either restrict its distribution of information and/or ch= arge for it?  I think we’d have to think carefully about that. &= nbsp;Would the IETF be willing to assert as part of its principles that it = won’t do such a thing?
>
> Thanks,
>
> Steve Crocker
> Chair, ICANN Board of Directors
>

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

--f46d043d6729cb5c7c04f471069b-- From nobody Wed Mar 12 16: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 8B25B1A07AE for ; Wed, 12 Mar 2014 16:42:20 -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_20=-0.001, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 VlmyqF968r91 for ; Wed, 12 Mar 2014 16:42:17 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id AC4891A02E6 for ; Wed, 12 Mar 2014 16:42:17 -0700 (PDT) Received: from 132.sub-70-192-223.myvzw.com ([70.192.223.132]:11044 helo=[10.162.0.201]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.82) (envelope-from ) id 1WNsmf-0004Dw-4q; Wed, 12 Mar 2014 16:42:05 -0700 Date: Wed, 12 Mar 2014 19:42:00 -0400 Message-ID: Importance: normal From: Eric Burger To: l.wood@surrey.ac.uk, gih@apnic.net, steve@shinkuro.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_70264554267460" 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/4GF8eBDpLl3mIFAdxbN2u72g3s0 Cc: internetgovtech@iab.org, ietf@ietf.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 12 Mar 2014 23:42:20 -0000 ----_com.android.email_70264554267460 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SUVURiBUcnVzdC4KCgpTZW50IGZyb20gbXkgbW9iaWxlIGRldmljZS4gVGhhbmtzIGJlIHRvIExF TU9OQURFOiBodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlClMyRVJD OiBodHRwOi8vczJlcmMuZ2VvcmdldG93bi5lZHUvCkdDU0M6IGh0dHA6Ly9nY3NjLmdlb3JnZXRv d24uZWR1LwpNZTogaHR0cDovL3d3dy5jcy5nZW9yZ2V0b3duLmVkdS9+IGVidXJnZXIKCi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogbC53b29kQHN1cnJleS5hYy51ayAK RGF0ZTowMy8xMi8yMDE0ICA1OjU5IFBNICAoR01ULTA1OjAwKSAKVG86IGdpaEBhcG5pYy5uZXQs c3RldmVAc2hpbmt1cm8uY29tIApDYzogaW50ZXJuZXRnb3Z0ZWNoQGlhYi5vcmcsaWV0ZkBpZXRm Lm9yZyAKU3ViamVjdDogUmU6IFtJbnRlcm5ldGdvdnRlY2hdIEd1aWRpbmcgdGhlIEV2b2x1dGlv biBvZiB0aGUgSUFOQSBQcm90b2NvbA0gCVBhcmFtZXRlciBSZWdpc3RyaWVzIAoKPiBBbGwgaW50 ZWxsZWN0dWFsIHByb3BlcnR5IHJpZ2h0cyBpbiB0aGUgY29udGVudCBvZiB0aGUgcmVnaXN0cmll cyByZW1haW5zIHRoYXQgb2YgdGhlIElFVEYsCgpTaW5jZSBJRVRGIGlzIGFuIElTT0MgYWN0aXZp dHksIGFuZCBJU09DIGlzIHRoZSBvcmdhbmlzYXRpb24gdGhhdCB3aWxsIGJlIGludm9sdmVkIGlu IGludGVsbGVjdHVhbCBwcm9wZXJ0eSBkaXNwdXRlcyAoc2VlIFJGQzIwMzEpIGlzbid0IHRoYXQg cmVhbGx5IElTT0Mgb3duZXJzaGlwPwoKTGxveWQgV29vZApodHRwOi8vYWJvdXQubWUvbGxveWR3 b29kCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogaWV0ZiBb aWV0Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvZmYgSHVzdG9uIFtnaWhAYXBu aWMubmV0XQpTZW50OiAxMiBNYXJjaCAyMDE0IDIwOjUwClRvOiBTdGV2ZSBDcm9ja2VyCkNjOiBp bnRlcm5ldGdvdnRlY2hAaWFiLm9yZzsgaWV0ZkBpZXRmLm9yZyBNYWlsaW5nIExpc3QKU3ViamVj dDogUmU6IEd1aWRpbmcgdGhlIEV2b2x1dGlvbiBvZiB0aGUgSUFOQSBQcm90b2NvbCBQYXJhbWV0 ZXIgUmVnaXN0cmllcwoKSGkgU3RldmUsCgpGaXJzdGx5IEkgc2hvdWxkIHJlaXRlcmF0ZSB0aGF0 IHRoaXMgaXMgbm90IGFib3V0IElDQU5OLiBJIGFncmVlIHdob2xlaGVhcnRlZGx5IHdpdGggdGhl ICJpbXBvcnRhbnQgb2JzZXJ2YXRpb24iIGluIFJ1c3MncyBwb3N0aW5nLCBhbmQgSSBhbSB2ZXJ5 IGhlYXJ0ZW5lZCB0byByZWFkIHlvdXIgdW5kZXJ0YWtpbmcgcmVsYXRpbmcgdG8gSUNBTk4gaGF2 aW5nIG5vIGludGVsbGVjdHVhbCBwcm9wZXJ0eSBpbnRlcmVzdHMgaW4gdGhlIG1hdGVyaWFsIGl0 IHB1Ymxpc2hlcyBpbiB0aGlzIHJvbGUgYXMgcHJvdG9jb2wgcGFyYW1ldGVyIHJlZ2lzdHJ5IG9w ZXJhdG9yLiBGb3IgbWUsIGl0IHdhcyB2ZXJ5IHdlbGNvbWUgYXMgYSBzdGF0ZW1lbnQgYXQgdGhl IG1lZXRpbmcsIGFuZCBlcXVhbGx5IHdlbGNvbWUgYXMgYSBzdGF0ZW1lbnQgaGVyZSwgYW5kLCB3 aGlsZSBJIGNhbiBvbmx5IHNwZWFrIHBlcnNvbmFsbHksIEkgd291bGQgbGlrZSB0byBzaW5jZXJl bHkgZXh0ZW5kIG15IHRoYW5rcyBmb3IgbWFraW5nIHRoaXMgdW5kZXJ0YWtpbmcuCgpNeSBwb3N0 aW5nIHdhcyBub3QgYWJvdXQgdGhlIHNwZWNpZmljLCBidXQgYWJvdXQgdGhlIHByaW5jaXBsZS4g SSBiZWxpZXZlIGl0IHRvIGJlIGluY3VtYmVudCBvbiB0aGUgSUVURiB0byBjbGVhcmx5IHN0YXRl IHRoZSBwcmluY2lwbGUsIG5hbWVseSB0aGF0IHRoZSBvcGVyYXRvciBvZiBhIHByb3RvY29sIHBh cmFtZXRlciByZWdpc3RyeSBpcyBkb2luZyBzbyBhdCB0aGUgc3BlY2lmaWMgYmVoZXN0IG9mIHRo ZSBJRVRGLCBhbmQgYXMgYW4gYWdlbnQgb2YgdGhlIElFVEYuIEFsbCBpbnRlbGxlY3R1YWwgcHJv cGVydHkgcmlnaHRzIGluIHRoZSBjb250ZW50IG9mIHRoZSByZWdpc3RyaWVzIHJlbWFpbnMgdGhh dCBvZiB0aGUgSUVURiwgYW5kIGRvZXMgbm90IHZlc3Qgd2l0aCB0aGUgcmVnaXN0cnkgb3BlcmF0 b3IuIFRoaXMgaXMgZGVzaXJlIHRoYXQgSSBiZWxpZXZlIGlzIGVudGlyZWx5IGNvbnNpc3RlbnQg d2l0aCB5b3VyIHVuZGVydGFraW5nIHRoYXQgSUNBTk4gYXMgYSBwcm90b2NvbCBwYXJhbWV0ZXIg cmVnaXN0cnkgb3BlcmF0b3IgbWFrZXMgbm8gc3VjaCBjbGFpbSwgaG93ZXZlciBJIHN1cHBvc2Ug SSBhbSB3YW50aW5nIHRoaXMgdG8gYmUgYSBwcmluY2lwbGUgdGhhdCBhcHBsaWVzIGdlbmVyYWxs eS4KCkFzIHRvIGZvbGsgY2hhbmdpbmcgdGhlaXIgbWluZCBpbiB0aGUgZnV0dXJlLCBpdHMgdHJ1 ZSB0aGF0IHRoZSBmdXR1cmUgaXMgYSBjb25zdGFudCBzb3VyY2Ugb2Ygc3VycHJpc2UgdG8gdXMs IGFuZCBzdGF0ZW1lbnRzIHRoYXQgaW5jbHVkZSB0ZXJtcyBzdWNoIGFzICJuZXZlciIgb3IgImZv cmV2ZXIiIGFyZSBjb25zdGFudGx5IGJlaW5nIG1vY2tlZCBieSB0aGUgdW5mb2xkaW5nIG9mIHRp bWUuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gY3Jvc3MgZXZlcnkgYnJpZGdlIGhlcmUg LSB3ZSBjYW4gYXQgYmVzdCBzZXQgZm9ydGggb3VyIHZhbHVlcyBhbmQgcHJpbmNpcGxlcyBvbiB0 aGUgZGF5IGFuZCBob3BlIHRoYXQgb3VyIHN1Y2Nlc3NvcnMgYXQgbGVhc3QgY29uc2lkZXIgd2hh dCB3ZSB3ZXJlIHRyeWluZyB0byBhY2hpZXZlIGFuZCB3aHkgd2UgdGhvdWdodCBpdCB0byBiZSBp bXBvcnRhbnQgYXMgdGhleSBtYWtlIHRoZWlyIGNoYW5nZXMgdG8gc3VpdCB0aGVpciB3b3JsZC4g VGhlc2UgcHJpbmNpcGxlcyBhcHBlYXIgdG8gYmUgYW4gZWFybmVzdCBlZmZvcnQgaW4gdGhhdCBk aXJlY3Rpb24uCgpraW5kIHJlZ2FyZHMsCgrCoMKgIEdlb2ZmCgoKT24gMTMgTWFyIDIwMTQsIGF0 IDc6MDcgYW0sIFN0ZXZlIENyb2NrZXIgPHN0ZXZlQHNoaW5rdXJvLmNvbT4gd3JvdGU6Cgo+IEdl b2ZmLCBldCBhbCwKPgo+IEkgbWFkZSBhIHN0YXRlbWVudCBpbiB0aGUgaWdvdnVwZGF0ZSBzZXNz aW9uIGFuZCBJ4oCZbGwgcmVpdGVyYXRlIGhlcmUgaW4gdGhlIHNwaXJpdCBvZiB1c2luZyB0aGUg bGlzdCBhcyB0aGUgZGVmaW5pdGl2ZSByZWNvcmQgYW5kIG5vdCB0aGUgZmFjZSB0byBmYWNlIHNl c3Npb24uCj4KPiBJQ0FOTiBoYXMgTk8gaW50ZWxsZWN0dWFsIHByb3BlcnR5IGludGVyZXN0cyBp biB0aGUgbWF0ZXJpYWwgaXQgcHVibGlzaGVzLsKgIE15IHVuZGVyc3RhbmRpbmcgb2YgY29weXJp Z2h0IGxhdyBpcyB0aGF0IGNvcHlyaWdodCBhdHRhY2hlcyB0byB0aGUgY3JlYXRvciBvZiBjb250 ZW50LCBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciB0aGV5IHJlZ2lzdGVyIHRoYXQgY29weXJpZ2h0 LsKgIChUaGVyZSBpcyB1dGlsaXR5IGluIHJlZ2lzdGVyaW5nIGNvcHlyaWdodHPCoCBJIGFtIG5v dCBlbm91Z2ggb2YgZXhwZXJ0IHRvIGV4cG91bmQgb24gdGhvc2UgZGV0YWlscywgbm9yIGRvIEkg dGhpbmsgdGhleeKAmXJlIHJlbGV2YW50IHRvIHRoaXMgZGlzY3Vzc2lvbi4pCj4KPiBEdXJpbmcg dGhlIGRpc2N1c3Npb24gaW4gdGhlIGlnb3Z1cGRhdGUgc2Vzc2lvbiBJIGhlYXJkIGJyaWVmIG1l bnRpb24gb2YgcG9zc2libGUgaXNzdWVzIHJlZ2FyZGluZyB2YXJpb3VzIFJGQ3MgYW5kIHJlZ2lz dHJpZXMgb3ZlciB0aGUgeWVhcnMuwqAgVGhlc2UgcGVydGFpbmVkIHRvIHZhcmlvdXMgZ292ZXJu bWVudCBhZ2VuY2llcyBhbmQgb3RoZXJzLCBidXQgZGlkIG5vdCBpbnZvbHZlIElDQU5OLgo+Cj4g SWYgdGhlIGNvbW11bml0eSBkZXNpcmVzIGEgZm9ybWFsIGRvY3VtZW50IHNheWluZyB3aGF0IEni gJl2ZSBzYWlkIGFib3ZlLCBJIHdpbGwgcGVyc29uYWxseSBzaGVwaGVyZCBpdCB0aHJvdWdoIG91 ciBzeXN0ZW0uCj4KPiBMZXQgbWUgYWRkcmVzcyB0d28gb3RoZXIgcG9pbnRzLCBvbmUgdGhhdCBp cyBtZW50aW9uZWQgYmVsb3cgYW5kIG9uZSB0aGF0IGlzIGVudGlyZWx5IHNlcGFyYXRlLgo+Cj4g SSBiZWxpZXZlIHRoZSBzY2VuYXJpbyBvZiBtb3ZpbmcgdGhlIHByb3RvY29sIHBhcmFtZXRlciBy ZWdpc3RyaWVzIHRvIGFub3RoZXIgb3BlcmF0b3IgaGFzIGFscmVhZHkgYmVlbiBleHBsb3JlZC7C oCBJIGFtIGdpdmVuIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUgSUVURiBoYXMgY29uZHVjdGVkIGV4 ZXJjaXNlcyB0aGF0IG1pcnJvciB0aGVzZSByZWdpc3RyaWVzLsKgIEkgYW0gbm90IGZhbWlsaWFy IHdpdGggdGhlIGRldGFpbHMuwqAgVGhlIElBT0MgaXMgcHJvYmFibHkgdGhlIGJlc3QgZ3JvdXAg dG8gc2F5IG1vcmUgYWJvdXQgdGhpcy7CoCBJbiBhbnkgY2FzZSwgSSBkb27igJl0IHRoaW5rIHdv dWxkIGJlIHByb2JsZW1hdGljIGFuZCBhcyBhIG1hdHRlciBvZiBnb29kIGJ1c2luZXNzIHByYWN0 aWNlIHdlIHdpbGwgY29vcGVyYXRlIHdpdGggYW55IHJlYXNvbmFibGUgZXhlcmNpc2Ugb3IgZGVt b25zdHJhdGlvbiB0byBwcm92aWRlIHRoYXQgYXNzdXJhbmNlLgo+Cj4gU29tZXRoaW5nIHRoYXQg b2NjdXJyZWQgdG8gbWUgZHVyaW5nIHRoZSBkaXNjdXNzaW9uIHdoaWNoIEkgaGF2ZSBub3Qgc2Vl biBtZW50aW9uZWQgYmVmb3JlIGlzIHRoZSBmb2xsb3dpbmcuwqAgQWxsIG9mIHVzIGZvbGxvdyB0 aGUgcHJpbmNpcGxlIHRoYXQgdGhlIGluZm9ybWF0aW9uIGNyZWF0ZWQgYnkgdGhlIElFVEYgaXMg YXZhaWxhYmxlIHRvIGFueW9uZSwgYW55d2hlcmUsIHdpdGhvdXQgY29zdC7CoCBXaGF0IHdvdWxk IGhhcHBlbiBpZiB0aGUgSUVURiBjaGFuZ2VzIGl0cyBwb3NpdGlvbiBhbmQgcmVxdWlyZXMgSUFO QSB0byBlaXRoZXIgcmVzdHJpY3QgaXRzIGRpc3RyaWJ1dGlvbiBvZiBpbmZvcm1hdGlvbiBhbmQv b3IgY2hhcmdlIGZvciBpdD/CoCBJIHRoaW5rIHdl4oCZZCBoYXZlIHRvIHRoaW5rIGNhcmVmdWxs eSBhYm91dCB0aGF0LsKgIFdvdWxkIHRoZSBJRVRGIGJlIHdpbGxpbmcgdG8gYXNzZXJ0IGFzIHBh cnQgb2YgaXRzIHByaW5jaXBsZXMgdGhhdCBpdCB3b27igJl0IGRvIHN1Y2ggYSB0aGluZz8KPgo+ IFRoYW5rcywKPgo+IFN0ZXZlIENyb2NrZXIKPiBDaGFpciwgSUNBTk4gQm9hcmQgb2YgRGlyZWN0 b3JzCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCklu dGVybmV0Z292dGVjaCBtYWlsaW5nIGxpc3QKSW50ZXJuZXRnb3Z0ZWNoQGlhYi5vcmcKaHR0cHM6 Ly93d3cuaWFiLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVybmV0Z292dGVjaAo= ----_com.android.email_70264554267460 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5JRVRGIFRydXN0LjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PlNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNl LiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2ll dGYvbGVtb25hZGU8ZGl2PlMyRVJDOiBodHRwOi8vczJlcmMuZ2VvcmdldG93bi5lZHUvPC9kaXY+ PGRpdj5HQ1NDOiBodHRwOi8vZ2NzYy5nZW9yZ2V0b3duLmVkdS88L2Rpdj48ZGl2Pk1lOiBodHRw Oi8vd3d3LmNzLmdlb3JnZXRvd24uZWR1L34gZWJ1cmdlcjwvZGl2Pjxicj48YnI+LS0tLS0tLS0g T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5Gcm9tOiBsLndvb2RAc3VycmV5LmFjLnVrIDxi cj5EYXRlOjAzLzEyLzIwMTQgIDU6NTkgUE0gIChHTVQtMDU6MDApIDxicj5UbzogZ2loQGFwbmlj Lm5ldCxzdGV2ZUBzaGlua3Vyby5jb20gPGJyPkNjOiBpbnRlcm5ldGdvdnRlY2hAaWFiLm9yZyxp ZXRmQGlldGYub3JnIDxicj5TdWJqZWN0OiBSZTogW0ludGVybmV0Z292dGVjaF0gR3VpZGluZyB0 aGUgRXZvbHV0aW9uIG9mIHRoZSBJQU5BIFByb3RvY29sDSAJUGFyYW1ldGVyIFJlZ2lzdHJpZXMg PGJyPjxicj4mZ3Q7IEFsbCBpbnRlbGxlY3R1YWwgcHJvcGVydHkgcmlnaHRzIGluIHRoZSBjb250 ZW50IG9mIHRoZSByZWdpc3RyaWVzIHJlbWFpbnMgdGhhdCBvZiB0aGUgSUVURiw8YnI+PGJyPlNp bmNlIElFVEYgaXMgYW4gSVNPQyBhY3Rpdml0eSwgYW5kIElTT0MgaXMgdGhlIG9yZ2FuaXNhdGlv biB0aGF0IHdpbGwgYmUgaW52b2x2ZWQgaW4gaW50ZWxsZWN0dWFsIHByb3BlcnR5IGRpc3B1dGVz IChzZWUgUkZDMjAzMSkgaXNuJ3QgdGhhdCByZWFsbHkgSVNPQyBvd25lcnNoaXA/PGJyPjxicj5M bG95ZCBXb29kPGJyPmh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2Q8YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5Gcm9tOiBpZXRmIFtpZXRmLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW9mZiBIdXN0b24gW2dpaEBhcG5pYy5uZXRdPGJyPlNlbnQ6 IDEyIE1hcmNoIDIwMTQgMjA6NTA8YnI+VG86IFN0ZXZlIENyb2NrZXI8YnI+Q2M6IGludGVybmV0 Z292dGVjaEBpYWIub3JnOyBpZXRmQGlldGYub3JnIE1haWxpbmcgTGlzdDxicj5TdWJqZWN0OiBS ZTogR3VpZGluZyB0aGUgRXZvbHV0aW9uIG9mIHRoZSBJQU5BIFByb3RvY29sIFBhcmFtZXRlciBS ZWdpc3RyaWVzPGJyPjxicj5IaSBTdGV2ZSw8YnI+PGJyPkZpcnN0bHkgSSBzaG91bGQgcmVpdGVy YXRlIHRoYXQgdGhpcyBpcyBub3QgYWJvdXQgSUNBTk4uIEkgYWdyZWUgd2hvbGVoZWFydGVkbHkg d2l0aCB0aGUgImltcG9ydGFudCBvYnNlcnZhdGlvbiIgaW4gUnVzcydzIHBvc3RpbmcsIGFuZCBJ IGFtIHZlcnkgaGVhcnRlbmVkIHRvIHJlYWQgeW91ciB1bmRlcnRha2luZyByZWxhdGluZyB0byBJ Q0FOTiBoYXZpbmcgbm8gaW50ZWxsZWN0dWFsIHByb3BlcnR5IGludGVyZXN0cyBpbiB0aGUgbWF0 ZXJpYWwgaXQgcHVibGlzaGVzIGluIHRoaXMgcm9sZSBhcyBwcm90b2NvbCBwYXJhbWV0ZXIgcmVn aXN0cnkgb3BlcmF0b3IuIEZvciBtZSwgaXQgd2FzIHZlcnkgd2VsY29tZSBhcyBhIHN0YXRlbWVu dCBhdCB0aGUgbWVldGluZywgYW5kIGVxdWFsbHkgd2VsY29tZSBhcyBhIHN0YXRlbWVudCBoZXJl LCBhbmQsIHdoaWxlIEkgY2FuIG9ubHkgc3BlYWsgcGVyc29uYWxseSwgSSB3b3VsZCBsaWtlIHRv IHNpbmNlcmVseSBleHRlbmQgbXkgdGhhbmtzIGZvciBtYWtpbmcgdGhpcyB1bmRlcnRha2luZy48 YnI+PGJyPk15IHBvc3Rpbmcgd2FzIG5vdCBhYm91dCB0aGUgc3BlY2lmaWMsIGJ1dCBhYm91dCB0 aGUgcHJpbmNpcGxlLiBJIGJlbGlldmUgaXQgdG8gYmUgaW5jdW1iZW50IG9uIHRoZSBJRVRGIHRv IGNsZWFybHkgc3RhdGUgdGhlIHByaW5jaXBsZSwgbmFtZWx5IHRoYXQgdGhlIG9wZXJhdG9yIG9m IGEgcHJvdG9jb2wgcGFyYW1ldGVyIHJlZ2lzdHJ5IGlzIGRvaW5nIHNvIGF0IHRoZSBzcGVjaWZp YyBiZWhlc3Qgb2YgdGhlIElFVEYsIGFuZCBhcyBhbiBhZ2VudCBvZiB0aGUgSUVURi4gQWxsIGlu dGVsbGVjdHVhbCBwcm9wZXJ0eSByaWdodHMgaW4gdGhlIGNvbnRlbnQgb2YgdGhlIHJlZ2lzdHJp ZXMgcmVtYWlucyB0aGF0IG9mIHRoZSBJRVRGLCBhbmQgZG9lcyBub3QgdmVzdCB3aXRoIHRoZSBy ZWdpc3RyeSBvcGVyYXRvci4gVGhpcyBpcyBkZXNpcmUgdGhhdCBJIGJlbGlldmUgaXMgZW50aXJl bHkgY29uc2lzdGVudCB3aXRoIHlvdXIgdW5kZXJ0YWtpbmcgdGhhdCBJQ0FOTiBhcyBhIHByb3Rv Y29sIHBhcmFtZXRlciByZWdpc3RyeSBvcGVyYXRvciBtYWtlcyBubyBzdWNoIGNsYWltLCBob3dl dmVyIEkgc3VwcG9zZSBJIGFtIHdhbnRpbmcgdGhpcyB0byBiZSBhIHByaW5jaXBsZSB0aGF0IGFw cGxpZXMgZ2VuZXJhbGx5Ljxicj48YnI+QXMgdG8gZm9sayBjaGFuZ2luZyB0aGVpciBtaW5kIGlu IHRoZSBmdXR1cmUsIGl0cyB0cnVlIHRoYXQgdGhlIGZ1dHVyZSBpcyBhIGNvbnN0YW50IHNvdXJj ZSBvZiBzdXJwcmlzZSB0byB1cywgYW5kIHN0YXRlbWVudHMgdGhhdCBpbmNsdWRlIHRlcm1zIHN1 Y2ggYXMgIm5ldmVyIiBvciAiZm9yZXZlciIgYXJlIGNvbnN0YW50bHkgYmVpbmcgbW9ja2VkIGJ5 IHRoZSB1bmZvbGRpbmcgb2YgdGltZS4gQnV0IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBjcm9z cyBldmVyeSBicmlkZ2UgaGVyZSAtIHdlIGNhbiBhdCBiZXN0IHNldCBmb3J0aCBvdXIgdmFsdWVz IGFuZCBwcmluY2lwbGVzIG9uIHRoZSBkYXkgYW5kIGhvcGUgdGhhdCBvdXIgc3VjY2Vzc29ycyBh dCBsZWFzdCBjb25zaWRlciB3aGF0IHdlIHdlcmUgdHJ5aW5nIHRvIGFjaGlldmUgYW5kIHdoeSB3 ZSB0aG91Z2h0IGl0IHRvIGJlIGltcG9ydGFudCBhcyB0aGV5IG1ha2UgdGhlaXIgY2hhbmdlcyB0 byBzdWl0IHRoZWlyIHdvcmxkLiBUaGVzZSBwcmluY2lwbGVzIGFwcGVhciB0byBiZSBhbiBlYXJu ZXN0IGVmZm9ydCBpbiB0aGF0IGRpcmVjdGlvbi48YnI+PGJyPmtpbmQgcmVnYXJkcyw8YnI+PGJy PiZuYnNwOyZuYnNwOyBHZW9mZjxicj48YnI+PGJyPk9uIDEzIE1hciAyMDE0LCBhdCA3OjA3IGFt LCBTdGV2ZSBDcm9ja2VyICZsdDtzdGV2ZUBzaGlua3Vyby5jb20mZ3Q7IHdyb3RlOjxicj48YnI+ Jmd0OyBHZW9mZiwgZXQgYWwsPGJyPiZndDs8YnI+Jmd0OyBJIG1hZGUgYSBzdGF0ZW1lbnQgaW4g dGhlIGlnb3Z1cGRhdGUgc2Vzc2lvbiBhbmQgSeKAmWxsIHJlaXRlcmF0ZSBoZXJlIGluIHRoZSBz cGlyaXQgb2YgdXNpbmcgdGhlIGxpc3QgYXMgdGhlIGRlZmluaXRpdmUgcmVjb3JkIGFuZCBub3Qg dGhlIGZhY2UgdG8gZmFjZSBzZXNzaW9uLjxicj4mZ3Q7PGJyPiZndDsgSUNBTk4gaGFzIE5PIGlu dGVsbGVjdHVhbCBwcm9wZXJ0eSBpbnRlcmVzdHMgaW4gdGhlIG1hdGVyaWFsIGl0IHB1Ymxpc2hl cy4mbmJzcDsgTXkgdW5kZXJzdGFuZGluZyBvZiBjb3B5cmlnaHQgbGF3IGlzIHRoYXQgY29weXJp Z2h0IGF0dGFjaGVzIHRvIHRoZSBjcmVhdG9yIG9mIGNvbnRlbnQsIGlycmVzcGVjdGl2ZSBvZiB3 aGV0aGVyIHRoZXkgcmVnaXN0ZXIgdGhhdCBjb3B5cmlnaHQuJm5ic3A7IChUaGVyZSBpcyB1dGls aXR5IGluIHJlZ2lzdGVyaW5nIGNvcHlyaWdodHMmbmJzcDsgSSBhbSBub3QgZW5vdWdoIG9mIGV4 cGVydCB0byBleHBvdW5kIG9uIHRob3NlIGRldGFpbHMsIG5vciBkbyBJIHRoaW5rIHRoZXnigJly ZSByZWxldmFudCB0byB0aGlzIGRpc2N1c3Npb24uKTxicj4mZ3Q7PGJyPiZndDsgRHVyaW5nIHRo ZSBkaXNjdXNzaW9uIGluIHRoZSBpZ292dXBkYXRlIHNlc3Npb24gSSBoZWFyZCBicmllZiBtZW50 aW9uIG9mIHBvc3NpYmxlIGlzc3VlcyByZWdhcmRpbmcgdmFyaW91cyBSRkNzIGFuZCByZWdpc3Ry aWVzIG92ZXIgdGhlIHllYXJzLiZuYnNwOyBUaGVzZSBwZXJ0YWluZWQgdG8gdmFyaW91cyBnb3Zl cm5tZW50IGFnZW5jaWVzIGFuZCBvdGhlcnMsIGJ1dCBkaWQgbm90IGludm9sdmUgSUNBTk4uPGJy PiZndDs8YnI+Jmd0OyBJZiB0aGUgY29tbXVuaXR5IGRlc2lyZXMgYSBmb3JtYWwgZG9jdW1lbnQg c2F5aW5nIHdoYXQgSeKAmXZlIHNhaWQgYWJvdmUsIEkgd2lsbCBwZXJzb25hbGx5IHNoZXBoZXJk IGl0IHRocm91Z2ggb3VyIHN5c3RlbS48YnI+Jmd0Ozxicj4mZ3Q7IExldCBtZSBhZGRyZXNzIHR3 byBvdGhlciBwb2ludHMsIG9uZSB0aGF0IGlzIG1lbnRpb25lZCBiZWxvdyBhbmQgb25lIHRoYXQg aXMgZW50aXJlbHkgc2VwYXJhdGUuPGJyPiZndDs8YnI+Jmd0OyBJIGJlbGlldmUgdGhlIHNjZW5h cmlvIG9mIG1vdmluZyB0aGUgcHJvdG9jb2wgcGFyYW1ldGVyIHJlZ2lzdHJpZXMgdG8gYW5vdGhl ciBvcGVyYXRvciBoYXMgYWxyZWFkeSBiZWVuIGV4cGxvcmVkLiZuYnNwOyBJIGFtIGdpdmVuIHRv IHVuZGVyc3RhbmQgdGhhdCB0aGUgSUVURiBoYXMgY29uZHVjdGVkIGV4ZXJjaXNlcyB0aGF0IG1p cnJvciB0aGVzZSByZWdpc3RyaWVzLiZuYnNwOyBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBk ZXRhaWxzLiZuYnNwOyBUaGUgSUFPQyBpcyBwcm9iYWJseSB0aGUgYmVzdCBncm91cCB0byBzYXkg bW9yZSBhYm91dCB0aGlzLiZuYnNwOyBJbiBhbnkgY2FzZSwgSSBkb27igJl0IHRoaW5rIHdvdWxk IGJlIHByb2JsZW1hdGljIGFuZCBhcyBhIG1hdHRlciBvZiBnb29kIGJ1c2luZXNzIHByYWN0aWNl IHdlIHdpbGwgY29vcGVyYXRlIHdpdGggYW55IHJlYXNvbmFibGUgZXhlcmNpc2Ugb3IgZGVtb25z dHJhdGlvbiB0byBwcm92aWRlIHRoYXQgYXNzdXJhbmNlLjxicj4mZ3Q7PGJyPiZndDsgU29tZXRo aW5nIHRoYXQgb2NjdXJyZWQgdG8gbWUgZHVyaW5nIHRoZSBkaXNjdXNzaW9uIHdoaWNoIEkgaGF2 ZSBub3Qgc2VlbiBtZW50aW9uZWQgYmVmb3JlIGlzIHRoZSBmb2xsb3dpbmcuJm5ic3A7IEFsbCBv ZiB1cyBmb2xsb3cgdGhlIHByaW5jaXBsZSB0aGF0IHRoZSBpbmZvcm1hdGlvbiBjcmVhdGVkIGJ5 IHRoZSBJRVRGIGlzIGF2YWlsYWJsZSB0byBhbnlvbmUsIGFueXdoZXJlLCB3aXRob3V0IGNvc3Qu Jm5ic3A7IFdoYXQgd291bGQgaGFwcGVuIGlmIHRoZSBJRVRGIGNoYW5nZXMgaXRzIHBvc2l0aW9u IGFuZCByZXF1aXJlcyBJQU5BIHRvIGVpdGhlciByZXN0cmljdCBpdHMgZGlzdHJpYnV0aW9uIG9m IGluZm9ybWF0aW9uIGFuZC9vciBjaGFyZ2UgZm9yIGl0PyZuYnNwOyBJIHRoaW5rIHdl4oCZZCBo YXZlIHRvIHRoaW5rIGNhcmVmdWxseSBhYm91dCB0aGF0LiZuYnNwOyBXb3VsZCB0aGUgSUVURiBi ZSB3aWxsaW5nIHRvIGFzc2VydCBhcyBwYXJ0IG9mIGl0cyBwcmluY2lwbGVzIHRoYXQgaXQgd29u 4oCZdCBkbyBzdWNoIGEgdGhpbmc/PGJyPiZndDs8YnI+Jmd0OyBUaGFua3MsPGJyPiZndDs8YnI+ Jmd0OyBTdGV2ZSBDcm9ja2VyPGJyPiZndDsgQ2hhaXIsIElDQU5OIEJvYXJkIG9mIERpcmVjdG9y czxicj4mZ3Q7PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5JbnRlcm5ldGdvdnRlY2ggbWFpbGluZyBsaXN0PGJyPkludGVybmV0Z292dGVj aEBpYWIub3JnPGJyPmh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlcm5l dGdvdnRlY2g8YnI+PC9ib2R5Pg== ----_com.android.email_70264554267460-- From nobody Wed Mar 12 22:24: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 49F761A08C1 for ; Wed, 12 Mar 2014 22:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 KkxFgE969LzJ for ; Wed, 12 Mar 2014 22:24:23 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 3AD261A08C8 for ; Wed, 12 Mar 2014 22:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=cO//nbIyjb+talvZazw1HqR7o7kiDYM2c9jTydX8DXM=; b=nVFJX0U6k+tA76U9xtOhL8JBgZK0A1ksFqqiLp2zH9VgBbqbnN8d28iH0jxsO8THNO4l+Rs76l06s Y0itRNyuptFtLXlggfmhwJsZcBm38KklXnhZ0KATKTvQseXckjDFQ5i3H4K7SDxIHaxPjFUKnZ7we4 2B8OADcaIGBKVx/0= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 13 Mar 2014 15:24:12 +1000 (EST) Received: from [10.225.97.118] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Mar 2014 15:24:11 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> Date: Thu, 13 Mar 2014 16:23:56 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> , <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> To: X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/BaLoz3kC3-PDPrzn0vB7lXvB1TQ Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 05:24:25 -0000 Weaving the web of wording around various RFCs and the distinctions = between the IASA, the IAOC and the IETF, I have absolutely no idea = whether a) the IETF itself is an ISOC activity per se and b) issues = about the intellectual property rights associated with the protocol = parameter registry contents vest with any of the preceding bodies. But I = thought we were talking principles, and the principle I was espousing = was that all intellectual property rights in the content of the protocol = parameters registries remains with the IETF, and does not vest with the = registry operator. I guess I'm treading on the toes of an historic US = position that in the past appeared to be that the intellectual property = rights of the IANA protocol parameter registries that were operated = under the terms of contracts with variously ARPA, DARPA and the NSF = vested with the USG in some fashion, and its a question that we appear = to want to avoid as there has never been any statements from the NTIA = that expressly disclaim this, and noone appears to want to press the = point. I personally am in favour of a stronger statement of principle from the = IETF in this area, but I'm just one voice, and I sense from the posts = for Jari and Eliot that they are unwilling to head further in this = direction - fair enough. regards, Geoff On 13 Mar 2014, at 8:59 am, = wrote: >> All intellectual property rights in the content of the registries = remains that of the IETF, >=20 > Since IETF is an ISOC activity, and ISOC is the organisation that will = be involved in intellectual property disputes (see RFC2031) isn't that = really ISOC ownership? >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ From nobody Wed Mar 12 22:40: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 572531A08E3 for ; Wed, 12 Mar 2014 22:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 Otc6d-5Mr6HW for ; Wed, 12 Mar 2014 22:40:56 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1A1A08DC for ; Wed, 12 Mar 2014 22:40:56 -0700 (PDT) Received: from ix-2.local (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 05D0522898; Thu, 13 Mar 2014 06:40:49 +0100 (CET) Message-ID: <532144E0.2080302@frobbit.se> Date: Thu, 13 Mar 2014 06:40:48 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Geoff Huston , l.wood@surrey.ac.uk References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> , <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> In-Reply-To: <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FOcjmCfeR5xjdFkcSj0Ssadq2fTjXTl2r" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/CTSLTZXFq0PHwWcvCxVAR-A3uI8 Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 05:40:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FOcjmCfeR5xjdFkcSj0Ssadq2fTjXTl2r Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-03-13 06:23, Geoff Huston wrote: > I personally am in favour of a stronger statement of principle from the= IETF in this area, but I'm just one voice, and I sense from the posts fo= r Jari and Eliot that they are unwilling to head further in this directio= n - fair enough. FWIW, I support Geoff here, given the history we have seen not only in direct IETF history but also in other Internet related registries (for example various TLD-registries). That said, I at the same time agree with Jari and Eliot that the over all goal is in the principles. That finding a solution "is implementation= ". So, I just would like to have a stronger statement so this is not forgott= en. The copyright for a parameter and its assigments should stay with whatever organization "owns" that parameter. Not belong to whoever acts as the care taker of the registry. That ICANN also say they do not have any interest as the operator in IPR for the registry is good, but if the registry operator changes, IPR issues I absolutely would like to see in the agreement(s). I am because of that of course sort of happy with what Jari and Eliot stated. This can be found in the principles. Just do not forget about it... Patrik --FOcjmCfeR5xjdFkcSj0Ssadq2fTjXTl2r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTIUTgrMabGguI180RAvxeAJ9BPnvlXzofXo2/JZAnFwyHKSDi2ACfflEc CjoAk3dVvoHYAHzexVB+bzc= =Y7KC -----END PGP SIGNATURE----- --FOcjmCfeR5xjdFkcSj0Ssadq2fTjXTl2r-- From nobody Wed Mar 12 22:47: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 CFFCA1A08E2 for ; Wed, 12 Mar 2014 22:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, 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 bJom3tBITMPJ for ; Wed, 12 Mar 2014 22:47:43 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3DA1A08D6 for ; Wed, 12 Mar 2014 22:47:42 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so403229wes.2 for ; Wed, 12 Mar 2014 22:47:36 -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=vDxo/on8JUZBcL/HNKMWQCBWfT8+b4kF4GSDBP7VjGY=; b=GdcAuEmgRKIqvaDYTB8IFBjUz2R2WINvn31YWS1duNk4MPbCNO58XgRrwg1MluCilP 6tPZzPss2sqC7pMT273emtI8niuYpIw11M+gLbwF1FEY3+HnNgwqSLIX5MRNKisToaoe 0xkwUA2Qb+6WeLAUtri0gOD3SWsxMHLM5giHdLr1sVo2vE5ocPkzo/hpZczfOuSffM1P 5+7tGWIZ8or3wQMEjz6IEFZ+TRgzlp8aaHtAAdlEtgJPIbQD8kQYHGYHDqm9d7Ifnjym WbC5oupMETc8MOBpK7WUZ9JUunl5j1b147VWYEu4SuuhlF+A4yIizrwn7hao0G3pPA4Y luTA== MIME-Version: 1.0 X-Received: by 10.194.58.180 with SMTP id s20mr13044wjq.54.1394689656035; Wed, 12 Mar 2014 22:47:36 -0700 (PDT) Received: by 10.194.0.228 with HTTP; Wed, 12 Mar 2014 22:47:35 -0700 (PDT) In-Reply-To: <532144E0.2080302@frobbit.se> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <532144E0.2080302@frobbit.se> Date: Thu, 13 Mar 2014 13:47:35 +0800 Message-ID: From: Pindar Wong To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=047d7b86cb68851fb604f4767d6d Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/4keXud5hKByJT-lqqoa-06TR8dQ Cc: internetgovtech@iab.org, Geoff Huston , l.wood@surrey.ac.uk, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 05:47:45 -0000 --047d7b86cb68851fb604f4767d6d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fwiw also be mindful of http://en.wikipedia.org/wiki/Sui_generis_database_right p. On Thu, Mar 13, 2014 at 1:40 PM, Patrik F=E4ltstr=F6m wrot= e: > On 2014-03-13 06:23, Geoff Huston wrote: > > I personally am in favour of a stronger statement of principle from the > IETF in this area, but I'm just one voice, and I sense from the posts for > Jari and Eliot that they are unwilling to head further in this direction = - > fair enough. > > FWIW, I support Geoff here, given the history we have seen not only in > direct IETF history but also in other Internet related registries (for > example various TLD-registries). > > That said, I at the same time agree with Jari and Eliot that the over > all goal is in the principles. That finding a solution "is implementation= ". > > So, I just would like to have a stronger statement so this is not > forgotten. > > The copyright for a parameter and its assigments should stay with > whatever organization "owns" that parameter. Not belong to whoever acts > as the care taker of the registry. > > That ICANN also say they do not have any interest as the operator in IPR > for the registry is good, but if the registry operator changes, IPR > issues I absolutely would like to see in the agreement(s). > > I am because of that of course sort of happy with what Jari and Eliot > stated. This can be found in the principles. > > Just do not forget about it... > > Patrik > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > --047d7b86cb68851fb604f4767d6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 13, 2014 at 1:40 PM, Patrik = F=E4ltstr=F6m <paf@frobbit.se> wrote:
On 2014-03-13 06:23, Geoff Huston wrote:
> I personally am in favour of a stronger statement of principle from th= e IETF in this area, but I'm just one voice, and I sense from the posts= for Jari and Eliot that they are unwilling to head further in this directi= on - fair enough.

FWIW, I support Geoff here, given the history we have seen not only i= n
direct IETF history but also in other Internet related registries (for
example various TLD-registries).

That said, I at the same time agree with Jari and Eliot that the over
all goal is in the principles. That finding a solution "is implementat= ion".

So, I just would like to have a stronger statement so this is not forgotten= .

The copyright for a parameter and its assigments should stay with
whatever organization "owns" that parameter. Not belong to whoeve= r acts
as the care taker of the registry.

That ICANN also say they do not have any interest as the operator in IPR for the registry is good, but if the registry operator changes, IPR
issues I absolutely would like to see in the agreement(s).

I am because of that of course sort of happy with what Jari and Eliot
stated. This can be found in the principles.

Just do not forget about it...

=A0 =A0Patrik


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


--047d7b86cb68851fb604f4767d6d-- From nobody Wed Mar 12 23:34: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 8B59B1A0929 for ; Wed, 12 Mar 2014 23:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.747 X-Spam-Level: X-Spam-Status: No, score=-9.747 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 Eu68luNBTqsW for ; Wed, 12 Mar 2014 23:34:49 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 70DE81A08FE for ; Wed, 12 Mar 2014 23:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1891; q=dns/txt; s=iport; t=1394692483; x=1395902083; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=LdwNI1MzI/CF+junGYpNL2HGiPej6P7qQEU347VDVZM=; b=LrMtZJAdE78cOznCFxzCUtRezS+ymY5kuIo11dxISKeLfC+E+LWKsqTj j+oXIgcjSUJnNahTeeoyNIF6haNAXueYhnr1zNdmrfS9X7SCd9JYK/9vD KNAl4YknM6OVc5PVuOuGv2gSdHHlSQ9ZP+LjejtJbNL7tOcakkjBQ7W5C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAFJRIVOQ/khR/2dsb2JhbABZgwY7g12FXbh9gRsWdIIlAQEBBCNVARALBAETCRYLAgIJAwIBAgErGgYBDAEHAQGHdQ2xXqFpF45cB4JvgUkEmEWSLYFvgT88 X-IronPort-AV: E=Sophos;i="4.97,644,1389744000"; d="scan'208,217";a="3884972" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-4.cisco.com with ESMTP; 13 Mar 2014 06:34:42 +0000 Received: from mctiny.local ([10.61.222.48]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2D6Ygwr000305; Thu, 13 Mar 2014 06:34:42 GMT Message-ID: <53215182.7020007@cisco.com> Date: Thu, 13 Mar 2014 07:34:42 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Pindar Wong , =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Y=?= =?UTF-8?B?bQ==?= References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <532144E0.2080302@frobbit.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060105050506040301080603" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3Djnkt818mGlRdVDHid79EujZxw Cc: internetgovtech@iab.org, Geoff Huston , l.wood@surrey.ac.uk, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 06:34:51 -0000 This is a multi-part message in MIME format. --------------060105050506040301080603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Pindar, On 3/13/14, 6:47 AM, Pindar Wong wrote: > fwiw also be mindful of > > http://en.wikipedia.org/wiki/Sui_generis_database_right > > p. > > Indeed. But I do think there is probably an additional word or two we can say about seeing that any intellectual property that exists in the parameters stays with the IETF, for the purpose of making it available to all. Eliot --------------060105050506040301080603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Pindar,

On 3/13/14, 6:47 AM, Pindar Wong wrote:



Indeed.  But I do think there is probably an additional word or two we can say about seeing that any intellectual property that exists in the parameters stays with the IETF, for the purpose of making it available to all.

Eliot
--------------060105050506040301080603-- From nobody Wed Mar 12 23:49: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 70FC61A0926 for ; Wed, 12 Mar 2014 23:49:16 -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 2p_rOYhXpLjk for ; Wed, 12 Mar 2014 23:49:14 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2511A091E for ; Wed, 12 Mar 2014 23:49:14 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so455081wgh.16 for ; Wed, 12 Mar 2014 23:49:07 -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=rmcMHNXS5sa1O25+vcZRRXQy+3x/RRl0Hs4OBLXzAFs=; b=MHSQL8E1cwfc1ImX6cr/IpsI1HO6M/aTUkcIWpIExMQ4+Faagay22Dz0zAmRYisuw4 AD/AlkK9SLrjM5aRGrXnv6mvSVv6Y+YG5ymG9SOJUqHFeXOJXGftfp91sgTEwMyK5xtr TYmwzg6mFSidb+EFqBY3CVe6IznfAsqSztkZ/qaJg5K/4aBUw5KOiNDd46cGcyMrgAJs EoF757KXWds6neBWhYT/htIUA8ru9fmK4FhfEkmAoatItAEuZpv5kly7xsDTCovcBwe9 iJpTYCczDtcNfOf4D3smV2E3olVZwwsWWoHTnCyeFvlxNRl2s7Vp9IlAMdnMcz0BHx3Q AvwA== MIME-Version: 1.0 X-Received: by 10.194.58.180 with SMTP id s20mr192107wjq.54.1394693347313; Wed, 12 Mar 2014 23:49:07 -0700 (PDT) Received: by 10.194.0.228 with HTTP; Wed, 12 Mar 2014 23:49:07 -0700 (PDT) In-Reply-To: <53215182.7020007@cisco.com> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <532144E0.2080302@frobbit.se> <53215182.7020007@cisco.com> Date: Thu, 13 Mar 2014 14:49:07 +0800 Message-ID: From: Pindar Wong To: Eliot Lear Content-Type: multipart/alternative; boundary=047d7b86cb68898ca804f4775984 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/dG2o3HsgciyXbrcu2Txsiw2x_Rw Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" , Geoff Huston , l.wood@surrey.ac.uk, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 06:49:16 -0000 --047d7b86cb68898ca804f4775984 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 13, 2014 at 2:34 PM, Eliot Lear wrote: > Pindar, > > > On 3/13/14, 6:47 AM, Pindar Wong wrote: > > fwiw also be mindful of > > http://en.wikipedia.org/wiki/Sui_generis_database_right > > p. > > > > Indeed. But I do think there is probably an additional word or two we can > say about seeing that any intellectual property that exists in the > parameters stays with the IETF, for the purpose of making it available to > all. > Agreed. I merely raise this to support both Geoff and Patrik's point that perhaps extra clarity at the level of principle might be especially helpful in this inherently muddy area that comprises the territorially demarcated Intellectual Property space. In turns out that after some 7 years of operational experience with the then Creative Commons licence suite -- that 'Sui generis database rights' were particularly unhelpful (when you're actually trying to legally licence your rights away) and one of the principle drivers behind the development of the Creative Commons (4.0) Licence suite. The gory details fwiw are here:- http://wiki.creativecommons.org/4.0/Sui_generis_database_rights p. > Eliot > --047d7b86cb68898ca804f4775984 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 13, 2014 at 2:34 PM, Eliot Lear <<= a href=3D"mailto:lear@cisco.com" target=3D"_blank">lear@cisco.com> wrote:
=20 =20 =20
Pindar,


On 3/13/14, 6:47 AM, Pindar Wong wrote:
=20



Indeed.=A0 But I do think there is probably an additional word or two we can say about seeing that any intellectual property that exists in the parameters stays with the IETF, for the purpose of making it available to all.

Agreed. I merely raise this to = support both Geoff and Patrik's point that perhaps extra clarity at the= level of principle might be especially helpful in this=A0 inherently muddy= area that comprises the territorially demarcated=A0 Intellectual Property= =A0 space.

In turns out that after some 7 years of operational experience with the= then Creative Commons licence suite --=A0 that 'Sui generis database r= ights' were particularly unhelpful (when you're actually trying to = legally licence your rights away) and one of the principle drivers behind t= he development of the Creative Commons (4.0) Licence suite.=A0 The gory det= ails fwiw are here:-

http://wiki.creativecommons.org/4.0/Sui_generis_database_rights
p.


Eliot

--047d7b86cb68898ca804f4775984-- From nobody Thu Mar 13 00:49: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 8FC931A095A for ; Thu, 13 Mar 2014 00:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, 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 4wwbH4GAt0DB for ; Thu, 13 Mar 2014 00:49:35 -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 281E61A094E for ; Thu, 13 Mar 2014 00:49:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2D7nCog008823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 00:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1394696965; bh=vyyqSMnlaJjfFg48X0zwssyT26VMgN1VeMCroYZSCig=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=l4f2XuBAKC9BPKg9di2D2ljXQBya1doyRkRiYuCtRhqGcXk9ngA3x77oBzHtxQjG/ BWSevFAcyf4wMMKWDP4ri3asO2wUhFzzuATngqjJDZsBVPKPCfzXY7vMI9VHISqy3D GIh2N5RiZhIc22KvvqHgPHBLpNdBSk7RIW65OJco= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1394696965; i=@elandsys.com; bh=vyyqSMnlaJjfFg48X0zwssyT26VMgN1VeMCroYZSCig=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ky+eueqW8gdykuF8bnQlBgilb10g1tZ9tej5WE3POOa+RZLmt3bjYTZbJGTLJr+jY bzLtMNH7q4x7dkzAB28YV6OpRgxRLmCW/QRKg1CLlyW/OmPwRPNwg5zLgJJImC8fSQ biFynpxe5TwKovvr8IcaNdzBb2brU+8SVfd1GfGo= Message-Id: <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Mar 2014 00:46:05 -0700 To: Geoff Huston , l.wood@surrey.ac.uk From: S Moonesamy In-Reply-To: <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/uyzpoiD7I0QJI7s-4EhMWV4p0f0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 07:49:36 -0000 Hi Geoff, At 22:23 12-03-2014, Geoff Huston wrote: >Weaving the web of wording around various RFCs and the distinctions >between the IASA, the IAOC and the IETF, I have absolutely no idea >whether a) the IETF itself is an ISOC activity per se and b) issues >about the intellectual property rights associated with the protocol >parameter registry contents vest with any of the preceding bodies. >But I thought we were talking principles, and the principle I was >espousing was that all intellectual property rights in the content >of the protocol parameters registries remains with the IETF, and >does not vest with the registry operator. I guess I'm treading on >the toes of an historic US position that in the past appeared to be >that the intellectual property rights of the IANA protocol parameter >registries that were operated under the terms of contracts with >variously ARPA, DARPA and the NSF vested with the USG in some >fashion, and its a question that we appear to want to avoid as there >has never been any statements from the NTIA that expressly disclaim >this, and noone appears to want to press the point. I'll comment about (b). There is a RFC published in 2011 which states that the intellectual property rights of IETF protocol parameter assignment information is held by the IETF Trust. There isn't any (formal) agreement about the intellectual property rights. There is, as mentioned above, the legacy stuff. The bottom line is that the legal aspect is unclear. Regards, S. Moonesamy From nobody Thu Mar 13 01:13: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 437711A0981 for ; Thu, 13 Mar 2014 01:13:19 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IQq8os1yM8cw for ; Thu, 13 Mar 2014 01:13:08 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7161A097E for ; Thu, 13 Mar 2014 01:13:02 -0700 (PDT) Received: from [193.109.255.147:53556] by server-5.bemta-14.messagelabs.com id 62/39-16688-68861235; Thu, 13 Mar 2014 08:12:54 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-4.tower-72.messagelabs.com!1394698371!8028822!2 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26868 invoked from network); 13 Mar 2014 08:12:54 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-4.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 13 Mar 2014 08:12:54 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Thu, 13 Mar 2014 08:12:53 +0000 From: To: , Date: Thu, 13 Mar 2014 08:12:39 +0000 Thread-Topic: Guiding the Evolution of the IANA Protocol Parameter Registries Thread-Index: Ac8+kMTJNRTuKveMTOOKMt6ctgNt0gAAzt7m Message-ID: <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surrey.ac.uk> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net>, <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> In-Reply-To: <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3owhWse8AfzUq5f4t2fP5-yGixw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 08:13:19 -0000 Ah, RFC 6620 and RFC 4748.=20 Lloyd Wood http://about.me/lloydwood ________________________________________ From: S Moonesamy [sm+ietf@elandsys.com] Sent: 13 March 2014 07:46 To: Geoff Huston; Wood L Dr (Electronic Eng) Cc: internetgovtech@iab.org Subject: Re: Guiding the Evolution of the IANA Protocol Parameter Registri= es Hi Geoff, At 22:23 12-03-2014, Geoff Huston wrote: >Weaving the web of wording around various RFCs and the distinctions >between the IASA, the IAOC and the IETF, I have absolutely no idea >whether a) the IETF itself is an ISOC activity per se and b) issues >about the intellectual property rights associated with the protocol >parameter registry contents vest with any of the preceding bodies. >But I thought we were talking principles, and the principle I was >espousing was that all intellectual property rights in the content >of the protocol parameters registries remains with the IETF, and >does not vest with the registry operator. I guess I'm treading on >the toes of an historic US position that in the past appeared to be >that the intellectual property rights of the IANA protocol parameter >registries that were operated under the terms of contracts with >variously ARPA, DARPA and the NSF vested with the USG in some >fashion, and its a question that we appear to want to avoid as there >has never been any statements from the NTIA that expressly disclaim >this, and noone appears to want to press the point. I'll comment about (b). There is a RFC published in 2011 which states that the intellectual property rights of IETF protocol parameter assignment information is held by the IETF Trust. There isn't any (formal) agreement about the intellectual property rights. There is, as mentioned above, the legacy stuff. The bottom line is that the legal aspect is unclear. Regards, S. Moonesamy From nobody Thu Mar 13 02:01: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 221E71A098C for ; Thu, 13 Mar 2014 02:01:27 -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 n8ldqrt7umDF for ; Thu, 13 Mar 2014 02:01:26 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B5DE41A0923 for ; Thu, 13 Mar 2014 02:01:25 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so561518wes.15 for ; Thu, 13 Mar 2014 02:01: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=JGwP9ueXWa6E1nt+z9CDseDYQU0R/3TiE4x/y5tFxTU=; b=L1L0Lplfhv04003WYipz1mWv0Fd1VJecsMqK617rwMs0AagmiWVkFqYJmZoIQHP1AG xFudWQDDddfBcLmz7vMegricDqUDIWghsycOEZi7qgMioAE2jqgd/+2E6mCpUE6t+zIM 6kJLw6+FuyiTHt31MqFSxw4yNx4i5wdGDcY9z5GbrjXcgBSt1wSAfu5zU09XJ3sqVfat 5KVwvmf/lS1hVOd4lwpz/Nl1V3MdxarZxf792HzN26BzkEG4+b56azSBuCfvRT5Dk9y2 mxtNBRBc4F5QFereSW6h3DEDrfYGmX85UE6FDcQq2iJ5a/RukvgVW/rrt7Zp7wtCNNWl I9cA== X-Received: by 10.180.100.169 with SMTP id ez9mr597619wib.15.1394701278496; Thu, 13 Mar 2014 02:01:18 -0700 (PDT) Received: from [192.168.0.3] (cpc8-mort6-2-0-cust102.croy.cable.virginm.net. [82.43.108.103]) by mx.google.com with ESMTPSA id z1sm3893267wjq.19.2014.03.13.02.01.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 02:01:17 -0700 (PDT) Message-ID: <532173E3.2050707@gmail.com> Date: Thu, 13 Mar 2014 22:01:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <532144E0.2080302@frobbit.se> <53215182.7020007@cisco.com> In-Reply-To: <53215182.7020007@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jQwwq4VscxYy4nO4iOZ5vy9qLOc Cc: "ietf@ietf.org Mailing List" , l.wood@surrey.ac.uk, Geoff Huston , internetgovtech@iab.org, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Y=?= =?UTF-8?B?bQ==?= , Pindar Wong Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 09:01:27 -0000 On 13/03/2014 19:34, Eliot Lear wrote: > Pindar, > > On 3/13/14, 6:47 AM, Pindar Wong wrote: >> fwiw also be mindful of >> >> http://en.wikipedia.org/wiki/Sui_generis_database_right >> >> p. >> >> > > Indeed. But I do think there is probably an additional word or two we > can say about seeing that any intellectual property that exists in the > parameters stays with the IETF, for the purpose of making it available > to all. For everything assigned since the IETF/IANA MoU was ratified in March 2000, we could certainly make that assertion, and presumably vest the IPR in the IETF Trust. For assignments prior to March 2000, I think things are less clear. IANAL. Brian From nobody Thu Mar 13 03:38: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 389541A09D6 for ; Thu, 13 Mar 2014 03:38:52 -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 MX21DB6CWc3O for ; Thu, 13 Mar 2014 03:38:47 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C40101A09D0 for ; Thu, 13 Mar 2014 03:38:46 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi5so3660506wib.11 for ; Thu, 13 Mar 2014 03:38:39 -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=yGdTR1V33tt0PPXd16tqgLxLlawCaRdk7FqOCDtl874=; b=MegcOTBCalMQVsmKwgAPYIuWxZSwTJ1f4LxcUS8jeTfllvckAMhH6Qjw/DaUGMfjnD GInM0zFn/mQIvQjUvAeusWph/4ICgWmV6zts+9NCW0PaC3KaoLnmbIhHZZobmWO/4H60 O687h7Mr2Htdaii/fV8QeLS6G21E/ILXUUXxYHdB57lAkz0TaZhLPbCz10FLGkiGwwjd auCN/7RL0xrDlfUMHpLs9pnrZ9MYA7I5YEiLK7CdcDAFRrJkRaCv+rt5pvB99pWotGb/ l3P8jlH7Uo36msRp6pN0sGcRjKl/7RqRN9RDB0+CDDmlAWJNY7t+APppsaS1KEZdzg/M BVpQ== X-Received: by 10.180.205.204 with SMTP id li12mr997794wic.34.1394707119811; Thu, 13 Mar 2014 03:38:39 -0700 (PDT) Received: from [192.168.0.3] (cpc8-mort6-2-0-cust102.croy.cable.virginm.net. [82.43.108.103]) by mx.google.com with ESMTPSA id ci4sm4532448wjc.21.2014.03.13.03.38.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 03:38:39 -0700 (PDT) Message-ID: <53218AB5.6010808@gmail.com> Date: Thu, 13 Mar 2014 23:38:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: l.wood@surrey.ac.uk References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net>, <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/-mqEPqJEA-KlbiTssJ7Vlw1Z1QA Cc: internetgovtech@iab.org, sm+ietf@elandsys.com, gih@apnic.net Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 10:38:52 -0000 Not 6620, so which one do you mean? Regards Brian On 13/03/2014 21:12, l.wood@surrey.ac.uk wrote: > Ah, RFC 6620 and RFC 4748. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: S Moonesamy [sm+ietf@elandsys.com] > Sent: 13 March 2014 07:46 > To: Geoff Huston; Wood L Dr (Electronic Eng) > Cc: internetgovtech@iab.org > Subject: Re: Guiding the Evolution of the IANA Protocol Parameter Registries > > Hi Geoff, > At 22:23 12-03-2014, Geoff Huston wrote: >> Weaving the web of wording around various RFCs and the distinctions >> between the IASA, the IAOC and the IETF, I have absolutely no idea >> whether a) the IETF itself is an ISOC activity per se and b) issues >> about the intellectual property rights associated with the protocol >> parameter registry contents vest with any of the preceding bodies. >> But I thought we were talking principles, and the principle I was >> espousing was that all intellectual property rights in the content >> of the protocol parameters registries remains with the IETF, and >> does not vest with the registry operator. I guess I'm treading on >> the toes of an historic US position that in the past appeared to be >> that the intellectual property rights of the IANA protocol parameter >> registries that were operated under the terms of contracts with >> variously ARPA, DARPA and the NSF vested with the USG in some >> fashion, and its a question that we appear to want to avoid as there >> has never been any statements from the NTIA that expressly disclaim >> this, and noone appears to want to press the point. > > I'll comment about (b). There is a RFC published in 2011 which > states that the intellectual property rights of IETF protocol > parameter assignment information is held by the IETF Trust. There > isn't any (formal) agreement about the intellectual property > rights. There is, as mentioned above, the legacy stuff. The bottom > line is that the legal aspect is unclear. > > Regards, > S. Moonesamy > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > From nobody Thu Mar 13 06:31: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 77D691A0963 for ; Thu, 13 Mar 2014 06:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.68 X-Spam-Level: ** X-Spam-Status: No, score=2.68 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_12_24=1.049, 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 NgRA-mdLioz3 for ; Thu, 13 Mar 2014 06:31:47 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7781A08C8 for ; Thu, 13 Mar 2014 06:31:47 -0700 (PDT) Received: from [85.159.233.116] (port=44760 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WO5jX-0007PA-BB; Thu, 13 Mar 2014 06:31:40 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2014 01:54:59 +0100 To: Geoff Huston ,Steve Crocker From: Jefsey In-Reply-To: <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.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: 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/W1kWy4O3u2XanF8jA8EOqC06alk Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 13:31:48 -0000 At 21:50 12/03/2014, Geoff Huston wrote: >But I don't think we need to cross every bridge here - we can at >best set forth our values and principles on the day and hope that >our successors at least consider what we were trying to achieve and >why we thought it to be important as they make their changes to suit >their world. These principles appear to be an earnest effort in that direction. Geoff, as such I am afraid they do not belong to the internet. RFC 1958 defines the principles of the Internet architecture. The first of these principles is the principle of constant change: "The principle of constant change is perhaps the only principle of the Internet that should survive indefinitely". It seems that this principle invalidates your entire claim as what you want to protect (IETF protocols) is based on the idea that they are published to be continously adapted. This puts them outside of any copyright (as something being used, supported, parametered, etc.) but fully subject to initial author rights? jfc From nobody Thu Mar 13 08:17: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 86F141A0A1D for ; Thu, 13 Mar 2014 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, 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 RrK6QsuG4I3X for ; Thu, 13 Mar 2014 08:17: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 1F4301A0A20 for ; Thu, 13 Mar 2014 08:17:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2DFGil2019525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 08:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1394723819; bh=U4e1ulfmcHNw3H99IFnYOwtcbC6Ydjnzbciwtue0am4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2HU/cjFG9EhivgFMjMHU5GVq7WDntEr6cHvxIuxz4xyajvIpFmuKcf12R+cxVEy8v 10mxBWB7C/VJE9gVchY5cVv44sB2At2XlNhjmfonqAcnzqbpW5BmSb6twnwtEDR0lB tfKJdTzqiYLzTnhNxPlK1Tj6LVGCZ4HSyDNDX2Lo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1394723819; i=@elandsys.com; bh=U4e1ulfmcHNw3H99IFnYOwtcbC6Ydjnzbciwtue0am4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G7BBR69icnN9shS3BVFoFy1pvqPmW0FtR+AWNsKaZZIqBauinM4yk5TenR+BmbN2s D9It0YIsWehhmxJzA1wC+ewKaD1zOEQo1jHwlkgggCxeGEwXAs2y80dhYTeN8LNzpZ 9alrQQxS0pm1V9qrdrGTf/s2Xzjxu9l85/67BFGA= Message-Id: <6.2.5.6.2.20140313075853.0d5f9778@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Mar 2014 08:00:55 -0700 To: l.wood@surrey.ac.uk, gih@apnic.net, Brian E Carpenter From: S Moonesamy In-Reply-To: <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surre y.ac.uk> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/4Iv8YaEOyww-ZvxKWvuUQ5QC2AA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 15:17:19 -0000 Hi Llyod, At 01:12 13-03-2014, l.wood@surrey.ac.uk wrote: >Ah, RFC 6620 and RFC 4748. Yes. There might be a typo for RFC 6220. Regards, S. Moonesamy From nobody Thu Mar 13 10:55: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 ED82C1A0A23 for ; Thu, 13 Mar 2014 10:55:18 -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 oq2aCr1u-IFl for ; Thu, 13 Mar 2014 10:55:17 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 097221A0A0F for ; Thu, 13 Mar 2014 10:55:16 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so1207680wgh.32 for ; Thu, 13 Mar 2014 10:55: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=50jnIT+U3KNwy8QDfsNECbG6EWgWyuYJRpf9xMRZAco=; b=hrqu9fBkaGPnk2Trd6LbnIVYWMrmlzQvXxkcBuxlJyduJGjRtv8oHF+wfivla76a09 kMrZZQIzV+iGM5cqs0O1PUpQ0lB/fNZYCNYnzJkS0lYC9bPU/zz4Gx11+JRvRKwHfKhZ Wc9UkfiBpynma7LdRtMX+7eCuCdoPykp8CEVKDe7R1/K827WqgR3KusAhzdL8QRCp9Gy REkaopAcw4yOpqCYblPP0hNlH5+ojIe3p6k/P0dfA4toAEHRPU/XJIZVxOFE67Go37jb vWI9wpYhTWiXfsan8Vsz0xVoTm7oNzq4TuAa/T/FNsXsJsfpEOXNiYtcG4T7s+YpdJqC GrgA== X-Received: by 10.194.192.132 with SMTP id hg4mr2927580wjc.28.1394733309993; Thu, 13 Mar 2014 10:55:09 -0700 (PDT) Received: from [192.168.0.3] (cpc8-mort6-2-0-cust102.croy.cable.virginm.net. [82.43.108.103]) by mx.google.com with ESMTPSA id v6sm9476257wif.0.2014.03.13.10.55.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 10:55:09 -0700 (PDT) Message-ID: <5321F104.4020100@gmail.com> Date: Fri, 14 Mar 2014 06:55:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: S Moonesamy References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surrey.ac.uk> <6.2.5.6.2.20140313075853.0d5f9778@resistor.net> In-Reply-To: <6.2.5.6.2.20140313075853.0d5f9778@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YwUW60IKfkXuP1ntS2v5afZ0nXo Cc: internetgovtech@iab.org, gih@apnic.net, l.wood@surrey.ac.uk Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 17:55:19 -0000 On 14/03/2014 04:00, S Moonesamy wrote: > Hi Llyod, > At 01:12 13-03-2014, l.wood@surrey.ac.uk wrote: >> Ah, RFC 6620 and RFC 4748. > > Yes. There might be a typo for RFC 6220. Thanks. Which indeed states that rights belong to the IETF Trust. But that is only a statement in an Informational RFC. Good luck in court. Brian From nobody Thu Mar 13 12:55: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 6C3751A0A16 for ; Thu, 13 Mar 2014 12:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, 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 y5k7d_KIU_41 for ; Thu, 13 Mar 2014 12:55:50 -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 6314D1A0763 for ; Thu, 13 Mar 2014 12:55:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2DJtJT9009331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 12:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1394740534; bh=WcPxSYFtjG6DkP+L0/ShWHOC3x4VS7zPSWcyyvYhjgU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T6u0r5d89TJOIXJNtJc6BosM7jTvI7t1V3NCPJhy1I/1FjBydqmn29kmL5Zz+scDZ yYgVq8HGVmK1/Q6vdukZT5ZaDyb7A7YXCiFZNVkFZYuT1n02xyN38+eaVuZsF+eHsr cFUudyUqDiCKvbKeOq3Djp5E0NPVZ52XoxUXsN58= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1394740534; i=@elandsys.com; bh=WcPxSYFtjG6DkP+L0/ShWHOC3x4VS7zPSWcyyvYhjgU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=glKc5RiWQbXC1mf3HmQfzPv9wMIDJkyebptHXGQxKfENa8YgwgLQm3w+JSVZfIUfQ OtWjE2Lq1ts5NgsbcCPNoqVTbq+EuMD3xT53f54RQ4lw4IIZwvqubtK3T2P7qTLwEh bTn4Kdji8P4y3EE3sksPf1yX10pXWUrEEOeylrJw= Message-Id: <6.2.5.6.2.20140313112815.0d2f2270@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Mar 2014 12:32:11 -0700 To: Brian E Carpenter From: S Moonesamy In-Reply-To: <5321F104.4020100@gmail.com> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> <6.2.5.6.2.20140312231344.0c54d7b8@resistor.net> <290E20B455C66743BE178C5C84F1240847E6334770@EXMB01CMS.surrey.ac.uk> <6.2.5.6.2.20140313075853.0d5f9778@resistor.net> <5321F104.4020100@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/K9K4wJkmbYKuInFNjQ123DpF5to Cc: internetgovtech@iab.org, gih@apnic.net, l.wood@surrey.ac.uk Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 13 Mar 2014 19:55:51 -0000 Hi Brian, At 10:55 13-03-2014, Brian E Carpenter wrote: >Thanks. Which indeed states that rights belong to the IETF Trust. >But that is only a statement in an Informational RFC. Good luck >in court. In a previous message I mentioned that there isn't any (formal) agreement about the intellectual property rights. I spent a few minutes thinking about the matter. It is like opening Pandora's box [1]. Regards, S. Moonesamy 1. a source of many troubles From nobody Fri Mar 14 13:53: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 0FC5D1A01CB for ; Fri, 14 Mar 2014 13:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 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, MISSING_MID=0.497, RP_MATCHES_RCVD=-0.547, 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 G3iX6NRdOGQq for ; Fri, 14 Mar 2014 13:49:12 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37D1A01DC for ; Fri, 14 Mar 2014 13:49:12 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id dUr91n0091ap0As55Yp5Qq; Fri, 14 Mar 2014 20:49:05 +0000 Received: from Mike-T530ssd.comcast.net ([68.34.113.195]) by omta22.westchester.pa.mail.comcast.net with comcast id dYp31n00e4D0RQL3iYp5d7; Fri, 14 Mar 2014 20:49:05 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Mar 2014 16:49:08 -0400 To: Geoff Huston , From: Michael StJohns In-Reply-To: <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> References: <53066F72.6080809@cisco.com> <53078600.3090104@cisco.com> <53086568.7050707@cisco.com> <3FFD6830-DC12-4707-AE2B-0FE1F251B198@vigilsec.com> <530921E3.7060005@cisco.com> <39ED9EBA-C644-40A4-B45B-9764032CE277@apnic.net> <0F0A2653-1FC8-475F-B123-01E96E26CECF@apnic.net> <290E20B455C66743BE178C5C84F1240847E633476A@EXMB01CMS.surrey.ac.uk> <3F12C9B5-61B6-4C28-B73A-320D80A6AE17@apnic.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_305081701==.ALT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394830145; bh=KG1nBbssufnbsgMxq/f5Itb2vYMkxBma/oHy/JxLkaA=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=XozkdmWmQuPwvwcoLOl+aENcpi5zPFUYBSsAK15UIZVpZUSjGyxqewbtuPPRWp+8s izxXOUchfA1pCiipEliuV9CyYlvJmUbhAoS26KopZiMFBE84DGuO2JdqLekdZ9xSUE cVKM10m/GqYQICPBdqE6Sx6l8ba/kNMQb3PYk0z4hDQSTQn9+Lm1LFk6bNIm8IhTcQ joS4ITzWD4cF4C4NbSvznCZicenZTX9uPJPHq4zkyAX6mOHe96TDyMLloOywZrZOFb Skew3CeJclRJb8aJq+lHAaTza8Euasr/V60/MS2iM83IV4qLoSIASZfQtUN2Dt8mBL KaNVb5YPX9puA== Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9clzYNp8OCAxYQM_5aXwu_ghFzw X-Mailman-Approved-At: Fri, 14 Mar 2014 13:53:04 -0700 Cc: internetgovtech@iab.org, "ietf@ietf.org Mailing List" Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries 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, 14 Mar 2014 20:49:18 -0000 --=====================_305081701==.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 01:23 AM 3/13/2014, Geoff Huston wrote: >. But I thought we were talking principles, and the principle I was= espousing was that all intellectual property rights in the content of the= protocol parameters registries remains with the IETF, and does not vest= with the registry operator. I guess I'm treading on the toes of an historic= US position that in the past appeared to be that the intellectual property= rights of the IANA protocol parameter registries that were operated under= the terms of contracts with variously ARPA, DARPA and the NSF vested with= the USG in some fashion, and its a question that we appear to want to avoid= as there has never been any statements from the NTIA that expressly= disclaim this, and noone appears to want to press the point. There's this legal concept of a "quitclaim" that might be useful here. It= can be used by anyone, especially in cases where there may be an appearance= of (legal) interest, but where the actual facts aren't firmly established. Webster has it as: > >quit=B7claim > > > >transitive verb \ kwit- kl m\ >: to release or relinquish a legal claim to; especially : to release a= claim to or convey by a quitclaim deed=20 >=AD quitclaim noun=20 Maybe the right answer is to simply ask for quitclaims from the US Gov't,= and from ICANN, (and others?) with respect to any and all IPR, copyright= claims, etc they may hold, if any, in the protocol parameters registry to= be resolved or transferred to or for the benefit of the IETF trust. At= least then we'd know rather than continuing to dance around it. The quid= pro quo might be a quitclaim from us for similar interests in the DNS and= IP registries. Mike --=====================_305081701==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 01:23 AM 3/13/2014, Geoff Huston wrote:
. But I thought we were talki= ng principles, and the principle I was espousing was that all intellectual property rights in the content of the protocol parameters registries remains with the IETF, and does not vest with the registry operator. I guess I'm treading on the toes of an historic US position that in the past appeared to be that the intellectual property rights of the IANA protocol parameter registries that were operated under the terms of contracts with variously ARPA, DARPA and the NSF vested with the USG in some fashion, and its a question that we appear to want to avoid as there has never been any statements from the NTIA that expressly disclaim this, and noone appears to want to press the point.

There's this legal concept of a "quitclaim" that might be useful here.  It can be used by anyone, especially in cases where there may be an appearance of (legal) interest, but where the actual facts aren't firmly established.

Webster has it as:

quit=B7claim

<= br>
transitive verb \ kwit- kl m\
:  to release or relinquish a legal claim to; especially :  to release a claim to or convey by a quitclaim deed
=AD quitclaim noun


Maybe the right answer is to simply ask for quitclaims from the US Gov't, and from ICANN, (and others?) with respect to any and all IPR, copyright claims, etc they may hold, if any,  in the protocol parameters registry to be resolved or transferred to or for the benefit of the IETF trust.  At least then we'd know rather than continuing to dance around it.  The quid pro quo might be a quitclaim from us for similar interests in the DNS and IP registries.


Mike

--=====================_305081701==.ALT-- From nobody Fri Mar 14 15:20: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 D371D1A01EC for ; Fri, 14 Mar 2014 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 alaUkh9Y0lS0 for ; Fri, 14 Mar 2014 15:14:53 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 13D3B1A01FE for ; Fri, 14 Mar 2014 15:14:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A5E651E12A8; Fri, 14 Mar 2014 15:13:35 -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 AmUq7BSWTwwX; Fri, 14 Mar 2014 15:13:35 -0700 (PDT) Received: from [10.30.0.127] (unknown [83.150.71.93]) by c8a.amsl.com (Postfix) with ESMTPSA id CCC5C1E12A5; Fri, 14 Mar 2014 15:13:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: IETF Chair Date: Sat, 15 Mar 2014 00:14:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: To: "ietf-announce@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/t-1KbDrRQpHE6l64UHRpY-3lmAo X-Mailman-Approved-At: Fri, 14 Mar 2014 15:20:18 -0700 Cc: "internetgovtech@iab.org" , "ietf@ietf.org Mailing List" Subject: [Internetgovtech] NTIA & IANA 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: Fri, 14 Mar 2014 22:14:55 -0000 I believe you will find this announcement interesting: = http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio= n-key-internet-domain-name-functions As we knew this might be coming, Russ and I (along with IESG/IAB) have = worked with various Internet technical organisations to prepare a = statement as well: = http://www.iab.org/documents/correspondence-reports-documents/2014-2/inter= net-technical-leaders-welcome-iana-globalization-progress/ There will be more to discuss in the coming weeks but I wanted to make = sure you saw these announcements. Jari Arkko, IETF Chair From nobody Thu Mar 20 10:00: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 27FEE1A0743 for ; Thu, 20 Mar 2014 10:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 j8_uVNHV_MhP for ; Thu, 20 Mar 2014 10:00:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 174DE1A0709 for ; Thu, 20 Mar 2014 10:00:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BB55C2CEC5 for ; Thu, 20 Mar 2014 18:59:55 +0200 (EET) 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 5IUih70RZRb6 for ; Thu, 20 Mar 2014 18:59:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 620D22CCD0 for ; Thu, 20 Mar 2014 18:59:49 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2EA5E4B4-DE50-494F-BB7B-E9604E03513D@piuha.net> Date: Fri, 21 Mar 2014 00:59:48 +0800 To: "internetgovtech@iab.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Jtn81NYqDuTc5Ju0lNxQ3AHMYbs Subject: [Internetgovtech] an initial proposal wrt IANA developments 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, 20 Mar 2014 17:00:08 -0000 You have all seen the NTIA announcement [1,2]: they want to transition = their role to multi-stakeholder organisations. And you've seen the = common statement that was issued by the leaders of the technical = Internet organisations on this topic [3]: we said that we are committed = to further strengthening our processes and agreements related to the = IANA functions, and to building on the existing organizations and their = roles. At the London IETF, we also discussed principles guiding the IETF = regarding the role and evolution of IANA. After the meeting, Russ posted = his summary of the principles [4], including, for instance, that we = believe the protocol parameter registry function has been and continues = to be capably provided by the Internet technical community. I am sure similar discussions will be held, for instance, in the RIRs. = And as you may know, ICANN will facilitate discussion of the evolution, = starting from their upcoming meeting next week. =46rom an IETF point of view, I think the principles discussion is what = primarily guides us. But I also wanted to post something that goes into = a little bit more into details of what this all might mean in practice. = The following text is something that a small set of leaders from = technical Internet organisations wrote as one possible starting point = for the discussion. Your comments on this would be appreciated. Given = the situation, given the principles, given the roles of various = organisations, what specific actions would you like us to take with = regards to moving the NTIA role to the multi-stakeholder communities? Jari [1] = http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio= n-key-internet-domain-name-functions [2] = http://www.ntia.doc.gov/files/ntia/publications/qa_-_iana-for_web_eop.pdf [3] = http://www.nro.net/news/internet-technical-leaders-welcome-iana-globalizat= ion-progress [4] = http://www.iab.org/mail-archive/web/internetgovtech/current/msg00221.html ----- Status of the text below: This is something that some leaders of = technical Internet organisations have agreed is a reasonable starting point for discussing = how the role of the USG can be transitioned to the Internet community. It is a starting = point only, and not something that has been agreed by our respective = communities. In order to ensure global acceptance and affirmation of ICANN's role as administrator of the IANA functions, we are now pursuing the transition = of USG's stewardship of the IANA functions from the USG to ICANN. The roles of = all Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, = ccNSO, ccTLD ROs, and gNSO) stay unchanged. These bodies continue to hold policy authority for = the protocol parameter, number, and name spaces, including responsibility to = ensure the faithful registry implementation according to those policies. This transition from the USG has been envisaged since the early days of = ICANN. It is now feasible due to the growing maturity of ICANN and other = organisations in the Internet ecosystem. ICANN's structures and accountability = mechanisms continue to evolve and advance guided by the AoC community reviews, = including ATRT. In addition, ICANN will continue to embrace its aggressive roadmap = to=20 truly globalize its structures. In order to operationalize the transition from USG, ICANN will engage = with the Internet community in a bottom-up public consultation process to ensure = appropriate accountability mechanisms. In addition, ICANN will work with the names, = numbers, and protocol communities to formalize relationships, commitments, and = mutual responsibilities. When community stakeholders have input about the policies emanating from = the names, numbers, and protocol communities, they would be directed to = pursue their interests through the relevant Internet communities (such as the gNSO, = ccNSO, ccTLD ROs, ASO, IAB, IETF, or the RIRs) and their mechanisms for consideration and potential redress. The IETF, IAB, and RIRs are committed to open and transparent processes. = They also are committed to the role of ICANN as the IANA protocol parameter = and IP address registry operator. The accountability mechanisms for ICANN's administration of these core internet functions will provide escalation = routes that assure the names, numbers, and protocol communities that if IANA's performance is lacking, those communities can pursue defined processes = for improving performance, including pre-agreed independent 3rd party arbitration processes. ICANN reaffirms its commitment to implement all IANA registry functions = in accordance with the respective policies. ICANN will also provide = affirmations to all stakeholders (including governments) from all Internet registry = policy bodies and itself that all of us will use open and transparent = processes. From nobody Thu Mar 20 10:54: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 CD9861A0743 for ; Thu, 20 Mar 2014 10:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hDtyaom8qJds for ; Thu, 20 Mar 2014 10:54:48 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B91A0406 for ; Thu, 20 Mar 2014 10:54:47 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so1333119oag.13 for ; Thu, 20 Mar 2014 10:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Kc3MkTllv9bEVSrmWA4/tMCz2yGk1yEQ1SLNoN124Hc=; b=Ph9TFGQ4RfWvnE652depUiakn/Tz0U+gI1w9BBlCX7c7zoNDq3Scl7bHa9tepDu+kO 6m8bn+EIbOVgBXH0mSiP9PTovbX7R5Zq49QMoB7xr2Bxo1FSjjl1bu7+EZFRQLgO7DcJ Npbg79hePylHEWKLD+SoDswKtBqIUEq5aOFT7fQKx3YApiPwR2mxwW4QgrTHeDpnfglG /RaHXTVnnUcY2jfQoW7Ki3Yv9JkkZKA6tXVHmE2QQ9ALXdmTT7OS6FJn8ilHPFaU18m6 TXJTswN2BRmxpnCVEzMPImcdFjqMFEJyMmHkH3ooszoVzA8k23H7JBq7xuyMY8EFsgpq DZ0Q== X-Gm-Message-State: ALoCoQnUZnIWojqp0RRQYwdUYuFPZnFCxV9wtV4qYlzn664i92tPlhmSd5laFHBygLtwwLvSy2tB MIME-Version: 1.0 X-Received: by 10.60.73.164 with SMTP id m4mr38905306oev.8.1395338078765; Thu, 20 Mar 2014 10:54:38 -0700 (PDT) Received: by 10.60.69.102 with HTTP; Thu, 20 Mar 2014 10:54:38 -0700 (PDT) Date: Thu, 20 Mar 2014 13:54:38 -0400 Message-ID: From: Richard Barnes To: internetgovtech@iab.org Content-Type: multipart/alternative; boundary=001a1135f1b086dde604f50d7657 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/2249W4wpWdMPQRBPqVPPWmlaKJ4 Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 20 Mar 2014 17:54:51 -0000 --001a1135f1b086dde604f50d7657 Content-Type: text/plain; charset=ISO-8859-1 Hi Jari, Thanks for starting the discussion on this. It's important that we as an organization understand how the recent NTIA news affects us. Unfortunately, I disagree pretty fundamentally with the characterization in the text below. The below text seems to suppose or imply that ICANN is changing its behavior to compensate for the lack of NTIA involvement. That's just false. Or it should be -- since NTIA has had no operational role for a long time, our multistakeholder processes are not affected by their departure. I'm not denying that there may be changes over time in how the multistakeholder organizations work or how they relate to one another. Only that these changes are just part of the natural evolution of the community. They're not driven by NTIA's decision, so they don't need to be part of this discussion. My concern with focusing on change rather than continuity is that it invites trouble. Saying that there is a "transition" implies that there is some vacuum that needs to be filled by somebody. That just invites other people to argue that they should get to do NTIA's supposed job (which was actually nothing). There's no need for anyone to take on additional responsibilities Our focus in any statement should be to reaffirm our current processes -- as we have been executing for years. Any changes are simply to strengthen those processes, and should have been done irrespective of the NTIA decision. --Richard On 3/20/14 9:59 AM, "Jari Arkko" wrote: >You have all seen the NTIA announcement [1,2]: they want to transition >their role to multi-stakeholder organisations. And you've seen the common >statement that was issued by the leaders of the technical Internet >organisations on this topic [3]: we said that we are committed to further >strengthening our processes and agreements related to the IANA functions, >and to building on the existing organizations and their roles. > >At the London IETF, we also discussed principles guiding the IETF >regarding the role and evolution of IANA. After the meeting, Russ posted >his summary of the principles [4], including, for instance, that we >believe the protocol parameter registry function has been and continues >to be capably provided by the Internet technical community. > >I am sure similar discussions will be held, for instance, in the RIRs. >And as you may know, ICANN will facilitate discussion of the evolution, >starting from their upcoming meeting next week. > >From an IETF point of view, I think the principles discussion is what >primarily guides us. But I also wanted to post something that goes into a >little bit more into details of what this all might mean in practice. The >following text is something that a small set of leaders from technical >Internet organisations wrote as one possible starting point for the >discussion. Your comments on this would be appreciated. Given the >situation, given the principles, given the roles of various >organisations, what specific actions would you like us to take with >regards to moving the NTIA role to the multi-stakeholder communities? > >Jari > >[1] >http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio >n-key-internet-domain-name-functions >[2] >http://www.ntia.doc.gov/files/ntia/publications/qa_-_iana-for_web_eop.pdf >[3] >http://www.nro.net/news/internet-technical-leaders-welcome-iana-globalizat >ion-progress >[4] >http://www.iab.org/mail-archive/web/internetgovtech/current/msg00221.html > >----- > >Status of the text below: This is something that some leaders of >technical Internet >organisations have agreed is a reasonable starting point for discussing >how the role of >the USG can be transitioned to the Internet community. It is a starting >point >only, and not something that has been agreed by our respective >communities. > >In order to ensure global acceptance and affirmation of ICANN's role as >administrator of the IANA functions, we are now pursuing the transition >of USG's >stewardship of the IANA functions from the USG to ICANN. The roles of all >Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, ccNSO, >ccTLD ROs, and >gNSO) stay unchanged. These bodies continue to hold policy authority for >the >protocol parameter, number, and name spaces, including responsibility to >ensure >the faithful registry implementation according to those policies. > >This transition from the USG has been envisaged since the early days of >ICANN. >It is now feasible due to the growing maturity of ICANN and other >organisations >in the Internet ecosystem. ICANN's structures and accountability >mechanisms >continue to evolve and advance guided by the AoC community reviews, >including >ATRT. In addition, ICANN will continue to embrace its aggressive roadmap >to >truly globalize its structures. > >In order to operationalize the transition from USG, ICANN will engage >with the Internet >community in a bottom-up public consultation process to ensure appropriate >accountability mechanisms. In addition, ICANN will work with the names, >numbers, >and protocol communities to formalize relationships, commitments, and >mutual >responsibilities. > >When community stakeholders have input about the policies emanating from >the >names, numbers, and protocol communities, they would be directed to >pursue their >interests through the relevant Internet communities (such as the gNSO, >ccNSO, ccTLD ROs, >ASO, IAB, IETF, or the RIRs) and their mechanisms for consideration and >potential redress. > >The IETF, IAB, and RIRs are committed to open and transparent processes. >They >also are committed to the role of ICANN as the IANA protocol parameter >and IP >address registry operator. The accountability mechanisms for ICANN's >administration of these core internet functions will provide escalation >routes >that assure the names, numbers, and protocol communities that if IANA's >performance is lacking, those communities can pursue defined processes for >improving performance, including pre-agreed independent 3rd party >arbitration processes. > >ICANN reaffirms its commitment to implement all IANA registry functions in >accordance with the respective policies. ICANN will also provide >affirmations to >all stakeholders (including governments) from all Internet registry policy >bodies and itself that all of us will use open and transparent processes. > >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech --001a1135f1b086dde604f50d7657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jari,

Thanks for starting the disc= ussion on this.  It's important that we as an organization underst= and how the recent NTIA news affects us.  Unfortunately, I disagree pr= etty fundamentally with the characterization in the text below.  

The below text seems to suppose or imply that ICANN is changi= ng its behavior to compensate for the lack of NTIA involvement.  That&= #39;s just false.  Or it should be — since NTIA has had no opera= tional role for a long time, our multistakeholder processes are not affecte= d by their departure.

I'm not denying that there may be changes over time in ho= w the multistakeholder organizations work or how they relate to one another= .  Only that these changes are just part of the natural evolution of t= he community.  They're not driven by NTIA's decision, so they = don't need to be part of this discussion.

My concern with focusing on change rather = than continuity is that it invites trouble.  Saying that there is a &q= uot;transition" implies that there is some vacuum that needs to be fil= led by somebody.  That just invites other people to argue that they sh= ould get to do NTIA's supposed job (which was actually nothing).  = There's no need for anyone to take on additional responsibilities

Our f= ocus in any statement should be to reaffirm our current processes -- as we = have been executing for years. Any changes are simply to strengthen those p= rocesses, and should have been done irrespective of the NTIA decision.

--Richard


On 3/20/14 9:59 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote:

>You have all seen the NTIA announcement [1,2]: they want to transition<= br> >their role to multi-stakeholder organisations. And you've seen the = common
>statement that was issued by the leaders of the technical Internet
>organisations on this topic [3]: we said that we are committed to furth= er
>strengthening our processes and agreements related to the IANA function= s,
>and to building on the existing organizations and their roles.
>
>At the London IETF, we also discussed principles guiding the IETF
>regarding the role and evolution of IANA. After the meeting, Russ poste= d
>his summary of the principles [4], including, for instance, that we
>believe the protocol parameter registry function has been and continues=
>to be capably provided by the Internet technical community.
>
>I am sure similar discussions will be held, for instance, in the RIRs.<= br> >And as you may know, ICANN will facilitate discussion of the evolution,=
>starting from their upcoming meeting next week.
>
>From an IETF point of view, I think the principles discussion is what >primarily guides us. But I also wanted to post something that goes into= a
>little bit more into details of what this all might mean in practice. T= he
>following text is something that a small set of leaders from technical<= br> >Internet organisations wrote as one possible starting point for the
>discussion. Your comments on this would be appreciated. Given the
>situation, given the principles, given the roles of various
>organisations, what specific actions would you like us to take with
>regards to moving the NTIA role to the multi-stakeholder communities? >
>Jari
>
>[1]
>http://www.ntia.doc.gov/press-release/201= 4/ntia-announces-intent-transitio
>n-key-internet-domain-name-functions
>[2]
>http://www.ntia.doc.gov/files/ntia/publica= tions/qa_-_iana-for_web_eop.pdf
>[3]
>http://www.nro.net/news/internet-technica= l-leaders-welcome-iana-globalizat
>ion-progress
>[4]
>http://www.iab.org/mail-archive/web/intern= etgovtech/current/msg00221.html
>
>-----
>
>Status of the text below: This is something that some leaders of
>technical Internet
>organisations have agreed is a reasonable starting point for discussing=
>how the role of
>the USG can be transitioned to the Internet community. It is a starting=
>point
>only, and not something that has been agreed by our respective
>communities.
>
>In order to ensure global acceptance and affirmation of ICANN's rol= e as
>administrator of the IANA functions, we are now pursuing the transition=
>of USG's
>stewardship of the IANA functions from the USG to ICANN. The roles of a= ll
>Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, ccNS= O,
>ccTLD ROs, and
>gNSO) stay unchanged. These bodies continue to hold policy authority fo= r
>the
>protocol parameter, number, and name spaces, including responsibility t= o
>ensure
>the faithful registry implementation according to those policies.
>
>This transition from the USG has been envisaged since the early days of=
>ICANN.
>It is now feasible due to the growing maturity of ICANN and other
>organisations
>in the Internet ecosystem. ICANN's structures and accountability >mechanisms
>continue to evolve and advance guided by the AoC community reviews,
>including
>ATRT. In addition, ICANN will continue to embrace its aggressive roadma= p
>to
>truly globalize its structures.
>
>In order to operationalize the transition from USG, ICANN will engage >with the Internet
>community in a bottom-up public consultation process to ensure appropri= ate
>accountability mechanisms. In addition, ICANN will work with the names,=
>numbers,
>and protocol communities to formalize relationships, commitments, and >mutual
>responsibilities.
>
>When community stakeholders have input about the policies emanating fro= m
>the
>names, numbers, and protocol communities, they would be directed to
>pursue their
>interests through the relevant Internet communities (such as the gNSO,<= br> >ccNSO, ccTLD ROs,
>ASO, IAB, IETF, or the RIRs) and their mechanisms for consideration and=
>potential redress.
>
>The IETF, IAB, and RIRs are committed to open and transparent processes= .
>They
>also are committed to the role of ICANN as the IANA protocol parameter<= br> >and IP
>address registry operator. The accountability mechanisms for ICANN'= s
>administration of these core internet functions will provide escalation=
>routes
>that assure the names, numbers, and protocol communities that if IANA&#= 39;s
>performance is lacking, those communities can pursue defined processes = for
>improving performance, including pre-agreed independent 3rd party
>arbitration processes.
>
>ICANN reaffirms its commitment to implement all IANA registry functions= in
>accordance with the respective policies. ICANN will also provide
>affirmations to
>all stakeholders (including governments) from all Internet registry pol= icy
>bodies and itself that all of us will use open and transparent processe= s.
>
>_______________________________________________
>Internetgovtech mailing list
>Internetgovtech@iab.org<= br> >https://www.iab.org/mailman/listinfo/internetgovtech



--001a1135f1b086dde604f50d7657-- From nobody Thu Mar 20 11:27: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 85BA71A0410 for ; Thu, 20 Mar 2014 11:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 dUq9dsi1m0fn for ; Thu, 20 Mar 2014 11:26:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 79DF81A0429 for ; Thu, 20 Mar 2014 11:26:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C25BD2CEB6; Thu, 20 Mar 2014 20:26:47 +0200 (EET) 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 fEH9f_gLeC8j; Thu, 20 Mar 2014 20:26:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 04C942CCD0; Thu, 20 Mar 2014 20:26:45 +0200 (EET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: Date: Fri, 21 Mar 2014 02:26:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wb34MwyEfzKkJ9RvDN95N72BWkE Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 20 Mar 2014 18:27:01 -0000 Richard, I agree of course that we should reaffirm our processes, and that = continuous efforts should=20 be directed to strengthening those processes irrespective of the the = NTIA's decision. And I=20 think that is exactly what has been going on. One small example of this = is that the new 2014=20 SLA between IETF and ICANN's IANA function specifies a public audit to = be performed, to=20 ensure that policies have been followed when allocations have been made. = That is the kind=20 of improvements that I think we do need. And with the Internet's ever = growing importance,=20 this is even more important that everyone can be satisfied that = appropriate checks and=20 balances are there. And it is also important to not just have this = machinery, but to also be able explain and show it to everyone who is interested - particularly = now that there is a lot of attention on IANA. Jari From nobody Thu Mar 20 12:39: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 C3FE81A0859 for ; Thu, 20 Mar 2014 12:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, 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 tKuWIXKiFCEv for ; Thu, 20 Mar 2014 12:39: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 E726C1A077C for ; Thu, 20 Mar 2014 12:39:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.157.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2KJd1RT010011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2014 12:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1395344354; bh=zynVxBFBx86ZNG1T+4b9WVggb8qqIjN9NtL7wypBdiU=; h=Date:To:From:Subject:In-Reply-To:References; b=wNrSwG4QyTiKCzEgZMSyFCEeFAgKryrUGZjnjS/Peqa5Qw/6t/d9gZLdlwCXOc7wP lOiwH6lgbbF+Z4MAqmKnP2nC+ZhT7mrTn6EVbUIY1n9xuUki1G2ZB9dNTXy5JvpVFp M7ePl5Wh/K+kpNBId3Xn5sEMYJ7oPzdSDquvy7UA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1395344354; i=@elandsys.com; bh=zynVxBFBx86ZNG1T+4b9WVggb8qqIjN9NtL7wypBdiU=; h=Date:To:From:Subject:In-Reply-To:References; b=iwBE13FV222Z9T4tvKwCPkLOjY/EVwD4aJTscP0g3CpAXM0TaXmYh1S6V26I0pehX JR1g6Im6Aa2fJZWDa56d1qEEnC5y8iqN6ASBMHaADuy+wSHZ0CsG1OC/MmmR9pLdIb 40ihpWG8rb8EgtBvyE7pAqvPUWgZkClsfi+JPPFg= Message-Id: <6.2.5.6.2.20140320115650.0d5172e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Mar 2014 12:27:44 -0700 To: Jari Arkko , internetgovtech@iab.org From: S Moonesamy In-Reply-To: <2EA5E4B4-DE50-494F-BB7B-E9604E03513D@piuha.net> References: <2EA5E4B4-DE50-494F-BB7B-E9604E03513D@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/_oEJOc-J08lt6bzCmoojXaPlSfo Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 20 Mar 2014 19:39:26 -0000 Hi Jari, At 09:59 20-03-2014, Jari Arkko wrote: > From an IETF point of view, I think the principles discussion is > what primarily guides us. But I also wanted to post something that > goes into a little bit more into details of what this all might > mean in practice. The following text is something that a small set > of leaders from technical Internet organisations wrote as one > possible starting point for the discussion. Your comments on this > would be appreciated. Given the situation, given the principles, > given the roles of various organisations, what specific actions > would you like us to take with regards to moving the NTIA role to > the multi-stakeholder communities? The situation is evolving. I prefer not to take a position about the text. >The IETF, IAB, and RIRs are committed to open and transparent processes. They >also are committed to the role of ICANN as the IANA protocol parameter and IP >address registry operator. The accountability mechanisms for ICANN's >administration of these core internet functions will provide escalation routes >that assure the names, numbers, and protocol communities that if IANA's >performance is lacking, those communities can pursue defined processes for >improving performance, including pre-agreed independent 3rd party >arbitration processes. The above mentions the "IANA protocol parameter" and "registry operator". That is not the same as what is in RFC 6220. The second sentence mentions "names". I assume that it covers the DNS Root Zone. Does the IETF and/or the IAB have a position on that matter? Regards, S. Moonesamy From nobody Thu Mar 20 17:02:17 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 416151A07D2 for ; Thu, 20 Mar 2014 17:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 Fk8qPnz02vrQ for ; Thu, 20 Mar 2014 17:02:12 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 202071A077C for ; Thu, 20 Mar 2014 17:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4406; q=dns/txt; s=iport; t=1395360124; x=1396569724; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=i8wkMtB1ipbiUuOdXFOTAKMl0k0Xxcbk3PWWtnqLylQ=; b=jvj07Qy6zsS3mXZjcWAXYw7K93ePyERvfIZZBdHNWhrm73aXz2DFxGY7 JCB+62oW/g4vxd6Th6RDT4giI9MYfKVhSfwbeKtEYhwbj+KEW8YA8T/6v jX9Yr0QcV5SZzHAaoj0oQo7BLrwpVf6pYFXbZkA/MNc9yT01KVwfi3qRv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAuBK1OQ/khR/2dsb2JhbABZgwaEGb9LgRMWdIIlAQEBAwEjSAcGBgsLGgIFFgsCAgkDAgECAUUGAQwIAQEQh10IrTCiUxeBKYxoW4JvgUkBA4lQiwuDbJIwgzow X-IronPort-AV: E=Sophos;i="4.97,699,1389744000"; d="scan'208";a="5500695" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 21 Mar 2014 00:02:01 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM (rtp-vpn4-1151.cisco.com [10.82.212.127]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2L01w0J013599; Fri, 21 Mar 2014 00:01:59 GMT Message-ID: <532B8177.5050703@cisco.com> Date: Fri, 21 Mar 2014 08:01:59 +0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jari Arkko , "internetgovtech@iab.org" References: <2EA5E4B4-DE50-494F-BB7B-E9604E03513D@piuha.net> In-Reply-To: <2EA5E4B4-DE50-494F-BB7B-E9604E03513D@piuha.net> 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/JI4GhvCLwjZxLOEiim15TBoPoVs Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 21 Mar 2014 00:02:15 -0000 Hi Jari, I appreciate that many people have views as to what should happen, going forward. However, the text you quote below doesn't seem to me consistent with the principles that we have been establishing. On 3/21/14, 12:59 AM, Jari Arkko wrote: > > In order to ensure global acceptance and affirmation of ICANN's role as > administrator of the IANA functions, we are now pursuing the transition of USG's > stewardship of the IANA functions from the USG to ICANN. The roles of all > Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, ccNSO, ccTLD ROs, and > gNSO) stay unchanged. These bodies continue to hold policy authority for the > protocol parameter, number, and name spaces, including responsibility to ensure > the faithful registry implementation according to those policies. The above text should be aligned with principle #5, at least as far as the IANA parameters are concerned. > > This transition from the USG has been envisaged since the early days of ICANN. > It is now feasible due to the growing maturity of ICANN and other organisations > in the Internet ecosystem. It is beyond feasible. The job has been and is being done by the various organizations, generally with good collaboration between them. > ICANN's structures and accountability mechanisms > continue to evolve and advance guided by the AoC community reviews, including > ATRT. In addition, ICANN will continue to embrace its aggressive roadmap to > truly globalize its structures. This sounds very good, but why should this text not be addressed in an ICANN context? > In order to operationalize the transition from USG, ICANN will engage with the Internet > community in a bottom-up public consultation process to ensure appropriate > accountability mechanisms. In addition, ICANN will work with the names, numbers, > and protocol communities to formalize relationships, commitments, and mutual > responsibilities. Much of this has already been said by ICANN. > > When community stakeholders have input about the policies emanating from the > names, numbers, and protocol communities, they would be directed to pursue their > interests through the relevant Internet communities (such as the gNSO, ccNSO, ccTLD ROs, > ASO, IAB, IETF, or the RIRs) and their mechanisms for consideration and > potential redress. I like this part, actually. It seems to form the basis for the notion that consultation should flow to the communities where the experts are, and where those who are most impacted are likely to participate. IMHO the whole statement should be about this. > > The IETF, IAB, and RIRs are committed to open and transparent processes. They > also are committed to the role of ICANN as the IANA protocol parameter and IP > address registry operator. The accountability mechanisms for ICANN's > administration of these core internet functions will provide escalation routes > that assure the names, numbers, and protocol communities that if IANA's > performance is lacking, those communities can pursue defined processes for > improving performance, including pre-agreed independent 3rd party > arbitration processes. There was general agreement in London that ICANN does a good job for the IETF managing protocol parameters. As someone who has worked very closely with that team, I must agree. They deserve all the applause we gave them, and more. They do this work on our behalf. As a general rule, however, I prefer bilateral voluntary agreements rather than arbitration processes. That is, the IETF should always control its own destiny, and arbitration dilutes that autonomy. The above paragraph also should be aligned to our principles. > > ICANN reaffirms its commitment to implement all IANA registry functions in > accordance with the respective policies. ICANN will also provide affirmations to > all stakeholders (including governments) from all Internet registry policy > bodies and itself that all of us will use open and transparent processes. > Again, this sounds like an ICANN statement. A very GOOD ICANN statement, mind you, but I feel a little funny suggesting changes to their words as to what they would commit to. But a thousand blessings upon their house if they actually say this (I feel confident that they will, by the way, in some positive form). Eliot From nobody Thu Mar 20 20:49: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 67B701A090C for ; Thu, 20 Mar 2014 20:49:28 -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, HTML_MESSAGE=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 ghjHobJDTY0V for ; Thu, 20 Mar 2014 20:49:25 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 770841A0805 for ; Thu, 20 Mar 2014 20:49:25 -0700 (PDT) Received: from 1-193.icannmeeting.org ([199.91.193.1] helo=[10.196.204.240]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WQqSJ-000L2P-Pf; Fri, 21 Mar 2014 03:49:16 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 199.91.193.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX197KACG82MYN3FqOdKQRCOt Content-Type: multipart/alternative; boundary="Apple-Mail=_22C44021-75CF-493B-975E-C07C6085FDD2" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: John Curran In-Reply-To: Date: Fri, 21 Mar 2014 11:49:08 +0800 Message-Id: <46560FA3-2ACF-4DB2-AF2C-528F9F64FE58@istaff.org> References: To: Richard Barnes X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/w5Ha-JE2C8nQJMFT7AInBsxJxQA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 21 Mar 2014 03:49:28 -0000 --Apple-Mail=_22C44021-75CF-493B-975E-C07C6085FDD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 21, 2014, at 1:54 AM, Richard Barnes wrote: > Thanks for starting the discussion on this. It's important that we as = an organization understand how the recent NTIA news affects us. = Unfortunately, I disagree pretty fundamentally with the characterization = in the text below. =20 > The below text seems to suppose or imply that ICANN is changing its = behavior to compensate for the lack of NTIA involvement. That's just = false. Or it should be =97 since NTIA has had no operational role for a = long time, our multistakeholder processes are not affected by their = departure. >=20 > I'm not denying that there may be changes over time in how the = multistakeholder organizations work or how they relate to one another. = Only that these changes are just part of the natural evolution of the = community. They're not driven by NTIA's decision, so they don't need to = be part of this discussion. >=20 > My concern with focusing on change rather than continuity is that it = invites trouble. Saying that there is a "transition" implies that there = is some vacuum that needs to be filled by somebody. That just invites = other people to argue that they should get to do NTIA's supposed job = (which was actually nothing). There's no need for anyone to take on = additional responsibilities >=20 > Our focus in any statement should be to reaffirm our current processes = -- as we have been executing for years. Any changes are simply to = strengthen those processes, and should have been done irrespective of = the NTIA decision. Richard -=20 Several of the IETF protocol parameter spaces are general-purpose = (i.e. the DNS space, the=20 IP address spaces, etc.) and thus they pose "policy issues" in = additional to the technical criteria set by the IETF. Presently, these particular spaces are administered in a framework = which was established by=20 the Internet community and documented by two principal parties: both = by the USG/DoC/NTIA (via ICANN's formation and the IANA Function contract), and also by = the IAB/IETF (via RFC 2860). While NTIA's involvement has been extremely light-handed, its = presence supports the proposition that the various policy bodies in the general-purpose Internet = registry system (including ICANN=20 and the RIRs) are not operating completely without oversight, and = this is very reassuring to many=20 globally given the importance of the Internet today in societal and = economic development. So, while I agree with you that the message should be ongoing = evolution and continuity, it is also important for the IETF community to maintain some awareness of how = its general-purpose identifier=20 spaces are being administered, since their administration is = essential to the successful deployment=20 of IETF protocols globally. Similarly, NTIA's announcement does = require specific consideration by=20 this community, to the extent it leads to changes in oversight = mechanisms applicable to IETF's=20 general-purpose registries. (I am optimistic that any changes made = will continue to support the=20 success of IETF protocols, but that's presuming that IAB/IETF stays = engaged in the discussion...) /John Disclaimer: My views alone. --Apple-Mail=_22C44021-75CF-493B-975E-C07C6085FDD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Mar = 21, 2014, at 1:54 AM, Richard Barnes <rlb@ipv.sx> wrote:

Thanks for starting the = discussion on this.  It's important that we as an organization = understand how the recent NTIA news affects us.  Unfortunately, I = disagree pretty fundamentally with the characterization in the text = below.  

The below text seems to suppose = or imply that ICANN is changing its behavior to compensate for the lack = of NTIA involvement.  That's just false.  Or it should be =97 = since NTIA has had no operational role for a long time, our = multistakeholder processes are not affected by their departure.

I'm not denying that there may be changes over time in how = the multistakeholder organizations work or how they relate to one = another.  Only that these changes are just part of the natural = evolution of the community.  They're not driven by NTIA's decision, = so they don't need to be part of this discussion.

My concern with focusing on change = rather than continuity is that it invites trouble.  Saying that = there is a "transition" implies that there is some vacuum that needs to = be filled by somebody.  That just invites other people to argue = that they should get to do NTIA's supposed job (which was actually = nothing).  There's no need for anyone to take on additional = responsibilities

Our = focus in any statement should be to reaffirm our current processes -- as = we have been executing for years. Any changes are simply to strengthen = those processes, and should have been done irrespective of the NTIA = decision.

Richard = - 

   Several of the IETF = protocol parameter spaces are general-purpose (i.e. the DNS space, = the 
   IP address spaces, etc.) and thus they = pose "policy issues" in additional to the technical = criteria
   set by the = IETF.

   Presently, these particular = spaces are administered in a framework which was established = by 
   the Internet community and documented by = two principal parties: both by the USG/DoC/NTIA
  =  (via ICANN's formation and the IANA Function contract), and also = by the IAB/IETF (via RFC 2860).

  =  While NTIA's involvement has been extremely light-handed, its = presence supports the proposition
   that the = various policy bodies in the general-purpose Internet registry system = (including ICANN 
   and the RIRs) are not = operating completely without oversight, and this is very reassuring to = many 
   globally given the importance of the = Internet today in societal and economic = development.

   So, while I agree = with you that the message should be ongoing evolution and continuity, =  it is also
   important for the IETF community = to maintain some awareness of how its general-purpose = identifier 
   spaces are being administered, = since their administration is essential to the successful = deployment 
   of IETF protocols globally. =  Similarly, NTIA's announcement does require specific consideration = by 
   this community, to the extent it leads = to changes in oversight mechanisms applicable to = IETF's 
   general-purpose registries.  (I = am optimistic that any changes made will continue to support = the 
   success of IETF protocols, but that's = presuming that IAB/IETF stays engaged in the = discussion...)

/John

Dis= claimer: My views = alone.



= --Apple-Mail=_22C44021-75CF-493B-975E-C07C6085FDD2-- From nobody Fri Mar 21 00:48: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 7E7CC1A0959 for ; Fri, 21 Mar 2014 00:48: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 OmrieWi9rXBX for ; Fri, 21 Mar 2014 00:48:52 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 172341A0955 for ; Fri, 21 Mar 2014 00:48:51 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so1355007wgg.14 for ; Fri, 21 Mar 2014 00:48:42 -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=B+GBb99muOAIkKTLMbDTqO636xi0GLZ/9+2BY5PpXE8=; b=lBjOKdLnFWsDr3yjheLvxi4wAMkyPU27ctBHKgVVbhhMQCBOcs21kzvTBF6z8ZEhea npMbMc0Aa4B81Anb6vMVyJ+P93jCuweGSRmAb0NZeEbY1VW6IHMkef+l1DalvnBxQRL6 EcxEmn++6V7CbRCURTSiHERyZEHIK9jVvF1sirEhOQS0F1jlDruxLjQ9w7abgXyx11fS n3gSTW/YEIaINMRg1yWAAoOcKT0/uBVjooJHqVJ/A5PB5XtTEgeIOKTpP1sBf5xncG/a WWdZNqHM5eAkL2PN5HZrPebuVOFuEJRQNWbCMZR4Q1tFA+sybbnrvlNrVlJiZXmFXRLL zpgA== X-Received: by 10.194.92.228 with SMTP id cp4mr340305wjb.81.1395388122283; Fri, 21 Mar 2014 00:48:42 -0700 (PDT) Received: from [192.168.0.7] (cpc8-mort6-2-0-cust102.croy.cable.virginm.net. [82.43.108.103]) by mx.google.com with ESMTPSA id fo6sm2495341wib.7.2014.03.21.00.48.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 00:48:41 -0700 (PDT) Message-ID: <532BEEE5.4020303@gmail.com> Date: Fri, 21 Mar 2014 20:48:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Barnes References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/T-PRnt2E86y1bkZuppN4Dyypq3k Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 21 Mar 2014 07:48:54 -0000 On 21/03/2014 06:54, Richard Barnes wrote: > Hi Jari, ... > The below text seems to suppose or imply that ICANN is changing its > behavior to compensate for the lack of NTIA involvement. That's just > false. Or it should be -- since NTIA has had no operational role for a long > time, our multistakeholder processes are not affected by their departure. I think this is, or should be, true. I will be delighted to see the end of the NTIA contract, but in practical terms it's a no-op, except for giving ICANN the flexibility to improve itself. So we should focus on helping to improve ICANN, which initially means improving the checks and balances provided by the multi-stakeholder model. (And of course fending off attempts at direct governmental, UN or ITU influence beyond their part in the multi-stakeholder model.) Brian From nobody Sat Mar 22 08:58: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 937AE1A099D for ; Sat, 22 Mar 2014 08:58:36 -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 hhcqZrBVOeYs for ; Sat, 22 Mar 2014 08:58:35 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id ADF731A073F for ; Sat, 22 Mar 2014 08:58:35 -0700 (PDT) Received: from [85.159.233.116] (port=13604 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WROJd-0007Lm-J6; Sat, 22 Mar 2014 08:58:34 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Mar 2014 16:58:24 +0100 To: Jari Arkko From: JFC Morfin In-Reply-To: References: 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: 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/9YYDnx4vjSijcdUASI-GBYIM6AQ Cc: internetgovtech@iab.org, "discuss@1net.org List" , iucg@ietf.org Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 22 Mar 2014 15:58:36 -0000 Jari, for historic reasons, the NTIA/DoC/USG's vision of the internet, i.e. their virtual global network information center (INTERNIC), has prevailed in coordinating an accepted convenient reduction of the Internet capacities (particularly in the naming area) where: - the "US ccTLD" was the "elder" of the family - was organized by its government as "ICANN", - that other national ccTLDs joined in the ICANN/GAC to assist it in coordinating the DNS and the IP addressing plan. The NTIA retirement not only removes the USG historic participation, but it also calls for the same retirement by all the other Governments. The NTIA precludes to be replaced by any governmental organization. This is a complete change in the 36 year old nature of the international packet switch naming and addressing spaces. The IETF cannot do anything about it as it is not in the business of deciding who is a State, who is the political authority over a ccTLD, and who can delegate (ICANN or other) national address sets if such a thing exists. We, therefore, are in a situation where the "minority leader" (US), which assumed responsibility until now, quits in refusing the successor that the majority has decided on. Dubai WCIT is supported by nations covering 3.8 billion people, while the non-signatories cover 2.6 billion, and .6 billon had to technically abstain. This is a democratic, market, and political fact that the IETF cannot oppose, but has to consider in order to get it technically addressed. IETF, IAB, ISOC, W3C, and IEEE and IETF, IAB, ISOC, W3C, RIRs, and ICANN have committed to positions that give leadership either to economical and/or political decisions that informed users from the Libre, Institutional and Competitive sectors (IUsers) and other affected parties have not, so far, published that they had understood, or approved. I appealed them, allowing me to appeal to ISOC, what I would not prefer to do as long as other possibilities of consensus have not been proposed, studied, and exhausted. The situation which is likely to develop is the situation that the NTIA's strategy has tried to prevent for 30 years, because it reflects the reality of the world's diversity independence from US interests. This means a multiple class DNS and ISO 3166 structured IPv6 addressing plan and registries. The question is, therefore, who is to provide the necessary documentation, for this to happen in good order, knowing that: - this documentation should be public domain, i.e. not under IETF Trust Copyright and with the capacity to impeach derivative work. - it is very simple to organize from ISO 3166. - neither the NTIA nor the multitude will accept it to be published by a governmental multilateral body, what ISO is not. ICANN, being a member of the ISO 3166/MA (Maintenance Agency), I suggest that: - the necessary documents of reference are written and maintained as a new work intended proposal (NWIP) by this maintenance agency. Such an NWIP could be introduced by ANSI and written by ICANN. It would then be subject to the vote of every nation in terms of participation and contribution. - every affected party (IETF, ICANN, Govs, private sector organizations, JTC1, ITU, civil society organization, the multitude of persons) could then send the ISO 3166/MA recommendations and suggest members for an advisory panel to review and consolidate them. The NWIP could determine the rules governing the selection process of such a panel in such a way that a full MS approach is respected including the Public, Private, Civil, Libre, Technical, and Academic sector. - the maintenance of this list could be assumed within the DNSA framework under the supervision of the ISO 3166/MA agency in order to provide good reactivity and permit a permanent MS multilogue under the auspices of the independent non-Governmental normative leading agency whose standard has ensured the international stability of the international data services since their very inception in full coherence with the whole global standardization process. I note that if the post-NTIA transition is not seamless and this scheme has not been explored, documented and engaged by an IETF/ICANN/DNSA working group, responsibility will lie with IETF and/or ICANN. jfc From nobody Sun Mar 23 07:22: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 C28D21A6FD7 for ; Sun, 23 Mar 2014 07:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 w8gC_O6qodHs for ; Sun, 23 Mar 2014 07:22:44 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEFB1A6FD6 for ; Sun, 23 Mar 2014 07:22:44 -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 D144C20B96; Sun, 23 Mar 2014 10:22:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 23 Mar 2014 10:22:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=nlgWJaLa2J 6MK9gUmJUcgk+T4eo=; b=rp9Mve+VgeyqDFcdHuWdM0g5zCEdwDMtZNqPCJt4Z9 7d7s5LmsqFZu+5J5l/JwtUosvalVxH5Fyek2G1M0VPe24DoRKfmjJsd/sN+HK1et Nw3vCKCmFsxi06Ey3prXSJpuyOhsUn4gPHfOuKvlQYwCQIHtosH1QD1bjq4qrKvW g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=nlgWJaLa2J6MK9gUmJUcgk +T4eo=; b=KdHwvchUK82tW0f8yNRjcGruI7O2xifG3GK3yTmlWkZHFLn0oHyH60 ylJIi/p+JbAe7v9rLG9fb7eXkM2BfYcDGXcAbSDRECTCkVEqWfPsDaE1yQuz6QNV FNWyB85IHPwKaq7XeUcgKNXgqM5JY20K8IEOlVvNsk8Wg3Dqa1cKo= X-Sasl-enc: zR3NS9Ouq78bZfrYq+DxnDBU4hIuwgpvCjxmgWxSsUg9 1395584563 Received: from [10.21.121.122] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 8EE396801B5; Sun, 23 Mar 2014 10:22:41 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Sun, 23 Mar 2014 07:22:36 -0700 From: Alissa Cooper To: Eliot Lear , Jari Arkko , "internetgovtech@iab.org" Message-ID: Thread-Topic: [Internetgovtech] an initial proposal wrt IANA developments References: <2EA5E4B4-DE50-494F-BB7B-E9604E03513D@piuha.net> <532B8177.5050703@cisco.com> In-Reply-To: <532B8177.5050703@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vnD3vm0FXvFe26kdMCnVZuMqJ0Q Subject: Re: [Internetgovtech] an initial proposal wrt IANA developments 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, 23 Mar 2014 14:22:47 -0000 On 3/20/14 5:01 PM, "Eliot Lear" wrote: >> >> The IETF, IAB, and RIRs are committed to open and transparent >>processes. They >> also are committed to the role of ICANN as the IANA protocol parameter >>and IP >> address registry operator. The accountability mechanisms for ICANN's >> administration of these core internet functions will provide escalation >>routes >> that assure the names, numbers, and protocol communities that if IANA's >> performance is lacking, those communities can pursue defined processes >>for >> improving performance, including pre-agreed independent 3rd party >> arbitration processes. > >There was general agreement in London that ICANN does a good job for the >IETF managing protocol parameters. As someone who has worked very >closely with that team, I must agree. They deserve all the applause we >gave them, and more. They do this work on our behalf. As a general >rule, however, I prefer bilateral voluntary agreements rather than >arbitration processes. That is, the IETF should always control its own >destiny, and arbitration dilutes that autonomy. The above paragraph >also should be aligned to our principles. Completely agree. I would also like to echo the comments made about this starting point text being arbitrarily centered on ICANN's role. We know that it is possible to describe the roles involved with IANA generically -- the IAB is doing just that in draft-iab-iana-framework [1]. Perhaps focusing more on which of those roles need actual improvements/strengthening in light of the NTIA announcement and how they should be improved would be more productive. Alissa [1] http://tools.ietf.org/html/draft-iab-iana-framework-02 From nobody Sun Mar 23 23:53: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 2252E1A0104 for ; Sun, 23 Mar 2014 23:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_SORBS_WEB=0.77, 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 WidGmaW6Li7v for ; Sun, 23 Mar 2014 23:53:09 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 538F31A0100 for ; Sun, 23 Mar 2014 23:53:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2E65B1E125F; Sun, 23 Mar 2014 23:53:02 -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 sM0zApJitwHd; Sun, 23 Mar 2014 23:53:02 -0700 (PDT) Received: from [192.168.5.215] (unknown [61.8.225.37]) by c8a.amsl.com (Postfix) with ESMTPSA id 50D831DF11E; Sun, 23 Mar 2014 23:53:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: IAB Chair In-Reply-To: Date: Mon, 24 Mar 2014 02:53:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> References: To: IETF Announce X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/KJtwLRKckyO0kmf8JOxHA39qzXE Cc: internetgovtech@iab.org, IETF Subject: Re: [Internetgovtech] NTIA & IANA 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, 24 Mar 2014 06:53:11 -0000 Today at ICANN 49 in Singapore, process to develop an Internet community = plan was launched. Since the announcement by NTA just over a week ago, = discussions have been taking place in many hallways and mail lists. = Input from the all of the community discussions needs to be gathered, = and ICANN has provided a mail list for this purpose: = ianatransition@icann.org. An archive is available so that everyone can = see the collection of prior postings to the list: = http://mm.icann.org/pipermail/ianatransition/. The goal is to gather the input by 27 March 2014, and then combine the = output of the mail list discussion and the discussions happening at = ICANN 49, proposing a timeline and specific next steps by for public = comment and community feedback on 7 April 2014. Please contribute. Russ On Mar 14, 2014, at 6:14 PM, IETF Chair wrote: > I believe you will find this announcement interesting: >=20 > = http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio= n-key-internet-domain-name-functions >=20 > As we knew this might be coming, Russ and I (along with IESG/IAB) have = worked with various Internet technical organisations to prepare a = statement as well: >=20 > = http://www.iab.org/documents/correspondence-reports-documents/2014-2/inter= net-technical-leaders-welcome-iana-globalization-progress/ >=20 > There will be more to discuss in the coming weeks but I wanted to make = sure you saw these announcements. >=20 > Jari Arkko, IETF Chair >=20 From joly.nyc@gmail.com Mon Mar 24 01:14: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 ABD8E1A0158; Mon, 24 Mar 2014 01:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, 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 bOzMqcbIxXCb; Mon, 24 Mar 2014 01:14:52 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E47761A0156; Mon, 24 Mar 2014 01:14:51 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id cz12so5287930veb.16 for ; Mon, 24 Mar 2014 01:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3zSCGUrIcnPsvO6RqEaJod9oUQPVTA0zoiWSh/GAsC8=; b=XYlkBaPnSt/6YMdo/9AdyCD7jmvW0HNIe38fLIBHfnXwziEhRHHBd0DxhNjqI5XIjb 9bkDjWhQ3C7KT6SrHKHl4JnmEwpQoCtU1XLiNzui4SuRAkGbRwNwbTJdayEM7Y8Z5eNP bHM8vF1wLCr4b1p/U46/OSeD4J2jrbTuwqfpzx1bmaA6rkc7HoTelBFqIkVsjOZ1WB55 W1dsvy5HiSVV2NVcQyI8Z2MV0z8h6wnzVJKNWMKuU9p0Xg95dwZTFM4Ps9ILsDjRMgVJ 71G8iSo80Gy4G4A8gziHsIrY83WThu7tWbCdMxxz8DjPKPsFfgtU0KoJ8zUcC20CrDL2 X6Tg== X-Received: by 10.59.7.228 with SMTP id df4mr5966447ved.11.1395648890900; Mon, 24 Mar 2014 01:14:50 -0700 (PDT) MIME-Version: 1.0 Sender: joly.nyc@gmail.com Received: by 10.220.145.146 with HTTP; Mon, 24 Mar 2014 01:14:20 -0700 (PDT) In-Reply-To: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> References: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> From: Joly MacFie Date: Mon, 24 Mar 2014 04:14:20 -0400 X-Google-Sender-Auth: qQzN2lylSM1gazHsoREqEQSr-OA Message-ID: To: IAB Chair Content-Type: multipart/alternative; boundary=047d7bd7625e5f996104f555d4f0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/U2QveUPCFRCOu3nULGLgKIkNRLg Cc: internetgovtech@iab.org, IETF , Ergys Ramaj Subject: Re: [Internetgovtech] NTIA & IANA X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: joly@punkcast.com List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 08:37:37 -0000 --047d7bd7625e5f996104f555d4f0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 2:53 AM, IAB Chair wrote: > ICANN has provided a mail list for this purpose: ianatransition@icann.org. > An archive is available so that everyone can see the collection of prior > postings to the list: http://mm.icann.org/pipermail/ianatransition/. > This being a mailman instance, is it necessary to subscribe at https://mm.icann.org/mailman/listinfo/ianatransition to post? I note that the subscriber list is public. https://mm.icann.org/mailman/roster/ianatransition The goal is to gather the input by 27 March 2014 What will be the status of the list after this date? -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - --047d7bd7625e5f996104f555d4f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 24, 2014 at 2:53 AM, IAB Chair <iab-chair@iab.org> wrote:
ICA= NN has provided a mail list for this purpose: ianatransition@icann.org. =A0An archive is available so = that everyone can see the collection of prior postings to the list: http:/= /mm.icann.org/pipermail/ianatransition/.

This being a mailman instance, is it necessary= to subscribe at=A0https://mm.icann.org/mailman/listinfo/ianatransition to post?<= /div>

I note that= the subscriber list is public.=A0https://mm.icann.org/mailman/roster/ianatransition

The goal is to gather the input by =A027 March 2014

--047d7bd7625e5f996104f555d4f0-- From nobody Tue Mar 25 10:18: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 F3EE51A01EC for ; Tue, 25 Mar 2014 10:12:12 -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 R7lXVXHm056w for ; Tue, 25 Mar 2014 10:12:10 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0C41A01DD for ; Tue, 25 Mar 2014 10:12:10 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so1939093ykb.8 for ; Tue, 25 Mar 2014 10:12:09 -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=bqFZhINObLLyH6JCCboa9Gihn8xV5G8ZP23fC51P5r4=; b=kteiL46OZu1MvnTWN4nK8W43/BjuVckwBGEeWhIiRXtxgakr2cXwDyplVtpaDL29Tg rBmjp9MNsA/0sHOU8M8s5KWCjO6dVpn4t3tRqbOHuv4ySPdWEqRQf5KzNLl29BUXT8o3 BBWn8HixUcQ6ZzK/z4thBgg4PXEOlbRVhE1nvQe28ah/73rK3gsJ+bTD33OEFd7xXkji D8bAeZRRjkWx4/Eofxo9nZC+JNvXF2QOvvbzyaB2+j5jPVOScx0bHxO/yiAJ+KnXtq7y PFthcwcbZ5MMLYlmc3lTmX521RnbXXi5RC52YAoosAMYXshiZhYzYcecsw55PO1SjsRU ESgA== MIME-Version: 1.0 X-Received: by 10.236.135.129 with SMTP id u1mr4352668yhi.107.1395767529065; Tue, 25 Mar 2014 10:12:09 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Tue, 25 Mar 2014 10:12:09 -0700 (PDT) In-Reply-To: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> References: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> Date: Tue, 25 Mar 2014 18:12:09 +0100 Message-ID: From: Abdussalam Baryun To: "ietf@ietf.org" Content-Type: multipart/alternative; boundary=20cf301af961c2557504f5717334 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9R1_14C6UMFpIt1zQHZKSZca9rc X-Mailman-Approved-At: Tue, 25 Mar 2014 10:18:17 -0700 Cc: "internetgovtech@iab.org" Subject: Re: [Internetgovtech] NTIA & IANA 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, 25 Mar 2014 17:12:13 -0000 --20cf301af961c2557504f5717334 Content-Type: text/plain; charset=ISO-8859-1 Hi Russ, Thanks for the message, I tried to find discussions but there was no discussion on the list mentioned below. My problem is I got used to remote discussions on lists, so is there another list people are discussing the subject. My comments below, On Monday, March 24, 2014, IAB Chair wrote: > Today at ICANN 49 in Singapore, process to develop an Internet community > plan was launched. Since the announcement by NTA just over a week ago, > discussions have been taking place in many hallways and mail lists. Input > from the all of the community discussions needs to be gathered, and ICANN > has provided a mail list for this purpose: ianatransition@icann.org. > An archive is available so that everyone can see the collection of prior > postings to the list: http://mm.icann.org/pipermail/ianatransition/. ICANN needs to encourage discussions not just make a list and think community people will do directly. > > The goal is to gather the input by 27 March 2014, That is short time, I suggest icann postpones the goal date. I don't see many inputs (only 3 or 4) on the list of icann, and then combine the output of the mail list discussion and the discussions > happening at ICANN 49, proposing a timeline and specific next steps by for > public comment and community feedback on 7 April 2014. I prefer if they report to their list what F2F discussions were and then expect the remote discussion to start. I suggest about two weeks period for community discussion/input on that list to gather feedback. > Please contribute. I will contribute if there is encouragement by the icann managers, but usually will do my input because of your message. Thanks AB > > On Mar 14, 2014, at 6:14 PM, IETF Chair wrote: > > > I believe you will find this announcement interesting: > > > > > http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions > > > > As we knew this might be coming, Russ and I (along with IESG/IAB) have > worked with various Internet technical organisations to prepare a statement > as well: > > > > > http://www.iab.org/documents/correspondence-reports-documents/2014-2/internet-technical-leaders-welcome-iana-globalization-progress/ > > > > There will be more to discuss in the coming weeks but I wanted to make > sure you saw these announcements. > > > > Jari Arkko, IETF Chair > > > > --20cf301af961c2557504f5717334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Russ,

Thanks for the message, I tried to find=A0discu= ssions=A0but there was no discussion on the list mentioned below.=A0=A0My p= roblem is I got used to remote discussions on lists, so is there another li= st people are discussing the subject. My comments below,

On Monday, March 24, 2014, IAB Chair wrote:
Today at ICANN 49 in Singapore, process to develop an Internet comm= unity plan was launched. =A0Since the announcement by NTA just over a week = ago, discussions have been taking place in many hallways and mail lists. = =A0Input from the all of the community discussions needs to be gathered, an= d ICANN has provided a mail list for this purpose: = ianatransition@icann.org. =A0An archive is available so that everyone c= an see the collection of prior postings to the list: http://mm.icann.org/p= ipermail/ianatransition/.

ICANN needs to encourage discussions not just make a li= st and think community=A0people will do directly.=A0=A0

The goal is to gather the input by =A027 March 2014,=A0

That is short time= , I suggest icann postpones the goal date.=A0=A0I don't see many=A0inpu= ts (only 3 or 4)=A0on the list of icann,=A0

and then combine the output o= f the mail list discussion and the discussions happening at ICANN 49, propo= sing a timeline and specific next steps by for public comment and community= feedback on 7 April 2014.

I prefer if they report to their list what F2F discussi= ons were and then expect the remote discussion to start. I suggest about=A0= two weeks period for community=A0discussion/input on that list to gather fe= edback.=A0


Please contribute.

I will contribute if the= re is encouragement by the icann managers, but usually will do my input bec= ause of your message.=A0

Thanks
AB

=A0

On Mar 14, 2014, at 6:14 PM, IETF Chair wrote:

> I believe you will find this announcement interesting:
>
> =A0h= ttp://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-= key-internet-domain-name-functions
>
> As we knew this might be coming, Russ and I (along with IESG/IAB) have= worked with various Internet technical organisations to prepare a statemen= t as well:
>
> =A0http://www.iab.org/documents/correspondence-reports-do= cuments/2014-2/internet-technical-leaders-welcome-iana-globalization-progre= ss/
>
> There will be more to discuss in the coming weeks but I wanted to make= sure you saw these announcements.
>
> Jari Arkko, IETF Chair
>

--20cf301af961c2557504f5717334-- From nobody Tue Mar 25 12:45: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 86C171A0144; Tue, 25 Mar 2014 12:44:53 -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, HTML_MESSAGE=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 qerpl98iGyXZ; Tue, 25 Mar 2014 12:44:50 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 980D81A01E1; Tue, 25 Mar 2014 12:44:50 -0700 (PDT) Received: from [203.116.43.76] (helo=[172.30.1.185]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WSXHE-000OzF-Jw; Tue, 25 Mar 2014 19:44:49 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 203.116.43.76 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/a8uvy97L4hFfUTy4r2p6P Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_41C82359-56FC-414C-8563-024B55E6DD45" From: John Curran X-Priority: 1 In-Reply-To: Date: Wed, 26 Mar 2014 03:44:40 +0800 Message-Id: <40EBFD44-AF04-446B-AE9E-4BA535999B14@istaff.org> References: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/_wdogLQNLXP6v6gyNA4JXpeNUlY Cc: "internetgovtech@iab.org" , "ietf@ietf.org" Subject: Re: [Internetgovtech] NTIA & IANA 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, 25 Mar 2014 19:44:53 -0000 --Apple-Mail=_41C82359-56FC-414C-8563-024B55E6DD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 26, 2014, at 1:12 AM, Abdussalam Baryun = wrote: > On Monday, March 24, 2014, IAB Chair wrote: > Today at ICANN 49 in Singapore, process to develop an Internet = community plan was launched. Since the announcement by NTA just over a = week ago, discussions have been taking place in many hallways and mail = lists. Input from the all of the community discussions needs to be = gathered, and ICANN has provided a mail list for this purpose: = ianatransition@icann.org. An archive is available so that everyone can = see the collection of prior postings to the list: = http://mm.icann.org/pipermail/ianatransition/. >=20 > ICANN needs to encourage discussions not just make a list and think = community people will do directly. =20 AB -=20 As far as I can tell, this phase is simply an expedited call for input = on the cross-community=20 process and timeline that is to be used for IANA transition plan = development - specifically,=20 the entire community is being asked to comment on the presentation of = process and timeline=20 that ICANN (as the USG NTIA designated process convener) provided in = Singapore -=20 = Amongst other things, that presentation asks the following framing = questions regarding the=20 IANA transition plan development process -=20 - What are the most important principles? - What mechanisms are important to ensure a well-run process? It also notes a fairly large list of ICANN, IETF, and RIR meetings = occurring between now and=20 September 2015, although how community discussion and cross-community = synthesis of inputs=20 appears to be a completely open question (and hence particularly ripe = for community input now) > The goal is to gather the input by 27 March 2014,=20 >=20 > That is short time, I suggest icann postpones the goal date. I don't = see many inputs (only 3 or 4) on the list of icann,=20 It is incredibly short timeframe, but it's also important to get back = comments on the proposed timeline and process, integrate those into a draft, and get that out for = comment by 7 April so=20 that it can be finalized, since it is only upon completion of all that = we'll be able to utilize the=20 resulting development process and have some discussions of the actual = content of the IANA=20 Transition Plan. =20 For example, if you feel that there should be just one global mailing = list for the IANA transition=20 plan development with continuous synthesis of all input, or one = discussion in each community=20 each via their processes; or that we should use one global wiki-based = plan document editing facility, or have an appointed steering committee to synthesize inputs = between communities, or that there should be only a few selected face-to-face meetings where = we do open forum for=20 cross-community integration of positions, or that we should generate = initial draft IANA transition=20 plan text via a random number generator, or for that matter _any_ other = process suggestions regarding the IANA transition plan development, now is the time to get = those submitted asap... As noted above, once ICANN integrates the received input on the = development process into a=20 draft document, it will go out to a formal consultation on or about 7 = April, so there will definitely=20 be an opportunity to respond to all of the process input at that time. = That is why if you feel that=20 a particular process or mechanism should be used to develop the IANA = Transition plan, it is=20 crucial to submit it by 27 March so that the entire cross-community set = of participants will see=20 it in the 7 April draft process/timeline document. (This is probably far more information about this process for input than = anyone actually wanted to hear, but given the extremely tight timelines, I figured that is = better to write down everything we can discern about it from being here onsite at the ICANN meeting...) FYI, /John Disclaimer: My views alone. Not responsible for errors and omissions - = any resulting IANA from this process is purely the responsibility of the = participants. --Apple-Mail=_41C82359-56FC-414C-8563-024B55E6DD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 On Mar = 26, 2014, at 1:12 AM, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

On Monday, March 24, 2014, IAB Chair = wrote:
Today at ICANN 49 in Singapore, process to develop an Internet = community plan was launched.  Since the announcement by NTA just = over a week ago, discussions have been taking place in many hallways and = mail lists.  Input from the all of the community discussions needs = to be gathered, and ICANN has provided a mail list for this purpose: ianatransition@icann.org.  An = archive is available so that everyone can see the collection of prior = postings to the list: http://mm.icann.org/pipermail/ianatransition/.

ICANN needs to encourage discussions not just make a = list and think community people will do = directly.  

AB = - 

As far as I can tell, this phase is = simply an expedited call for input on the = cross-community 
process and timeline that is to be used = for IANA transition plan development - specifically, 
the = entire community is being asked to comment on the presentation of = process and timeline 
that ICANN (as the USG NTIA = designated process convener) provided in Singapore = - 


Amongst other things, that = presentation asks the following framing questions regarding = the 
IANA transition plan development process = - 

    - What are the most = important principles?
    - What mechanisms are important = to ensure a well-run process?

It also = notes a fairly large list of ICANN, IETF, and RIR meetings occurring = between now and 
September 2015, although how community = discussion and cross-community synthesis of = inputs 
appears to be a completely open question (and = hence particularly ripe for community input = now)

The goal is to gather the input by  27 March = 2014, 

That is short = time, I suggest icann postpones the goal date.  I don't see = many inputs (only 3 or 4) on the list of = icann, 

It is = incredibly short timeframe, but it's also important to get back comments = on the proposed
timeline and process, integrate those into a = draft, and get that out for comment by 7 April so 
that = it can be finalized, since it is only upon completion of all that we'll = be able to utilize the 
resulting development process and = have some discussions of the actual content of the = IANA 
Transition Plan. =  

For example, if you feel that there = should be just one global mailing list for the IANA = transition 
plan development with continuous synthesis of = all input, or one discussion in each community 
each via = their processes; or that we should use one global wiki-based plan = document editing
facility, or have an appointed steering = committee to synthesize inputs between communities,
or that = there should be only a few selected face-to-face meetings where we do = open forum for 
cross-community integration of positions, = or that we should generate initial draft IANA = transition 
plan text via a random number generator, or = for that matter _any_ other process suggestions
regarding the = IANA transition plan development, now is the time to get those submitted = asap...

As noted above, once ICANN integrates = the received input on the development process into = a 
draft document, it will go out to a formal = consultation on or about 7 April, so there will = definitely 
be an opportunity to respond to all of the = process input at that time.  That is why if you feel = that 
a particular process or mechanism should be used to = develop the IANA Transition plan, it is 
crucial to = submit it by 27 March so that the entire cross-community set of = participants will see 
it in the 7 April draft = process/timeline document.

(This is probably = far more information about this process for input than anyone actually = wanted
to hear, but given the extremely tight timelines, I = figured that is better to write down everything
we can discern = about it from being here onsite at the ICANN = meeting...)

FYI,
/John

Disclaimer: My views alone.  Not responsible for errors = and omissions - any resulting IANA
        =            from this process is purely the = responsibility of the = participants.

= --Apple-Mail=_41C82359-56FC-414C-8563-024B55E6DD45-- From nobody Tue Mar 25 20:22: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 8D64E1A0083 for ; Tue, 25 Mar 2014 20:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, J_BACKHAIR_53=1, 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 qLuA3GTIsivn for ; Tue, 25 Mar 2014 20:22:50 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 325231A0005 for ; Tue, 25 Mar 2014 20:22:50 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id m5so1636941qaj.39 for ; Tue, 25 Mar 2014 20:22:48 -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=HqnJ9Lw91oAs2EhecFxLcSMN0dOatjv4/LKgbaQxV8c=; b=Vym/ethPzBVsCdCaNut10Y/osD5tsXOlZAywm2QBXEczQdOJeF/prW8UeAbkmkBt4c iK5oIjSPa4u78B3ikaasOzXtcRSxpqImIzl6EMX+lDiKUuObJQ2kloCk2pwBLogdRI1v 0/z81eAc0u7lilMJtt6QSIlBM9TKFnqNWyBLhJfcOi7j7PVIsqTk97S/np9KiVlUfp90 WEPEvVjW0/ff9EhK2h5sYn15Jyao5Kct4A6QgcgPKnml9XPr3ZgjB6QiDvRbt5unoSR+ dXJvq/o3ov9wvVLHzsUmDAyhEB1LfPdxXOx56hQgYwNvn+/7QOPkZmRh/rT54icAmA0x 251w== MIME-Version: 1.0 X-Received: by 10.224.119.141 with SMTP id z13mr85038996qaq.48.1395804168720; Tue, 25 Mar 2014 20:22:48 -0700 (PDT) Received: by 10.140.107.55 with HTTP; Tue, 25 Mar 2014 20:22:48 -0700 (PDT) In-Reply-To: <40EBFD44-AF04-446B-AE9E-4BA535999B14@istaff.org> References: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> <40EBFD44-AF04-446B-AE9E-4BA535999B14@istaff.org> Date: Wed, 26 Mar 2014 04:22:48 +0100 Message-ID: From: Daniel Migault To: John Curran Content-Type: multipart/alternative; boundary=047d7bacbaaaa714ad04f579fb62 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/JlHepfXxDDh8_TU8DD1xg78O6Co Cc: "internetgovtech@iab.org" , "ietf@ietf.org" , Abdussalam Baryun Subject: Re: [Internetgovtech] NTIA & IANA 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, 26 Mar 2014 03:22:52 -0000 --047d7bacbaaaa714ad04f579fb62 Content-Type: text/plain; charset=ISO-8859-1 Hi, For those who wants to have the complete session, audioand transcripts are online. BR, Daniel [AUDIO] http://singapore49.icann.org/en/schedule/mon-iana-accountability [TRANSCRIPT] http://singapore49.icann.org/en/schedule/mon-iana-accountability/transcript-iana-accountability-24mar14-en On Tue, Mar 25, 2014 at 8:44 PM, John Curran wrote: > On Mar 26, 2014, at 1:12 AM, Abdussalam Baryun > wrote: > > On Monday, March 24, 2014, IAB Chair wrote: > >> Today at ICANN 49 in Singapore, process to develop an Internet community >> plan was launched. Since the announcement by NTA just over a week ago, >> discussions have been taking place in many hallways and mail lists. Input >> from the all of the community discussions needs to be gathered, and ICANN >> has provided a mail list for this purpose: ianatransition@icann.org. An >> archive is available so that everyone can see the collection of prior >> postings to the list: http://mm.icann.org/pipermail/ianatransition/. > > > ICANN needs to encourage discussions not just make a list and think > community people will do directly. > > > AB - > > As far as I can tell, this phase is simply an expedited call for input on > the cross-community > process and timeline that is to be used for IANA transition plan > development - specifically, > the entire community is being asked to comment on the presentation of > process and timeline > that ICANN (as the USG NTIA designated process convener) provided in > Singapore - > > < > http://singapore49.icann.org/en/schedule/mon-iana-accountability/presentation-iana-accountability-24mar14-en > > > > Amongst other things, that presentation asks the following framing > questions regarding the > IANA transition plan development process - > > - What are the most important principles? > - What mechanisms are important to ensure a well-run process? > > It also notes a fairly large list of ICANN, IETF, and RIR meetings > occurring between now and > September 2015, although how community discussion and cross-community > synthesis of inputs > appears to be a completely open question (and hence particularly ripe for > community input now) > > The goal is to gather the input by 27 March 2014, > > > That is short time, I suggest icann postpones the goal date. I don't see > many inputs (only 3 or 4) on the list of icann, > > > It is incredibly short timeframe, but it's also important to get back > comments on the proposed > timeline and process, integrate those into a draft, and get that out for > comment by 7 April so > that it can be finalized, since it is only upon completion of all that > we'll be able to utilize the > resulting development process and have some discussions of the actual > content of the IANA > Transition Plan. > > For example, if you feel that there should be just one global mailing list > for the IANA transition > plan development with continuous synthesis of all input, or one discussion > in each community > each via their processes; or that we should use one global wiki-based plan > document editing > facility, or have an appointed steering committee to synthesize inputs > between communities, > or that there should be only a few selected face-to-face meetings where we > do open forum for > cross-community integration of positions, or that we should generate > initial draft IANA transition > plan text via a random number generator, or for that matter _any_ other > process suggestions > regarding the IANA transition plan development, now is the time to get > those submitted asap... > > As noted above, once ICANN integrates the received input on the > development process into a > draft document, it will go out to a formal consultation on or about 7 > April, so there will definitely > be an opportunity to respond to all of the process input at that time. > That is why if you feel that > a particular process or mechanism should be used to develop the IANA > Transition plan, it is > crucial to submit it by 27 March so that the entire cross-community set of > participants will see > it in the 7 April draft process/timeline document. > > (This is probably far more information about this process for input than > anyone actually wanted > to hear, but given the extremely tight timelines, I figured that is better > to write down everything > we can discern about it from being here onsite at the ICANN meeting...) > > FYI, > /John > > Disclaimer: My views alone. Not responsible for errors and omissions - > any resulting IANA > from this process is purely the responsibility of the > participants. > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bacbaaaa714ad04f579fb62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 2= 5, 2014 at 8:44 PM, John Curran <jcurran@istaff.org> wrote:=
On Mar 26, 2014, at 1:1= 2 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

On Monday, March 24, 2014, IAB Chair wr= ote:
Today at ICANN 49 in Singapore, process to develop an Internet community pl= an was launched. =A0Since the announcement by NTA just over a week ago, dis= cussions have been taking place in many hallways and mail lists. =A0Input f= rom the all of the community discussions needs to be gathered, and ICANN ha= s provided a mail list for this purpose: ianatransition@icann.org. = =A0An archive is available so that everyone can see the collection of prior= postings to the list: http://mm.icann.org/pipermail/ianatransition/.<= /blockquote>

ICANN needs to encourage discussions not just make a li= st and think community=A0people will do directly.=A0=A0

AB -=A0

As far as I= can tell, this phase is simply an expedited call for input on the cross-co= mmunity=A0
process and timeline that is to be used for IANA transition plan devel= opment - specifically,=A0
the entire community is being asked to = comment on the presentation of process and timeline=A0
that ICANN= (as the USG NTIA designated process convener) provided in Singapore -=A0


Amongst other things, that presentation asks the follow= ing framing questions regarding the=A0
IANA transition plan devel= opment process -=A0

=A0 =A0 - What are the most im= portant principles?
=A0 =A0 - What mechanisms are important to=A0ensure a well-run process?

It also notes a fairly large list of ICANN, IETF, and= RIR meetings occurring between now and=A0
September 2015, althou= gh how community discussion and cross-community synthesis of inputs=A0
appears to be a completely open question (and hence particularly ripe = for community input now)

The goal is to gather the input by =A027 March 2014,=A0

That is short time= , I suggest icann postpones the goal date.=A0=A0I don't see many=A0inpu= ts (only 3 or 4)=A0on the list of icann,=A0

It is incredibly short timefra= me, but it's also important to get back comments on the proposed
<= div>timeline and process, integrate those into a draft, and get that out fo= r comment by 7 April so=A0
that it can be finalized, since it is only upon completion of all that= we'll be able to utilize the=A0
resulting development proces= s and have some discussions of the actual content of the IANA=A0
Transition Plan. =A0

For example, if you feel that= there should be just one global mailing list for the IANA transition=A0
plan development with continuous synthesis of all input, or one dis= cussion in each community=A0
each via their processes; or that we should use one global wiki-based = plan document editing
facility, or have an appointed steering com= mittee to synthesize inputs between communities,
or that there sh= ould be only a few selected face-to-face meetings where we do open forum fo= r=A0
cross-community integration of positions, or that we should generate i= nitial draft IANA transition=A0
plan text via a random number gen= erator, or for that matter _any_ other process suggestions
regard= ing the IANA transition plan development, now is the time to get those subm= itted asap...

As noted above, once ICANN integrates the received inpu= t on the development process into a=A0
draft document, it will go= out to a formal consultation on or about 7 April, so there will definitely= =A0
be an opportunity to respond to all of the process input at that time.= =A0That is why if you feel that=A0
a particular process or mecha= nism should be used to develop the IANA Transition plan, it is=A0
crucial to submit it by 27 March so that the entire cross-community set of= participants will see=A0
it in the 7 April draft process/timeline document.

(This is probably far more information about this process for input t= han anyone actually wanted
to hear, but given the extremely tight= timelines, I figured that is better to write down everything
we can discern about it from being here onsite at the ICANN meeting...= )

FYI,
/John

Di= sclaimer: My views alone. =A0Not responsible for errors and omissions - any= resulting IANA
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from this process is purely the= responsibility of the participants.




--
Daniel Migault
Orange Labs= -- Security
+33 6 70 72 69 58
--047d7bacbaaaa714ad04f579fb62-- From nobody Wed Mar 26 00:11: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 820D51A02AE for ; Wed, 26 Mar 2014 00:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 yBsfaoWXBfsw for ; Wed, 26 Mar 2014 00:10:55 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D4ABF1A00FF for ; Wed, 26 Mar 2014 00:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17446; q=dns/txt; s=iport; t=1395817855; x=1397027455; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Krf8M3r2w9OguSv9xi0GTZ+tBijzfoJuHnatT4wVjf4=; b=I9L10cgDUo03PsJjPqwclS9CAMgHfGChmeY0nBNw7xwAKy03pyfkKUwW 0o1/D8ufeOvA1vtRPyxmNmSX1YLpahu37Xy36uR4zxO3Lok1S21xpcKmV VKmfrP3Zv11PgfWDIQtwVQdiAgJREzrM3BaE8NROSHbCygMzhy9xTGIGG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAKN8MlOrRDoJ/2dsb2JhbABZgwY7g2KFXroTgRgWdIIlAQEBBB0GSwoBEAkCDgoJFggDAgIJAwIBAgEPHwYRBg0BBQIBARCHUQMQDpEAnBeFWZUtDYcdF4xSgUsBAU8Hgm+BSQSFXpECgW2BMos2hUqDLzyBNQ X-IronPort-AV: E=Sophos;i="4.97,734,1389744000"; d="scan'208,217";a="109044462" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 26 Mar 2014 07:10:54 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.195.69]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2Q7Apa8032034; Wed, 26 Mar 2014 07:10:52 GMT Message-ID: <53327D7B.4020109@cisco.com> Date: Wed, 26 Mar 2014 08:10:51 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Daniel Migault References: <9DC44D2D-63DF-494E-A46B-E412D3F47AB2@iab.org> <40EBFD44-AF04-446B-AE9E-4BA535999B14@istaff.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040205080508050808060702" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OSC24GpoCIU9ToyCeMFvzvfutYE Cc: "internetgovtech@iab.org" , Warren Kumari , "ietf@ietf.org" Subject: Re: [Internetgovtech] NTIA & IANA 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, 26 Mar 2014 07:10:59 -0000 This is a multi-part message in MIME format. --------------040205080508050808060702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Everyone, For those who don't know, Daniel Migault is one of our two appointed IETF liaisons to the Technical Liaison Group (TLG) for ICANN. The other is Warren Kumari. Thanks Daniel for these pointers, and thanks both of you for your service. Eliot On 3/26/14, 4:22 AM, Daniel Migault wrote: > Hi, > > For those who wants to have the complete session, audio > and > transcripts > > are online. > > BR, > Daniel > > [AUDIO] http://singapore49.icann.org/en/schedule/mon-iana-accountability > [TRANSCRIPT] > http://singapore49.icann.org/en/schedule/mon-iana-accountability/transcript-iana-accountability-24mar14-en > > > On Tue, Mar 25, 2014 at 8:44 PM, John Curran > wrote: > > On Mar 26, 2014, at 1:12 AM, Abdussalam Baryun > > > wrote: > >> On Monday, March 24, 2014, IAB Chair wrote: >> >> Today at ICANN 49 in Singapore, process to develop an >> Internet community plan was launched. Since the announcement >> by NTA just over a week ago, discussions have been taking >> place in many hallways and mail lists. Input from the all of >> the community discussions needs to be gathered, and ICANN has >> provided a mail list for this purpose: >> ianatransition@icann.org. An archive is available so that >> everyone can see the collection of prior postings to the >> list: http://mm.icann.org/pipermail/ianatransition/. >> >> >> ICANN needs to encourage discussions not just make a list and >> think community people will do directly. > > AB - > > As far as I can tell, this phase is simply an expedited call for > input on the cross-community > process and timeline that is to be used for IANA transition plan > development - specifically, > the entire community is being asked to comment on the presentation > of process and timeline > that ICANN (as the USG NTIA designated process convener) provided > in Singapore - > > > > > Amongst other things, that presentation asks the following framing > questions regarding the > IANA transition plan development process - > > - What are the most important principles? > - What mechanisms are important to ensure a well-run process? > > It also notes a fairly large list of ICANN, IETF, and RIR meetings > occurring between now and > September 2015, although how community discussion and > cross-community synthesis of inputs > appears to be a completely open question (and hence particularly > ripe for community input now) > >> The goal is to gather the input by 27 March 2014, >> >> >> That is short time, I suggest icann postpones the goal date. I >> don't see many inputs (only 3 or 4) on the list of icann, > > It is incredibly short timeframe, but it's also important to get > back comments on the proposed > timeline and process, integrate those into a draft, and get that > out for comment by 7 April so > that it can be finalized, since it is only upon completion of all > that we'll be able to utilize the > resulting development process and have some discussions of the > actual content of the IANA > Transition Plan. > > For example, if you feel that there should be just one global > mailing list for the IANA transition > plan development with continuous synthesis of all input, or one > discussion in each community > each via their processes; or that we should use one global > wiki-based plan document editing > facility, or have an appointed steering committee to synthesize > inputs between communities, > or that there should be only a few selected face-to-face meetings > where we do open forum for > cross-community integration of positions, or that we should > generate initial draft IANA transition > plan text via a random number generator, or for that matter _any_ > other process suggestions > regarding the IANA transition plan development, now is the time to > get those submitted asap... > > As noted above, once ICANN integrates the received input on the > development process into a > draft document, it will go out to a formal consultation on or > about 7 April, so there will definitely > be an opportunity to respond to all of the process input at that > time. That is why if you feel that > a particular process or mechanism should be used to develop the > IANA Transition plan, it is > crucial to submit it by 27 March so that the entire > cross-community set of participants will see > it in the 7 April draft process/timeline document. > > (This is probably far more information about this process for > input than anyone actually wanted > to hear, but given the extremely tight timelines, I figured that > is better to write down everything > we can discern about it from being here onsite at the ICANN > meeting...) > > FYI, > /John > > Disclaimer: My views alone. Not responsible for errors and > omissions - any resulting IANA > from this process is purely the responsibility > of the participants. > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 --------------040205080508050808060702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Everyone,

For those who don't know, Daniel Migault is one of our two appointed IETF liaisons to the Technical Liaison Group (TLG) for ICANN.  The other is Warren Kumari.  Thanks Daniel for these pointers, and thanks both of you for your service.

Eliot

On 3/26/14, 4:22 AM, Daniel Migault wrote:


On Tue, Mar 25, 2014 at 8:44 PM, John Curran <jcurran@istaff.org> wrote:
On Mar 26, 2014, at 1:12 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

On Monday, March 24, 2014, IAB Chair wrote:
Today at ICANN 49 in Singapore, process to develop an Internet community plan was launched.  Since the announcement by NTA just over a week ago, discussions have been taking place in many hallways and mail lists.  Input from the all of the community discussions needs to be gathered, and ICANN has provided a mail list for this purpose: ianatransition@icann.org.  An archive is available so that everyone can see the collection of prior postings to the list: http://mm.icann.org/pipermail/ianatransition/.

ICANN needs to encourage discussions not just make a list and think community people will do directly.  

AB - 

As far as I can tell, this phase is simply an expedited call for input on the cross-community 
process and timeline that is to be used for IANA transition plan development - specifically, 
the entire community is being asked to comment on the presentation of process and timeline 
that ICANN (as the USG NTIA designated process convener) provided in Singapore - 


Amongst other things, that presentation asks the following framing questions regarding the 
IANA transition plan development process - 

    - What are the most important principles?
    - What mechanisms are important to ensure a well-run process?

It also notes a fairly large list of ICANN, IETF, and RIR meetings occurring between now and 
September 2015, although how community discussion and cross-community synthesis of inputs 
appears to be a completely open question (and hence particularly ripe for community input now)

The goal is to gather the input by  27 March 2014, 

That is short time, I suggest icann postpones the goal date.  I don't see many inputs (only 3 or 4) on the list of icann, 

It is incredibly short timeframe, but it's also important to get back comments on the proposed
timeline and process, integrate those into a draft, and get that out for comment by 7 April so 
that it can be finalized, since it is only upon completion of all that we'll be able to utilize the 
resulting development process and have some discussions of the actual content of the IANA 
Transition Plan.  

For example, if you feel that there should be just one global mailing list for the IANA transition 
plan development with continuous synthesis of all input, or one discussion in each community 
each via their processes; or that we should use one global wiki-based plan document editing
facility, or have an appointed steering committee to synthesize inputs between communities,
or that there should be only a few selected face-to-face meetings where we do open forum for 
cross-community integration of positions, or that we should generate initial draft IANA transition 
plan text via a random number generator, or for that matter _any_ other process suggestions
regarding the IANA transition plan development, now is the time to get those submitted asap...

As noted above, once ICANN integrates the received input on the development process into a 
draft document, it will go out to a formal consultation on or about 7 April, so there will definitely 
be an opportunity to respond to all of the process input at that time.  That is why if you feel that 
a particular process or mechanism should be used to develop the IANA Transition plan, it is 
crucial to submit it by 27 March so that the entire cross-community set of participants will see 
it in the 7 April draft process/timeline document.

(This is probably far more information about this process for input than anyone actually wanted
to hear, but given the extremely tight timelines, I figured that is better to write down everything
we can discern about it from being here onsite at the ICANN meeting...)

FYI,
/John

Disclaimer: My views alone.  Not responsible for errors and omissions - any resulting IANA
                   from this process is purely the responsibility of the participants.




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--------------040205080508050808060702-- From nobody Wed Mar 26 02:12: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 20D111A0303 for ; Wed, 26 Mar 2014 02:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.632 X-Spam-Level: * X-Spam-Status: No, score=1.632 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 ATxaTysvQ2Xw for ; Wed, 26 Mar 2014 02:12:03 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3D61A02EC for ; Wed, 26 Mar 2014 02:12:03 -0700 (PDT) Received: from [85.159.233.116] (port=42000 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WSjsP-0000sh-5i; Wed, 26 Mar 2014 02:12:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Mar 2014 10:11:55 +0100 To: "discuss@1net.org List" From: Jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_226480863==.ALT" 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/QT6AODPHqFjYFNikqhQ2MeIhz0k Cc: "internetgovtech@iab.org" , ianatransition@icann.org, iucg@ietf.org Subject: [Internetgovtech] What is MSism? 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, 26 Mar 2014 09:12:05 -0000 --=====================_226480863==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The first question should be "what is MSism". I have posted this definition and its comparison with polycracy. I am surprised by the resulting general agreement (no one opposed). I therefore copy it to some other mailing lists, so we have a common working basis. ---- MSism, as we hear of it, is shaped from Doug Engelbart's (http://www.dougengelbart.org/about/dce-bio.html) concepts. It is a diktyarchy (from diktyos: network) i.e. an intergovernance between peer structured autoselected entities. The autoselection process is based upon the time network/global availability, i.e. the capacity to collectively meet on a mailing list and anytime anywhere. This is to produce the buzz that will exceed the noise of reality and the squawk of the multitude. It is to polycracy the equivalent of monarchy to democracy. Technically, MS proceeds from a root/server/client hierarchic model (however its slogan is "on an equal footing" [for the leaders only, cf. RFC 6852, Montevideo statement], while polycracy proceeds from a "master and master" open capability model. The difficulty in the extension from democracy to polycracy is that diktyarchy looks democratic to the onlooker: democracy is about decision decentralization; MSism keeps that decision decentralization within its political, business, and societal structures that dialogue together. Polycracy is actually about decision distribution among political, business, and societal individuals who multilogue together in any manner they wish and decide by themselves. This is why MSism is a method to deploy "reasonable" decisions collectively agreed among mutually accepted share/status/stake-holders, while polycracy is the autopoietic emergence of the life of the multitude through individual considered decisions. Both systems are adapted to our time. MSism is selected network centric, and polycracy is people centered. In MSism, structures (states and corporates) ally to govern the "others", i.e. the WSIS definition of the "civil society", and sponsor politically acceptable civil society structures. It is an interesting concept by its "mid-up/down" practical capacities of substitution: it is alliances centered. In its own turn, polycracy accepts substitution but only in its normal role of substitution of subsidiarity: it is people centered. What is at stake in here for the Internet Governance is the virtual world built as an ICANN contractual diktyarchy vs. a real world that will progressively erode the NTIA leadership in an operational polycracy. The real question is about whether this evolution will occur in the most seamless way possible, in the best respect of the "digility" (from digital personality) of everyone. This is why I propose to start from what we know, as the WSIS has advised. If we proceed from the person ("centrada en la persona" says the Spanish version of the WSIS declaration) entering the digisphere, i.e. the digitally split vision of its environmental reality, and considers its digital rights. We can pursue with the inviolability of people's "digicile" (digital-domicile: using simple, clear, universally understandable notions extending our daily life in the digisphere through direct metaphors can only help). From there we can then proceed and differentiate what belongs to physical government, ethical behavior, and digital governance. --=====================_226480863==.ALT Content-Type: text/html; charset="us-ascii" The first question should be "what is MSism". I have posted this definition and its comparison with polycracy. I am surprised by the resulting general agreement (no one opposed). I therefore copy it to some other mailing lists, so we have a common working basis.

----

MSism, as we hear of it, is shaped from Doug Engelbarts ( http://www.dougengelbart.org/about/dce-bio.html ) concepts. It is a diktyarchy (from diktyos: network) i.e. an intergovernance between peer structured autoselected entities. The autoselection process is based upon the time network/global availability, i.e. the capacity to collectively meet on a mailing list and anytime anywhere. This is to produce the buzz that will exceed the noise of reality and the squawk of the multitude. It is to polycracy the equivalent of monarchy to democracy. Technically, MS proceeds from a root/server/client hierarchic model (however its slogan is "on an equal footing" [for the leaders only, cf. RFC 6852, Montevideo statement], while polycracy proceeds from a "master and master" open capability model.

The difficulty in the extension from democracy to polycracy is that diktyarchy looks democratic to the onlooker: democracy is about decision decentralization; MSism keeps that decision decentralization within its political, business, and societal structures that dialogue together. Polycracy is actually about decision distribution among political, business, and societal individuals who multilogue together in any manner they wish and decide by themselves.

This is why MSism is a method to deploy "reasonable" decisions collectively agreed among mutually accepted share/status/stake-holders, while polycracy is the autopoietic emergence of the life of the multitude through individual considered decisions. Both systems are adapted to our time. MSism is selected network centric, and polycracy is people centered.

In MSism, structures (states and corporates) ally to govern the "others", i.e. the WSIS definition of the "civil society", and sponsor politically acceptable civil society structures. It is an interesting concept by its "mid-up/down" practical capacities of substitution: it is alliances centered. In its own turn, polycracy accepts substitution but only in its normal role of substitution of subsidiarity: it is people centered.

What is at stake in here for the Internet Governance is the virtual world built as an ICANN contractual diktyarchy vs. a real world that will progressively erode the NTIA leadership in an operational polycracy. The real question is about whether this evolution will occur in the most seamless way possible, in the best respect of the "digility" (from digital personality) of everyone.

This is why I propose to start from what we know, as the WSIS has advised. If we proceed from the person ("centrada en la persona" says the Spanish version of the WSIS declaration) entering the digisphere, i.e. the digitally split vision of its environmental reality, and considers its digital rights. We can pursue with the inviolability of peoples digicile (digital-domicile: using simple, clear, universally understandable notions extending our daily life in the digisphere through direct metaphors can only help). From there we can then proceed and differentiate what belongs to physical government, ethical behavior, and digital governance. --=====================_226480863==.ALT-- From nobody Wed Mar 26 06:10: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 283091A0316 for ; Wed, 26 Mar 2014 03:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 VjzQqxWp59OU for ; Wed, 26 Mar 2014 03:51:46 -0700 (PDT) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC56C1A0314 for ; Wed, 26 Mar 2014 03:51:45 -0700 (PDT) Received: from pdce1.reedsmith.com (pdce1.reedsmith.com [199.125.201.10]) (Using TLS) by us-mta-5.us.mimecast.lan; Wed, 26 Mar 2014 06:51:33 -0400 Received: from USPDCMAIL006P.reedsmith.com (10.180.2.6) by pdce1.reedsmith.com (10.180.221.14) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 26 Mar 2014 06:51:31 -0400 Received: from USPDCMAIL002P.reedsmith.com ([fe80::78c8:1ed3:1b7a:8fd]) by USPDCMAIL006P.reedsmith.com ([fe80::6095:f68c:6d1c:703a%19]) with mapi id 14.03.0181.007; Wed, 26 Mar 2014 06:51:31 -0400 From: "Shatan, Gregory S." To: 'Jefsey' , "discuss@1net.org List" Thread-Topic: [discuss] What is MSism? Thread-Index: AQHPSNOXH5U+FGjmREW6QFFwYFCY+JrzLnPg Date: Wed, 26 Mar 2014 10:51:31 +0000 Message-ID: References: <01534.114032605130103203@us-mta-3.us.mimecast.lan> In-Reply-To: <01534.114032605130103203@us-mta-3.us.mimecast.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.180.2.100] x-exclaimer-md-config: 35a2a35a-5651-415b-b3fc-0e9c17e2e02e MIME-Version: 1.0 X-MC-Unique: TXxv8Zm2SACNz2MU_xEetg-1 Content-Type: multipart/alternative; boundary="_000_DBD9F335EA4A684FA2640EEE94EEF27222C20929USPDCMAIL002Pre_" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wmUJdT_3sOiH3i-J3ceyxRhaINs X-Mailman-Approved-At: Wed, 26 Mar 2014 06:10:25 -0700 Cc: "internetgovtech@iab.org" , "ianatransition@icann.org" , "iucg@ietf.org" Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 10:51:51 -0000 --_000_DBD9F335EA4A684FA2640EEE94EEF27222C20929USPDCMAIL002Pre_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TXkgcmVzcG9uc2UgdG8gdGhpcyBwb3N0IGlzIHRvIHBvaW50IHRvIHR3byBvZiBHZW9yZ2XigJlz IGV0aXF1ZXR0ZSBpdGVtczoNCg0KOS4gSWYgdGhlcmUgYXJlIG5vIHJlc3BvbnNlcyB0byBhIHBv c3QsIHBvc3RlcnMgc2hvdWxkIG5vdCBhc3N1bWUgdGhhdCB0aGUgbWF0ZXJpYWwgdGhleSBoYXZl IHBvc3RlZCBoYXMgYmVlbiBhZ3JlZWQgdG8gYnkgcmVhZGVycy4gIFBlb3BsZSBvbiB0aGUgbGlz dCBnZW5lcmFsbHkgaGF2ZSBidXN5IGxpdmVzLCBhbmQgb2Z0ZW4gd2lsbCBub3QgcmVzcG9uZCB0 byBwb3N0cy4gIFN0YXRlbWVudHMgc3VjaCBhcyDigJxubyBvbmUgb24gdGhlIGxpc3QgaGFzIHJl ZnV0ZWQgbXkgc3RhdGVtZW50IHlldCIgc2hvdWxkIG5vdCBsZWFkIHRvIHRoZSBhc3N1bXB0aW9u IHRoYXQgb3RoZXJzIGFncmVlIHdpdGggaXQuICBJdCBpcyBlcXVhbGx5IGxpa2VseSB0aGF0IHRo ZSBwb3N0IGlzIGp1ZGdlZCB0byBiZSBpbmNvcnJlY3Qgb3IgaXJyZWxldmFudC4gUmVhZGVycyBo YXZlIG5vIG9ibGlnYXRpb24gdG8gY29ycmVjdCBlcnJvbmVvdXMgbWF0ZXJpYWwgdGhhdCBoYXMg YmVlbiBwb3N0ZWQgdG8gdGhlIGxpc3QgYnkgb3RoZXJzLg0KDQo1LiBTdWNjZXNzZnVsIHBvc3Rz IHVzZSB2b2NhYnVsYXJ5IHRoYXQgaXMgc2ltcGxlIGFuZCB3aG9zZSBtZWFuaW5nIGlzIHdlbGwt dW5kZXJzdG9vZCBieSByZWFkZXJzIG9mIHRoZSBsaXN0LiAgU3VjY2Vzc2Z1bCBwb3N0cyBhcmUg Zm9ybWF0dGVkICB3aXRoIHNvbWUgY2FyZSBzbyB0aGF0IHRoZXkgYXJlIGVhc2lseSByZWFkYWJs ZSBieSBvdGhlcnMuDQoNCkFuZCBJIHdvdWxkIGFsc28gcG9pbnQgdG8gbXkgc3VnZ2VzdGVkIGl0 ZW0gb2YgZXRpcXVldHRlOg0KDQpEb27igJl0IGNyb3NzLXBvc3QsIGV4Y2VwdCB0byBwcm92aWRl IHNvbWUgYmFzaWMgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBkaXNzZW1pbmF0ZWQgd2lk ZWx5IChlLmcuLCBOVElBIGFubm91bmNlbWVudCBvciBNYXJjYSBDaXZpbCksIGFuZCBldmVuIHRo aXMgc2hvdWxkIGJlIGF2b2lkZWQuICBEb27igJl0IGNyb3NzLXBvc3Qgb3BpbmlvbnMgb3IgYW55 dGhpbmcgdGhhdCB3b3VsZCByZXF1aXJlIGEgcmVzcG9uc2UuICBEb27igJl0IGNyb3NzLXBvc3Qg cmVwbGllcy4NCg0KR3JlZyBTaGF0YW4NCg0KRnJvbTogZGlzY3Vzcy1ib3VuY2VzQDFuZXQub3Jn IFttYWlsdG86ZGlzY3Vzcy1ib3VuY2VzQDFuZXQub3JnXSBPbiBCZWhhbGYgT2YgSmVmc2V5DQpT ZW50OiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0IDU6MTIgUE0NClRvOiBkaXNjdXNzQDFuZXQu b3JnIExpc3QNCkNjOiBpbnRlcm5ldGdvdnRlY2hAaWFiLm9yZzsgaWFuYXRyYW5zaXRpb25AaWNh bm4ub3JnOyBpdWNnQGlldGYub3JnDQpTdWJqZWN0OiBbZGlzY3Vzc10gV2hhdCBpcyBNU2lzbT8N Cg0KVGhlIGZpcnN0IHF1ZXN0aW9uIHNob3VsZCBiZSAid2hhdCBpcyBNU2lzbSIuIEkgaGF2ZSBw b3N0ZWQgdGhpcyBkZWZpbml0aW9uIGFuZCBpdHMgY29tcGFyaXNvbiB3aXRoIHBvbHljcmFjeS4g SSBhbSBzdXJwcmlzZWQgYnkgdGhlIHJlc3VsdGluZyBnZW5lcmFsIGFncmVlbWVudCAobm8gb25l IG9wcG9zZWQpLiBJIHRoZXJlZm9yZSBjb3B5IGl0IHRvIHNvbWUgb3RoZXIgbWFpbGluZyBsaXN0 cywgc28gd2UgaGF2ZSBhIGNvbW1vbiB3b3JraW5nIGJhc2lzLg0KDQotLS0tDQoNCk1TaXNtLCBh cyB3ZSBoZWFyIG9mIGl0LCBpcyBzaGFwZWQgZnJvbSBEb3VnIEVuZ2VsYmFydOKAmXMgKCBodHRw Oi8vd3d3LmRvdWdlbmdlbGJhcnQub3JnL2Fib3V0L2RjZS1iaW8uaHRtbCApIGNvbmNlcHRzLiBJ dCBpcyBhIGRpa3R5YXJjaHkgKGZyb20gZGlrdHlvczogbmV0d29yaykgaS5lLiBhbiBpbnRlcmdv dmVybmFuY2UgYmV0d2VlbiBwZWVyIHN0cnVjdHVyZWQgYXV0b3NlbGVjdGVkIGVudGl0aWVzLiBU aGUgYXV0b3NlbGVjdGlvbiBwcm9jZXNzIGlzIGJhc2VkIHVwb24gdGhlIHRpbWUgbmV0d29yay9n bG9iYWwgYXZhaWxhYmlsaXR5LCBpLmUuIHRoZSBjYXBhY2l0eSB0byBjb2xsZWN0aXZlbHkgbWVl dCBvbiBhIG1haWxpbmcgbGlzdCBhbmQgYW55dGltZSBhbnl3aGVyZS4gVGhpcyBpcyB0byBwcm9k dWNlIHRoZSBidXp6IHRoYXQgd2lsbCBleGNlZWQgdGhlIG5vaXNlIG9mIHJlYWxpdHkgYW5kIHRo ZSBzcXVhd2sgb2YgdGhlIG11bHRpdHVkZS4gSXQgaXMgdG8gcG9seWNyYWN5IHRoZSBlcXVpdmFs ZW50IG9mIG1vbmFyY2h5IHRvIGRlbW9jcmFjeS4gVGVjaG5pY2FsbHksIE1TIHByb2NlZWRzIGZy b20gYSByb290L3NlcnZlci9jbGllbnQgaGllcmFyY2hpYyBtb2RlbCAoaG93ZXZlciBpdHMgc2xv Z2FuIGlzICJvbiBhbiBlcXVhbCBmb290aW5nIiBbZm9yIHRoZSBsZWFkZXJzIG9ubHksIGNmLiBS RkMgNjg1MiwgTW9udGV2aWRlbyBzdGF0ZW1lbnRdLCB3aGlsZSBwb2x5Y3JhY3kgcHJvY2VlZHMg ZnJvbSBhICJtYXN0ZXIgYW5kIG1hc3RlciIgb3BlbiBjYXBhYmlsaXR5IG1vZGVsLg0KDQpUaGUg ZGlmZmljdWx0eSBpbiB0aGUgZXh0ZW5zaW9uIGZyb20gZGVtb2NyYWN5IHRvIHBvbHljcmFjeSBp cyB0aGF0IGRpa3R5YXJjaHkgbG9va3MgZGVtb2NyYXRpYyB0byB0aGUgb25sb29rZXI6IGRlbW9j cmFjeSBpcyBhYm91dCBkZWNpc2lvbiBkZWNlbnRyYWxpemF0aW9uOyBNU2lzbSBrZWVwcyB0aGF0 IGRlY2lzaW9uIGRlY2VudHJhbGl6YXRpb24gd2l0aGluIGl0cyBwb2xpdGljYWwsIGJ1c2luZXNz LCBhbmQgc29jaWV0YWwgc3RydWN0dXJlcyB0aGF0IGRpYWxvZ3VlIHRvZ2V0aGVyLiBQb2x5Y3Jh Y3kgaXMgYWN0dWFsbHkgYWJvdXQgZGVjaXNpb24gZGlzdHJpYnV0aW9uIGFtb25nIHBvbGl0aWNh bCwgYnVzaW5lc3MsIGFuZCBzb2NpZXRhbCBpbmRpdmlkdWFscyB3aG8gbXVsdGlsb2d1ZSB0b2dl dGhlciBpbiBhbnkgbWFubmVyIHRoZXkgd2lzaCBhbmQgZGVjaWRlIGJ5IHRoZW1zZWx2ZXMuDQoN ClRoaXMgaXMgd2h5IE1TaXNtIGlzIGEgbWV0aG9kIHRvIGRlcGxveSAicmVhc29uYWJsZSIgZGVj aXNpb25zIGNvbGxlY3RpdmVseSBhZ3JlZWQgYW1vbmcgbXV0dWFsbHkgYWNjZXB0ZWQgc2hhcmUv c3RhdHVzL3N0YWtlLWhvbGRlcnMsIHdoaWxlIHBvbHljcmFjeSBpcyB0aGUgYXV0b3BvaWV0aWMg ZW1lcmdlbmNlIG9mIHRoZSBsaWZlIG9mIHRoZSBtdWx0aXR1ZGUgdGhyb3VnaCBpbmRpdmlkdWFs IGNvbnNpZGVyZWQgZGVjaXNpb25zLiBCb3RoIHN5c3RlbXMgYXJlIGFkYXB0ZWQgdG8gb3VyIHRp bWUuIE1TaXNtIGlzIHNlbGVjdGVkIG5ldHdvcmsgY2VudHJpYywgYW5kIHBvbHljcmFjeSBpcyBw ZW9wbGUgY2VudGVyZWQuDQoNCkluIE1TaXNtLCBzdHJ1Y3R1cmVzIChzdGF0ZXMgYW5kIGNvcnBv cmF0ZXMpIGFsbHkgdG8gZ292ZXJuIHRoZSAib3RoZXJzIiwgaS5lLiB0aGUgV1NJUyBkZWZpbml0 aW9uIG9mIHRoZSAiY2l2aWwgc29jaWV0eSIsIGFuZCBzcG9uc29yIHBvbGl0aWNhbGx5IGFjY2Vw dGFibGUgY2l2aWwgc29jaWV0eSBzdHJ1Y3R1cmVzLiBJdCBpcyBhbiBpbnRlcmVzdGluZyBjb25j ZXB0IGJ5IGl0cyAibWlkLXVwL2Rvd24iIHByYWN0aWNhbCBjYXBhY2l0aWVzIG9mIHN1YnN0aXR1 dGlvbjogaXQgaXMgYWxsaWFuY2VzIGNlbnRlcmVkLiBJbiBpdHMgb3duIHR1cm4sIHBvbHljcmFj eSBhY2NlcHRzIHN1YnN0aXR1dGlvbiBidXQgb25seSBpbiBpdHMgbm9ybWFsIHJvbGUgb2Ygc3Vi c3RpdHV0aW9uIG9mIHN1YnNpZGlhcml0eTogaXQgaXMgcGVvcGxlIGNlbnRlcmVkLg0KDQpXaGF0 IGlzIGF0IHN0YWtlIGluIGhlcmUgZm9yIHRoZSBJbnRlcm5ldCBHb3Zlcm5hbmNlIGlzIHRoZSB2 aXJ0dWFsIHdvcmxkIGJ1aWx0IGFzIGFuIElDQU5OIGNvbnRyYWN0dWFsIGRpa3R5YXJjaHkgdnMu IGEgcmVhbCB3b3JsZCB0aGF0IHdpbGwgcHJvZ3Jlc3NpdmVseSBlcm9kZSB0aGUgTlRJQSBsZWFk ZXJzaGlwIGluIGFuIG9wZXJhdGlvbmFsIHBvbHljcmFjeS4gVGhlIHJlYWwgcXVlc3Rpb24gaXMg YWJvdXQgd2hldGhlciB0aGlzIGV2b2x1dGlvbiB3aWxsIG9jY3VyIGluIHRoZSBtb3N0IHNlYW1s ZXNzIHdheSBwb3NzaWJsZSwgaW4gdGhlIGJlc3QgcmVzcGVjdCBvZiB0aGUgImRpZ2lsaXR5IiAo ZnJvbSBkaWdpdGFsIHBlcnNvbmFsaXR5KSBvZiBldmVyeW9uZS4NCg0KVGhpcyBpcyB3aHkgSSBw cm9wb3NlIHRvIHN0YXJ0IGZyb20gd2hhdCB3ZSBrbm93LCBhcyB0aGUgV1NJUyBoYXMgYWR2aXNl ZC4gSWYgd2UgcHJvY2VlZCBmcm9tIHRoZSBwZXJzb24gKCJjZW50cmFkYSBlbiBsYSBwZXJzb25h IiBzYXlzIHRoZSBTcGFuaXNoIHZlcnNpb24gb2YgdGhlIFdTSVMgZGVjbGFyYXRpb24pIGVudGVy aW5nIHRoZSBkaWdpc3BoZXJlLCBpLmUuIHRoZSBkaWdpdGFsbHkgc3BsaXQgdmlzaW9uIG9mIGl0 cyBlbnZpcm9ubWVudGFsIHJlYWxpdHksIGFuZCBjb25zaWRlcnMgaXRzIGRpZ2l0YWwgcmlnaHRz LiBXZSBjYW4gcHVyc3VlIHdpdGggdGhlIGludmlvbGFiaWxpdHkgb2YgcGVvcGxl4oCZcyDigJxk aWdpY2lsZeKAnSAoZGlnaXRhbC1kb21pY2lsZTogdXNpbmcgc2ltcGxlLCBjbGVhciwgdW5pdmVy c2FsbHkgdW5kZXJzdGFuZGFibGUgbm90aW9ucyBleHRlbmRpbmcgb3VyIGRhaWx5IGxpZmUgaW4g dGhlIGRpZ2lzcGhlcmUgdGhyb3VnaCBkaXJlY3QgbWV0YXBob3JzIGNhbiBvbmx5IGhlbHApLiBG cm9tIHRoZXJlIHdlIGNhbiB0aGVuIHByb2NlZWQgYW5kIGRpZmZlcmVudGlhdGUgd2hhdCBiZWxv bmdzIHRvIHBoeXNpY2FsIGdvdmVybm1lbnQsIGV0aGljYWwgYmVoYXZpb3IsIGFuZCBkaWdpdGFs IGdvdmVybmFuY2UuDQoNCg0KDQoqICogKg0KDQpUaGlzIEUtbWFpbCwgYWxvbmcgd2l0aCBhbnkg YXR0YWNobWVudHMsIGlzIGNvbnNpZGVyZWQgY29uZmlkZW50aWFsIGFuZCBtYXkgd2VsbCBiZSBs ZWdhbGx5IHByaXZpbGVnZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCB5b3Ug YXJlIG9uIG5vdGljZSBvZiBpdHMgc3RhdHVzLiBQbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5 IGJ5IHJlcGx5IGUtbWFpbCBhbmQgdGhlbiBkZWxldGUgdGhpcyBtZXNzYWdlIGZyb20geW91ciBz eXN0ZW0uIFBsZWFzZSBkbyBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3Nlcywg b3IgZGlzY2xvc2UgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uIFRoYW5rIHlvdSBm b3IgeW91ciBjb29wZXJhdGlvbi4NCg0KKiAqICoNCg0KVG8gZW5zdXJlIGNvbXBsaWFuY2Ugd2l0 aCBUcmVhc3VyeSBEZXBhcnRtZW50IHJlZ3VsYXRpb25zLCB3ZSBpbmZvcm0geW91IHRoYXQsIHVu bGVzcyBvdGhlcndpc2UgaW5kaWNhdGVkIGluIHdyaXRpbmcsIGFueSBVLlMuIEZlZGVyYWwgdGF4 IGFkdmljZSBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uICAoaW5jbHVkaW5nIGFueSBh dHRhY2htZW50cykgaXMgbm90IGludGVuZGVkIG9yIHdyaXR0ZW4gdG8gYmUgdXNlZCwgYW5kIGNh bm5vdCBiZSB1c2VkLCBmb3IgdGhlIHB1cnBvc2Ugb2YgKDEpIGF2b2lkaW5nIHBlbmFsdGllcyB1 bmRlciB0aGUgSW50ZXJuYWwgUmV2ZW51ZSBDb2RlIG9yIGFwcGxpY2FibGUgc3RhdGUgYW5kIGxv Y2FsIHByb3Zpc2lvbnMgb3IgKDIpIHByb21vdGluZywgbWFya2V0aW5nIG9yIHJlY29tbWVuZGlu ZyB0byBhbm90aGVyIHBhcnR5IGFueSB0YXgtcmVsYXRlZCBtYXR0ZXJzIGFkZHJlc3NlZCBoZXJl aW4uDQoNCkRpc2NsYWltZXIgVmVyc2lvbiBSUy5VUy4yMC4xMC4wMA0K --_000_DBD9F335EA4A684FA2640EEE94EEF27222C20929USPDCMAIL002Pre_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBNYWlsIERpc2NsYWltZXJzIG9uIDA2OjUxOjMxIFdlZG5lc2RheSwgMjYgTWFyY2ggMjAx NCAtLT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+UC5kZDgyMWUzOS0wZjAx LTQ4MDQtOGVhZC01MzI3YTYwZmY3Yzkgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJLmRk ODIxZTM5LTBmMDEtNDgwNC04ZWFkLTUzMjdhNjBmZjdjOSB7DQoJTUFSR0lOOiAwY20gMGNtIDBw dA0KfQ0KRElWLmRkODIxZTM5LTBmMDEtNDgwNC04ZWFkLTUzMjdhNjBmZjdjOSB7DQoJTUFSR0lO OiAwY20gMGNtIDBwdA0KfQ0KVEFCTEUuZGQ4MjFlMzktMGYwMS00ODA0LThlYWQtNTMyN2E2MGZm N2M5VGFibGUgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFn ZTogU2VjdGlvbjENCn0NCjwvc3R5bGU+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8cCBjbGFzcz0iZGQ4MjFlMzktMGYw MS00ODA0LThlYWQtNTMyN2E2MGZmN2M5Ij48L3A+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk15IHJlc3BvbnNlIHRvIHRoaXMgcG9zdCBpcyB0byBwb2ludCB0byB0d28gb2Yg R2Vvcmdl4oCZcyBldGlxdWV0dGUgaXRlbXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj45LiBJZiB0aGVyZSBhcmUgbm8g cmVzcG9uc2VzIHRvIGEgcG9zdCwgcG9zdGVycyBzaG91bGQgbm90IGFzc3VtZSB0aGF0IHRoZSBt YXRlcmlhbCB0aGV5IGhhdmUgcG9zdGVkIGhhcyBiZWVuIGFncmVlZCB0byBieSByZWFkZXJzLiZu YnNwOyBQZW9wbGUgb24gdGhlIGxpc3QgZ2VuZXJhbGx5DQogaGF2ZSBidXN5IGxpdmVzLCBhbmQg b2Z0ZW4gd2lsbCBub3QgcmVzcG9uZCB0byBwb3N0cy4mbmJzcDsgU3RhdGVtZW50cyBzdWNoIGFz IOKAnG5vIG9uZSBvbiB0aGUgbGlzdCBoYXMgcmVmdXRlZCBteSBzdGF0ZW1lbnQgeWV0JnF1b3Q7 IHNob3VsZCBub3QgbGVhZCB0byB0aGUgYXNzdW1wdGlvbiB0aGF0IG90aGVycyBhZ3JlZSB3aXRo IGl0LiZuYnNwOyBJdCBpcyBlcXVhbGx5IGxpa2VseSB0aGF0IHRoZSBwb3N0IGlzIGp1ZGdlZCB0 byBiZSBpbmNvcnJlY3Qgb3IgaXJyZWxldmFudC4NCiBSZWFkZXJzIGhhdmUgbm8gb2JsaWdhdGlv biB0byBjb3JyZWN0IGVycm9uZW91cyBtYXRlcmlhbCB0aGF0IGhhcyBiZWVuIHBvc3RlZCB0byB0 aGUgbGlzdCBieSBvdGhlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj41LiBTdWNjZXNzZnVsIHBvc3RzIHVzZSB2b2Nh YnVsYXJ5IHRoYXQgaXMgc2ltcGxlIGFuZCB3aG9zZSBtZWFuaW5nIGlzIHdlbGwtdW5kZXJzdG9v ZCBieSByZWFkZXJzIG9mIHRoZSBsaXN0LiZuYnNwOyBTdWNjZXNzZnVsIHBvc3RzIGFyZSBmb3Jt YXR0ZWQmbmJzcDsgd2l0aCBzb21lIGNhcmUNCiBzbyB0aGF0IHRoZXkgYXJlIGVhc2lseSByZWFk YWJsZSBieSBvdGhlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgSSB3b3VsZCBhbHNvIHBvaW50IHRvIG15IHN1 Z2dlc3RlZCBpdGVtIG9mIGV0aXF1ZXR0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvbuKAmXQgY3Jvc3MtcG9zdCwg ZXhjZXB0IHRvIHByb3ZpZGUgc29tZSBiYXNpYyBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJl IGRpc3NlbWluYXRlZCB3aWRlbHkgKGUuZy4sIE5USUEgYW5ub3VuY2VtZW50IG9yIE1hcmNhIENp dmlsKSwgYW5kIGV2ZW4gdGhpcyBzaG91bGQNCiBiZSBhdm9pZGVkLiZuYnNwOyBEb27igJl0IGNy b3NzLXBvc3Qgb3BpbmlvbnMgb3IgYW55dGhpbmcgdGhhdCB3b3VsZCByZXF1aXJlIGEgcmVzcG9u c2UuJm5ic3A7IERvbuKAmXQgY3Jvc3MtcG9zdCByZXBsaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R3JlZyBTaGF0 YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkaXNjdXNzLWJvdW5jZXNAMW5ldC5vcmcgW21haWx0bzpk aXNjdXNzLWJvdW5jZXNAMW5ldC5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkplZnNleTxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0IDU6MTIgUE08YnI+DQo8Yj5U bzo8L2I+IGRpc2N1c3NAMW5ldC5vcmcgTGlzdDxicj4NCjxiPkNjOjwvYj4gaW50ZXJuZXRnb3Z0 ZWNoQGlhYi5vcmc7IGlhbmF0cmFuc2l0aW9uQGljYW5uLm9yZzsgaXVjZ0BpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBbZGlzY3Vzc10gV2hhdCBpcyBNU2lzbT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmlyc3QgcXVlc3Rpb24gc2hvdWxk IGJlICZxdW90O3doYXQgaXMgTVNpc20mcXVvdDsuIEkgaGF2ZSBwb3N0ZWQgdGhpcyBkZWZpbml0 aW9uIGFuZCBpdHMgY29tcGFyaXNvbiB3aXRoIHBvbHljcmFjeS4gSSBhbSBzdXJwcmlzZWQgYnkg dGhlIHJlc3VsdGluZyBnZW5lcmFsIGFncmVlbWVudCAobm8gb25lIG9wcG9zZWQpLiBJIHRoZXJl Zm9yZSBjb3B5IGl0IHRvIHNvbWUgb3RoZXIgbWFpbGluZyBsaXN0cywgc28gd2UgaGF2ZQ0KIGEg Y29tbW9uIHdvcmtpbmcgYmFzaXMuPGJyPg0KPGJyPg0KLS0tLTxicj4NCjxicj4NCjxhIG5hbWU9 Il9Hb0JhY2siPk1TaXNtLCBhcyB3ZSBoZWFyIG9mIGl0LCBpcyBzaGFwZWQgZnJvbSBEb3VnIEVu Z2VsYmFydOKAmXMgKDwvYT48YSBocmVmPSJodHRwOi8vd3d3LmRvdWdlbmdlbGJhcnQub3JnL2Fi b3V0L2RjZS1iaW8uaHRtbCI+IGh0dHA6Ly93d3cuZG91Z2VuZ2VsYmFydC5vcmcvYWJvdXQvZGNl LWJpby5odG1sPC9hPiApIGNvbmNlcHRzLiBJdCBpcyBhIGRpa3R5YXJjaHkgKGZyb20gZGlrdHlv czogbmV0d29yaykgaS5lLiBhbiBpbnRlcmdvdmVybmFuY2UNCiBiZXR3ZWVuIHBlZXIgc3RydWN0 dXJlZCBhdXRvc2VsZWN0ZWQgZW50aXRpZXMuIFRoZSBhdXRvc2VsZWN0aW9uIHByb2Nlc3MgaXMg YmFzZWQgdXBvbiB0aGUgdGltZSBuZXR3b3JrL2dsb2JhbCBhdmFpbGFiaWxpdHksIGkuZS4gdGhl IGNhcGFjaXR5IHRvIGNvbGxlY3RpdmVseSBtZWV0IG9uIGEgbWFpbGluZyBsaXN0IGFuZCBhbnl0 aW1lIGFueXdoZXJlLiBUaGlzIGlzIHRvIHByb2R1Y2UgdGhlIGJ1enogdGhhdCB3aWxsIGV4Y2Vl ZCB0aGUgbm9pc2UNCiBvZiByZWFsaXR5IGFuZCB0aGUgc3F1YXdrIG9mIHRoZSBtdWx0aXR1ZGUu IEl0IGlzIHRvIHBvbHljcmFjeSB0aGUgZXF1aXZhbGVudCBvZiBtb25hcmNoeSB0byBkZW1vY3Jh Y3kuIFRlY2huaWNhbGx5LCBNUyBwcm9jZWVkcyBmcm9tIGEgcm9vdC9zZXJ2ZXIvY2xpZW50IGhp ZXJhcmNoaWMgbW9kZWwgKGhvd2V2ZXIgaXRzIHNsb2dhbiBpcyAmcXVvdDtvbiBhbiBlcXVhbCBm b290aW5nJnF1b3Q7IFtmb3IgdGhlIGxlYWRlcnMgb25seSwgY2YuIFJGQyA2ODUyLCBNb250ZXZp ZGVvDQogc3RhdGVtZW50XSwgd2hpbGUgcG9seWNyYWN5IHByb2NlZWRzIGZyb20gYSAmcXVvdDtt YXN0ZXIgYW5kIG1hc3RlciZxdW90OyBvcGVuIGNhcGFiaWxpdHkgbW9kZWwuDQo8YnI+DQo8YnI+ DQpUaGUgZGlmZmljdWx0eSBpbiB0aGUgZXh0ZW5zaW9uIGZyb20gZGVtb2NyYWN5IHRvIHBvbHlj cmFjeSBpcyB0aGF0IGRpa3R5YXJjaHkgbG9va3MgZGVtb2NyYXRpYyB0byB0aGUgb25sb29rZXI6 IGRlbW9jcmFjeSBpcyBhYm91dCBkZWNpc2lvbiBkZWNlbnRyYWxpemF0aW9uOyBNU2lzbSBrZWVw cyB0aGF0IGRlY2lzaW9uIGRlY2VudHJhbGl6YXRpb24gd2l0aGluIGl0cyBwb2xpdGljYWwsIGJ1 c2luZXNzLCBhbmQgc29jaWV0YWwgc3RydWN0dXJlcw0KIHRoYXQgZGlhbG9ndWUgdG9nZXRoZXIu IFBvbHljcmFjeSBpcyBhY3R1YWxseSBhYm91dCBkZWNpc2lvbiBkaXN0cmlidXRpb24gYW1vbmcg cG9saXRpY2FsLCBidXNpbmVzcywgYW5kIHNvY2lldGFsIGluZGl2aWR1YWxzIHdobyBtdWx0aWxv Z3VlIHRvZ2V0aGVyIGluIGFueSBtYW5uZXIgdGhleSB3aXNoIGFuZCBkZWNpZGUgYnkgdGhlbXNl bHZlcy4NCjxicj4NCjxicj4NClRoaXMgaXMgd2h5IE1TaXNtIGlzIGEgbWV0aG9kIHRvIGRlcGxv eSAmcXVvdDtyZWFzb25hYmxlJnF1b3Q7IGRlY2lzaW9ucyBjb2xsZWN0aXZlbHkgYWdyZWVkIGFt b25nIG11dHVhbGx5IGFjY2VwdGVkIHNoYXJlL3N0YXR1cy9zdGFrZS1ob2xkZXJzLCB3aGlsZSBw b2x5Y3JhY3kgaXMgdGhlIGF1dG9wb2lldGljIGVtZXJnZW5jZSBvZiB0aGUgbGlmZSBvZiB0aGUg bXVsdGl0dWRlIHRocm91Z2ggaW5kaXZpZHVhbCBjb25zaWRlcmVkIGRlY2lzaW9ucy4gQm90aCBz eXN0ZW1zDQogYXJlIGFkYXB0ZWQgdG8gb3VyIHRpbWUuIE1TaXNtIGlzIHNlbGVjdGVkIG5ldHdv cmsgY2VudHJpYywgYW5kIHBvbHljcmFjeSBpcyBwZW9wbGUgY2VudGVyZWQuDQo8YnI+DQo8YnI+ DQpJbiBNU2lzbSwgc3RydWN0dXJlcyAoc3RhdGVzIGFuZCBjb3Jwb3JhdGVzKSBhbGx5IHRvIGdv dmVybiB0aGUgJnF1b3Q7b3RoZXJzJnF1b3Q7LCBpLmUuIHRoZSBXU0lTIGRlZmluaXRpb24gb2Yg dGhlICZxdW90O2NpdmlsIHNvY2lldHkmcXVvdDssIGFuZCBzcG9uc29yIHBvbGl0aWNhbGx5IGFj Y2VwdGFibGUgY2l2aWwgc29jaWV0eSBzdHJ1Y3R1cmVzLiBJdCBpcyBhbiBpbnRlcmVzdGluZyBj b25jZXB0IGJ5IGl0cyAmcXVvdDttaWQtdXAvZG93biZxdW90OyBwcmFjdGljYWwgY2FwYWNpdGll cyBvZg0KIHN1YnN0aXR1dGlvbjogaXQgaXMgYWxsaWFuY2VzIGNlbnRlcmVkLiBJbiBpdHMgb3du IHR1cm4sIHBvbHljcmFjeSBhY2NlcHRzIHN1YnN0aXR1dGlvbiBidXQgb25seSBpbiBpdHMgbm9y bWFsIHJvbGUgb2Ygc3Vic3RpdHV0aW9uIG9mIHN1YnNpZGlhcml0eTogaXQgaXMgcGVvcGxlIGNl bnRlcmVkLjxicj4NCjxicj4NCldoYXQgaXMgYXQgc3Rha2UgaW4gaGVyZSBmb3IgdGhlIEludGVy bmV0IEdvdmVybmFuY2UgaXMgdGhlIHZpcnR1YWwgd29ybGQgYnVpbHQgYXMgYW4gSUNBTk4gY29u dHJhY3R1YWwgZGlrdHlhcmNoeSB2cy4gYSByZWFsIHdvcmxkIHRoYXQgd2lsbCBwcm9ncmVzc2l2 ZWx5IGVyb2RlIHRoZSBOVElBIGxlYWRlcnNoaXAgaW4gYW4gb3BlcmF0aW9uYWwgcG9seWNyYWN5 LiBUaGUgcmVhbCBxdWVzdGlvbiBpcyBhYm91dCB3aGV0aGVyIHRoaXMgZXZvbHV0aW9uDQogd2ls bCBvY2N1ciBpbiB0aGUgbW9zdCBzZWFtbGVzcyB3YXkgcG9zc2libGUsIGluIHRoZSBiZXN0IHJl c3BlY3Qgb2YgdGhlICZxdW90O2RpZ2lsaXR5JnF1b3Q7IChmcm9tIGRpZ2l0YWwgcGVyc29uYWxp dHkpIG9mIGV2ZXJ5b25lLjxicj4NCjxicj4NClRoaXMgaXMgd2h5IEkgcHJvcG9zZSB0byBzdGFy dCBmcm9tIHdoYXQgd2Uga25vdywgYXMgdGhlIFdTSVMgaGFzIGFkdmlzZWQuIElmIHdlIHByb2Nl ZWQgZnJvbSB0aGUgcGVyc29uICgmcXVvdDtjZW50cmFkYSBlbiBsYSBwZXJzb25hJnF1b3Q7IHNh eXMgdGhlIFNwYW5pc2ggdmVyc2lvbiBvZiB0aGUgV1NJUyBkZWNsYXJhdGlvbikgZW50ZXJpbmcg dGhlIGRpZ2lzcGhlcmUsIGkuZS4gdGhlIGRpZ2l0YWxseSBzcGxpdCB2aXNpb24gb2YgaXRzIGVu dmlyb25tZW50YWwNCiByZWFsaXR5LCBhbmQgY29uc2lkZXJzIGl0cyBkaWdpdGFsIHJpZ2h0cy4g V2UgY2FuIHB1cnN1ZSB3aXRoIHRoZSBpbnZpb2xhYmlsaXR5IG9mIHBlb3BsZeKAmXMg4oCcZGln aWNpbGXigJ0gKGRpZ2l0YWwtZG9taWNpbGU6IHVzaW5nIHNpbXBsZSwgY2xlYXIsIHVuaXZlcnNh bGx5IHVuZGVyc3RhbmRhYmxlIG5vdGlvbnMgZXh0ZW5kaW5nIG91ciBkYWlseSBsaWZlIGluIHRo ZSBkaWdpc3BoZXJlIHRocm91Z2ggZGlyZWN0IG1ldGFwaG9ycyBjYW4gb25seSBoZWxwKS4NCiBG cm9tIHRoZXJlIHdlIGNhbiB0aGVuIHByb2NlZWQgYW5kIGRpZmZlcmVudGlhdGUgd2hhdCBiZWxv bmdzIHRvIHBoeXNpY2FsIGdvdmVybm1lbnQsIGV0aGljYWwgYmVoYXZpb3IsIGFuZCBkaWdpdGFs IGdvdmVybmFuY2UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+PC9wPg0KPHAgY2xhc3M9 ImRkODIxZTM5LTBmMDEtNDgwNC04ZWFkLTUzMjdhNjBmZjdjOSI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9ImRkODIxZTM5LTBmMDEtNDgwNC04ZWFkLTUzMjdhNjBmZjdjOSIgYWxpZ249ImNlbnRlciI+ PGZvbnQgc2l6ZT0iMSI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkFyaWFsIj4qICogKjwvZm9udD48L2ZvbnQ+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJk ZDgyMWUzOS0wZjAxLTQ4MDQtOGVhZC01MzI3YTYwZmY3YzkiPjxmb250IHNpemU9IjEiPjxmb250 IHNpemU9IjMiIGZhY2U9IkFyaWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+VGhpcyBF LW1haWwsIGFsb25nIHdpdGggYW55IGF0dGFjaG1lbnRzLCZuYnNwO2lzIGNvbnNpZGVyZWQgY29u ZmlkZW50aWFsIGFuZCBtYXkgd2VsbCBiZSBsZWdhbGx5IHByaXZpbGVnZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIGl0IGluIGVycm9yLA0KIHlvdSBhcmUgb24gbm90aWNlIG9mIGl0cyBzdGF0dXMu IFBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmVwbHkgZS1tYWlsIGFuZCB0aGVuIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gUGxlYXNlIGRvIG5vdCBjb3B5IGl0 IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2VzLCBvciBkaXNjbG9zZSBpdHMgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbi4mbmJzcDtUaGFuayB5b3UgZm9yIHlvdXIgY29vcGVyYXRpb24uPC9m b250PjwvZm9udD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9ImRkODIxZTM5LTBmMDEtNDgwNC04ZWFk LTUzMjdhNjBmZjdjOSIgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0iMSI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4qICogKjwvZm9udD48 L2ZvbnQ+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJkZDgyMWUzOS0wZjAxLTQ4MDQtOGVhZC01MzI3 YTYwZmY3YzkiPjxmb250IHNpemU9IjEiPjxmb250IHNpemU9IjMiIGZhY2U9IkFyaWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+VG8gZW5zdXJlIGNvbXBsaWFuY2Ugd2l0aCBUcmVhc3Vy eSBEZXBhcnRtZW50IHJlZ3VsYXRpb25zLCZuYnNwO3dlIGluZm9ybSB5b3UgdGhhdCwgdW5sZXNz IG90aGVyd2lzZSBpbmRpY2F0ZWQgaW4gd3JpdGluZywgYW55IFUuUy4gRmVkZXJhbCB0YXgNCiBh ZHZpY2UgY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiZuYnNwOyAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgaXMgbm90IGludGVuZGVkIG9yIHdyaXR0ZW4gdG8gYmUgdXNlZCwgYW5k IGNhbm5vdCBiZSB1c2VkLCBmb3IgdGhlIHB1cnBvc2Ugb2YgKDEpIGF2b2lkaW5nIHBlbmFsdGll cyB1bmRlciB0aGUmbmJzcDtJbnRlcm5hbCBSZXZlbnVlIENvZGUmbmJzcDtvciBhcHBsaWNhYmxl IHN0YXRlIGFuZCBsb2NhbCBwcm92aXNpb25zIG9yICgyKSBwcm9tb3RpbmcsDQogbWFya2V0aW5n IG9yIHJlY29tbWVuZGluZyB0byBhbm90aGVyIHBhcnR5IGFueSB0YXgtcmVsYXRlZCBtYXR0ZXJz IGFkZHJlc3NlZCBoZXJlaW4uPC9mb250PjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4g MHB0IiBhbGlnbj0icmlnaHQiPjxmb250IHNpemU9IjEiPkRpc2NsYWltZXIgVmVyc2lvbiBSUy5V Uy4yMC4xMC4wMDwvZm9udD48L3A+DQo8L2ZvbnQ+PC9mb250Pg0KPHA+PC9wPg0KPHA+PC9wPg0K PHA+PC9wPg0KPHA+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBD9F335EA4A684FA2640EEE94EEF27222C20929USPDCMAIL002Pre_-- From nobody Wed Mar 26 06:10: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 580E21A033A for ; Wed, 26 Mar 2014 06:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_COCK=1.544, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, LOTS_OF_MONEY=0.001, MISSING_MID=0.497, T_FRT_COCK=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 YKdfFzFYrw4G for ; Wed, 26 Mar 2014 06:04:10 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7661A00CA for ; Wed, 26 Mar 2014 06:04:10 -0700 (PDT) Received: from 229.77.14.81.rev.sfr.net ([81.14.77.229]:50921 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WSnV1-00074E-9Y; Wed, 26 Mar 2014 06:04:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Mar 2014 14:02:33 +0100 To: "Shatan, Gregory S." , 'Jefsey' ,"discuss@1net.org List" From: Michel Gauthier In-Reply-To: References: <01534.114032605130103203@us-mta-3.us.mimecast.lan> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_240048800==.ALT" 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 - telepresse.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/RoSDIdKclbczw-uA_kbXcC8pu6s X-Mailman-Approved-At: Wed, 26 Mar 2014 06:10:26 -0700 Cc: "internetgovtech@iab.org" , "ianatransition@icann.org" , "iucg@ietf.org" Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 13:04:13 -0000 --=====================_240048800==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit May be, Greg, you have not read the whole mail of George when is says one should read before responding. Nor read the mail of JFC when he says that he will consider George's mail (it is more kindly said) only when George will apply his own rules to himeself. This response of yours only gives the feeling that you do not know how to comment JFC definitions. JFC, I am quite interested in your clear explanation of what MSism and polycracy (might) mean. However, I feel you make a dichotomy between those two, or at least between diktyarchy and polycracy while one could imagine (it seems it is what we do all the day long) a complementarity between those two. On your French list you use the idea of the multitude having to invest the magnitude's mailing lists in order to keep themselves abreast, I would say, of the way they are going to be coocked. Is that not some forme of cooperation between the Cook and the cooked? M G At 11:51 26/03/2014, Shatan, Gregory S. wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_DBD9F335EA4A684FA2640EEE94EEF27222C20929USPDCMAIL002Pre_" > >My response to this post is to point to two of George’s etiquette items: > >9. If there are no responses to a post, posters should not assume >that the material they have posted has been agreed to by >readers. People on the list generally have busy lives, and often >will not respond to posts. Statements such as “no one on the list >has refuted my statement yet" should not lead to the assumption that >others agree with it. It is equally likely that the post is judged >to be incorrect or irrelevant. Readers have no obligation to correct >erroneous material that has been posted to the list by others. > >5. Successful posts use vocabulary that is simple and whose meaning >is well-understood by readers of the list. Successful posts are >formatted with some care so that they are easily readable by others. > >And I would also point to my suggested item of etiquette: > >Don’t cross-post, except to provide some basic information that >needs to be disseminated widely (e.g., NTIA announcement or Marca >Civil), and even this should be avoided. Don’t cross-post >opinions or anything that would require a response. Don’t >cross-post replies. > >Greg Shatan > >From: discuss-bounces@1net.org [mailto:discuss-bounces@1net.org] On >Behalf Of Jefsey >Sent: Wednesday, March 26, 2014 5:12 PM >To: discuss@1net.org List >Cc: internetgovtech@iab.org; ianatransition@icann.org; iucg@ietf.org >Subject: [discuss] What is MSism? > >The first question should be "what is MSism". I have posted this >definition and its comparison with polycracy. I am surprised by the >resulting general agreement (no one opposed). I therefore copy it to >some other mailing lists, so we have a common working basis. > >---- > >MSism, as we hear of it, is shaped from Doug Engelbart’s ( >http://www.dougengelbart.org/about/dce-bio.html ) concepts. It is a >diktyarchy (from diktyos: network) i.e. an intergovernance between >peer structured autoselected entities. The autoselection process is >based upon the time network/global availability, i.e. the capacity >to collectively meet on a mailing list and anytime anywhere. This is >to produce the buzz that will exceed the noise of reality and the >squawk of the multitude. It is to polycracy the equivalent of >monarchy to democracy. Technically, MS proceeds from a >root/server/client hierarchic model (however its slogan is "on an >equal footing" [for the leaders only, cf. RFC 6852, Montevideo >statement], while polycracy proceeds from a "master and master" open >capability model. > >The difficulty in the extension from democracy to polycracy is that >diktyarchy looks democratic to the onlooker: democracy is about >decision decentralization; MSism keeps that decision >decentralization within its political, business, and societal >structures that dialogue together. Polycracy is actually about >decision distribution among political, business, and societal >individuals who multilogue together in any manner they wish and >decide by themselves. > >This is why MSism is a method to deploy "reasonable" decisions >collectively agreed among mutually accepted >share/status/stake-holders, while polycracy is the autopoietic >emergence of the life of the multitude through individual considered >decisions. Both systems are adapted to our time. MSism is selected >network centric, and polycracy is people centered. > >In MSism, structures (states and corporates) ally to govern the >"others", i.e. the WSIS definition of the "civil society", and >sponsor politically acceptable civil society structures. It is an >interesting concept by its "mid-up/down" practical capacities of >substitution: it is alliances centered. In its own turn, polycracy >accepts substitution but only in its normal role of substitution of >subsidiarity: it is people centered. > >What is at stake in here for the Internet Governance is the virtual >world built as an ICANN contractual diktyarchy vs. a real world that >will progressively erode the NTIA leadership in an operational >polycracy. The real question is about whether this evolution will >occur in the most seamless way possible, in the best respect of the >"digility" (from digital personality) of everyone. > >This is why I propose to start from what we know, as the WSIS has >advised. If we proceed from the person ("centrada en la persona" >says the Spanish version of the WSIS declaration) entering the >digisphere, i.e. the digitally split vision of its environmental >reality, and considers its digital rights. We can pursue with the >inviolability of people’s “digicile” (digital-domicile: using >simple, clear, universally understandable notions extending our >daily life in the digisphere through direct metaphors can only >help). From there we can then proceed and differentiate what belongs >to physical government, ethical behavior, and digital governance. > > > >* * * > >This E-mail, along with any attachments, is considered confidential >and may well be legally privileged. If you have received it in >error, you are on notice of its status. Please notify us immediately >by reply e-mail and then delete this message from your system. >Please do not copy it or use it for any purposes, or disclose its >contents to any other person. Thank you for your cooperation. > >* * * > >To ensure compliance with Treasury Department regulations, we inform >you that, unless otherwise indicated in writing, any U.S. Federal >tax advice contained in this communication (including any >attachments) is not intended or written to be used, and cannot be >used, for the purpose of (1) avoiding penalties under the Internal >Revenue Code or applicable state and local provisions or (2) >promoting, marketing or recommending to another party any >tax-related matters addressed herein. > >Disclaimer Version RS.US.20.10.00 > >_______________________________________________ >discuss mailing list >discuss@1net.org >http://1net-mail.1net.org/mailman/listinfo/discuss --=====================_240048800==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit May be, Greg, you have not read the whole mail of George when is says one should read before responding. Nor read the mail of JFC when he says that he will consider George's mail (it is more kindly said) only when George will apply his own rules to himeself. This response of yours only gives the feeling that you do not know how to comment JFC definitions.


JFC, I am quite interested in your clear explanation of what MSism and polycracy (might) mean. However, I feel you make a dichotomy between those two, or at least between diktyarchy and polycracy while one could imagine (it seems it is what we do all the day long) a complementarity between those two. On your French list you use the idea of the multitude having to invest the magnitude's mailing lists in order to keep themselves abreast, I would say, of the way they are going to be coocked. Is that not some forme of cooperation between the Cook and the cooked?

M G


At 11:51 26/03/2014, Shatan, Gregory S. wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_DBD9F335EA4A684FA2640EEE94EEF27222C20929USPDCMAIL002Pre_"

My response to this post is to point to two of George’s etiquette items:
 
9. If there are no responses to a post, posters should not assume that the material they have posted has been agreed to by readers.  People on the list generally have busy lives, and often will not respond to posts.  Statements such as “no one on the list has refuted my statement yet" should not lead to the assumption that others agree with it.  It is equally likely that the post is judged to be incorrect or irrelevant. Readers have no obligation to correct erroneous material that has been posted to the list by others.
 
5. Successful posts use vocabulary that is simple and whose meaning is well-understood by readers of the list.  Successful posts are formatted  with some care so that they are easily readable by others.
 
And I would also point to my suggested item of etiquette:
 
Don’t cross-post, except to provide some basic information that needs to be disseminated widely (e.g., NTIA announcement or Marca Civil), and even this should be avoided.  Don’t cross-post opinions or anything that would require a response.  Don’t cross-post replies.
 
Greg Shatan
 
From: discuss-bounces@1net.org [ mailto:discuss-bounces@1net.org] On Behalf Of Jefsey
Sent: Wednesday, March 26, 2014 5:12 PM
To: discuss@1net.org List
Cc: internetgovtech@iab.org; ianatransition@icann.org; iucg@ietf.org
Subject: [discuss] What is MSism?
 
The first question should be "what is MSism". I have posted this definition and its comparison with polycracy. I am surprised by the resulting general agreement (no one opposed). I therefore copy it to some other mailing lists, so we have a common working basis.

----

MSism, as we hear of it, is shaped from Doug Engelbart’s ( http://www.dougengelbart.org/about/dce-bio.html ) concepts. It is a diktyarchy (from diktyos: network) i.e. an intergovernance between peer structured autoselected entities. The autoselection process is based upon the time network/global availability, i.e. the capacity to collectively meet on a mailing list and anytime anywhere. This is to produce the buzz that will exceed the noise of reality and the squawk of the multitude. It is to polycracy the equivalent of monarchy to democracy. Technically, MS proceeds from a root/server/client hierarchic model (however its slogan is "on an equal footing" [for the leaders only, cf. RFC 6852, Montevideo statement], while polycracy proceeds from a "master and master" open capability model.

The difficulty in the extension from democracy to polycracy is that diktyarchy looks democratic to the onlooker: democracy is about decision decentralization; MSism keeps that decision decentralization within its political, business, and societal structures that dialogue together. Polycracy is actually about decision distribution among political, business, and societal individuals who multilogue together in any manner they wish and decide by themselves.

This is why MSism is a method to deploy "reasonable" decisions collectively agreed among mutually accepted share/status/stake-holders, while polycracy is the autopoietic emergence of the life of the multitude through individual considered decisions. Both systems are adapted to our time. MSism is selected network centric, and polycracy is people centered.

In MSism, structures (states and corporates) ally to govern the "others", i.e. the WSIS definition of the "civil society", and sponsor politically acceptable civil society structures. It is an interesting concept by its "mid-up/down" practical capacities of substitution: it is alliances centered. In its own turn, polycracy accepts substitution but only in its normal role of substitution of subsidiarity: it is people centered.

What is at stake in here for the Internet Governance is the virtual world built as an ICANN contractual diktyarchy vs. a real world that will progressively erode the NTIA leadership in an operational polycracy. The real question is about whether this evolution will occur in the most seamless way possible, in the best respect of the "digility" (from digital personality) of everyone.

This is why I propose to start from what we know, as the WSIS has advised. If we proceed from the person ("centrada en la persona" says the Spanish version of the WSIS declaration) entering the digisphere, i.e. the digitally split vision of its environmental reality, and considers its digital rights. We can pursue with the inviolability of people’s “digicile” (digital-domicile: using simple, clear, universally understandable notions extending our daily life in the digisphere through direct metaphors can only help). From there we can then proceed and differentiate what belongs to physical government, ethical behavior, and digital governance.

 

* * *

This E-mail, along with any attachments, is considered confidential and may well be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. Thank you for your cooperation.

* * *

To ensure compliance with Treasury Department regulations, we inform you that, unless otherwise indicated in writing, any U.S. Federal tax advice contained in this communication  (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (1) avoiding penalties under the Internal Revenue Code or applicable state and local provisions or (2) promoting, marketing or recommending to another party any tax-related matters addressed herein.

Disclaimer Version RS.US.20.10.00

_______________________________________________
discuss mailing list
discuss@1net.org
http://1net-mail.1net.org/mailman/listinfo/discuss
--=====================_240048800==.ALT-- From nobody Wed Mar 26 09:07: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 18C301A00E3 for ; Wed, 26 Mar 2014 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_COCK=1.544, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_COCK=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 5HO1OfXdQgWC for ; Wed, 26 Mar 2014 09:07:16 -0700 (PDT) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by ietfa.amsl.com (Postfix) with ESMTP id A0E191A0344 for ; Wed, 26 Mar 2014 09:07:02 -0700 (PDT) Received: from pdce1.reedsmith.com (pdce1.reedsmith.com [199.125.201.10]) (Using TLS) by us-mta-2.us.mimecast.lan; Wed, 26 Mar 2014 12:06:57 -0400 Received: from USPDCMAIL004P.reedsmith.com (10.180.2.4) by pdce1.reedsmith.com (10.180.221.14) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 26 Mar 2014 12:06:56 -0400 Received: from USPDCMAIL002P.reedsmith.com ([fe80::78c8:1ed3:1b7a:8fd]) by USPDCMAIL004P.reedsmith.com ([fe80::80c5:ffee:4992:62eb%19]) with mapi id 14.03.0181.007; Wed, 26 Mar 2014 12:06:56 -0400 From: "Shatan, Gregory S." To: 'Michel Gauthier' , 'Jefsey' , "discuss@1net.org List" Thread-Topic: [discuss] What is MSism? Thread-Index: AQHPSNOXH5U+FGjmREW6QFFwYFCY+JrzLnPggAAnqgOAACtnUA== Date: Wed, 26 Mar 2014 16:06:55 +0000 Message-ID: References: <01534.114032605130103203@us-mta-3.us.mimecast.lan> <37137.114032609041004905@us-mta-5.us.mimecast.lan> In-Reply-To: <37137.114032609041004905@us-mta-5.us.mimecast.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.180.2.100] x-exclaimer-md-config: 35a2a35a-5651-415b-b3fc-0e9c17e2e02e MIME-Version: 1.0 X-MC-Unique: uhpwTfNNQpeTltCtSXK2Dg-5 Content-Type: multipart/alternative; boundary="_000_DBD9F335EA4A684FA2640EEE94EEF27222C20C8EUSPDCMAIL002Pre_" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/2Z7t_3soR4SReWBwMwC2rThfW5s Cc: "internetgovtech@iab.org" , "ianatransition@icann.org" , "iucg@ietf.org" Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 16:07:23 -0000 --_000_DBD9F335EA4A684FA2640EEE94EEF27222C20C8EUSPDCMAIL002Pre_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TWljaGVsOg0KDQpZb3UgYXJlIGluY29ycmVjdC4gIEkgcmVhZCBHZW9yZ2XigJlzIGVudGlyZSBl bWFpbCwgYXMgd2VsbCBhcyBib3RoIG9mIEplZnNleeKAmXMgZW1haWxzLiAgRm9sbG93aW5nIHRo YXQsIEkgcG9zdGVkIHRoZSBlbWFpbCB0byB3aGljaCB5b3UgcmVwbGllZC4NCg0KSSBzZWUgbm8g cmVhc29uIHRvIGFzc3VtZSB0aGF0IEdlb3JnZSB3aWxsIG5vdCDigJxhcHBseSBoaXMgb3duIHJ1 bGVzIHRvIGhpbXNlbGYu4oCdICBJIGJlbGlldmUgaGlzIHByaW9yIHBvc3RzIGFyZSBjb25zaXN0 ZW50IHdpdGggaGlzIOKAnHJ1bGVzLuKAnSAgSGUgaGFzIG5vdCBwb3N0ZWQgc2luY2UgdGhlIOKA nHJ1bGVz4oCdIHBvc3QuICBUaGVyZWZvcmUsIG5vdCBvbmx5IGlzIHRoZSDigJxJIHdpbGwgd2hl biB5b3Ugd2lsbOKAnSBwb3NpdGlvbiB1bnByb2R1Y3RpdmUsIGl0IGhhcyBubyBmYWN0dWFsIGJh c2lzLiAgSW4gYW55IGV2ZW50LCB0aGVzZSBhcmUgbm90IOKAnEdlb3JnZeKAmXMgcnVsZXPigJ07 IGEgbnVtYmVyIG9mIHBhcnRpY2lwYW50cyBpbiB0aGUgbGlzdCBoYXZlIGFscmVhZHkgaW5kaWNh dGVkIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYW5kIGFncmVlbWVudCB0byBhYmlkZSBieSB0aGVz ZSBydWxlcyBvZiDigJxOZXRpcXVldHRlLuKAnQ0KDQpBcyB0byB5b3VyIGNvbW1lbnQgdGhhdCBJ IOKAnGRvIG5vdCBrbm93IGhvdyB0byBjb21tZW50IFtvbl0gSkZDW+KAmHNdIGRlZmluaXRpb25z 4oCdOyBJIGZpbmQgdGhhdCwgaW4gR2Vvcmdl4oCZcyB3b3Jkcywg4oCcZGlzZGFpbmZ1bCBhbmQg aW1wb2xpdGUu4oCdICBJIG1heSBvciBtYXkgbm90IHJlc3BvbmQgb3Igb3RoZXJ3aXNlIGRpc2N1 c3MgdGhlIGlzc3VlIG9mIHdoYXQgbXVsdGlzdGFrZWhvbGRlcmlzbSBpcy4gIElmICBkb27igJl0 LCBpdCBpcyBub3QgYmVjYXVzZSBJIGxhY2sgdGhlIGFiaWxpdHkgb3IgdGFsZW50cyB0byBkbyBz by4gIElmIEkgZmVsdCBpdCB3YXMgdGhlIGJlc3QgdXNlIG9mIG15IGxpbWl0ZWQgdGltZSwgSSB3 b3VsZCByZXNwb25kLiAgSWYgbm90LCBpdCBpcyBiZWNhdXNlIEkgZmluZCBvdGhlciB0aGluZ3Mg aGVyZSBtb3JlIHByZXNzaW5nLCByZWxldmFudCBvciBmcnVpdGZ1bC4NCg0KR3JlZyBTaGF0YW4N Cg0KRnJvbTogTWljaGVsIEdhdXRoaWVyIFttYWlsdG86bWdAdGVsZXByZXNzZS5jb21dDQpTZW50 OiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0IDk6MDMgUE0NClRvOiBTaGF0YW4sIEdyZWdvcnkg Uy47ICdKZWZzZXknOyBkaXNjdXNzQDFuZXQub3JnIExpc3QNCkNjOiBpbnRlcm5ldGdvdnRlY2hA aWFiLm9yZzsgaWFuYXRyYW5zaXRpb25AaWNhbm4ub3JnOyBpdWNnQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2Rpc2N1c3NdIFdoYXQgaXMgTVNpc20/DQoNCk1heSBiZSwgR3JlZywgeW91IGhhdmUg bm90IHJlYWQgdGhlIHdob2xlIG1haWwgb2YgR2VvcmdlIHdoZW4gaXMgc2F5cyBvbmUgc2hvdWxk IHJlYWQgYmVmb3JlIHJlc3BvbmRpbmcuIE5vciByZWFkIHRoZSBtYWlsIG9mIEpGQyB3aGVuIGhl IHNheXMgdGhhdCBoZSB3aWxsIGNvbnNpZGVyIEdlb3JnZSdzIG1haWwgKGl0IGlzIG1vcmUga2lu ZGx5IHNhaWQpIG9ubHkgd2hlbiBHZW9yZ2Ugd2lsbCBhcHBseSBoaXMgb3duIHJ1bGVzIHRvIGhp bWVzZWxmLiBUaGlzIHJlc3BvbnNlIG9mIHlvdXJzIG9ubHkgZ2l2ZXMgdGhlIGZlZWxpbmcgdGhh dCB5b3UgZG8gbm90IGtub3cgaG93IHRvIGNvbW1lbnQgSkZDIGRlZmluaXRpb25zLg0KDQoNCkpG QywgSSBhbSBxdWl0ZSBpbnRlcmVzdGVkIGluIHlvdXIgY2xlYXIgZXhwbGFuYXRpb24gb2Ygd2hh dCBNU2lzbSBhbmQgcG9seWNyYWN5IChtaWdodCkgbWVhbi4gSG93ZXZlciwgSSBmZWVsIHlvdSBt YWtlIGEgZGljaG90b215IGJldHdlZW4gdGhvc2UgdHdvLCBvciBhdCBsZWFzdCBiZXR3ZWVuIGRp a3R5YXJjaHkgYW5kIHBvbHljcmFjeSB3aGlsZSBvbmUgY291bGQgaW1hZ2luZSAoaXQgc2VlbXMg aXQgaXMgd2hhdCB3ZSBkbyBhbGwgdGhlIGRheSBsb25nKSBhIGNvbXBsZW1lbnRhcml0eSBiZXR3 ZWVuIHRob3NlIHR3by4gT24geW91ciBGcmVuY2ggbGlzdCB5b3UgdXNlIHRoZSBpZGVhIG9mIHRo ZSBtdWx0aXR1ZGUgaGF2aW5nIHRvIGludmVzdCB0aGUgbWFnbml0dWRlJ3MgbWFpbGluZyBsaXN0 cyBpbiBvcmRlciB0byBrZWVwIHRoZW1zZWx2ZXMgYWJyZWFzdCwgSSB3b3VsZCBzYXksIG9mIHRo ZSB3YXkgdGhleSBhcmUgZ29pbmcgdG8gYmUgY29vY2tlZC4gSXMgdGhhdCBub3Qgc29tZSBmb3Jt ZSBvZiBjb29wZXJhdGlvbiBiZXR3ZWVuIHRoZSBDb29rIGFuZCB0aGUgY29va2VkPw0KDQpNIEcN Cg0KDQpBdCAxMTo1MSAyNi8wMy8yMDE0LCBTaGF0YW4sIEdyZWdvcnkgUy4gd3JvdGU6DQoNCkNv bnRlbnQtTGFuZ3VhZ2U6IGVuLVVTDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2 ZTsNCiAgICAgICAgIGJvdW5kYXJ5PSJfMDAwX0RCRDlGMzM1RUE0QTY4NEZBMjY0MEVFRTk0RUVG MjcyMjJDMjA5MjlVU1BEQ01BSUwwMDJQcmVfIg0KDQpNeSByZXNwb25zZSB0byB0aGlzIHBvc3Qg aXMgdG8gcG9pbnQgdG8gdHdvIG9mIEdlb3JnZcOi4oKs4oSicyBldGlxdWV0dGUgaXRlbXM6DQoN CjkuIElmIHRoZXJlIGFyZSBubyByZXNwb25zZXMgdG8gYSBwb3N0LCBwb3N0ZXJzIHNob3VsZCBu b3QgYXNzdW1lIHRoYXQgdGhlIG1hdGVyaWFsIHRoZXkgaGF2ZSBwb3N0ZWQgaGFzIGJlZW4gYWdy ZWVkIHRvIGJ5IHJlYWRlcnMuICBQZW9wbGUgb24gdGhlIGxpc3QgZ2VuZXJhbGx5IGhhdmUgYnVz eSBsaXZlcywgYW5kIG9mdGVuIHdpbGwgbm90IHJlc3BvbmQgdG8gcG9zdHMuICBTdGF0ZW1lbnRz IHN1Y2ggYXMgw6LigqzFk25vIG9uZSBvbiB0aGUgbGlzdCBoYXMgcmVmdXRlZCBteSBzdGF0ZW1l bnQgeWV0IiBzaG91bGQgbm90IGxlYWQgdG8gdGhlIGFzc3VtcHRpb24gdGhhdCBvdGhlcnMgYWdy ZWUgd2l0aCBpdC4gIEl0IGlzIGVxdWFsbHkgbGlrZWx5IHRoYXQgdGhlIHBvc3QgaXMganVkZ2Vk IHRvIGJlIGluY29ycmVjdCBvciBpcnJlbGV2YW50LiBSZWFkZXJzIGhhdmUgbm8gb2JsaWdhdGlv biB0byBjb3JyZWN0IGVycm9uZW91cyBtYXRlcmlhbCB0aGF0IGhhcyBiZWVuIHBvc3RlZCB0byB0 aGUgbGlzdCBieSBvdGhlcnMuDQoNCjUuIFN1Y2Nlc3NmdWwgcG9zdHMgdXNlIHZvY2FidWxhcnkg dGhhdCBpcyBzaW1wbGUgYW5kIHdob3NlIG1lYW5pbmcgaXMgd2VsbC11bmRlcnN0b29kIGJ5IHJl YWRlcnMgb2YgdGhlIGxpc3QuICBTdWNjZXNzZnVsIHBvc3RzIGFyZSBmb3JtYXR0ZWQgIHdpdGgg c29tZSBjYXJlIHNvIHRoYXQgdGhleSBhcmUgZWFzaWx5IHJlYWRhYmxlIGJ5IG90aGVycy4NCg0K QW5kIEkgd291bGQgYWxzbyBwb2ludCB0byBteSBzdWdnZXN0ZWQgaXRlbSBvZiBldGlxdWV0dGU6 DQoNCkRvbsOi4oKs4oSidCBjcm9zcy1wb3N0LCBleGNlcHQgdG8gcHJvdmlkZSBzb21lIGJhc2lj IGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgZGlzc2VtaW5hdGVkIHdpZGVseSAoZS5nLiwg TlRJQSBhbm5vdW5jZW1lbnQgb3IgTWFyY2EgQ2l2aWwpLCBhbmQgZXZlbiB0aGlzIHNob3VsZCBi ZSBhdm9pZGVkLiAgRG9uw6LigqzihKJ0IGNyb3NzLXBvc3Qgb3BpbmlvbnMgb3IgYW55dGhpbmcg dGhhdCB3b3VsZCByZXF1aXJlIGEgcmVzcG9uc2UuICBEb27DouKCrOKEonQgY3Jvc3MtcG9zdCBy ZXBsaWVzLg0KDQpHcmVnIFNoYXRhbg0KDQpGcm9tOiBkaXNjdXNzLWJvdW5jZXNAMW5ldC5vcmc8 bWFpbHRvOmRpc2N1c3MtYm91bmNlc0AxbmV0Lm9yZz4gWyBtYWlsdG86ZGlzY3Vzcy1ib3VuY2Vz QDFuZXQub3JnXSBPbiBCZWhhbGYgT2YgSmVmc2V5DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI2 LCAyMDE0IDU6MTIgUE0NClRvOiBkaXNjdXNzQDFuZXQub3JnPG1haWx0bzpkaXNjdXNzQDFuZXQu b3JnPiBMaXN0DQpDYzogaW50ZXJuZXRnb3Z0ZWNoQGlhYi5vcmc8bWFpbHRvOmludGVybmV0Z292 dGVjaEBpYWIub3JnPjsgaWFuYXRyYW5zaXRpb25AaWNhbm4ub3JnPG1haWx0bzppYW5hdHJhbnNp dGlvbkBpY2Fubi5vcmc+OyBpdWNnQGlldGYub3JnPG1haWx0bzppdWNnQGlldGYub3JnPg0KU3Vi amVjdDogW2Rpc2N1c3NdIFdoYXQgaXMgTVNpc20/DQoNClRoZSBmaXJzdCBxdWVzdGlvbiBzaG91 bGQgYmUgIndoYXQgaXMgTVNpc20iLiBJIGhhdmUgcG9zdGVkIHRoaXMgZGVmaW5pdGlvbiBhbmQg aXRzIGNvbXBhcmlzb24gd2l0aCBwb2x5Y3JhY3kuIEkgYW0gc3VycHJpc2VkIGJ5IHRoZSByZXN1 bHRpbmcgZ2VuZXJhbCBhZ3JlZW1lbnQgKG5vIG9uZSBvcHBvc2VkKS4gSSB0aGVyZWZvcmUgY29w eSBpdCB0byBzb21lIG90aGVyIG1haWxpbmcgbGlzdHMsIHNvIHdlIGhhdmUgYSBjb21tb24gd29y a2luZyBiYXNpcy4NCg0KLS0tLQ0KDQpNU2lzbSwgYXMgd2UgaGVhciBvZiBpdCwgaXMgc2hhcGVk IGZyb20gRG91ZyBFbmdlbGJhcnTDouKCrOKEonMgKCBodHRwOi8vd3d3LmRvdWdlbmdlbGJhcnQu b3JnL2Fib3V0L2RjZS1iaW8uaHRtbCApIGNvbmNlcHRzLiBJdCBpcyBhIGRpa3R5YXJjaHkgKGZy b20gZGlrdHlvczogbmV0d29yaykgaS5lLiBhbiBpbnRlcmdvdmVybmFuY2UgYmV0d2VlbiBwZWVy IHN0cnVjdHVyZWQgYXV0b3NlbGVjdGVkIGVudGl0aWVzLiBUaGUgYXV0b3NlbGVjdGlvbiBwcm9j ZXNzIGlzIGJhc2VkIHVwb24gdGhlIHRpbWUgbmV0d29yay9nbG9iYWwgYXZhaWxhYmlsaXR5LCBp LmUuIHRoZSBjYXBhY2l0eSB0byBjb2xsZWN0aXZlbHkgbWVldCBvbiBhIG1haWxpbmcgbGlzdCBh bmQgYW55dGltZSBhbnl3aGVyZS4gVGhpcyBpcyB0byBwcm9kdWNlIHRoZSBidXp6IHRoYXQgd2ls bCBleGNlZWQgdGhlIG5vaXNlIG9mIHJlYWxpdHkgYW5kIHRoZSBzcXVhd2sgb2YgdGhlIG11bHRp dHVkZS4gSXQgaXMgdG8gcG9seWNyYWN5IHRoZSBlcXVpdmFsZW50IG9mIG1vbmFyY2h5IHRvIGRl bW9jcmFjeS4gVGVjaG5pY2FsbHksIE1TIHByb2NlZWRzIGZyb20gYSByb290L3NlcnZlci9jbGll bnQgaGllcmFyY2hpYyBtb2RlbCAoaG93ZXZlciBpdHMgc2xvZ2FuIGlzICJvbiBhbiBlcXVhbCBm b290aW5nIiBbZm9yIHRoZSBsZWFkZXJzIG9ubHksIGNmLiBSRkMgNjg1MiwgTW9udGV2aWRlbyBz dGF0ZW1lbnRdLCB3aGlsZSBwb2x5Y3JhY3kgcHJvY2VlZHMgZnJvbSBhICJtYXN0ZXIgYW5kIG1h c3RlciIgb3BlbiBjYXBhYmlsaXR5IG1vZGVsLg0KDQpUaGUgZGlmZmljdWx0eSBpbiB0aGUgZXh0 ZW5zaW9uIGZyb20gZGVtb2NyYWN5IHRvIHBvbHljcmFjeSBpcyB0aGF0IGRpa3R5YXJjaHkgbG9v a3MgZGVtb2NyYXRpYyB0byB0aGUgb25sb29rZXI6IGRlbW9jcmFjeSBpcyBhYm91dCBkZWNpc2lv biBkZWNlbnRyYWxpemF0aW9uOyBNU2lzbSBrZWVwcyB0aGF0IGRlY2lzaW9uIGRlY2VudHJhbGl6 YXRpb24gd2l0aGluIGl0cyBwb2xpdGljYWwsIGJ1c2luZXNzLCBhbmQgc29jaWV0YWwgc3RydWN0 dXJlcyB0aGF0IGRpYWxvZ3VlIHRvZ2V0aGVyLiBQb2x5Y3JhY3kgaXMgYWN0dWFsbHkgYWJvdXQg ZGVjaXNpb24gZGlzdHJpYnV0aW9uIGFtb25nIHBvbGl0aWNhbCwgYnVzaW5lc3MsIGFuZCBzb2Np ZXRhbCBpbmRpdmlkdWFscyB3aG8gbXVsdGlsb2d1ZSB0b2dldGhlciBpbiBhbnkgbWFubmVyIHRo ZXkgd2lzaCBhbmQgZGVjaWRlIGJ5IHRoZW1zZWx2ZXMuDQoNClRoaXMgaXMgd2h5IE1TaXNtIGlz IGEgbWV0aG9kIHRvIGRlcGxveSAicmVhc29uYWJsZSIgZGVjaXNpb25zIGNvbGxlY3RpdmVseSBh Z3JlZWQgYW1vbmcgbXV0dWFsbHkgYWNjZXB0ZWQgc2hhcmUvc3RhdHVzL3N0YWtlLWhvbGRlcnMs IHdoaWxlIHBvbHljcmFjeSBpcyB0aGUgYXV0b3BvaWV0aWMgZW1lcmdlbmNlIG9mIHRoZSBsaWZl IG9mIHRoZSBtdWx0aXR1ZGUgdGhyb3VnaCBpbmRpdmlkdWFsIGNvbnNpZGVyZWQgZGVjaXNpb25z LiBCb3RoIHN5c3RlbXMgYXJlIGFkYXB0ZWQgdG8gb3VyIHRpbWUuIE1TaXNtIGlzIHNlbGVjdGVk IG5ldHdvcmsgY2VudHJpYywgYW5kIHBvbHljcmFjeSBpcyBwZW9wbGUgY2VudGVyZWQuDQoNCklu IE1TaXNtLCBzdHJ1Y3R1cmVzIChzdGF0ZXMgYW5kIGNvcnBvcmF0ZXMpIGFsbHkgdG8gZ292ZXJu IHRoZSAib3RoZXJzIiwgaS5lLiB0aGUgV1NJUyBkZWZpbml0aW9uIG9mIHRoZSAiY2l2aWwgc29j aWV0eSIsIGFuZCBzcG9uc29yIHBvbGl0aWNhbGx5IGFjY2VwdGFibGUgY2l2aWwgc29jaWV0eSBz dHJ1Y3R1cmVzLiBJdCBpcyBhbiBpbnRlcmVzdGluZyBjb25jZXB0IGJ5IGl0cyAibWlkLXVwL2Rv d24iIHByYWN0aWNhbCBjYXBhY2l0aWVzIG9mIHN1YnN0aXR1dGlvbjogaXQgaXMgYWxsaWFuY2Vz IGNlbnRlcmVkLiBJbiBpdHMgb3duIHR1cm4sIHBvbHljcmFjeSBhY2NlcHRzIHN1YnN0aXR1dGlv biBidXQgb25seSBpbiBpdHMgbm9ybWFsIHJvbGUgb2Ygc3Vic3RpdHV0aW9uIG9mIHN1YnNpZGlh cml0eTogaXQgaXMgcGVvcGxlIGNlbnRlcmVkLg0KDQpXaGF0IGlzIGF0IHN0YWtlIGluIGhlcmUg Zm9yIHRoZSBJbnRlcm5ldCBHb3Zlcm5hbmNlIGlzIHRoZSB2aXJ0dWFsIHdvcmxkIGJ1aWx0IGFz IGFuIElDQU5OIGNvbnRyYWN0dWFsIGRpa3R5YXJjaHkgdnMuIGEgcmVhbCB3b3JsZCB0aGF0IHdp bGwgcHJvZ3Jlc3NpdmVseSBlcm9kZSB0aGUgTlRJQSBsZWFkZXJzaGlwIGluIGFuIG9wZXJhdGlv bmFsIHBvbHljcmFjeS4gVGhlIHJlYWwgcXVlc3Rpb24gaXMgYWJvdXQgd2hldGhlciB0aGlzIGV2 b2x1dGlvbiB3aWxsIG9jY3VyIGluIHRoZSBtb3N0IHNlYW1sZXNzIHdheSBwb3NzaWJsZSwgaW4g dGhlIGJlc3QgcmVzcGVjdCBvZiB0aGUgImRpZ2lsaXR5IiAoZnJvbSBkaWdpdGFsIHBlcnNvbmFs aXR5KSBvZiBldmVyeW9uZS4NCg0KVGhpcyBpcyB3aHkgSSBwcm9wb3NlIHRvIHN0YXJ0IGZyb20g d2hhdCB3ZSBrbm93LCBhcyB0aGUgV1NJUyBoYXMgYWR2aXNlZC4gSWYgd2UgcHJvY2VlZCBmcm9t IHRoZSBwZXJzb24gKCJjZW50cmFkYSBlbiBsYSBwZXJzb25hIiBzYXlzIHRoZSBTcGFuaXNoIHZl cnNpb24gb2YgdGhlIFdTSVMgZGVjbGFyYXRpb24pIGVudGVyaW5nIHRoZSBkaWdpc3BoZXJlLCBp LmUuIHRoZSBkaWdpdGFsbHkgc3BsaXQgdmlzaW9uIG9mIGl0cyBlbnZpcm9ubWVudGFsIHJlYWxp dHksIGFuZCBjb25zaWRlcnMgaXRzIGRpZ2l0YWwgcmlnaHRzLiBXZSBjYW4gcHVyc3VlIHdpdGgg dGhlIGludmlvbGFiaWxpdHkgb2YgcGVvcGxlw6LigqzihKJzIMOi4oKsxZNkaWdpY2lsZcOi4oKs PyAoZGlnaXRhbC1kb21pY2lsZTogdXNpbmcgc2ltcGxlLCBjbGVhciwgdW5pdmVyc2FsbHkgdW5k ZXJzdGFuZGFibGUgbm90aW9ucyBleHRlbmRpbmcgb3VyIGRhaWx5IGxpZmUgaW4gdGhlIGRpZ2lz cGhlcmUgdGhyb3VnaCBkaXJlY3QgbWV0YXBob3JzIGNhbiBvbmx5IGhlbHApLiBGcm9tIHRoZXJl IHdlIGNhbiB0aGVuIHByb2NlZWQgYW5kIGRpZmZlcmVudGlhdGUgd2hhdCBiZWxvbmdzIHRvIHBo eXNpY2FsIGdvdmVybm1lbnQsIGV0aGljYWwgYmVoYXZpb3IsIGFuZCBkaWdpdGFsIGdvdmVybmFu Y2UuDQoNCg0KKiAqICoNCg0KVGhpcyBFLW1haWwsIGFsb25nIHdpdGggYW55IGF0dGFjaG1lbnRz LCBpcyBjb25zaWRlcmVkIGNvbmZpZGVudGlhbCBhbmQgbWF5IHdlbGwgYmUgbGVnYWxseSBwcml2 aWxlZ2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgeW91IGFyZSBvbiBub3Rp Y2Ugb2YgaXRzIHN0YXR1cy4gUGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseSBl LW1haWwgYW5kIHRoZW4gZGVsZXRlIHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBQbGVh c2UgZG8gbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZXMsIG9yIGRpc2Nsb3Nl IGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLiBUaGFuayB5b3UgZm9yIHlvdXIgY29v cGVyYXRpb24uDQoqICogKg0KDQpUbyBlbnN1cmUgY29tcGxpYW5jZSB3aXRoIFRyZWFzdXJ5IERl cGFydG1lbnQgcmVndWxhdGlvbnMsIHdlIGluZm9ybSB5b3UgdGhhdCwgdW5sZXNzIG90aGVyd2lz ZSBpbmRpY2F0ZWQgaW4gd3JpdGluZywgYW55IFUuUy4gRmVkZXJhbCB0YXggYWR2aWNlIGNvbnRh aW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBp cyBub3QgaW50ZW5kZWQgb3Igd3JpdHRlbiB0byBiZSB1c2VkLCBhbmQgY2Fubm90IGJlIHVzZWQs IGZvciB0aGUgcHVycG9zZSBvZiAoMSkgYXZvaWRpbmcgcGVuYWx0aWVzIHVuZGVyIHRoZSBJbnRl cm5hbCBSZXZlbnVlIENvZGUgb3IgYXBwbGljYWJsZSBzdGF0ZSBhbmQgbG9jYWwgcHJvdmlzaW9u cyBvciAoMikgcHJvbW90aW5nLCBtYXJrZXRpbmcgb3IgcmVjb21tZW5kaW5nIHRvIGFub3RoZXIg cGFydHkgYW55IHRheC1yZWxhdGVkIG1hdHRlcnMgYWRkcmVzc2VkIGhlcmVpbi4NCkRpc2NsYWlt ZXIgVmVyc2lvbiBSUy5VUy4yMC4xMC4wMA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmRpc2N1c3NAMW5ldC5v cmc8bWFpbHRvOmRpc2N1c3NAMW5ldC5vcmc+DQpodHRwOi8vMW5ldC1tYWlsLjFuZXQub3JnL21h aWxtYW4vbGlzdGluZm8vZGlzY3Vzcw0K --_000_DBD9F335EA4A684FA2640EEE94EEF27222C20C8EUSPDCMAIL002Pre_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGVsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IGFyZSBpbmNvcnJl Y3QuJm5ic3A7IEkgcmVhZCBHZW9yZ2XigJlzIGVudGlyZSBlbWFpbCwgYXMgd2VsbCBhcyBib3Ro IG9mIEplZnNleeKAmXMgZW1haWxzLiZuYnNwOyBGb2xsb3dpbmcgdGhhdCwgSSBwb3N0ZWQgdGhl IGVtYWlsIHRvIHdoaWNoIHlvdSByZXBsaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzZWUgbm8gcmVhc29uIHRv IGFzc3VtZSB0aGF0IEdlb3JnZSB3aWxsIG5vdCDigJxhcHBseSBoaXMgb3duIHJ1bGVzIHRvIGhp bXNlbGYu4oCdJm5ic3A7IEkgYmVsaWV2ZSBoaXMgcHJpb3IgcG9zdHMgYXJlIGNvbnNpc3RlbnQg d2l0aCBoaXMg4oCccnVsZXMu4oCdJm5ic3A7IEhlIGhhcyBub3QgcG9zdGVkDQogc2luY2UgdGhl IOKAnHJ1bGVz4oCdIHBvc3QuJm5ic3A7IFRoZXJlZm9yZSwgbm90IG9ubHkgaXMgdGhlIOKAnEkg d2lsbCB3aGVuIHlvdSB3aWxs4oCdIHBvc2l0aW9uIHVucHJvZHVjdGl2ZSwgaXQgaGFzIG5vIGZh Y3R1YWwgYmFzaXMuJm5ic3A7IEluIGFueSBldmVudCwgdGhlc2UgYXJlIG5vdCDigJxHZW9yZ2Xi gJlzIHJ1bGVz4oCdOyBhIG51bWJlciBvZiBwYXJ0aWNpcGFudHMgaW4gdGhlIGxpc3QgaGF2ZSBh bHJlYWR5IGluZGljYXRlZCB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFuZA0KIGFncmVlbWVudCB0 byBhYmlkZSBieSB0aGVzZSBydWxlcyBvZiDigJxOZXRpcXVldHRlLuKAnTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMg dG8geW91ciBjb21tZW50IHRoYXQgSSDigJxkbyBub3Qga25vdyBob3cgdG8gY29tbWVudCBbb25d IEpGQ1vigJhzXSBkZWZpbml0aW9uc+KAnTsgSSBmaW5kIHRoYXQsIGluIEdlb3JnZeKAmXMgd29y ZHMsIOKAnGRpc2RhaW5mdWwgYW5kIGltcG9saXRlLuKAnSZuYnNwOyBJIG1heSBvciBtYXkgbm90 DQogcmVzcG9uZCBvciBvdGhlcndpc2UgZGlzY3VzcyB0aGUgaXNzdWUgb2Ygd2hhdCBtdWx0aXN0 YWtlaG9sZGVyaXNtIGlzLiZuYnNwOyBJZiZuYnNwOyBkb27igJl0LCBpdCBpcyBub3QgYmVjYXVz ZSBJIGxhY2sgdGhlIGFiaWxpdHkgb3IgdGFsZW50cyB0byBkbyBzby4mbmJzcDsgSWYgSSBmZWx0 IGl0IHdhcyB0aGUgYmVzdCB1c2Ugb2YgbXkgbGltaXRlZCB0aW1lLCBJIHdvdWxkIHJlc3BvbmQu Jm5ic3A7IElmIG5vdCwgaXQgaXMgYmVjYXVzZSBJIGZpbmQgb3RoZXIgdGhpbmdzIGhlcmUNCiBt b3JlIHByZXNzaW5nLCByZWxldmFudCBvciBmcnVpdGZ1bC4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HcmVnIFNoYXRh bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pY2hlbCBHYXV0aGllciBbbWFpbHRvOm1nQHRlbGVwcmVz c2UuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMjYsIDIwMTQgOTow MyBQTTxicj4NCjxiPlRvOjwvYj4gU2hhdGFuLCBHcmVnb3J5IFMuOyAnSmVmc2V5JzsgZGlzY3Vz c0AxbmV0Lm9yZyBMaXN0PGJyPg0KPGI+Q2M6PC9iPiBpbnRlcm5ldGdvdnRlY2hAaWFiLm9yZzsg aWFuYXRyYW5zaXRpb25AaWNhbm4ub3JnOyBpdWNnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbZGlzY3Vzc10gV2hhdCBpcyBNU2lzbT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXkgYmUsIEdyZWcsIHlvdSBoYXZlIG5vdCByZWFkIHRo ZSB3aG9sZSBtYWlsIG9mIEdlb3JnZSB3aGVuIGlzIHNheXMgb25lIHNob3VsZCByZWFkIGJlZm9y ZSByZXNwb25kaW5nLiBOb3IgcmVhZCB0aGUgbWFpbCBvZiBKRkMgd2hlbiBoZSBzYXlzIHRoYXQg aGUgd2lsbCBjb25zaWRlciBHZW9yZ2UncyBtYWlsIChpdCBpcyBtb3JlIGtpbmRseSBzYWlkKSBv bmx5IHdoZW4gR2VvcmdlIHdpbGwgYXBwbHkgaGlzDQogb3duIHJ1bGVzIHRvIGhpbWVzZWxmLiBU aGlzIHJlc3BvbnNlIG9mIHlvdXJzIG9ubHkgZ2l2ZXMgdGhlIGZlZWxpbmcgdGhhdCB5b3UgZG8g bm90IGtub3cgaG93IHRvIGNvbW1lbnQgSkZDIGRlZmluaXRpb25zLg0KPGJyPg0KPGJyPg0KPGJy Pg0KSkZDLCBJIGFtIHF1aXRlIGludGVyZXN0ZWQgaW4geW91ciBjbGVhciBleHBsYW5hdGlvbiBv ZiB3aGF0IE1TaXNtIGFuZCBwb2x5Y3JhY3kgKG1pZ2h0KSBtZWFuLiBIb3dldmVyLCBJIGZlZWwg eW91IG1ha2UgYSBkaWNob3RvbXkgYmV0d2VlbiB0aG9zZSB0d28sIG9yIGF0IGxlYXN0IGJldHdl ZW4gZGlrdHlhcmNoeSBhbmQgcG9seWNyYWN5IHdoaWxlIG9uZSBjb3VsZCBpbWFnaW5lIChpdCBz ZWVtcyBpdCBpcyB3aGF0IHdlIGRvIGFsbCB0aGUgZGF5DQogbG9uZykgYSBjb21wbGVtZW50YXJp dHkgYmV0d2VlbiB0aG9zZSB0d28uIE9uIHlvdXIgRnJlbmNoIGxpc3QgeW91IHVzZSB0aGUgaWRl YSBvZiB0aGUgbXVsdGl0dWRlIGhhdmluZyB0byBpbnZlc3QgdGhlIG1hZ25pdHVkZSdzIG1haWxp bmcgbGlzdHMgaW4gb3JkZXIgdG8ga2VlcCB0aGVtc2VsdmVzIGFicmVhc3QsIEkgd291bGQgc2F5 LCBvZiB0aGUgd2F5IHRoZXkgYXJlIGdvaW5nIHRvIGJlIGNvb2NrZWQuIElzIHRoYXQgbm90IHNv bWUgZm9ybWUNCiBvZiBjb29wZXJhdGlvbiBiZXR3ZWVuIHRoZSBDb29rIGFuZCB0aGUgY29va2Vk Pzxicj4NCjxicj4NCk0gRzxicj4NCjxicj4NCjxicj4NCkF0IDExOjUxIDI2LzAzLzIwMTQsIFNo YXRhbiwgR3JlZ29yeSBTLiB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Q29udGVudC1MYW5n dWFnZTogZW4tVVM8YnI+DQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTs8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm91bmRh cnk9JnF1b3Q7XzAwMF9EQkQ5RjMzNUVBNEE2ODRGQTI2NDBFRUU5NEVFRjI3MjIyQzIwOTI5VVNQ RENNQUlMMDAyUHJlXyZxdW90Ozxicj4NCjxicj4NCk15IHJlc3BvbnNlIHRvIHRoaXMgcG9zdCBp cyB0byBwb2ludCB0byB0d28gb2YgR2Vvcmdlw6LigqzihKJzIGV0aXF1ZXR0ZSBpdGVtczo8YnI+ DQombmJzcDs8YnI+DQo5LiBJZiB0aGVyZSBhcmUgbm8gcmVzcG9uc2VzIHRvIGEgcG9zdCwgcG9z dGVycyBzaG91bGQgbm90IGFzc3VtZSB0aGF0IHRoZSBtYXRlcmlhbCB0aGV5IGhhdmUgcG9zdGVk IGhhcyBiZWVuIGFncmVlZCB0byBieSByZWFkZXJzLiZuYnNwOyBQZW9wbGUgb24gdGhlIGxpc3Qg Z2VuZXJhbGx5IGhhdmUgYnVzeSBsaXZlcywgYW5kIG9mdGVuIHdpbGwgbm90IHJlc3BvbmQgdG8g cG9zdHMuJm5ic3A7IFN0YXRlbWVudHMgc3VjaCBhcyDDouKCrMWTbm8gb25lIG9uIHRoZSBsaXN0 DQogaGFzIHJlZnV0ZWQgbXkgc3RhdGVtZW50IHlldCZxdW90OyBzaG91bGQgbm90IGxlYWQgdG8g dGhlIGFzc3VtcHRpb24gdGhhdCBvdGhlcnMgYWdyZWUgd2l0aCBpdC4mbmJzcDsgSXQgaXMgZXF1 YWxseSBsaWtlbHkgdGhhdCB0aGUgcG9zdCBpcyBqdWRnZWQgdG8gYmUgaW5jb3JyZWN0IG9yIGly cmVsZXZhbnQuIFJlYWRlcnMgaGF2ZSBubyBvYmxpZ2F0aW9uIHRvIGNvcnJlY3QgZXJyb25lb3Vz IG1hdGVyaWFsIHRoYXQgaGFzIGJlZW4gcG9zdGVkIHRvIHRoZSBsaXN0DQogYnkgb3RoZXJzLjxi cj4NCiZuYnNwOzxicj4NCjUuIFN1Y2Nlc3NmdWwgcG9zdHMgdXNlIHZvY2FidWxhcnkgdGhhdCBp cyBzaW1wbGUgYW5kIHdob3NlIG1lYW5pbmcgaXMgd2VsbC11bmRlcnN0b29kIGJ5IHJlYWRlcnMg b2YgdGhlIGxpc3QuJm5ic3A7IFN1Y2Nlc3NmdWwgcG9zdHMgYXJlIGZvcm1hdHRlZCZuYnNwOyB3 aXRoIHNvbWUgY2FyZSBzbyB0aGF0IHRoZXkgYXJlIGVhc2lseSByZWFkYWJsZSBieSBvdGhlcnMu PGJyPg0KJm5ic3A7PGJyPg0KQW5kIEkgd291bGQgYWxzbyBwb2ludCB0byBteSBzdWdnZXN0ZWQg aXRlbSBvZiBldGlxdWV0dGU6PGJyPg0KJm5ic3A7PGJyPg0KRG9uw6LigqzihKJ0IGNyb3NzLXBv c3QsIGV4Y2VwdCB0byBwcm92aWRlIHNvbWUgYmFzaWMgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0 byBiZSBkaXNzZW1pbmF0ZWQgd2lkZWx5IChlLmcuLCBOVElBIGFubm91bmNlbWVudCBvciBNYXJj YSBDaXZpbCksIGFuZCBldmVuIHRoaXMgc2hvdWxkIGJlIGF2b2lkZWQuJm5ic3A7IERvbsOi4oKs 4oSidCBjcm9zcy1wb3N0IG9waW5pb25zIG9yIGFueXRoaW5nIHRoYXQgd291bGQgcmVxdWlyZSBh IHJlc3BvbnNlLiZuYnNwOyBEb27DouKCrOKEonQgY3Jvc3MtcG9zdA0KIHJlcGxpZXMuPGJyPg0K Jm5ic3A7PGJyPg0KR3JlZyBTaGF0YW48YnI+DQombmJzcDs8YnI+DQo8Yj5Gcm9tOjwvYj4gPGEg aHJlZj0ibWFpbHRvOmRpc2N1c3MtYm91bmNlc0AxbmV0Lm9yZyI+ZGlzY3Vzcy1ib3VuY2VzQDFu ZXQub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmRpc2N1c3MtYm91bmNlc0AxbmV0Lm9yZyI+IG1h aWx0bzpkaXNjdXNzLWJvdW5jZXNAMW5ldC5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K ZWZzZXk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAyNiwgMjAxNCA1OjEyIFBN PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZGlzY3Vzc0AxbmV0Lm9yZyI+ZGlzY3Vz c0AxbmV0Lm9yZzwvYT4gTGlzdDxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmludGVy bmV0Z292dGVjaEBpYWIub3JnIj5pbnRlcm5ldGdvdnRlY2hAaWFiLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzppYW5hdHJhbnNpdGlvbkBpY2Fubi5vcmciPg0KaWFuYXRyYW5zaXRpb25AaWNhbm4u b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOml1Y2dAaWV0Zi5vcmciPml1Y2dAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtkaXNjdXNzXSBXaGF0IGlzIE1TaXNtPzxicj4NCiZuYnNw Ozxicj4NClRoZSBmaXJzdCBxdWVzdGlvbiBzaG91bGQgYmUgJnF1b3Q7d2hhdCBpcyBNU2lzbSZx dW90Oy4gSSBoYXZlIHBvc3RlZCB0aGlzIGRlZmluaXRpb24gYW5kIGl0cyBjb21wYXJpc29uIHdp dGggcG9seWNyYWN5LiBJIGFtIHN1cnByaXNlZCBieSB0aGUgcmVzdWx0aW5nIGdlbmVyYWwgYWdy ZWVtZW50IChubyBvbmUgb3Bwb3NlZCkuIEkgdGhlcmVmb3JlIGNvcHkgaXQgdG8gc29tZSBvdGhl ciBtYWlsaW5nIGxpc3RzLCBzbyB3ZSBoYXZlIGEgY29tbW9uIHdvcmtpbmcgYmFzaXMuPGJyPg0K PGJyPg0KLS0tLTxicj4NCjxicj4NCjxhIG5hbWU9Il9Hb0JhY2siPjwvYT5NU2lzbSwgYXMgd2Ug aGVhciBvZiBpdCwgaXMgc2hhcGVkIGZyb20gRG91ZyBFbmdlbGJhcnTDouKCrOKEonMgKA0KPGEg aHJlZj0iaHR0cDovL3d3dy5kb3VnZW5nZWxiYXJ0Lm9yZy9hYm91dC9kY2UtYmlvLmh0bWwiPmh0 dHA6Ly93d3cuZG91Z2VuZ2VsYmFydC5vcmcvYWJvdXQvZGNlLWJpby5odG1sPC9hPiApIGNvbmNl cHRzLiBJdCBpcyBhIGRpa3R5YXJjaHkgKGZyb20gZGlrdHlvczogbmV0d29yaykgaS5lLiBhbiBp bnRlcmdvdmVybmFuY2UgYmV0d2VlbiBwZWVyIHN0cnVjdHVyZWQgYXV0b3NlbGVjdGVkIGVudGl0 aWVzLiBUaGUgYXV0b3NlbGVjdGlvbiBwcm9jZXNzDQogaXMgYmFzZWQgdXBvbiB0aGUgdGltZSBu ZXR3b3JrL2dsb2JhbCBhdmFpbGFiaWxpdHksIGkuZS4gdGhlIGNhcGFjaXR5IHRvIGNvbGxlY3Rp dmVseSBtZWV0IG9uIGEgbWFpbGluZyBsaXN0IGFuZCBhbnl0aW1lIGFueXdoZXJlLiBUaGlzIGlz IHRvIHByb2R1Y2UgdGhlIGJ1enogdGhhdCB3aWxsIGV4Y2VlZCB0aGUgbm9pc2Ugb2YgcmVhbGl0 eSBhbmQgdGhlIHNxdWF3ayBvZiB0aGUgbXVsdGl0dWRlLiBJdCBpcyB0byBwb2x5Y3JhY3kgdGhl IGVxdWl2YWxlbnQNCiBvZiBtb25hcmNoeSB0byBkZW1vY3JhY3kuIFRlY2huaWNhbGx5LCBNUyBw cm9jZWVkcyBmcm9tIGEgcm9vdC9zZXJ2ZXIvY2xpZW50IGhpZXJhcmNoaWMgbW9kZWwgKGhvd2V2 ZXIgaXRzIHNsb2dhbiBpcyAmcXVvdDtvbiBhbiBlcXVhbCBmb290aW5nJnF1b3Q7IFtmb3IgdGhl IGxlYWRlcnMgb25seSwgY2YuIFJGQyA2ODUyLCBNb250ZXZpZGVvIHN0YXRlbWVudF0sIHdoaWxl IHBvbHljcmFjeSBwcm9jZWVkcyBmcm9tIGEgJnF1b3Q7bWFzdGVyIGFuZCBtYXN0ZXImcXVvdDsg b3Blbg0KIGNhcGFiaWxpdHkgbW9kZWwuIDxicj4NCjxicj4NClRoZSBkaWZmaWN1bHR5IGluIHRo ZSBleHRlbnNpb24gZnJvbSBkZW1vY3JhY3kgdG8gcG9seWNyYWN5IGlzIHRoYXQgZGlrdHlhcmNo eSBsb29rcyBkZW1vY3JhdGljIHRvIHRoZSBvbmxvb2tlcjogZGVtb2NyYWN5IGlzIGFib3V0IGRl Y2lzaW9uIGRlY2VudHJhbGl6YXRpb247IE1TaXNtIGtlZXBzIHRoYXQgZGVjaXNpb24gZGVjZW50 cmFsaXphdGlvbiB3aXRoaW4gaXRzIHBvbGl0aWNhbCwgYnVzaW5lc3MsIGFuZCBzb2NpZXRhbCBz dHJ1Y3R1cmVzDQogdGhhdCBkaWFsb2d1ZSB0b2dldGhlci4gUG9seWNyYWN5IGlzIGFjdHVhbGx5 IGFib3V0IGRlY2lzaW9uIGRpc3RyaWJ1dGlvbiBhbW9uZyBwb2xpdGljYWwsIGJ1c2luZXNzLCBh bmQgc29jaWV0YWwgaW5kaXZpZHVhbHMgd2hvIG11bHRpbG9ndWUgdG9nZXRoZXIgaW4gYW55IG1h bm5lciB0aGV5IHdpc2ggYW5kIGRlY2lkZSBieSB0aGVtc2VsdmVzLg0KPGJyPg0KPGJyPg0KVGhp cyBpcyB3aHkgTVNpc20gaXMgYSBtZXRob2QgdG8gZGVwbG95ICZxdW90O3JlYXNvbmFibGUmcXVv dDsgZGVjaXNpb25zIGNvbGxlY3RpdmVseSBhZ3JlZWQgYW1vbmcgbXV0dWFsbHkgYWNjZXB0ZWQg c2hhcmUvc3RhdHVzL3N0YWtlLWhvbGRlcnMsIHdoaWxlIHBvbHljcmFjeSBpcyB0aGUgYXV0b3Bv aWV0aWMgZW1lcmdlbmNlIG9mIHRoZSBsaWZlIG9mIHRoZSBtdWx0aXR1ZGUgdGhyb3VnaCBpbmRp dmlkdWFsIGNvbnNpZGVyZWQgZGVjaXNpb25zLiBCb3RoIHN5c3RlbXMNCiBhcmUgYWRhcHRlZCB0 byBvdXIgdGltZS4gTVNpc20gaXMgc2VsZWN0ZWQgbmV0d29yayBjZW50cmljLCBhbmQgcG9seWNy YWN5IGlzIHBlb3BsZSBjZW50ZXJlZC4NCjxicj4NCjxicj4NCkluIE1TaXNtLCBzdHJ1Y3R1cmVz IChzdGF0ZXMgYW5kIGNvcnBvcmF0ZXMpIGFsbHkgdG8gZ292ZXJuIHRoZSAmcXVvdDtvdGhlcnMm cXVvdDssIGkuZS4gdGhlIFdTSVMgZGVmaW5pdGlvbiBvZiB0aGUgJnF1b3Q7Y2l2aWwgc29jaWV0 eSZxdW90OywgYW5kIHNwb25zb3IgcG9saXRpY2FsbHkgYWNjZXB0YWJsZSBjaXZpbCBzb2NpZXR5 IHN0cnVjdHVyZXMuIEl0IGlzIGFuIGludGVyZXN0aW5nIGNvbmNlcHQgYnkgaXRzICZxdW90O21p ZC11cC9kb3duJnF1b3Q7IHByYWN0aWNhbCBjYXBhY2l0aWVzIG9mDQogc3Vic3RpdHV0aW9uOiBp dCBpcyBhbGxpYW5jZXMgY2VudGVyZWQuIEluIGl0cyBvd24gdHVybiwgcG9seWNyYWN5IGFjY2Vw dHMgc3Vic3RpdHV0aW9uIGJ1dCBvbmx5IGluIGl0cyBub3JtYWwgcm9sZSBvZiBzdWJzdGl0dXRp b24gb2Ygc3Vic2lkaWFyaXR5OiBpdCBpcyBwZW9wbGUgY2VudGVyZWQuPGJyPg0KPGJyPg0KV2hh dCBpcyBhdCBzdGFrZSBpbiBoZXJlIGZvciB0aGUgSW50ZXJuZXQgR292ZXJuYW5jZSBpcyB0aGUg dmlydHVhbCB3b3JsZCBidWlsdCBhcyBhbiBJQ0FOTiBjb250cmFjdHVhbCBkaWt0eWFyY2h5IHZz LiBhIHJlYWwgd29ybGQgdGhhdCB3aWxsIHByb2dyZXNzaXZlbHkgZXJvZGUgdGhlIE5USUEgbGVh ZGVyc2hpcCBpbiBhbiBvcGVyYXRpb25hbCBwb2x5Y3JhY3kuIFRoZSByZWFsIHF1ZXN0aW9uIGlz IGFib3V0IHdoZXRoZXIgdGhpcyBldm9sdXRpb24NCiB3aWxsIG9jY3VyIGluIHRoZSBtb3N0IHNl YW1sZXNzIHdheSBwb3NzaWJsZSwgaW4gdGhlIGJlc3QgcmVzcGVjdCBvZiB0aGUgJnF1b3Q7ZGln aWxpdHkmcXVvdDsgKGZyb20gZGlnaXRhbCBwZXJzb25hbGl0eSkgb2YgZXZlcnlvbmUuPGJyPg0K PGJyPg0KVGhpcyBpcyB3aHkgSSBwcm9wb3NlIHRvIHN0YXJ0IGZyb20gd2hhdCB3ZSBrbm93LCBh cyB0aGUgV1NJUyBoYXMgYWR2aXNlZC4gSWYgd2UgcHJvY2VlZCBmcm9tIHRoZSBwZXJzb24gKCZx dW90O2NlbnRyYWRhIGVuIGxhIHBlcnNvbmEmcXVvdDsgc2F5cyB0aGUgU3BhbmlzaCB2ZXJzaW9u IG9mIHRoZSBXU0lTIGRlY2xhcmF0aW9uKSBlbnRlcmluZyB0aGUgZGlnaXNwaGVyZSwgaS5lLiB0 aGUgZGlnaXRhbGx5IHNwbGl0IHZpc2lvbiBvZiBpdHMgZW52aXJvbm1lbnRhbA0KIHJlYWxpdHks IGFuZCBjb25zaWRlcnMgaXRzIGRpZ2l0YWwgcmlnaHRzLiBXZSBjYW4gcHVyc3VlIHdpdGggdGhl IGludmlvbGFiaWxpdHkgb2YgcGVvcGxlw6LigqzihKJzIMOi4oKsxZNkaWdpY2lsZcOi4oKsPyAo ZGlnaXRhbC1kb21pY2lsZTogdXNpbmcgc2ltcGxlLCBjbGVhciwgdW5pdmVyc2FsbHkgdW5kZXJz dGFuZGFibGUgbm90aW9ucyBleHRlbmRpbmcgb3VyIGRhaWx5IGxpZmUgaW4gdGhlIGRpZ2lzcGhl cmUgdGhyb3VnaCBkaXJlY3QgbWV0YXBob3JzIGNhbg0KIG9ubHkgaGVscCkuIEZyb20gdGhlcmUg d2UgY2FuIHRoZW4gcHJvY2VlZCBhbmQgZGlmZmVyZW50aWF0ZSB3aGF0IGJlbG9uZ3MgdG8gcGh5 c2ljYWwgZ292ZXJubWVudCwgZXRoaWNhbCBiZWhhdmlvciwgYW5kIGRpZ2l0YWwgZ292ZXJuYW5j ZS4NCjxicj4NCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+KiAqICo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5UaGlzIEUtbWFpbCwgYWxvbmcgd2l0aCBhbnkgYXR0YWNobWVu dHMsIGlzIGNvbnNpZGVyZWQgY29uZmlkZW50aWFsIGFuZCBtYXkgd2VsbCBiZSBsZWdhbGx5IHBy aXZpbGVnZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCB5b3UgYXJlIG9uIG5v dGljZSBvZiBpdHMgc3RhdHVzLiBQbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJlcGx5 IGUtbWFpbCBhbmQgdGhlbiBkZWxldGUNCiB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4g UGxlYXNlIGRvIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2VzLCBvciBkaXNj bG9zZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4gVGhhbmsgeW91IGZvciB5b3Vy IGNvb3BlcmF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiogKiAqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+VG8gZW5zdXJlIGNvbXBsaWFuY2Ugd2l0aCBUcmVhc3VyeSBEZXBh cnRtZW50IHJlZ3VsYXRpb25zLCB3ZSBpbmZvcm0geW91IHRoYXQsIHVubGVzcyBvdGhlcndpc2Ug aW5kaWNhdGVkIGluIHdyaXRpbmcsIGFueSBVLlMuIEZlZGVyYWwgdGF4IGFkdmljZSBjb250YWlu ZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uJm5ic3A7IChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz KSBpcyBub3QgaW50ZW5kZWQgb3INCiB3cml0dGVuIHRvIGJlIHVzZWQsIGFuZCBjYW5ub3QgYmUg dXNlZCwgZm9yIHRoZSBwdXJwb3NlIG9mICgxKSBhdm9pZGluZyBwZW5hbHRpZXMgdW5kZXIgdGhl IEludGVybmFsIFJldmVudWUgQ29kZSBvciBhcHBsaWNhYmxlIHN0YXRlIGFuZCBsb2NhbCBwcm92 aXNpb25zIG9yICgyKSBwcm9tb3RpbmcsIG1hcmtldGluZyBvciByZWNvbW1lbmRpbmcgdG8gYW5v dGhlciBwYXJ0eSBhbnkgdGF4LXJlbGF0ZWQgbWF0dGVycyBhZGRyZXNzZWQgaGVyZWluLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5 bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQiPkRpc2Ns YWltZXIgVmVyc2lvbiBSUy5VUy4yMC4xMC4wMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KZGlzY3VzcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86ZGlzY3Vzc0AxbmV0Lm9yZyI+ZGlzY3Vzc0AxbmV0Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwOi8vMW5ldC1tYWlsLjFuZXQub3JnL21haWxtYW4vbGlzdGluZm8vZGlzY3VzcyI+aHR0cDov LzFuZXQtbWFpbC4xbmV0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc2N1c3M8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBD9F335EA4A684FA2640EEE94EEF27222C20C8EUSPDCMAIL002Pre_-- From nobody Wed Mar 26 10:17: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 A972C1A02DC; Wed, 26 Mar 2014 10:17:49 -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 Kb_slylCVBPT; Wed, 26 Mar 2014 10:17:47 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3AE1A01D1; Wed, 26 Mar 2014 10:17:47 -0700 (PDT) Received: from [203.116.43.76] (helo=[172.30.1.185]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WSrSS-000K7u-9o; Wed, 26 Mar 2014 17:17:44 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 203.116.43.76 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/Oeq+H5v7iIa2R2E+7XHYI Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: John Curran X-Priority: 1 In-Reply-To: <20140326091244.818F921364D@smtp2.arin.net> Date: Thu, 27 Mar 2014 01:17:33 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7F11B8A9-988A-4CC1-B6C9-C96D756E39B0@istaff.org> References: <20140326091244.818F921364D@smtp2.arin.net> To: Jefsey X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jxtZ33APJA97ywSbCo4pFvquzB8 Cc: "internetgovtech@iab.org" , "discuss@1net.org List" , ianatransition@icann.org, iucg@ietf.org Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 17:17:50 -0000 On Mar 26, 2014, at 5:11 PM, Jefsey wrote: > The first question should be "what is MSism". I have posted this = definition and its comparison with polycracy. I am surprised by the = resulting general agreement (no one opposed). I therefore copy it to = some other mailing lists, so we have a common working basis. JFC -=20 =20 Lack of response does not indicate "general agreement" nor "no one = opposed";=20 it simply indicates "lack of response". To refer to it otherwise is = disingenuous.=20 However, I do have some good news, in that I will respond to your = proposed =20 MS definition (i.e. "It is to polycracy the equivalent of monarchy to = democracy.=20 Technically, MS proceeds from a root/server/client hierarchic model") = and note that I believe it to be contrary to existing usage of the term and = otherwise without merit. (The good news being that now you _can_ summarize your = responses=20 received, the result being "overwhelmingly opposed"...) In keeping with the George's proposed etiquette or the 1net discuss = list, I shall make the observation that our views are quite divergent, likely = irreconcilable, and thus my constructive suggestion is that you find a mailing list = of those of similar beliefs, and refine your ideas in that forum (I've included = the cc's on this=20 reply to aid in that process, but ask that you refrain from cross = posting in the=20 future, and simply use one forum of like-minded folks to continue = your efforts.) Thanks! /John Disclaimer: My views alone (although I may be able to safely omit it = this time...) From nobody Wed Mar 26 11:36: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 0CCB81A0354 for ; Wed, 26 Mar 2014 11:36:12 -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 7HbF0rVD-36x for ; Wed, 26 Mar 2014 11:36:10 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id A5FA41A0345 for ; Wed, 26 Mar 2014 11:36:10 -0700 (PDT) Received: from [85.159.233.116] (port=37640 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WSsgJ-0005g6-Ic; Wed, 26 Mar 2014 11:36:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Mar 2014 19:36:02 +0100 To: John Curran From: Jefsey In-Reply-To: <7F11B8A9-988A-4CC1-B6C9-C96D756E39B0@istaff.org> References: <20140326091244.818F921364D@smtp2.arin.net> <7F11B8A9-988A-4CC1-B6C9-C96D756E39B0@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: 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/s-yBN6WW5mX6o8lufD6MjYJmiJg Cc: "internetgovtech@iab.org" , "discuss@1net.org List" , ianatransition@icann.org, iucg@ietf.org Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 18:36:12 -0000 At 18:17 26/03/2014, John Curran wrote >JFC - > Lack of response does not indicate "general agreement" nor "no > one opposed"; > it simply indicates "lack of response". To refer to it > otherwise is disingenuous. Pretty obvious. But it obliges people to explain what they pretend to knowingly discuss. > However, I do have some good news, in that I will respond to > your proposed > MS definition (i.e. "It is to polycracy the equivalent of > monarchy to democracy. > Technically, MS proceeds from a root/server/client hierarchic > model") and note > that I believe it to be contrary to existing usage of the term > and otherwise without > merit. You can believe what you want as long as you document it. Every creed welcome: this is a HR. > (The good news being that now you _can_ summarize your responses > received, the result being "overwhelmingly opposed"...) Up to now this is (surprisingly) inexact. But I know, MSism would ceased to be a magic trick if it was investigated. Now, when a camailla invades an open public space it is not surprising that the real world majority is not welcome :-) May I remember you that we are discussing a matter where the world majority in Dubai has opposed your vision. Also that our minority has aggregated by loyalty around the now retiring NTIA, which has found a better strategy. One can therefore consider that the transfer to ICANN is its sacrifice to this new strategy. The USG has measured where was its best interest, and plays it very well. They let you drop. The problem is to know how one can reasonably reach a balanced transition. You do not help it in sticking to positions that the NTIA abandons to ICANN (with glorious words, I acknowledge it). You do not help in refusing (by despite? or unbelief of the change) that we reach out to you. > In keeping with the George's proposed etiquette or the 1net > discuss list, I shall > make the observation that our views are quite divergent, likely > irreconcilable, Correct, from your rigid point of view, at this time. Totally uncorrect from mine. You are part of a VGNIC structure. The largest one so far. But the time for VGNICs fair competition has come. Introducing competition does not means killing the incumbent. However it means for the incumbent not to block the new commers. Otherwise it will be sued (best) or opposed and will lose. I fully understand this is new to you, and it is difficult to accept (while it seems so unlikely) and adapt. You feel you are still the big one: this is true, but the NTIA has accepted that you are not the only one anymore. And the spirit of the law, and probably the jurisprudence, and the law once the Congress has understood the opportunity, is against your position. This deregulating datacommunications. Not my decision: the ITU vote for an increased regulation and the USG cute reponse. > and thus my constructive suggestion is that you find a mailing > list of those of > similar beliefs, and refine your ideas in that forum (I've > included the cc's on this > reply to aid in that process, but ask that you refrain from > cross posting in the > future, and simply use one forum of like-minded folks to > continue your efforts.) I thought you would be more MSist. The attempted trick is understandable, but is poor. We have an open mailing list established by the inculbent to convene a debate on MS-IG. We are two stakeholders. You for ARIN, depending on ICANN, me for VGNICs depending on IUsers. And all what you can tell me amount to say: "please I cannot resist, Dubai, Snowden, VGNs, the NTIA retirement, and now Marco Civil by our co-host, what next? Please leave me die in peace...". I will only do it by force for the whole world to see. We do not want you to die. We want you to behave as what you claim you are: a stakeholder. Not a monopoly component anymore, but a stand-alone stakeholder in our common enhanced cooperation. We just want you to adapt to the new reality of the legal rather than political US leadership strategy attempted by the NTIA. As loyal US allies, we are ready to help, but our priroities is to our nations, people and ourselves. If you do not want us, you will end irritating us! And we will be many, many more than you. With everyone his HomeRoot and SuperIANA. Cheers. jfc Cheers ! jfc From nobody Wed Mar 26 12:14: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 E25B81A039A; Wed, 26 Mar 2014 12:13: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 xkAT-A8HbzBy; Wed, 26 Mar 2014 12:13:58 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 262481A0364; Wed, 26 Mar 2014 12:13:57 -0700 (PDT) Received: from [203.116.43.76] (helo=[172.30.1.185]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WStGu-000DLl-7Q; Wed, 26 Mar 2014 19:13:56 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 203.116.43.76 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18tSwMjE7NfnuE8hpIixsLH Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: John Curran In-Reply-To: <20140326183653.DEFE721365F@smtp2.arin.net> Date: Thu, 27 Mar 2014 03:13:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <170128E5-F66A-4AC1-A2D7-FB759B5BB040@istaff.org> References: <20140326091244.818F921364D@smtp2.arin.net> <7F11B8A9-988A-4CC1-B6C9-C96D756E39B0@istaff.org> <20140326183653.DEFE721365F@smtp2.arin.net> To: Jefsey X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/S9lZC9FZ9RugyqSKqsJ61Z5io6I Cc: "internetgovtech@iab.org" , "discuss@1net.org List" , ianatransition@icann.org, iucg@ietf.org Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 19:14:00 -0000 On Mar 27, 2014, at 2:36 AM, Jefsey wrote: > Totally uncorrect from mine. You are part of a VGNIC structure. The = largest one so far. But the time for VGNICs fair competition has come. = ... JFC -=20 I actually acknowledged your interesting multiple VGNIC perspective long ago (see 1net discuss email from me earlier on the 1st and 2nd of this month), so you can stop proselytizing. The difference in viewpoint is that I also recognize that the folks in the "ICANN VGNIC" (using your terminology) have the right to use the 1net list for discussion of problems that they see in governance of this particular VGNIC, using the terminology and definitions that=20= they see most appropriate. You acknowledged this right of VGNIC self- organization and determination, but then repeatedly have attempted to insert terminology which has not been accepted by those participating=20= in this discussion. I fully acknowledge you have the right to your beliefs and framework,=20= but your continued interference to those who which to discuss Internet=20= governance within this particular Internet scope (using the = terminology of their own choice) is both disruptive and inconsistent with the=20 claimed VGNIC framework you repeated try to foist on this community... As such, I was just letting your know that I see no need to respond further, and was suggesting that you might find a mailing list that=20 contains folks with beliefs similar to yours to be helpful in working out some of these kinks in your VGNIC framework. Thanks! /John Disclaimer: My views alone. From nobody Wed Mar 26 15:25: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 95A5D1A03E0 for ; Wed, 26 Mar 2014 15:25:36 -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 7wKMX1eqA10p for ; Wed, 26 Mar 2014 15:25:35 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id DC1201A03DF for ; Wed, 26 Mar 2014 15:25:35 -0700 (PDT) Received: from 229.77.14.81.rev.sfr.net ([81.14.77.229]:56490 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WSwGK-0001fh-DR; Wed, 26 Mar 2014 15:25:32 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Mar 2014 23:24:03 +0100 To: John Curran From: Michel Gauthier In-Reply-To: <170128E5-F66A-4AC1-A2D7-FB759B5BB040@istaff.org> References: <20140326091244.818F921364D@smtp2.arin.net> <7F11B8A9-988A-4CC1-B6C9-C96D756E39B0@istaff.org> <20140326183653.DEFE721365F@smtp2.arin.net> <170128E5-F66A-4AC1-A2D7-FB759B5BB040@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 - telepresse.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/Dyq3kri67s2yFYIvLoQf-Vo7C4g Cc: "internetgovtech@iab.org" , "discuss@1net.org List" , ianatransition@icann.org, iucg@ietf.org Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 26 Mar 2014 22:25:36 -0000 At 20:13 26/03/2014, John Curran wrote: > I actually acknowledged your interesting multiple VGNIC perspective > long ago (see 1net discuss email from me earlier on the 1st and 2nd > of this month), so you can stop proselytizing. John, I have some difficulty understanding you. You and I agree with a technical analysis that seems clear and obvious. There is not other way to name it. But you call proselitism using it? This could be understandable if there was a single known case. But there are many other "VGN" occurrences. How do to call them all? M G From nobody Wed Mar 26 17:31: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 717EF1A040F for ; Wed, 26 Mar 2014 17:31: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 5YqFFnQDMsRd for ; Wed, 26 Mar 2014 17:31:38 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 966791A0256 for ; Wed, 26 Mar 2014 17:31:37 -0700 (PDT) Received: from 229.77.14.81.rev.sfr.net ([81.14.77.229]:57719 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WSyEF-00033u-Sk; Wed, 26 Mar 2014 17:31:32 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Mar 2014 01:30:02 +0100 To: "Shatan, Gregory S." , From: Michel Gauthier In-Reply-To: References: <01534.114032605130103203@us-mta-3.us.mimecast.lan> <37137.114032609041004905@us-mta-5.us.mimecast.lan> 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 - telepresse.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/2YCFegb8_nhxFKxQkS3WWQcPmG4 Cc: "internetgovtech@iab.org" , "ianatransition@icann.org" , "iucg@ietf.org" Subject: Re: [Internetgovtech] [discuss] What is MSism? 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, 27 Mar 2014 00:31:39 -0000 Dear Greg, Jorge wants us to use plain language. I think it is sometimes simpler than trying to diplomatically to make things understood. There are two main types of mailing lists: the ones whith "contributors", and the one with also "interlocutors" using the lists buzz to "discuss without openly discussing". If you do not consider yourself as an interlocutor negociating something, you are for them interesting contributor who is being used as a cover. You know better. Not my cup of tea. I LOVE these later lists. Because the best interest of the interlcutors is to tell the truth in a way that irritates the contributors, and hence augments the buzz, is unnoticed and can be quoted further on ("I told you and you did not consider: your responsibility"). Some are mail-combat to warn adversaries, mark territories or even provoke results. Others are negociations. Like this one, I feel. Pre-Sao Paulo. This feeling of mine (from the mood - not from the content which is quite complex) is that for now most of the fundamental information has been exchanged and confirmed. Some details remain to be clarified. Orientations are settled. Future ICANN mailing lists, working groups, debates, meetings, contributions, etc. will only be for brainwashing. The outcome will emerge from what is now established (dont ask me: I am an analyst, not a guru) and from pratical development in the months to come. I would says there is probably a good mutual understanding among "strategists", and common misunderstandings of the usefull "believers". This is usually the case, except that in this case there as a long term indoctrination to consider concerning a large number of States and Stakeholders; and an extremely tight and precise calendar for two years - since Dubai preparation. Anyway, now has come the time of the writers of the official statements and presentation speakers. They may help understanding what has been settled, or prepare the next step. Probably not before end of 2015, unless there are planned last minute or out of sequence shoots. M G At 17:06 26/03/2014, Shatan, Gregory S. wrote: >Michel: > >You are incorrect. I read George’s entire email, as well as both >of Jefsey’s emails. Following that, I posted the email to which you replied. > >I see no reason to assume that George will not “apply his own >rules to himself.” I believe his prior posts are consistent with >his “rules.” He has not posted since the “rules” >post. Therefore, not only is the “I will when you will” >position unproductive, it has no factual basis. In any event, these >are not “George’s rules”; a number of participants in the list >have already indicated their appreciation for and agreement to abide >by these rules of “Netiquette.” > >As to your comment that I “do not know how to comment [on] >JFC[‘s] definitions”; I find that, in George’s words, >“disdainful and impolite.” I may or may not respond or >otherwise discuss the issue of what multistakeholderism >is. If don’t, it is not because I lack the ability or talents to >do so. If I felt it was the best use of my limited time, I would >respond. If not, it is because I find other things here more >pressing, relevant or fruitful. > >Greg Shatan