From nobody Sat Oct 4 01:34:30 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD21A0191; Sat, 4 Oct 2014 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 KCGrebMGqVjR; Sat, 4 Oct 2014 01:34:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCF81A9005; Sat, 4 Oct 2014 01:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 75D502CC64; Sat, 4 Oct 2014 11:34:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WacpjiwEh6WI; Sat, 4 Oct 2014 11:34:09 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2E3362CC4D; Sat, 4 Oct 2014 11:34:09 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_7733860F-6A32-48B4-9DA0-761DD77AC000"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <20140923000751.91C651A6F63@ietfa.amsl.com> Date: Sat, 4 Oct 2014 11:34:13 +0300 Message-Id: <1015C26A-D582-4049-8CA0-97C8A2114E01@piuha.net> References: <20140923000751.91C651A6F63@ietfa.amsl.com> To: JFC Morfin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/e8Qjyq8jq8tQdn9VOTQ9LyXTiSI Cc: ianaplan-chairs@tools.ietf.org, IAB , The IESG , "iucg@ietf.org" Subject: Re: [iucg] [IAB] [Ianaplan] IANAPLAN virtual meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:34:26 -0000 --Apple-Mail=_7733860F-6A32-48B4-9DA0-761DD77AC000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 JFC, I was initially not going to respond to this because I thought the = answer was obvious, and since you got an answer from Pete. And because I = was busy :-) But since you=92ve raised it again later: > Prior to this virtual global meeting, I would like to request an = IANAPLAN IETF/WG charter update in two directions. I do not plan to update the charter at this time. I believe the current = charter is supported by IETF consensus, as determined by the IESG during = the WG Review of this charter. Not only was IETF-wide WG Review held = (with an announcement to other SDOs), but there was also a BOF held at = the previous IETF meeting. In both instances, the community was = insistent that the WG not be given the latitude to change current = operational procedures. Jari Arkko (speaking as the responsible AD for the WG) --Apple-Mail=_7733860F-6A32-48B4-9DA0-761DD77AC000 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 iQIcBAEBCgAGBQJUL7EGAAoJEM80gCTQU46qnUYP/j7AEca7Z/+Snp3IcwS9CcDx 2HkAf5rrT88Bc71SnsLc7ZpkZb2lEwDsjvm2t1ejVQpjiLHSOKbzrn0ffKiB8uJO kgpT2OjPymEYyaM+TZ2sTMtajwVM+FxjERMbTmF2aywpth2V/g6/BrgZLOQfZAWX xNBXATQ5MaCZSinFJwjZTBG/CEeWQ6iA/pBHgB67mGGcCQzDstni85Usarivt50e OtwaX1IA0JX9X4IhtjKHxI/q1cv9oLBxuU9MdJnd1Mq9Vk+1mq2U/FWTSN4LsD4K nZV34nUwH9+GAUayLzhQ640rGeJhwTwOzzHbFyCLxAmVAJNBvJhGpmRlPAaYmJmG WFjEVVdnRSwiR4d6C63Kyx79aRIfTysgm3xfzNwSZObykNpgjQs0H1ZGfieIbEaW RZ5i8SYLT2FDniolU2Gbdyxw/YLKXHESFXq1ID5/chS6IG5EsPXzj6mFsMq6R7c4 kz3JZJf6iZn1lYG5wuACEWwHbYLZgg2UaskurOSyIZH45M8Ka0MEiNMbQXSWFkJq iUSIlIiXP9ZYekeLRHiqK2GKisx5CvDK4/Cxw2DRSCuF2wOQdd2JX6yzSQR38nrJ 5pz+nmLGQ/osXsjvuZFK0Di9UoCOCPPGeqkVCyGRD+4qh8F93pPgYIGw6fLqgJfy MyrhlKaStR+rnXCCK4kx =cZN3 -----END PGP SIGNATURE----- --Apple-Mail=_7733860F-6A32-48B4-9DA0-761DD77AC000-- From nobody Mon Oct 6 07:59:19 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FACB1A00C2; Mon, 6 Oct 2014 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_17=0.6, MISSING_MID=0.497] 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 3hC0xi3g3Atr; Mon, 6 Oct 2014 07:59:12 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64741A00B8; Mon, 6 Oct 2014 07:59:12 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:25763 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xb9kk-0004qX-KA; Mon, 06 Oct 2014 07:59:11 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Oct 2014 16:59:04 +0200 To: Jari Arkko From: JFC Morfin In-Reply-To: References: <9390B5F8-8E21-40C2-9E96-168CD599419B@viagenie.ca> <542EEADA.6000206@thinkingcat.com> <20141004065827.84D7D1A8F46@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_370486758==.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 - ietf.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/iucg/SxPbl1yxldY_LAZLuUeh5w53ssc Cc: Marc Blanchet , "Leslie Daigle \(TCE\)" , "iucg@ietf.org" , iesg@ietf.org, "ianaplan@ietf.org" Subject: [iucg] prior to he today virtual meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:59:15 -0000 --=====================_370486758==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:35 04/10/2014, Jari Arkko wrote: >Jefsey, > > > I am sorry, but my various efforts in order to avoid an appeal > against the charter's status-quo spirit and letter did not succeed so far. > >For what it is worth, I do not plan to update the charter at this >time. I believe the current charter is supported by IETF consensus, >as determined by the IESG during the WG Review of this charter. Not >only was IETF-wide WG Review held (with an announcement to other >SDOs), but there was also a BOF held at the previous IETF meeting. >In both instances, the community was insistent that the WG not be >given the latitude to change current operational procedures. > >Jari Arkko (speaking as the responsible AD for the WG) Dear Jari (as an IESG chair and WG/IANAPLAN AD), As you know, I am planning to appeal the IESG 08 Sep 2014 09:02:52 -0700 decision to adopt the WG/IANAPLAN Charter, but I wish we could avoid the implied work load and hassle. The target so far (some additional elements may result from today's virtual meeting report) is for the internet users' various community layers (individual, local, corporate, national, governmental) to be able to assess the capacity and motivation of the IETF to continue documenting a technically better internet when a-priori strategies are decided on that are based upon economic motives and governmental injunctions, as it would seem to be the case for the response to the unclear NTIA unilateral March 14, 2014 announcement. Two parts in the charter seem to be critical for the stability of the Internet community and technology: 1. "In the case of the elements of the IANA function concerning the IETF protocol registries, it is likely that the existing well-documented practices will continue and no or little new activity will be required." This is something that contradicts the RFC 6852 assessment of digital world reality. Only considering the status quo in a fundamentally changing situation, as the Chair (Leslie Daigle) assigned it to the WG, is either an deliberate (why?) ostrich policy or a hidden coordination with the authors of the change. 2. "Should proposals made by other communities regarding the transition of other IANA functions affect the IETF protocol parameter registries or the IETF, the WG may also review and comment on them." This wording is not only contemptuous of other communities, but also to all internet users since it permits the WG to not consider inputs from other stakeholders, to select the stakeholders it "could" listen to, and to not address the positive or negative impact of their positions on the common good. The Chair (Marc Blanchet) said that the WG would consider every proposal. It is necessary for the AD and Chairs to formally commit to what they will consider, comment on, and address regarding the announcements and/or proposals made by all other stakeholders. Now, we are facing a problem of timing. At the ICANN's request, the January 15 milestone is a rough consensus over a complete protocol parameters registries document. - The appeal limit date is November 8, 2014. I hope that I do not need that long (all of us want quick clarifications since we are engaged in status quo or innovative solution projects) but this may depend on today's virtual meeting. - If the IESG responds negatively the same day, I could appeal the IAB until January 8, 2015. - Again, the IAB could respond negatively the same day and stay ahead of the January 15 date. - However, such fast responses would certainly give me good grounds to appeal ISOC. This is why I suggest that we try to play this out reasonably, keeping political interests, the press, and sponsors aside. The difficulty that we are facing is simple to evaluate. The USG's and OECD's internet governance vision that the NTIA is trying to sneak-in was multilaterally and democratically defeated in Dubai. This vision is questioned by the users, when the WSIS has consensually declared that the information society was to be people [and not business or jurisdiction] centered, decisions are to be made on a multistakeholder (govs, business, civil society) basis, and the I*Society's mantra is that the internet is for everyone to use, innovate, experiment on, and deploy. The NTIA multistakeholder reduced the mutual recognition constraints in reference of govs and lead users are diplomatically pious vows. They will do what they want. Datagrams do not really care about diplomatic announcements. We know that there is a wide portion of the Internet users that disagrees with the NTIA's idea that ICANN is to protect them from their own Governments and who trust their own political and Defense national institutions (they pay for that through their taxes) to engage in active precautionary strategies, at least when public and private NSAs are concerned. The IETF's job is not to judge whether these people are right or wrong. It is to technically ensure that its published set of protocol rules will best adapt to their needs and the resulting situational changes, and that these people trust them. Otherwise, such people and Govs will patch their own contingency plan and technical solutions (or have them ready). I know this well because I am, as you know, carrying that out myself, for my local non-profit Libre digital operator and my fellow independent involved etc. users. jfc --=====================_370486758==.ALT Content-Type: text/html; charset="us-ascii" At 10:35 04/10/2014, Jari Arkko wrote:
Jefsey,

> I am sorry, but my various efforts in order to avoid an appeal against the charter's status-quo spirit and letter did not succeed so far.

For what it is worth, I do not plan to update the charter at this time. I believe the current charter is supported by IETF consensus, as determined by the IESG during the WG Review of this charter. Not only was IETF-wide WG Review held (with an announcement to other SDOs), but there was also a BOF held at the previous IETF meeting. In both instances, the community was insistent that the WG not be given the latitude to change current operational procedures.

Jari Arkko (speaking as the responsible AD for the WG)

Dear Jari (as an IESG chair and WG/IANAPLAN AD),

As you know, I am planning to appeal the IESG 08 Sep 2014 09:02:52 -0700 decision to adopt the WG/IANAPLAN Charter, but I wish we could avoid the implied work load and hassle.

The target so far (some additional elements may result from today’s virtual meeting report) is for the internet users’ various community layers (individual, local, corporate, national, governmental) to be able to assess the capacity and motivation of the IETF to continue documenting a technically better internet when a-priori strategies are decided on that are based upon economic motives and governmental injunctions, as it would seem to be the case for the response to the unclear NTIA unilateral March 14, 2014 announcement.

Two parts in the charter seem to be critical for the stability of the Internet community and technology:

1. "In the case of the elements of the IANA function concerning the IETF protocol registries, it is likely that the existing well-documented practices will continue and no or little new activity will be required." This is something that contradicts the RFC 6852 assessment of digital world reality. Only considering the status quo in a fundamentally changing situation, as the Chair (Leslie Daigle) assigned it to the WG, is either an deliberate (why?) ostrich policy or a hidden coordination with the authors of the change.

2. "Should proposals made by other communities regarding the transition of other IANA functions affect the IETF protocol parameter registries or the IETF, the WG may also review and comment on them." This wording is not only contemptuous of other communities, but also to all internet users since it permits the WG to not consider inputs from other stakeholders, to select the stakeholders it "could" listen to, and to not address the positive or negative impact of their positions on the common good. The Chair (Marc Blanchet) said that the WG would consider every proposal. It is necessary for the AD and Chairs to formally commit to what they will consider, comment on, and address regarding the announcements and/or proposals made by all other stakeholders.

Now, we are facing a problem of timing. At the ICANN's request, the January 15 milestone is a rough consensus over a complete protocol parameters registries document.

- The appeal limit date is November 8, 2014. I hope that I do not need that long (all of us want quick clarifications since we are engaged in status quo or innovative solution projects) but this may depend on today's virtual meeting.
- If the IESG responds negatively the same day, I could appeal the IAB until January 8, 2015.
- Again, the IAB could respond negatively the same day and stay ahead of the January 15 date.
- However, such fast responses would certainly give me good grounds to appeal ISOC.

This is why I suggest that we try to play this out reasonably, keeping political interests, the press, and sponsors aside. The difficulty that we are facing is simple to evaluate. The USG's and OECD's internet governance vision that the NTIA is trying to sneak-in was multilaterally and democratically defeated in Dubai. This vision is questioned by the users, when the WSIS has consensually declared that the information society was to be people [and not business or jurisdiction] centered, decisions are to be made on a multistakeholder (govs, business, civil society) basis, and the I*Society's mantra is that the internet is for everyone to use, innovate, experiment on, and deploy. The NTIA multistakeholder reduced the mutual recognition constraints in reference of  govs and lead users are diplomatically pious vows. They will do what they want. Datagrams do not really care about diplomatic announcements.

We know that there is a wide portion of the Internet users that disagrees with the NTIA's idea that ICANN is to protect them from their own Governments and who trust their own political and Defense national institutions (they pay for that through their taxes) to engage in active precautionary strategies, at least when public and private NSAs are concerned.

The IETF's job is not to judge whether these people are right or wrong. It is to technically ensure that its published set of protocol rules will best adapt to their needs and the resulting situational changes, and that these people trust them. Otherwise, such people and Govs will patch their own contingency plan and technical solutions (or have them ready). I know this well because I am, as you know, carrying that out myself, for my local non-profit Libre digital operator and my fellow independent involved etc. users.

 jfc
--=====================_370486758==.ALT-- From nobody Mon Oct 6 10:55:33 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261781A874F; Mon, 6 Oct 2014 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 W3O-Z06lnGJa; Mon, 6 Oct 2014 10:55:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id D4CBC1A00BF; Mon, 6 Oct 2014 10:55:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BD9CC2CED6; Mon, 6 Oct 2014 20:55:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZf7iK_KNSdj; Mon, 6 Oct 2014 20:55:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2CEB62CEB0; Mon, 6 Oct 2014 20:55:04 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0A5A6905-68F1-4A57-B1E4-114494456236"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <20141006145918.8EE1B1A6FCF@ietfa.amsl.com> Date: Mon, 6 Oct 2014 10:53:53 -0700 Message-Id: <147A9E87-BA4E-4031-B2A1-F28881A61CD1@piuha.net> References: <9390B5F8-8E21-40C2-9E96-168CD599419B@viagenie.ca> <542EEADA.6000206@thinkingcat.com> <20141004065827.84D7D1A8F46@ietfa.amsl.com> <20141006145918.8EE1B1A6FCF@ietfa.amsl.com> To: JFC Morfin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/441rv8vpZRIXawKqFw6p-NXxrN0 Cc: Marc Blanchet , "Leslie Daigle \(TCE\)" , "ianaplan@ietf.org" , "iucg@ietf.org" , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] prior to he today virtual meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 17:55:28 -0000 --Apple-Mail=_0A5A6905-68F1-4A57-B1E4-114494456236 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jefsey, Regarding strategies, I think we should skip attributing motives to them = or the participants. The situation is really very simple, as the = participants together have and will voice opinions about how to approach = the task ahead. The IETF is an open organisation and we have a long = track record of evolving the IANA services for protocol parameters. The = NTIA change is just one step in that evolution. Regarding proposals from other communities, the charter says it very = clearly: Should proposals made by other communities regarding the transition of other IANA functions affect the IETF protocol parameter registries or the IETF, the WG may also review and comment on them. And of course, since we are an open organisation, this does not limit = who we listen to. It just specifies what other things besides our own = proposal we need to review. Obviously, we are open for input with = everything, including the transition proposal that awe are working. Jari --Apple-Mail=_0A5A6905-68F1-4A57-B1E4-114494456236 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 iQIcBAEBCgAGBQJUMtcyAAoJEM80gCTQU46qfZcQAMFsbbO/9/cX5aBFMak8UlD6 tyf+QxH6AHpsSzNV3+iy2Ny/yIv/sLXKGS5th5SR5XtiR40LyajKicv0NBc/RQjp jV74nU8ZH/lN3Za7VKWUpwv4ft/MmCngSAPG9pXptHhxi7u46gimi7rY3leVqiwg /FdgVYsRHQ8Gf5Ozz7rgPDh7u4DseRG+GuwVHWlm0MdqDk0LgqpyT0StTXPGq699 WBIr3MfKR+64LjW5+Nzkf0IMoS6pzIe1a3Sva4e/+JZKO0z6YKoOZn05G51GQnD1 liJ4mjpHRjrFVTAPYvTs7iDVvJMin6iPBShSQGld1uX15vwRyt4nHJvFwjRApcyQ Vqa9uf80sU3TL7FHHxMpneLPNUgoo1fKKYycftR+0wnPRRtpTVFZUE1S1YSye2M0 Kuddo6XJPHocS3OaMziW+F3ldJNFNfbkuoeRqLPS3AKUnGlooHBbKxf/9sX15Zo5 aw+APWL2sNTZBF9NccoHH3g0KA5xbEfRQG970Cyv0u5g5I/RbxlSjoMTkIlcHN7m 8ybdRjhe+29ax2nrEInkbEjWB41y1dyPtQjZBXZKw7cVwakTohNIbnSoYpIRGxEm rb7Zkiz8ppCRxCkkKvH/aEZ//BR7O0Iqg+V2c+lu4lzYvqycfbntE/D91Ja3nHVh fLse/VqsrkzHdMMihDYY =OH0+ -----END PGP SIGNATURE----- --Apple-Mail=_0A5A6905-68F1-4A57-B1E4-114494456236-- From nobody Wed Oct 8 08:15:34 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA311A6F11; Wed, 8 Oct 2014 08:15:15 -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 Z_KBqlFG5rbL; Wed, 8 Oct 2014 08:15:13 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632CD1A6F0A; Wed, 8 Oct 2014 08:15:10 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:11135 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XbsxI-0006ef-4J; Wed, 08 Oct 2014 08:15:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Oct 2014 17:14:18 +0200 To: Jari Arkko From: Jefsey In-Reply-To: <147A9E87-BA4E-4031-B2A1-F28881A61CD1@piuha.net> References: <9390B5F8-8E21-40C2-9E96-168CD599419B@viagenie.ca> <542EEADA.6000206@thinkingcat.com> <20141004065827.84D7D1A8F46@ietfa.amsl.com> <20141006145918.8EE1B1A6FCF@ietfa.amsl.com> <147A9E87-BA4E-4031-B2A1-F28881A61CD1@piuha.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_544241015==.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 - ietf.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/iucg/3v17IO_BP2bHqOpsXsVe7DrjFE4 Cc: "ianaplan@ietf.org" , "Leslie Daigle \(TCE\)" , Marc Blanchet , iab@iab.org, "iucg@ietf.org" , iesg@ietf.org Subject: [iucg] Response to Jari X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:15:16 -0000 --=====================_544241015==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 19:53 06/10/2014, Jari Arkko wrote: >And of course, since we are an open organisation, this does not >limit who we listen to. It just specifies what other things besides >our own proposal we need to review. Obviously, we are open for input >with everything, including the transition proposal that awe are working. Dear Jari, Thank you for your response. An open organization in a changing context can suffer from it or catalyze it, more over in acting at the proprer time. Let me review this. The past context The IETF is a voluntary standardization organization that is supposed to adhere to its own RFC 6852 "Affirmation of the Modern Paradigm for Standards". ICANN is a US Government, non-profit contractor for making available the IETF IANA parameters and its own IANA names and numbers under the US Government oversight that also contracts to Verisign the permanent availability of the names (root) reference file. The US Government legislation concerning the packet switching network, FCC operational licenses, and international data relations agreements predates by several years the creation of the Internet, as the internetting of the ARPANET system, which connected to the international packet switch services (IPSS) network in 1984. This means that: 1. the network can economically, politically, technically, and legally operate without the IETF, ICANN, and the IANA. They are only our today's way to attend needs that belong to the network technology and its governance evolution. 2. Since their inception in 1986 and 1998, each of them has always existed within the sole US Government oversight framework. They benefited from the international mutual recognition of that framework to enter into some agreements with international organizations, such as ITU, ISO, WIPO, etc. and developed their external, internal, and mutual practices under that sole umbrella. This context dies and that umbrella closes on September 30, 2015. The new context What will remain will only be: 1) the world digital ecosystem communications infrastructure owned by local network providers and its use by billions of people under the contractual private terms that they bilaterally signed, and the World Communications International Treaty (WCIT) that the US Government has not signed. 2) private agreements and contracts between two US private organizations (ISOC and ICANN) specializing in a kind of usage (TCP/IP with a single DNS root, IANA, IPv4/6 addressing schemes) of that infrastructure 3) public affirmations produced by these organizations (RFCs in the case of IETF, and ICPs and AoC in the case of ICANN) to which people and corporations may refer in their own products, operations, and mutual contracts, subject to their (IETF Trust and ICANN) IPRs, under terms that are still to adapt to the conjunction of the "standard paradigm affirmation", the ICANN community Montevideo statement, and the NTIA announcement (as discussed by this WG). 4) the network of private bilateral contracts weaved by ICANN within the ICANN/NTIA "IN" DNS Class management framework. No one knows the market value of a domain name in that class after September 30, 2015 (can increase as being famous, or lose value as being a few among a broad offer/private offer). Any response, position, or question including the terms "obvious" and/or "of course" instead of accountable commitments bound to international law is, therefore, void and only leads to distrust of its author and the organization that he/she might represent or chair as being outdated or inadequate. The IETF a pain or an help? As a Libre and small operator, directly accountable to its user members, I can freely and responsibly raise the problem that I share with Govs, new technologies, incumbents operators, newcomers, and lead users. Why not give a chance to the IETF to document what is not "just one step" on "a long track record of evolving the IANA services"? The WG/IANAPLAN Chair (Leslie Daigle) has clearly indicated that this has not been the IETF intent so far, unless the IESG decides otherwise. This is why there is a need to ask the IESG first if it wants to stay outside of the multistakeholder loop, and possibly make sure that it is the whole IETF position in asking the IAB. If someone does not do it prior to 11/8 we probably have three options: - an alternative root situation development (cf. ICANN/ICP-3 as the document of reference) leading to a ***possible*** technological breakthrough or to a ***possible*** mess. - the emergence of a use/high level layers-oriented IETF equivalent. It will most probably take time. - an ITU solution discussed within the WCIT framework. An interesting consequence of the NTIA initiative. The RFC 6852 tactical opportunity I also want to emphasize that, at this time, RFC 6852 is still sufficiently new for: - its sole economic demand orientation to be accepted, - which should help a fast and simple enough refoundation debate. Further on, its ultimate innovation decision track, by economic power dominance over inter-global community competition, will disappear as people, cultural, political, military and many other demands, priorities, and R&D capacities become considered. The responsibility is yours as the AD and as the IETF Chair. jfc --=====================_544241015==.ALT Content-Type: text/html; charset="us-ascii" At 19:53 06/10/2014, Jari Arkko wrote:
And of course, since we are an open organisation, this does not limit who we listen to. It just specifies what other things besides our own proposal we need to review. Obviously, we are open for input with everything, including the transition proposal that awe are working.


Dear Jari,

Thank you for your response. An open organization in a changing context can suffer from it or catalyze it, more over in acting at the proprer time. Let me review this.


The past context

The IETF is a voluntary standardization organization that is supposed to adhere to its own RFC 6852 "Affirmation of the Modern Paradigm for Standards". ICANN is a US Government, non-profit contractor for making available the IETF IANA parameters and its own IANA names and numbers under the US Government oversight that also contracts to Verisign the permanent availability of the names (root) reference file.

The US Government legislation concerning the packet switching network, FCC operational licenses, and international data relations agreements predates by several years the creation of the Internet, as the internetting of the ARPANET system, which connected to the international packet switch services (IPSS) network in 1984.

This means that:

1. the network can economically, politically, technically, and legally operate without  the IETF, ICANN, and the IANA. They are only our today’s way to attend needs that belong to the network technology and its governance evolution.

2. Since their inception in 1986 and 1998, each of them has always existed within the sole US Government oversight framework. They benefited from the international mutual recognition of that framework to enter into some agreements with international organizations, such as ITU, ISO, WIPO, etc. and developed their external, internal, and mutual practices under that sole umbrella.

This context dies and that umbrella closes on September 30, 2015.


The new context

What will remain will only be:

1) the world digital ecosystem communications infrastructure owned by local network providers and its use by billions of people under the contractual private terms that they bilaterally signed, and the World Communications International Treaty (WCIT) that the US Government has not signed.

2) private agreements and contracts between two US private organizations (ISOC and ICANN) specializing in a kind of usage (TCP/IP with a single DNS root, IANA, IPv4/6 addressing schemes) of that infrastructure

3) public affirmations produced by these organizations (RFCs in the case of IETF, and ICPs and AoC in the case of ICANN) to which people and corporations may refer in their own products, operations, and mutual contracts, subject to their (IETF Trust and ICANN) IPRs, under terms that are still to adapt to the conjunction of the “standard paradigm affirmation”, the ICANN community Montevideo statement, and the NTIA announcement (as discussed by this WG).

4) the network of private bilateral contracts weaved by ICANN within the ICANN/NTIA "IN" DNS Class management framework. No one knows the market value of a domain name in that class after September 30, 2015 (can increase as being famous, or lose value as being a few among a broad offer/private offer).

Any response, position, or question including the terms "obvious" and/or "of course" instead of accountable commitments bound to international law is, therefore, void and only leads to distrust of its author and the organization that he/she might represent or chair as being outdated or inadequate.


The IETF a pain or an help?

As a Libre and small operator, directly accountable to its user members, I can freely and responsibly raise the problem that I share with Govs, new technologies, incumbents operators, newcomers, and lead users. Why not give a chance to the IETF to document what is not "just one step" on "a long track record of evolving the IANA services"?

The WG/IANAPLAN Chair (Leslie Daigle) has clearly indicated that this has not been the IETF intent so far, unless the IESG decides otherwise. This is why there is a need to ask the IESG first if it wants to stay outside of the multistakeholder loop, and possibly make sure that it is the whole IETF position in asking the IAB.

If someone does not do it prior to 11/8 we probably have three options:

- an alternative root situation development (cf. ICANN/ICP-3 as the document of reference) leading to a ***possible*** technological breakthrough or to a ***possible*** mess.
- the emergence of a use/high level layers-oriented IETF equivalent. It will most probably take time.
- an ITU solution discussed within the WCIT framework. An interesting consequence of the NTIA initiative.


The RFC 6852 tactical opportunity

I also want to emphasize that, at this time, RFC 6852 is still sufficiently new for:
- its sole economic demand orientation to be accepted,
- which should help a fast and simple enough refoundation debate.

Further on, its ultimate innovation decision track, by economic power dominance over inter-global community competition, will disappear as people, cultural, political, military and many other demands, priorities, and R&D capacities become considered.

The responsibility is yours as the AD and as the IETF Chair.

jfc

--=====================_544241015==.ALT-- From nobody Wed Oct 8 11:40:25 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8A1ACE52; Wed, 8 Oct 2014 11:40:22 -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 vwFXXJl7ql9H; Wed, 8 Oct 2014 11:40:21 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7FC1ACD01; Wed, 8 Oct 2014 11:40:21 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:16532 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xbw9s-00027P-S7; Wed, 08 Oct 2014 11:40:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Oct 2014 20:40:03 +0200 To: Alissa Cooper ,Eliot Lear From: Jefsey In-Reply-To: <2F1E6F5D-F072-4573-BB50-E47B3180649C@cooperw.in> References: <5433AC94.50005@cisco.com> <543450F6.2080600@cisco.com> <5007442A-779C-4F88-B58D-8C8293C5BD83@cooperw.in> <5434BE3C.90000@cisco.com> <2F1E6F5D-F072-4573-BB50-E47B3180649C@cooperw.in> 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 - ietf.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/iucg/zCoy1XY_4NkyD6eo6d8aCKS_VMU Cc: "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 18:40:22 -0000 At 19:57 08/10/2014, Alissa Cooper wrote: >Agreement to minimize confusion seems fine; a requirement on ICANN >to declare that we have some authority is a non-starter from my perspective. Allissa, dont you think that where there is confusion it should be clarified rather than minimized? Is it not better to have a tough negociation today rather than a conflict further on? Do you mean that ICANN could have some authority on any structural issue? Their role is to govern, not to normalize. Architectonics is the political science that deals with how things are. Governance is the political art to command to free (now interconnected) men. (Aristotle). The IETF area is the first one, the ICANN area is the second one. If we are not strict on this, we will add to confusion at the IETF level, and multiply confusion outside because others will create their own clearly separated documentation. I think we miss the USCC position in this debate. What are they ready to accept from ICANN? or has Admiral Michael S. Rodgers already a budget for a IANATO? We are discussing a new phase for a real world. jfc From nobody Thu Oct 9 02:00:30 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716361ACCFA; Thu, 9 Oct 2014 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zkEkVlzYldv; Thu, 9 Oct 2014 02:00:24 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC0F1ACCF0; Thu, 9 Oct 2014 02:00:24 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:61610 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xc9aA-0004i7-Qf; Thu, 09 Oct 2014 02:00:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Oct 2014 11:00:25 +0200 To: rhill@hill-a.ch,"Andrei Robachevsky" , "Alissa Cooper" , "Miles Fidelman" From: JFC Morfin In-Reply-To: References: <543634B4.4060602@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 - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/WEEKdw1cMrGhLsii1CcQbekA1uA Cc: ianaplan@ietf.org, IAB , "iucg@ietf.org" , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 09:00:25 -0000 At 09:12 09/10/2014, Richard Hill wrote: >I agree with Andrei. Yes. But one does not change people and their habits. One change their context. Things are simple: if the nexus is not the USG anymore what will it be? ICANN/Business, ITU/Gov, IUse/people, a World Digital Organization, or chaos? Unless some want the IETF to be that nexus, the IETF is not to side with one camp but to make sure the internet is ready for the context resulting from any of them. > > Yes, the authority doesn't come from a contract. But the contract can > > help minimize possible confusion in the future. The hardcoded registry > > location is a pretty strong lever in whatever possible future > > negotiations, IMO. > > > > Andrei Note: I know most of the people on the ianaplan mailing list do not read my posts. They are writen for those who work for an intelligent world for all rather than a world of intelligence on all and for the coming negociation background and probable (?) IETF higher layers fork. This is ***their*** decision - unless the IESG, IAB, ISOC jfc PS. The GSN concept that guide the world: "A global solution network consists of diverse stakeholders, organized to address a global problem, making use of transnational networking, and with membership and governance that are self-organized". This has a name: in politics, a lobby, in the real world, an enhanced global coalition of global interests and RFC 6852 communities toward the RFC 6852 "huge bounty". Such nexus architectonically oppose a WSIS people centered society. http://gsnetworks.org/sponsorship/ http://www.libertyglobal.com/about-us.html http://www.rockefellerfoundation.org/ http://www.rbc.com/aboutus/index.html http://google.com etc. From nobody Fri Oct 10 00:58:48 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755391A1B80; Fri, 10 Oct 2014 00:58:45 -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 fzlzt19VaB97; Fri, 10 Oct 2014 00:58:44 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62121A1B7E; Fri, 10 Oct 2014 00:58:44 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:47562 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XcV63-00013n-SU; Fri, 10 Oct 2014 00:58:44 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Oct 2014 09:58:36 +0200 To: Andrei Robachevsky , Bernard Aboba , "Leslie Daigle (TCE)" From: Jefsey In-Reply-To: <5437876A.60607@gmail.com> References: <5437031D.9080505@thinkingcat.com> <5437876A.60607@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 - ietf.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/iucg/s0Rdx51Lt1bDH5FR78ydzIooByk Cc: "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] teasing the issues apart -- IANA.org, authoritative IETF repository X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 07:58:45 -0000 At 09:14 10/10/2014, Andrei Robachevsky wrote: >IMHO, as long as ICANN continues to host iana.org (as part of providing >at least one of the IANA functions, or as a hosting service alone) it >must point to the authoritative registry location in case a new operator >for a function is selected. Andrei, the point is not what others "must" do, but what if they don't do. jfc From nobody Fri Oct 10 05:14:49 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2EB1A90DA; Fri, 10 Oct 2014 05:14:44 -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 s3UD7VAGrdzC; Fri, 10 Oct 2014 05:14:44 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABAC1A8BAF; Fri, 10 Oct 2014 05:14:43 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:53555 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XcZ5m-00056p-KE; Fri, 10 Oct 2014 05:14:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Oct 2014 14:14:35 +0200 To: "Leslie Daigle (TCE)" , "ianaplan@ietf.org" From: JFC Morfin In-Reply-To: <5437031D.9080505@thinkingcat.com> References: <5437031D.9080505@thinkingcat.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 - ietf.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/iucg/Xrt6TAoEznrhgZ1O9tazfiToeY8 Cc: iab@iab.org, vint Cerf , iesg@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] teasing the issues apart -- IANA.org, authoritative IETF repository X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 12:14:45 -0000 At 23:50 09/10/2014, Leslie Daigle (TCE) wrote: >I feel there is still a discussion to be had here, though I am >sensitive to the fact that we're spelunking in a pretty big rathole >at this time. Trying to tease issues apart to see if it helps the >discussion -- from the couple of days' messages, it seems that: Thank you, this defines the IETF present questions rather well that are to be seen, at this WG/IANAPLAN through Andrew Sullivan's filter: "Our charter tells us to do the minimum possible. We should heed its instructions." However, we have to be careful at not doing less than the minimum required. 1. internet ownership >1/ Some people think the IETF (Trust) is the obvious home of iana.org . Yes. This makes the ISOC/IETF Trust the owner of the Internet technology. From a Libre point of view, RFCs should be subject to a Chinese wall and the internet use to be specified again from a user point of view in order to free the internet system from the IETF Trust. > Others don't believe that and/or think it would be a stretch to > get the rest of the world to agree. Correct. It is unlikely that BRICS, Europe, and Libre will accept the IETF Trust terms at this stage. This may result in some TPP/TAFTA legal actions that will have no impact on the people's intelligent use of the internet. However, might affect IETF and ICANN's image and credibility and the US industry's interests. >But, for now, I would like to suggest we take discussion of "1/" off >the table. This would not make any sense, if (as most probably the rest of the world believes) "1/" is the key to "2/". ==> suggested action: to port the IETF deliverables (RFCs and IANA Tables) under a Creative Common license. From ISOC proprietary to Free. From a GSN pact to people's Libre. 2. tightly bind the future to the past. >2/ The issue that Eliot opened on the document was to address how >best to go about "requiring the current operator make clear upon >termination that their copy is no longer the version that is >maintained on our behalf, where at on[e] point (today and hopefully >long from now) it was. " (Eliot's words). > >I think "2/" has been characterized as rational contractual >behavior, and it seems like a worthwhile problem to address. The >challenge is that the most obvious way to achieve 2 is to bind >iana.org and the registries, tightly, as they are today. This supposes that the real world is not the world described by the RFC 6852 paradigm, i.e. there is still only one global community network managed by ICANN and documented by ISOC. 3. Preventing the fork >Other thoughts? Unless the IESG, IAB, and ISOC say otherwise you are documenting an IETF fork between the past and reality, and between IEN 48 first and second objectives, when it could have been cooperation between robust end to end lower layers and intelligent fringe to fringe higher layers. ==> suggested action: to add to the RFC 3935 missions of the IETF: "to engage in the IEN 48 second objective along its core values, the RFC 6852 paradigm and the consequence of the US/NTIA removal, i.e. to share the global catenet among/with other technologies". This would translate into advocating a WG/RFC3935bis. 4. Conclusion There are only three clarifications needed: 1/ is the NTIA transitioning its DNS or complete IANA oversight? 2/ is RFC 3935 or RFC 6852 the reference for the IETF or a consistent update of RFC 3869, 3935, and 6852 to be done? 3/ is the IETF wishing to constrain innovation to the past, or provide a stable basis to open future innovation? This seems to clearly delineate the purpose of my appeal. Thank you. jfc From nobody Fri Oct 10 22:21:05 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958FB1A1ABF; Fri, 10 Oct 2014 22:20:52 -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 uuQob03jeY20; Fri, 10 Oct 2014 22:20:51 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D531A1ABC; Fri, 10 Oct 2014 22:20:51 -0700 (PDT) Received: from 94.104.14.81.rev.sfr.net ([81.14.104.94]:6642 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xcp6o-0005sX-HC; Fri, 10 Oct 2014 22:20:50 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Oct 2014 07:20:39 +0200 To: Milton L Mueller , Brian E Carpenter , "rhill@hill-a.ch" From: Jefsey In-Reply-To: References: <54383562.7010109@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 - ietf.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/iucg/1o0BUArt62pXOvruW5_Gik9NwV4 Cc: "ianaplan@ietf.org" , Alissa Cooper , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Suggested text X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 05:20:52 -0000 At 22:37 10/10/2014, Milton L Mueller wrote: >Clearly, past experiences which are not applicable to the current >situation are distorting some judgments about how to proceed today. Correct. And this is true for everything, including the technology deployment as it has been affected by the IANA oversight through the "status-quo" strategy. The post-partum internet will be inherently different from the ante-partum internet. >You need to understand that you are not bargaining with ICANN, as >you were in 1999-2000. You are making a proposal to the NTIA, which >is then supposed to require ICANN to abide by it. I don't know how >many times I have to reiterate this simple fact. Correct. I don't know either how many times I have to reiterate the simple fact that the NTIA own's new environment is (1) the post-Dubai/Snowden context, (2) the RFC 6852 uncompletely documented normative paradigm and (3) the natural "IUse" trend, i.e. a free and individually/communinitarily autonomous lead user approach of the Internet utilization. >Lots of problems could intervene (the US congress, for example), but >one problem we do not have is ICANN's counsel not allowing them to >do what a finalized proposal from ICG asks them to do. Correct. But be sure that their/our legal counsels will certainly influence the ante-partum finalization of the proposal finalization process. The same as people like you and me, communities of technical interests, and Govs will try to influence the whole technical/political context through technical break-throughs (such as the MYCANN Plug-in) and/or political influence (as your mails). No one reasonable can accept that their daily global digital presence and investments depend on an unaccountable zombicann structure. jfc From nobody Sun Oct 12 07:50:55 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E591A88B2; Fri, 10 Oct 2014 09:10:23 -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 zwHpBuCZ26MB; Fri, 10 Oct 2014 09:10:22 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08281A887D; Fri, 10 Oct 2014 09:09:11 -0700 (PDT) Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:58739 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xccka-0001EW-0M; Fri, 10 Oct 2014 09:09:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Oct 2014 18:08:54 +0200 To: "Eliot Lear (elear)" ,Alissa Cooper From: Jefsey In-Reply-To: References: <54366147.3080508@cs.tcd.ie> <20141009180055.GE22512@mx1.yitter.info> <5436D407.6000300@cs.tcd.ie> <9CA428EA-0FCC-4EFC-98CA-FBABAC15713D@cooperw.in> 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 - ietf.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/iucg/eAzORAoRowESy2IUZkPMDERz16Q X-Mailman-Approved-At: Sun, 12 Oct 2014 07:50:54 -0700 Cc: "ianaplan@ietf.org" , Andrew Sullivan , Stephen Farrell Subject: Re: [iucg] [Ianaplan] Suggested text X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:10:23 -0000 At 16:47 10/10/2014, Eliot Lear (elear) wrote: >NTIA, ICANN, and the IETF must take steps to leave no doubt but that >they are in the public domain. Unfortunately they are not. BCP 78 is not CC. This is the whole issue. jfc From nobody Sun Oct 12 09:04:48 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586A1A6F02; Sun, 12 Oct 2014 09:04:41 -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 wGwhg6FJpCo2; Sun, 12 Oct 2014 09:04:39 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9081A6EEF; Sun, 12 Oct 2014 09:04:39 -0700 (PDT) Received: from 144.57.14.81.rev.sfr.net ([81.14.57.144]:40272 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XdLdN-0007fS-W7; Sun, 12 Oct 2014 09:04:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Oct 2014 18:04:29 +0200 To: Miles Fidelman From: Jefsey In-Reply-To: <543A71E5.5040606@meetinghouse.net> References: <543A2A27.6050006@it.aoyama.ac.jp> <543A71E5.5040606@meetinghouse.net> 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 - ietf.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/iucg/C_hGb5KsV1jII_JT13XmSu5VK2A Cc: ianaplan@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Suggested text X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 16:04:41 -0000 At 14:19 12/10/2014, Miles Fidelman wrote: >Something I really don't understand here: The NTIA transition is >explicitly a contractual matter - why the reluctance to deal with >contractual and legal issues? For the simple reason that we, the member of this list, are not lawyers, and for most not considering this issue as an international law case. Actually they are told not to. This may also be that the NTIA is attempting a "multi-stakeholder" non-democratic minority coup against the Dubaï democratic (both in terms of States and of represented people) vote. This is not surprising since the USG Executive branch, of which the NTIA is a part, also oversights the NSA democratic usages. >For that matter, why is it that IETF is the entity responding to the >TCG, not the legal entity involved (IETF trust or ISOC - it's >getting harder and harder to keep track of the players, without a scorecard). The IETF Trust is the tool to support BCP 78, which is the non-CC RFC license. The whole things is the ISOC GSN (1) dtrategy. This approach was documented by Lynn St-Amour (on this list) and Don Tapscott in a very long Press Release accompanied by two big books published on .... March 4, 2014. It was their immediate reaction to the NTIA annoucement in reaction to the unexpected NETmundial unexpected decision by Fadi and Dilma http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/ The Lynn/Don's strategy for the Internet this WG is engineered to help endorsing results from a several years cooperation that is documented on Don's site: http://martinprosperity.org/media/GSN%20Prospectus%20101012.pdf http://martinprosperity.org/media/R%20GSN%20Prospectus%202013.pdf etc. This can be described as a mutially selected/recognised stakeholders aristocracy doctrine to counter a fractal (independent of the scale) democratic legimacy and deny its ultimate mulitude's polycratic mechanisms (the way democracy works without states) the network technology leads to and enforces. The efficient internet of the dominants vs. the interneted people's life. They know better than me what makes me happy .... jfc ---- notes ---- (1) "a global solution network consists of diverse stakeholders, organized to address a global problem, making use of transnational networking, and with membership and governance that are self-organized". This is the not-at-all democratic thinking behind the US "multi-stakeholderism". It is introduced by Don Tapscott (http://dontapscott.com/) Lynn St-Amour Martin Properity, This thinking is engineered by GSN sponsored among others by (http://gsnetworks.org/sponsorship/) : Google, MasterCard, HP, SAP, Liberty Globa, Royal Bank of Canada, Rockefeller Foundation, accenture, Ontario, Seagate, Qualcomm, the US State Department, Cisco, the Canadian Ministry of Industry; in partnership with the UN Global Compact (2), the Lisbon Council (3), Digital Opportunity Trust (4), C40 Cities (5) (2) "The UN Global Compact asks companies to embrace universal principles and to partner with the United Nations. It has grown to become a critical platform for the UN to engage effectively with enlightened global business." UN Secretary-General Ban Ki-moon (3) "The Lisbon Council is a Brussels-based think tank and policy network committed to making a positive contribution by engaging political leaders and the public at large in a constructive exchange about the economic and social challenges of the 21st century" (4) Digital Opportunity Trust (DOT) is a leading international social enterprise headquartered in Ottawa, Canada with local operations around the globe. Its mission is "To create global networks of talented, energetic young leaders who make real change by educating local communities to apply technology effectively to real life." (5) C40 Cities : a compact representing 1/12 of the people of the world and 18% of the world GNP. >Miles Fidelman > > >"Martin J. Dürst" wrote: >>On 2014/10/11 18:47, Richard Hill wrote: >> >>>Since ICG is an emanation of ICANN, and is acting in accordance with the >>>mandate given to it by ICANN, I don't see why ICANN's counsel would (or even >>>could) advise ICANN to do anything other than what is in the final ICG >>>proposal. >> >>Well, sure it might be possible for a lawyer to try to come up with >>some minor legality in order to try to avoid (perceivedly) >>unpleasant things. But we shouldn't worry about that in advance. >> >> >>>Turning to the substantive matter, the NTIA said that the transition >>>proposal must "maintain the security, stability, and resiliency of the >>>Internet DNS". >>> >>>I think that we all agree that an unfriendly separation between ICANN and >>>IETF regarding the IANA function would result in some instability, even if >>>we disagree regarding the duration or severity of that instability. >> >>Even if we all agreed that the duration and severity of such an >>instability would be very minor, I think there's another aspect to consider: >> >>Some other organizations (governments, ITU,...) may want to claim >>that after NTIA is gone, stability has decreased. Whatever we can >>do to reduce their argumentation surface is probably a good thing. >> >>Regards, Martin. >> >> >>>So it seems to me that the transition plan should resist a stress test, of >>>the form "what happens in case of unfriendly separation". >>> >>>That is, the transition plan should be such that stability is maintained >>>even in the worst case scenario, provided of course that the resultant plan >>>is implementable. >> >>_______________________________________________ >>Ianaplan mailing list >>Ianaplan@ietf.org >>https://www.ietf.org/mailman/listinfo/ianaplan > > >-- >In theory, there is no difference between theory and practice. >In practice, there is. .... Yogi Berra > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan From nobody Sun Oct 12 10:19:18 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A30B1A6FC7; Sun, 12 Oct 2014 10:19:15 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char C3 hex): To: "Martin J. D\303\274rst" ) id 1XdMnY-0003Mj-ID; Sun, 12 Oct 2014 10:19:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Oct 2014 19:16:48 +0200 To: "Martin J. Dürst" ,rhill@hill-a.ch, Milton L Mueller , Brian E Carpenter From: JFC Morfin In-Reply-To: <543A2A27.6050006@it.aoyama.ac.jp> References: <543A2A27.6050006@it.aoyama.ac.jp> 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 - ietf.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/iucg/dWto7197KgfuGUVd7bGKUWoxtGA Cc: ianaplan@ietf.org, Alissa Cooper , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Suggested text X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 17:19:15 -0000 At 09:13 12/10/2014, Martin J. Dürst wrote: >Some other organizations (governments, ITU,...) may want to claim >that after NTIA is gone, stability has decreased. Whatever we can do >to reduce their argumentation surface is probably a good thing. Martin, this is exactly what we (as Libre and citizens) feel. This trust decrease will also affect the IETF in proportion to the firmeness/adequation of the position adopted by this WG. This is why the "mycann plug-in" definition and development projects start receiving some momentum and support. I frankly doubt they can be prevented (dont ask me the date as this is new development or political decision) because some Govs already have one and we all know that any geek can navigate the internet without paying attention to ICANN. However, their generalization, together with the coexistence with new technologies (NDN, SDN, VGN conception) is actually leading to the, long "status-quoed", IEN 48 second objective. This will be something like a "super-NAT" case. If we do not pay attention to it, we will not be entitled to complain afterward. The IETF should consider the end to end interface aspects of this fringe to fringe resulting middleware. jfc PS. I know nobody cares. My mails are just to demonstrate it. From nobody Mon Oct 13 09:22:42 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C131A037D; Mon, 13 Oct 2014 09:22:36 -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 FZJdWgDiPrem; Mon, 13 Oct 2014 09:22:33 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC6F1A030B; Mon, 13 Oct 2014 09:22:33 -0700 (PDT) Received: from 144.57.14.81.rev.sfr.net ([81.14.57.144]:1904 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XdiOG-0004hv-H8; Mon, 13 Oct 2014 09:22:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2014 18:22:24 +0200 To: "ianaplan@ietf.org" From: JFC Morfin In-Reply-To: <543BDC65.4090502@gmail.com> References: <5437031D.9080505@thinkingcat.com> <543BDC65.4090502@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_980286227==.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 - ietf.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/iucg/EofhdtmsBoHTA-4saJkES1_4FLo Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] teasing the issues apart -- IANA.org, authoritative IETF repository X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:22:36 -0000 --=====================_980286227==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >At 23:08 12/10/2014, Bernard Aboba wrote: >It is my assumption that the Trustees are following this discussion >and are thinking about next steps. If they discussed it in here, subject to the IETF consensus and to the IUsers' review, it could save us an appeal and possibly avoid a fork. >At 00:08 13/10/2014, Brian E Carpenter wrote: >IMHO that can include our expectations for any future additional >legal framework, plus the factual statement that the IETF Trust is >the responsible body for actual legal ink on paper. Ink on paper without having something to say is just a blot. To decide what to say (and what to do) belongs to this WG. >At 00:20 13/10/2014, Miles Fidelman wrote: >Which, to me, says that: >1. The WG charter is not sufficient to yield a complete response to >the TCG, and >2. It is not at all clear how the parts of the response, outside the >WG's purview, are to be developed and coordinated. > >If the response is to be both complete, and the result of a >consensus process -- leaving those issues in limbo seems inappropriate. Amen. >At 01:28 13/10/2014, Suzanne Woolf wrote: >The working group will not attempt to produce or discuss >documentation for these details, but will request the IAB or IAOC to >provide them separately. Instead of updating the charter, I might just appeal for changing its name from "ianaplan" to "ianaplahplah"... >The WG shall seek the expertise of the IAB IANA Evolution Program to >formulate its output. It is expected that members of the IAB IANA >Evolution Program will actively participate in the WG." For our best common information: who in this debate is a member of the "IAB IANA Evolution Program"? How many here are in that Program and how many in total? >At 09:25 13/10/2014, Stephen Farrell wrote: > >On 13/10/14 04:52, Milton L Mueller wrote: > > I hope to see some response to this point from responsible IETF > participants. >You are an IETF participant since you are posting to this list. Agreed! :-) However, this may call for a more in depth reading of RFC 3935. >RFC 3935 - Definition of terms: >- "Volunteer Core - our participants and our leadership are people >who come to the IETF because they want to do work that furthers the >IETF's mission of "making the Internet work better"" >- "Participants: Individuals who participate in the process are the >fundamental unit of the IETF organization and the IETF's work." >- "Relevant: In this context, useful to some group of people who >have to make decisions that affect the Internet, including, but not >limited to, hardware and software implementors, network builders, >network operators, and users of the Internet. Note that it does not >mean "correct" or "positive"" RFC 3935 - Mission Statement: "The IETF has to make decisions. And in some cases, people acting on behalf of the IETF have to make decisions without consulting the entire IETF first" - "Having a defined mission is one of the steps we can take in order to evaluate alternatives: Does this help or hinder the mission, or is it orthogonal to it? If there are limited resources, are there things that they could be invested in that help the mission better? Having a defined mission is one of the steps we can take in order to evaluate alternatives: Does this help or hinder the mission, or is it orthogonal to it? If there are limited resources, are there things that they could be invested in that help the mission better? (Another step is to choose leaders that we trust to exercise their good judgement and do the right thing. But we're already trying to do that.)". The leaders who we trust have exercised their good judgment and have done the right thing in changing the mission (and the standard process) of the IETF, through RFC 6852. - From IETF: "to make the Internet work better" by rough consensus. - To OpenStand IETF: "to contribute to the economics of global markets fueled by technological advancements, in driving a global deployment of standards developed through an open participatory process and voluntarily adopted globally that support interoperability and foster global competition regardless of their formal status, serve as building blocks for products and services targeted at meeting the needs of the market and consumer, and thereby drive an innovation that in turn will result in the creation of new markets and the growth and expansion of existing markets." As a result, we face a cultural difference between the traditional IETF "rough consensus" and the new ISOC/OpenStand RFC 6852 "broad consensus" documented by Lynn St-Amour/Don Tapscott's in the Internet multi-stakeholders GSN doctrine sponsored by Google/State Department/RBC, etc. and adopted, imposed, and propagated by the NTIA. - in the IETF, the rough consensus is evaluated by the Chair, - in a GSN environment, broad consensus is worked out among the WG-advised leaders of the mutually selected stakeholders in order to enforce the assigned goal. In this case, the goal assigned to the WG is to document a seamless application of the NTIA ukase, thereby making the internet work better or not. As if the govs and users were to seamlessly adopt a strategy that they have already voted gainst and will vote against - as they consider it preoccupying for democracy, people rights, development, and world peace as being demanded by the core (*) dominant state, the invading edge (*), and the spying leader (*) for economic reasons (*). Our best interest is the same as the US best interest, i.e. internet stability, neutrality, and transparency. Our duty is to make the NTIA understand that the way to reach that common goal is not the "status quo" and the ICANN being unilaterally global (BUG) to best serve a Business United Governance (BUG). (*) These terms are from/to be considered in relation to the RFC 3935 definition of the term "Internet": " The Internet: A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both - the "core Internet" (ISP networks) - and "edge Internet" (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices). The Internet is a truly global network, reaching into just about every country in the world. The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society". At that time (10 years ago this month), the Internet was to influence economics rather than to be led by it. Its target was to build a better human society; not to reduce us into better consumers parked in global market communities. >At 12:08 13/10/2014, Richard Hill wrote: >The IGC charter says that the ICG will deliver its report to the >NTIA. Since the discussions on this list are about replying to the >ICG, I think that we have to stick to what the ICG charter says. We can certainly take into account what the IGC will tell ICANN to report to the NTIA on the IANA transition in response to their question on the DNS transition. However, don't you think we should mainly focus on telling the IESG that we want to stick to the way to make the internet work better under the new circumstances that we observe and expect? >At 16:06 13/10/2014, Andrei Robachevsky wrote: >Why don't we recommend that these (or similar) provisions are added >to the existing MoU, since, as we all agree, the existing system >hasn't raised any concerns for the IETF? what about the wording/relation with RUSIANA, CNIANA, INDIANA, JFCIANA? Cheers jfc --=====================_980286227==.ALT Content-Type: text/html; charset="us-ascii"
At 23:08 12/10/2014, Bernard Aboba wrote:
It is my assumption that the Trustees are following this discussion and are thinking about next  steps.

If they discussed it in here, subject to the IETF consensus and to the IUsers' review, it could save us an appeal and possibly avoid a fork.


At 00:08 13/10/2014, Brian E Carpenter wrote:
IMHO that can include our expectations for any future additional legal framework, plus the factual statement that the IETF Trust is the responsible body for actual legal ink on paper.

Ink on paper without having something to say is just a blot. To decide what to say (and what to do) belongs to this WG.


At 00:20 13/10/2014, Miles Fidelman wrote:
Which, to me, says that:
1. The WG charter is not sufficient to yield a complete response to the TCG, and
2. It is not at all clear how the parts of the response, outside the WG's purview, are to be developed and coordinated.

If the response is to be both complete, and the result of a consensus process -- leaving those issues in limbo seems inappropriate.

Amen.


At 01:28 13/10/2014, Suzanne Woolf wrote:
The working group will not attempt to produce or discuss documentation for these details, but will request the IAB or IAOC to provide them separately.

Instead of updating the charter, I might just appeal for changing its name from "ianaplan" to "ianaplahplah"...


The WG shall seek the expertise of the IAB IANA Evolution Program to formulate its output. It is expected that members of the IAB IANA Evolution Program will actively participate in the WG."

For our best common information: who in this debate is a member of the "IAB IANA Evolution Program"? How many here are in that Program and how many in total?


At 09:25 13/10/2014, Stephen Farrell wrote:
>On 13/10/14 04:52, Milton L Mueller wrote:
> I hope to see some response to this point from responsible IETF participants.
You are an IETF participant since you are posting to this list.

Agreed! :-) However, this may call for a more in depth reading of RFC 3935.


RFC 3935 - Definition of terms:
- "Volunteer Core - our participants and our leadership are people who come to the IETF because they want to do work that furthers the IETF's mission of "making the Internet work better""
- "Participants: Individuals who participate in the process are the fundamental unit of the IETF organization and the IETF's work."
- "Relevant: In this context, useful to some group of people who have to make decisions that affect the Internet, including, but not limited to, hardware and software implementors, network builders, network operators, and users of the Internet.  Note that it does not mean "correct" or "positive""

RFC 3935 - Mission Statement:
"The IETF has to make decisions.  And in some cases, people acting on behalf of the IETF have to make decisions without consulting the entire IETF first" - "Having a defined mission is one of the steps we can take in order to evaluate alternatives: Does this help or hinder the mission, or is it orthogonal to it? If there are limited resources, are there things that they could be invested in that help the mission better? Having a defined mission is one of the steps we can take in order to evaluate alternatives: Does this help or hinder the mission, or is it orthogonal to it? If there are limited resources, are there things that they could be invested in that help the mission better? (Another step is to choose leaders that we trust to exercise their good judgement and do the right thing.  But we're already trying to do that.)".

The leaders who we trust have exercised their good judgment and have done the right thing in changing the mission (and the standard process) of the IETF, through RFC 6852.

- From IETF: "to make the Internet work better” by rough consensus.
- To OpenStand IETF:  "to contribute to the economics of global markets fueled by technological advancements, in driving a global deployment of standards developed through an open participatory process and voluntarily adopted globally that support interoperability and foster global competition regardless of their formal status, serve as building blocks for products and services targeted at meeting the needs of the market and consumer, and thereby drive an innovation that in turn will result in the creation of new markets and the growth and expansion of existing markets."

As a result, we face a cultural difference between the traditional IETF "rough consensus" and the new ISOC/OpenStand RFC 6852 "broad consensus" documented by Lynn St-Amour/Don Tapscott's in the Internet multi-stakeholders GSN doctrine sponsored by Google/State Department/RBC, etc. and adopted, imposed, and propagated by the NTIA.

- in the IETF, the rough consensus is evaluated by the Chair,
- in a GSN environment, broad consensus is worked out among the WG-advised leaders of the mutually selected stakeholders in order to enforce the assigned goal.

In this case, the goal assigned to the WG is to document a seamless application of the NTIA ukase, thereby making the internet work better or not.

As if the govs and users were to seamlessly adopt a strategy that they have already voted gainst and will vote against - as they consider it preoccupying for democracy, people rights, development, and world peace as being demanded by the core (*) dominant state, the invading edge (*), and the spying leader (*) for economic reasons (*). Our best interest is the same as the US best interest, i.e. internet stability, neutrality, and transparency. Our duty is to make the NTIA understand that the way to reach that common goal is not the “status quo” and the ICANN being unilaterally global (BUG) to best serve a Business United Governance (BUG).

(*) <note>These terms are from/to be considered in relation to the RFC 3935 definition of the term "Internet": " The Internet: A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. 

The term includes both
- the "core Internet" (ISP networks)
- and "edge Internet"  (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices). 

The Internet is a truly global network, reaching into just about every country in the world.

The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society".

At that time (10 years ago this month), the Internet was to influence economics rather than to be led by it. Its target was to build a better human society; not to reduce us into better consumers parked in global market communities.
<note>


At 12:08 13/10/2014, Richard Hill wrote:
The IGC charter says that the ICG will deliver its report to the NTIA.  Since the discussions on this list are about replying to the ICG, I think that we have to stick to what the ICG charter says.

We can certainly take into account what the IGC will tell ICANN to report to the NTIA on the IANA transition in response to their question on the DNS transition. However, don't you think we should mainly focus on telling the IESG that we want to stick to the way to make the internet work better under the new circumstances that we observe and expect?


At 16:06 13/10/2014, Andrei Robachevsky wrote:
Why don't we recommend that these (or similar) provisions are added to the existing MoU, since, as we all agree, the existing system hasn't raised any concerns for the IETF?

what about the wording/relation with RUSIANA, CNIANA, INDIANA, JFCIANA?

Cheers
jfc --=====================_980286227==.ALT-- From nobody Sun Oct 19 11:22:05 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13921A1AB3; Sun, 19 Oct 2014 11:22:03 -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 4hHca__yUS70; Sun, 19 Oct 2014 11:22:02 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F3F1A1AB1; Sun, 19 Oct 2014 11:22:02 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:4265 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xfv7B-0004vJ-6j; Sun, 19 Oct 2014 11:22:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 19 Oct 2014 20:13:03 +0200 To: rhill@hill-a.ch,"Ianaplan@Ietf. Org" 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 - ietf.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/iucg/HgsUIYiDi2qXCYfgOv1CdjWqDzE Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] SSAC Report on the IANA Functions contract X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 18:22:04 -0000 At 10:34 14/10/2014, Richard Hill wrote: >The SSAC has prepared a Report on the IANA Functions Contract >(SAC068). It is at: > > https://www.icann.org/en/system/files/files/sac-068-en.pdf Dear Richard, This document concerns the pre-post-NTIA-removal. I belong to those who do not believe ICANN can have the NTIA's US sovereignty transferred to it. In that category, there seems to be 191 non-US States that do not share the NTIA plan, and actually have, in their wide majority, voted against it or politely abstained in Dubai. What I know is that from now until September 30, 2015, all of them, most of the ISP, Libre developers, network lead users, entrepreneurs, militaries, informed politicians, etc. will consider at one time or another the "MYCANN Plugs-in" options. We all know how to assemble it. However, we do not know where it can politically/commercially lead us and what will be the innovative impact on the vision of the network architecture. For the transition to be seamless, this new NTIA-less context is to be prepared. If ICANN has found a credible self-accountability formula (not only a "community" applauded one), many will stay with ICANN, at least until the MYCANN Plugs-in have been validated. Many others will probably have a gallant, legal, or greedy attempt at having one or several MYCANN Plugs-in. They will most probably help improving their codes, features, and services and stabilize them in the architectural netscape, as has happened for NATs. It is up to this WG to decide how its beloved status quo is going to match this. I have played my whistleblower's part. It is on the records. I will appeal the IESG in due time (after having seen how this debate develops), and then probably the IAB, and thereafter probably ISOC. I have started exploring, experimenting, preparing documents, and gathering developers. Our team will proceed (and advocate to proceed) along the ICANN ICP-3 reasonable constraints. Our first objective is the experimentation, a pragmatic understanding of the nature, structure, advantages, and risks of a MYCANN Plug-in (MPI), and then report on it. As per RFC 6852, lead users, developers, governments, cyber commands, entrepreneurs, politics, edge providers, manufacturers, ISPs, and markets will then decide. Best, jfc From nobody Sun Oct 19 16:36:32 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5274C1A1A2E; Sun, 19 Oct 2014 16:36:30 -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 2220EknE41A3; Sun, 19 Oct 2014 16:36:29 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5184A1A1A21; Sun, 19 Oct 2014 16:36:29 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:57929 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xg01U-0000eT-6O; Sun, 19 Oct 2014 16:36:28 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Oct 2014 01:36:24 +0200 To: Miles Fidelman , "Ianaplan@Ietf. Org" From: JFC Morfin In-Reply-To: <54441B78.2020709@meetinghouse.net> References: <20141019182207.69BF91A1AC9@ietfa.amsl.com> <54441B78.2020709@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/e7DJM3tChZZYCi__xDD7Uk3Ak-k Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] SSAC Report on the IANA Functions contract X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 23:36:30 -0000 At 22:13 19/10/2014, Miles Fidelman wrote: >Either way, though, the notion that voluntary standards bodies are >the authoritative parties vis-a-vis the Internet should carry over >into a post-NTIA world. Dear Miles, I understand and agree with your analysis (and I can innovatively explain it with scientific rigor), BUT that is provided the IETF technology is the only acceptable/possible digital network technology, and the way it is managed is agreed by everyone. We know that this is not the case. Three points extensively documented by experience, analysis, books, documents of reference, etc. show it: - the NTIA oversight is only an avatar of the 1977 initiated variation of the USG regulation of a universal service - that is still subsidized. The NTIA transition is only an adaptation of this regulation 40 years later on, taking into consideration the change of scale in use and locality. - the internet architecture is blocked since 1983. This is the "status-quo" US strategy: IETF has never scaled above the first IEN 48 motivation (a global TCP/IP catenet) and engaged in the second motivation (a TCP/IP Tymnet). It planned it, it did not do it, but the world is engaged in the process. This makes innovation an uncertain parameter. Lower layers may very well stay stable (probably not the way you see it, because there is no real "voluntary" SDO at these layers anymore, but along RFC 6852). The architecture is opening through the economically based technical competition among "global communities". Plural. This means that the "technical market power" (capacity to impose its standards by market influence) of DARPA, NSA, USCC is progressively affected by what can be called an "intelligent use by economic necessity". - the digitalities' networks have three main strata: hardware, software, brainware. Tymnet, IANA, ICANN have demonstrated that the naming space rules the nets - and technology and politics are showing that this is at the three strata. With the gTLDs mad project ICANN has killed its only advantage: clarity.They also have been unable to make the IETF keep the multilingual space (names and tags) efficient and clear. As a result ICANN cannot help stabilizing innovation through names. - Hardwware: IoT, NDN. - Software: iDNs do not really work + MYCANN plugs-in.+ Rossetanet - Brainware: names/languages is the brain's semantics communication's technology. ICANN and IETF are decades away of "brain names" and their semantic upper layer evolution. This is documented in ICANN/ICP-3: how to R&D a non-unique authoritatie root DNS. Now, again, I played my wistleblower part. I will keep wistling through an appeal. But now I work. Cheers. jfc jfc From nobody Mon Oct 20 00:01:17 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9641A6FC4; Mon, 20 Oct 2014 00:01:16 -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 9KUxrVG-84eG; Mon, 20 Oct 2014 00:01:16 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E0B1A6FC3; Mon, 20 Oct 2014 00:01:15 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:13641 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xg6xv-0004PU-0h; Mon, 20 Oct 2014 00:01:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Oct 2014 09:01:11 +0200 To: Seth Johnson , "ianaplan@ietf.org" ,Eliot Lear From: JFC Morfin 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 - ietf.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/iucg/dbsQwM5LuXEfN0QGdOwy2NVE2VE Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] I-D Action: draft-ietf-ianaplan-icg-response-01.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 07:01:17 -0000 At 17:02 17/10/2014, Seth Johnson wrote: >Policy sources other than the RFCs and the system developed between >the IETF and the operator could affect that system. Correct. Also parallel or higher layer technology sources. There must be support for a technological multistakeholderism respecting the cooperation principle that founds the RFC 6852 Modern Paradigm for Standards: "Cooperation. Respectful cooperation between standards organizations, whereby each respects the autonomy, integrity, processes, and intellectual property rules of the others". A minima, the deliverable of this WG should be endorsed by IEEE and W3C. A norma, it should discuss the way its arrangements' incumbents will welcome newcomers. A maxima, it should document how every user can adapt it to his/her own needs without unbalancing the whole global set up. jfc From nobody Mon Oct 20 10:15:07 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C91A6F3F; Mon, 20 Oct 2014 10:15:02 -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 aME-IzSUWvam; Mon, 20 Oct 2014 10:14:59 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556641A86F3; Mon, 20 Oct 2014 10:04:25 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:29262 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XgGNc-0006Xu-0S; Mon, 20 Oct 2014 10:04:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Oct 2014 19:04:19 +0200 To: Miles Fidelman , "Ianaplan@Ietf. Org" From: JFC Morfin In-Reply-To: <54444E65.6080308@meetinghouse.net> References: <20141019182207.69BF91A1AC9@ietfa.amsl.com> <54441B78.2020709@meetinghouse.net> <20141019233630.43BE0CC095@server1.neighborhoods.net> <54444E65.6080308@meetinghouse.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_368812774==.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 - ietf.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/iucg/1a8FAELk62PmI0F7kEWR4nDmj90 Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] SSAC Report on the IANA Functions contract X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:15:02 -0000 --=====================_368812774==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:51 20/10/2014, Miles Fidelman wrote: >JFC Morfin wrote: >>At 22:13 19/10/2014, Miles Fidelman wrote: >>>Either way, though, the notion that voluntary standards bodies are >>>the authoritative parties vis-a-vis the Internet should carry over >>>into a post-NTIA world. >> >>Dear Miles, >> >>I understand and agree with your analysis (and I can innovatively >>explain it with scientific rigor), BUT that is provided the IETF >>technology is the only acceptable/possible digital network >>technology, and the way it is managed is agreed by everyone. > >Appreciate the concurrence, but beg to differ that we're talking >about technology here. The topic is on the table is governance, >specifically governance of protocols and numbering for a specific >infrastructure, the Internet. Dear Miles, We are discussing the overlooked fundamental layer that can help everyone understand the issue. However, we need to be clear about the real matter. As you say, the topic on the table is governance, but governance of the international use of a given uncompleted technology within the circumstances of a given operational strategy. My reading is that the topic is on the table because the technology leaders (RFC 6852) have (IMHO, correctly but incompletely) evaluated that the market forces are competitively completing the technology - what is going to affect the operational strategy - and modify the economical/political/commercial equilibrium. I fully realize that we both see the situation from our respective 40 year old American and International technical and political backgrounds. This is why I think that we can bring this debate to its real level and question: will we have a seamless or a competitive transition from the IEN 48 first to second motivations. >By analogy - IEEE is the accepted standards body and registrar for >all things related to Ethernet - including, not only protocols, but >things like UUIDs. For the Internet, IETF is essentially playing >the same role - with some aspects (names, numbers) being done by >several other bodies. Yes. The question is simple: do IEEE, IAB, IETF, ISOC, and W3C cover today the entire digital technology spectrum? This WG assumes that the answer is yes and accepts a governance status quo on its faith in an architectural status quo (what does not prevent technological innovations). I have full respect for believers, but I am afraid that we are confronted with an over conservative faith vision. There is an architectonical (what concerns architectures) dichotomy between the IETF offering and the markets' (identified as technically competing "global communities" on economic grounds by our leaders) needs. In more practical terms and IETF language: the IETF end to end does not match the fringe to fringe needs, and as a result the digital governance is unstabilized by the edge provision (and this is just the beginning of big data). >>We know that this is not the case. Three points extensively >>documented by experience, analysis, books, documents of reference, >>etc. show it: >> >>- the NTIA oversight is only an avatar of the 1977 initiated >>variation of the USG regulation of a universal service - that is >>still subsidized. The NTIA transition is only an adaptation of this >>regulation 40 years later on, taking into consideration the change >>of scale in use and locality. > >Wow, is that not the case. Internet governance - by NTIA and others >is incredibly far from the regimes imposed on telecom. carriers by >the FCC and state Public Utility Commissions - stemming from a >legislative tradition dating back to the 1910 Mann-Elkins Act (wrote >a book chapter on the evolution of US telecom regulation at one >point). The machinations that the Internet community went through >to avoid any such regulation were pretty intense, back in the day. >Arguably, we (in the US at least) would be better off in terms of >things like "network neutrality" if Internet access networks were >subject to common carrier regulation. This is probably overlooking a few deregulation issues and the global context (as we saw in Dubai). However, on a triple decade basis we agree: what the NTIA is attempting is a "smart return to the past". To bring back the enhanced services under regulation, a quite different and adapted form of regulation, but regulation all the same. I am not against the idea, but if we do not want a technical civil war, we are better to discuss it as such as incumbents (IETF, ICANN, RIRs stakeholders) have to adapt and welcome newcomers (from my point of view those I call the IUsers, with an "I" standing for many characteristics, including "inventive". Does the IETF want a competition or an alliance with the IUsers? This is the question. IUsers are not well understood/accepted as a community yet, except as the "paying one" ("consumers"). IMHO, in an economy driven technology (RFC 6852), the future is on the purses' side. >>- the internet architecture is blocked since 1983. This is the >>"status-quo" US strategy: IETF has never scaled above the first IEN >>48 motivation (a global TCP/IP catenet) and engaged in the second >>motivation (a TCP/IP Tymnet). It planned it, it did not do it, but >>the world is engaged in the process. This makes innovation an >>uncertain parameter. Lower layers may very well stay stable >>(probably not the way you see it, because there is no real >>"voluntary" SDO at these layers anymore, but along RFC 6852). The >>architecture is opening through the economically based technical >>competition among "global communities". Plural. This means that the >>"technical market power" (capacity to impose its standards by >>market influence) of DARPA, NSA, USCC is progressively affected by >>what can be called an "intelligent use by economic necessity". > >Of course one might argue that the Internet is precisely scoped as >an operational TCP/IP catenet - with a highly evolved governance >mechanism. And that is the scope of the governance issues on the >table. And, compared to other telecom regulatory environments >(e.g., the telephone network), far more open to evolution and >innovation - that's something that's working pretty well - no need to break it. Correct. However, while you are correctly using plural for "environments", you are only referring to the telephone lower stratum, and implicitly opposing the ITU and, therefore, the UN. This is where you are breaking the system pile. There is a progress toward the upper layers. Status quo breaks the momentum in freezing the architectonic evolution. The UN takes care of the ground. ITU takes care of the bandwidth. IEEE takes care of the hardware. IETF takes care of the software. I am interested in brainware (a more general and plural word for your "highly evolved governance mechanism") and in its ground, structural, hardware, and software support. The question I am asking over and over again, under different ways, is simple. How long can brainware dynamic be supported only by the existing IETF layers and the ICANN monopoly? When is a new SDO to be created, and how it is to be pragmatically organized to best consolidate the common good work achieved so far? Cheers, jfc --=====================_368812774==.ALT Content-Type: text/html; charset="us-ascii" At 01:51 20/10/2014, Miles Fidelman wrote:
JFC Morfin wrote:
At 22:13 19/10/2014, Miles Fidelman wrote:
Either way, though, the notion that voluntary standards bodies are the authoritative parties vis-a-vis the Internet should carry over into a post-NTIA world.

Dear Miles,

I understand and agree with your analysis (and I can innovatively explain it with scientific rigor), BUT that is provided the IETF technology is the only acceptable/possible digital network technology, and the way it is managed is agreed by everyone.

Appreciate the concurrence, but beg to differ that we're talking about technology here.  The topic is on the table is governance, specifically governance of protocols and numbering for a specific infrastructure, the Internet.


Dear Miles,

We are discussing the overlooked fundamental layer that can help everyone understand the issue.

However, we need to be clear about the real matter. As you say, the topic on the table is governance, but governance of the international use of a given uncompleted technology within the circumstances of a given operational strategy. My reading is that the topic is on the table because the technology leaders (RFC 6852) have (IMHO, correctly but incompletely) evaluated that the market forces are competitively completing the technology - what is going to affect the operational strategy - and modify the economical/political/commercial equilibrium.

I fully realize that we both see the situation from our respective 40 year old American and International technical and political backgrounds. This is why I think that we can bring this debate to its real level and question: will we have a seamless or a competitive transition from the IEN 48 first to second motivations.


By analogy - IEEE is the accepted standards body and registrar for all things related to Ethernet - including, not only protocols, but things like UUIDs.  For the Internet, IETF is essentially playing the same role - with some aspects (names, numbers) being done by several other bodies.

Yes. The question is simple: do IEEE, IAB, IETF, ISOC, and W3C cover today the entire digital technology spectrum? This WG assumes that the answer is yes and accepts a governance status quo on its faith in an architectural status quo (what does not prevent technological innovations).

I have full respect for believers, but I am afraid that we are confronted with an over conservative faith vision. There is an architectonical (what concerns architectures) dichotomy between the IETF offering and the markets’ (identified as technically competing "global communities" on economic grounds by our leaders) needs. In more practical terms and IETF language: the IETF end to end does not match the fringe to fringe needs, and as a result the digital governance is unstabilized by the edge provision (and this is just the beginning of big data).


We know that this is not the case. Three points extensively documented by experience, analysis, books, documents of reference, etc. show it:

- the NTIA oversight is only an avatar of the 1977 initiated variation of the USG regulation of a universal service - that is still subsidized. The NTIA transition is only an adaptation of this regulation 40 years later on, taking into consideration the change of scale in use and locality.

Wow, is that not the case.  Internet governance - by NTIA and others is incredibly far from the regimes imposed on telecom. carriers by the FCC and state Public Utility Commissions - stemming from a legislative tradition dating back to the 1910 Mann-Elkins Act (wrote a book chapter on the evolution of US telecom regulation at one point).  The machinations that the Internet community went through to avoid any such regulation were pretty intense, back in the day. Arguably, we (in the US at least) would be better off in terms of things like "network neutrality" if Internet access networks were subject to common carrier regulation.

This is probably overlooking a few deregulation issues and the global context (as we saw in Dubai). However, on a triple decade basis we agree: what the NTIA is attempting is a "smart return to the past". To bring back the enhanced services under regulation, a quite different and adapted form of regulation, but regulation all the same. I am not against the idea, but if we do not want a technical civil war, we are better to discuss it as such as incumbents (IETF, ICANN, RIRs stakeholders) have to adapt and welcome newcomers (from my point of view those I call the IUsers, with an "I" standing for many characteristics, including "inventive".

Does the IETF want a competition or an alliance with the IUsers? This is the question. IUsers are not well understood/accepted as a community yet, except as the "paying one" (“consumers”). IMHO, in an economy driven technology (RFC 6852), the future is on the purses' side.

- the internet architecture is blocked since 1983. This is the "status-quo" US strategy: IETF has never scaled above the first IEN 48 motivation (a global TCP/IP catenet) and engaged in the second motivation (a TCP/IP Tymnet). It planned it, it did not do it, but the world is engaged in the process. This makes innovation an uncertain parameter. Lower layers may very well stay stable (probably not the way you see it, because there is no real "voluntary" SDO at these layers anymore, but along RFC 6852). The architecture is opening through the economically based technical competition among "global communities". Plural. This means that the "technical market power" (capacity to impose its standards by market influence) of DARPA, NSA, USCC is progressively affected by what can be called an "intelligent use by economic necessity".

Of course one might argue that the Internet is precisely scoped as an operational TCP/IP catenet - with a highly evolved governance mechanism.  And that is the scope of the governance issues on the table.  And, compared to other telecom regulatory environments (e.g., the telephone network), far more open to evolution and innovation - that's something that's working pretty well - no need to break it.

Correct. However, while you are correctly using plural for "environments", you are only referring to the telephone lower stratum, and implicitly opposing the ITU and, therefore, the UN. This is where you are breaking the system pile. There is a progress toward the upper layers. Status quo breaks the momentum in freezing the architectonic evolution.

The UN takes care of the ground. ITU takes care of the bandwidth. IEEE takes care of the hardware. IETF takes care of the software. I am interested in brainware (a more general and plural word for your "highly evolved governance mechanism") and in its ground, structural, hardware, and software support.

The question I am asking over and over again, under different ways, is simple. How long can brainware dynamic be supported only by the existing IETF layers and the ICANN monopoly? When is a new SDO to be created, and how it is to be pragmatically organized to best consolidate the common good work achieved so far?

Cheers,

jfc

--=====================_368812774==.ALT-- From nobody Tue Oct 21 08:18:07 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9700D1A8744; Tue, 21 Oct 2014 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hk7isEFJwety; Tue, 21 Oct 2014 08:17:56 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C301A8742; Tue, 21 Oct 2014 08:17:56 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:52941 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XgbC7-00034E-Gd; Tue, 21 Oct 2014 08:17:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Oct 2014 17:17:50 +0200 To: "Leslie Daigle (TCE)" , John Curran From: Jefsey In-Reply-To: <54466DD7.20803@thinkingcat.com> References: <20141016162506.2081.63917.idtracker@ietfa.amsl.com> <543FF9CF.9020900@cisco.com> <5440C620.9090108@gmail.com> <5440CE3A.5080906@cisco.com> <5440D0DF.1070201@gmail.com> <5440D202.70809@cisco.com> <5440D3FD.4080800@gmail.com> <6.2.5.6.2.20141019164013.0ca79060@resistor.net> <2F63C7E0-8467-4532-853F-136E1AFC97A1@istaff.org> <6.2.5.6.2.20141020051845.0c5fbea8@elandnews.com> <9C3073E9-093E-4721-8743-E38A6CF5B299@istaff.org> <0CB07576-E51D-49A6-84AE-E67A365C625F@istaff.org> <544535D0.8000203@gmail.com> <54454481.1030001@gmail.com> <54455723.6060808@cisco.com> <544663D1.1040101@thinkingcat.com> <0CCFAAD7-FC37-4805-9125-4095C2BEBFDD@istaff.org> <54466DD7.20803@thinkingcat.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 - ietf.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/iucg/01zmEZsLD_54q8fPDDutiBznNsE Cc: Andrei Robachevsky , "iucg@ietf.org" , Eliot Lear , ianaplan@ietf.org Subject: Re: [iucg] [Ianaplan] General purpose number registries & policy engagement X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:17:57 -0000 At 16:29 21/10/2014, Leslie Daigle (TCE) wrote: >I think, for someone who is not as well-versed in the current >understandings and expectations between the RIRs and the IETF as you >are, the difference in the two statements is who determines the fate >of any address space not in identified specialized sub-registries. > >The first statement says that all address space that is not listed >as an IETF sub-registry is general address space for allocation via >the Internet Number Registry System. > >The second says that the IETF will identify what space is up for >allocation via the Internet Number Registry System. It leaves open >the question of whether (portions of) that space might become >special-purpose, handed to the Internet Number Registry System in >the future, or what. The question is to know if IPv6 addresses are common goods (organized by the IETF and managed by ICANN), an ITEF Trust or an ICANN property. In order to push forn an IPvITU International Number Registry Sysem being created in order to adress specific sovereign requirements and the fact that the NTIA has only indicated its intent to transfer DNS responsibilities to ICANN, the second understanding seems advisable since it does not create any de facto monopoly and retrains the capacity for the IETF to allocate IPv6 addressing space portions along new demands. jfc From nobody Wed Oct 22 09:14:18 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84F1ACDC7; Wed, 22 Oct 2014 09:14:14 -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 ja4pW5-AapLJ; Wed, 22 Oct 2014 09:14:13 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD701ACD82; Wed, 22 Oct 2014 09:14:13 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:19682 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XgyY7-0004pv-PF; Wed, 22 Oct 2014 09:14:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Oct 2014 18:14:06 +0200 To: Suzanne Woolf , Brian E Carpenter From: Jefsey In-Reply-To: References: <20141016162506.2081.63917.idtracker@ietfa.amsl.com> <543FF9CF.9020900@cisco.com> <5440C620.9090108@gmail.com> <5440CE3A.5080906@cisco.com> <5440D0DF.1070201@gmail.com> <5440D202.70809@cisco.com> <5440D3FD.4080800@gmail.com> <6.2.5.6.2.20141019164013.0ca79060@resistor.net> <2F63C7E0-8467-4532-853F-136E1AFC97A1@istaff.org> <6.2.5.6.2.20141020051845.0c5fbea8@elandnews.com> <9C3073E9-093E-4721-8743-E38A6CF5B299@istaff.org> <0CB07576-E51D-49A6-84AE-E67A365C625F@istaff.org> <544535D0.8000203@gmail.com> <54454481.1030001@gmail.com> <54455723.6060808@cisco.com> <544663D1.1040101@thinkingcat.com> <0CCFAAD7-FC37-4805-9125-4095C2BEBFDD@istaff.org> <54466DD7.20803@thinkingcat.com> <2C6DBEF9-86A7-45D0-9272-29C91DBA8534@virtualized.org> <5446AC68.2030701@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 - ietf.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/iucg/UHf3qVNf6Kt8odJFtw7vwsa1EME Cc: ianaplan@ietf.org, "Leslie Daigle \(TCE\)" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] General purpose number registries & policy engagement X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 16:14:14 -0000 At 22:24 21/10/2014, Suzanne Woolf wrote: >In fact this is one of the basic principles that keep the rest of >the system coherent. What actually keeps the system "coherent" (I would say "closed") is that the ISPs chose that their routers support TCP/IP + accept the RIR addressing plan. Obviously, this is for marketing and political reasons (these people are nationally incorporated corporations). In addition, any political decision to do otherwise or innovation that would permit them to do more (support other technologies, other addressing plans) might meet license (BCP 78) problems and IANA use political/compatibility issues. This protects "status-quo" of the unachieved architecture Under that circumstance, the IETF Trust ownership is an advisable do-no-better makeshift until BCP78 is replaced by a CC BY SA licence or a chinese wall big work simplifies the way to use the world digital infrastructure in publishing a Free Wolrd Digital Reference Book with Catenet, Internet, Interplus, Brainware layers parts and online acess to updated tables. Things take time. 30 years of strategic status quo ... jfc From nobody Sat Oct 25 07:59:21 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D0E1A6F63; Sun, 19 Oct 2014 13:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIcffX_qujvL; Sun, 19 Oct 2014 13:13:54 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id A36811A01A8; Sun, 19 Oct 2014 13:13:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 0143FCC099; Sun, 19 Oct 2014 16:13:54 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dpQsMn4lcqOH; Sun, 19 Oct 2014 16:13:49 -0400 (EDT) Received: from new-host.home (pool-96-237-159-213.bstnma.fios.verizon.net [96.237.159.213]) by server1.neighborhoods.net (Postfix) with ESMTPSA id F1408CC07D; Sun, 19 Oct 2014 16:13:48 -0400 (EDT) Message-ID: <54441B78.2020709@meetinghouse.net> Date: Sun, 19 Oct 2014 16:13:44 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "Ianaplan@Ietf. Org" References: <20141019182207.69BF91A1AC9@ietfa.amsl.com> In-Reply-To: <20141019182207.69BF91A1AC9@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/ra0oSGShLljJmIrulshlQhtjfdU X-Mailman-Approved-At: Sat, 25 Oct 2014 07:59:21 -0700 Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] SSAC Report on the IANA Functions contract X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 20:13:57 -0000 JFC Morfin wrote: > At 10:34 14/10/2014, Richard Hill wrote: >> The SSAC has prepared a Report on the IANA Functions Contract >> (SAC068). It is at: >> >> https://www.icann.org/en/system/files/files/sac-068-en.pdf > > Dear Richard, > > This document concerns the pre-post-NTIA-removal. I belong to those > who do not believe ICANN can have the NTIA's US sovereignty > transferred to it. In that category, there seems to be 191 non-US > States that do not share the NTIA plan, and actually have, in their > wide majority, voted against it or politely abstained in Dubai. There is another way of looking at this. Voluntary standards bodies have long been recognized and deferred to by governments and inter-governmental bodies in lots of areas. Essentially, IETF et. al. are voluntary standards bodies, with ICANN and various registries operating at the behest of these voluntary standards bodies. At this point, the NTIA-ICANN contract is little more than written recognition of the role of these various standards bodies, and of ICANN as a contractor supporting them - and possibly adding a smidge of accountability and oversight within US Government jurisdiction. Many maintain that the NTIA role is superflous and the status quo will remain in the absence of the NTIA contract. Others, myself included, argue that some level of accountability and oversight will be required - particularly in that ICANN is a contractor, not a voluntary standards body - thus some "backstop" would be useful to reinforce the ability of IETF, et. al., to hold ICANN accountable, and, if necessary, to change contractors for the various registry functions. Either way, though, the notion that voluntary standards bodies are the authoritative parties vis-a-vis the Internet should carry over into a post-NTIA world. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Oct 25 07:59:23 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C871A1A39; Sun, 19 Oct 2014 16:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m4EcDSSuYvL; Sun, 19 Oct 2014 16:51:12 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id A613B1A1A4C; Sun, 19 Oct 2014 16:51:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 280CECC097; Sun, 19 Oct 2014 19:51:12 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id km2BVhI6+J+G; Sun, 19 Oct 2014 19:51:03 -0400 (EDT) Received: from new-host.home (pool-96-237-159-213.bstnma.fios.verizon.net [96.237.159.213]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 26A0FCC081; Sun, 19 Oct 2014 19:51:03 -0400 (EDT) Message-ID: <54444E65.6080308@meetinghouse.net> Date: Sun, 19 Oct 2014 19:51:01 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "Ianaplan@Ietf. Org" References: <20141019182207.69BF91A1AC9@ietfa.amsl.com> <54441B78.2020709@meetinghouse.net> <20141019233630.43BE0CC095@server1.neighborhoods.net> In-Reply-To: <20141019233630.43BE0CC095@server1.neighborhoods.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/nqTZ7ayWo62SQfxO-m-_WRsGsZw X-Mailman-Approved-At: Sat, 25 Oct 2014 07:59:21 -0700 Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] SSAC Report on the IANA Functions contract X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 23:51:14 -0000 JFC Morfin wrote: > At 22:13 19/10/2014, Miles Fidelman wrote: >> Either way, though, the notion that voluntary standards bodies are >> the authoritative parties vis-a-vis the Internet should carry over >> into a post-NTIA world. > > Dear Miles, > > I understand and agree with your analysis (and I can innovatively > explain it with scientific rigor), BUT that is provided the IETF > technology is the only acceptable/possible digital network technology, > and the way it is managed is agreed by everyone. Appreciate the concurrence, but beg to differ that we're talking about technology here. The topic is on the table is governance, specifically governance of protocols and numbering for a specific infrastructure, the Internet. By analogy - IEEE is the accepted standards body and registrar for all things related to Ethernet - including, not only protocols, but things like UUIDs. For the Internet, IETF is essentially playing the same role - with some aspects (names, numbers) being done by several other bodies. > > We know that this is not the case. Three points extensively documented > by experience, analysis, books, documents of reference, etc. show it: > > - the NTIA oversight is only an avatar of the 1977 initiated variation > of the USG regulation of a universal service - that is still > subsidized. The NTIA transition is only an adaptation of this > regulation 40 years later on, taking into consideration the change of > scale in use and locality. Wow, is that not the case. Internet governance - by NTIA and others is incredibly far from the regimes imposed on telecom. carriers by the FCC and state Public Utility Commissions - stemming from a legislative tradition dating back to the 1910 Mann-Elkins Act (wrote a book chapter on the evolution of US telecom regulation at one point). The machinations that the Internet community went through to avoid any such regulation were pretty intense, back in the day. Arguably, we (in the US at least) would be better off in terms of things like "network neutrality" if Internet access networks were subject to common carrier regulation. > > - the internet architecture is blocked since 1983. This is the > "status-quo" US strategy: IETF has never scaled above the first IEN 48 > motivation (a global TCP/IP catenet) and engaged in the second > motivation (a TCP/IP Tymnet). It planned it, it did not do it, but the > world is engaged in the process. This makes innovation an uncertain > parameter. Lower layers may very well stay stable (probably not the > way you see it, because there is no real "voluntary" SDO at these > layers anymore, but along RFC 6852). The architecture is opening > through the economically based technical competition among "global > communities". Plural. This means that the "technical market power" > (capacity to impose its standards by market influence) of DARPA, NSA, > USCC is progressively affected by what can be called an "intelligent > use by economic necessity". Of course one might argue that the Internet is precisely scoped as an operational TCP/IP catenet - with a highly evolved governance mechanism. And that is the scope of the governance issues on the table. And, compared to other telecom regulatory environments (e.g., the telephone network), far more open to evolution and innovation - that's something that's working pretty well - no need to break it. Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Tue Oct 28 08:51:58 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0231A8BBD; Tue, 28 Oct 2014 08:51:47 -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 7LEvglahSd8U; Tue, 28 Oct 2014 08:51:46 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61141A8BAF; Tue, 28 Oct 2014 08:51:46 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:50735 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xj93h-0006Bo-Tf; Tue, 28 Oct 2014 08:51:46 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Oct 2014 16:51:39 +0100 To: John Curran From: Jefsey In-Reply-To: <232BE25A-BB7A-46F0-BFF0-00141D96A95F@istaff.org> References: <544B44BD.7030805@cisco.com> <734aafb2601d4c7f9fa3184daa6dddb1@EX13-MBX-13.ad.syr.edu> <544D3DC3.5000409@cisco.com> <544D4437.7080108@meetinghouse.net> <20141027180404.407AB1A88F0@ietfa.amsl.com> <232BE25A-BB7A-46F0-BFF0-00141D96A95F@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.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/iucg/MxdeZDzrBHJ1uodttb0J4LT-1NU Cc: "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:51:48 -0000 At 00:47 28/10/2014, John Curran wrote: >On Oct 27, 2014, at 4:02 PM, JFC Morfin wrote: > > ... > > Should all this not be discussed at the PSO as per RFC 2691, the > IETF has established to that end (ICANN/IETF protocol parameters issues)? > > John, Thank you to help me making the point: I did not find back this notice. 1) as it was explained to Richad Hill recently, the IETF has its own ways. An RFC is to be obsoleted by an RFC. The notice is only signed by the IETF Chair, as is RFC 6852, which is also signed by the IAB, the ISOC, the W3C and the IEEE Chairs and is IAB Stream. Either RFC 6852 is to be considered, or it is not, nor the resignation you quote, and the PSO is the proper place. My point is certainly that the uncompleted (lack of accountability) RFC 6852 framework applies. 2) This RFC involves the ITU, the W3C and any SDO who could wish to adhere, meet the criteria, and be accepted. This examplifies the ICANN attitude with peers. 3) More importantly, I suggest everyone to carefully note that if the IETF has removed itself from the PSO it is NOT by its own decision, but due to the UNILATERAL decision of ICANN to remove the PSO from its own organization. From this experience why would IETF trust any agreement with ICANN, even agreed and signed with/by other major SDOs (such ITU and W3C)? In French we say "chat échaudé craint l'eau froide" and in latin "errare humanum est, diabolicum perseverare". jfc From nobody Tue Oct 28 12:23:36 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255FB1ACCEC; Tue, 28 Oct 2014 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 RDPLT-ZRPGkU; Tue, 28 Oct 2014 12:23:24 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784EF1A9078; Tue, 28 Oct 2014 12:23:24 -0700 (PDT) Received: from [200.73.76.67] (helo=[10.10.0.157]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjCMV-000BSq-G8; Tue, 28 Oct 2014 19:23:23 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 200.73.76.67 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Tlo5vwyyF+7XlRvbEtnNU Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: John Curran In-Reply-To: <20141028155201.E12071A8BC4@ietfa.amsl.com> Date: Tue, 28 Oct 2014 16:23:19 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <259C8736-D095-4E37-8827-7E460BA8BCCA@istaff.org> References: <544B44BD.7030805@cisco.com> <734aafb2601d4c7f9fa3184daa6dddb1@EX13-MBX-13.ad.syr.edu> <544D3DC3.5000409@cisco.com> <544D4437.7080108@meetinghouse.net> <20141027180404.407AB1A88F0@ietfa.amsl.com> <232BE25A-BB7A-46F0-BFF0-00141D96A95F@istaff.org> <20141028155201.E12071A8BC4@ietfa.amsl.com> To: Jefsey X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/Ps8brNJEcCL-YQYi7eyTtLAfaaU Cc: "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:23:30 -0000 On Oct 28, 2014, at 12:51 PM, Jefsey wrote: > ... > 3) More importantly, I suggest everyone to carefully note that if the = IETF has removed itself from the PSO it is NOT by its own decision, but = due to the UNILATERAL decision of ICANN to remove the PSO from its own = organization. =46rom this experience why would IETF trust any agreement = with ICANN, even agreed and signed with/by other major SDOs (such ITU = and W3C)? = ' The IAB is in general agreement with this recommendation (that = "The Protocol Supporting Organization should be dissolved."), as the IAB = sees no merit in the continuation of the PSO, as currently chartered. ' /John From nobody Tue Oct 28 18:31:02 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AC31A1BDF; Tue, 28 Oct 2014 18:31:00 -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 ed_uNO5yWB34; Tue, 28 Oct 2014 18:30:58 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D70A1A1BDD; Tue, 28 Oct 2014 18:30:58 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:57428 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XjI6D-0003O4-J5; Tue, 28 Oct 2014 18:30:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Oct 2014 02:30:48 +0100 To: John Curran ,Jefsey From: JFC Morfin In-Reply-To: <259C8736-D095-4E37-8827-7E460BA8BCCA@istaff.org> References: <544B44BD.7030805@cisco.com> <734aafb2601d4c7f9fa3184daa6dddb1@EX13-MBX-13.ad.syr.edu> <544D3DC3.5000409@cisco.com> <544D4437.7080108@meetinghouse.net> <20141027180404.407AB1A88F0@ietfa.amsl.com> <232BE25A-BB7A-46F0-BFF0-00141D96A95F@istaff.org> <20141028155201.E12071A8BC4@ietfa.amsl.com> <259C8736-D095-4E37-8827-7E460BA8BCCA@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 - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/-3bkTxkjTJSqVDofknBbjH_B4_c Cc: "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 01:31:00 -0000 At 20:23 28/10/2014, John Curran wrote: >On Oct 28, 2014, at 12:51 PM, Jefsey wrote: > > ... > > 3) More importantly, I suggest everyone to carefully note that if > the IETF has removed itself from the PSO it is NOT by its own > decision, but due to the UNILATERAL decision of ICANN to remove the > PSO from its own organization. From this experience why would IETF > trust any agreement with ICANN, even agreed and signed with/by > other major SDOs (such ITU and W3C)? > > > ' The IAB is in general agreement with this recommendation > (that "The Protocol Supporting Organization should be dissolved."), > as the IAB sees no merit in the continuation of the PSO, as > currently chartered. ' John, Thank you! May I suggest you read a little further than the polite diplomatic language. The author is our co-Chair and she writes (12 years ago - things have not changed? Why would they change once ICANN is sovereign?). "IETF Protocol Parameters "The report references a statement of ICANN's mission which includes the role of coordination of the allocation and assignment of Protocol port and parameter numbers, as distinct from domain names and IP addresses and Autonomous System numbers. "The IAB notes that this role is undertaken for the IETF as part of the process of implementation of "IANA Considerations" in Internet Standards-track protocol specifications (IETF protocols), as specified in the MoU documented in RFC2860, and is distinct from the ICANN role in the management of domain names and unicast IP addresses. This IETF protocol parameter coordination role is an integral component of the IETF's Internet Standards function. For this reason the IAB disputes the assertion in the ICANN mission statement that this particular role forms an integral part of ICANN's mission. "The IAB is deeply concerned that the role of the management of protocol parameter assignments for IETF Internet-Standard protocols is being confounded within the deeper issues concerning the role of ICANN with respect to the operation of the domain name system and with respect to unicast IP address assignment. "This situation is not acceptable to the IAB. The IAB is evaluating the best path forward to maintain the IETF's protocol parameter coordination." The more it changes, the more it is the same? Best jfc From nobody Tue Oct 28 18:34:11 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E372D1A1BE9; Tue, 28 Oct 2014 18:34:07 -0700 (PDT) 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 7ZgOtWZ4FYv7; Tue, 28 Oct 2014 18:34:06 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084781A1B9C; Tue, 28 Oct 2014 18:34:06 -0700 (PDT) Received: from [200.73.76.67] (helo=[10.10.0.157]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjI9F-000H1t-7M; Wed, 29 Oct 2014 01:34:05 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 200.73.76.67 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18W6k6TUYAgBYYO1kxWZvTh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: John Curran In-Reply-To: <20141029010206.2BA47170E7B@mail-11-pao.dyndns.com> Date: Tue, 28 Oct 2014 22:33:57 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <928B3AAC-8D52-4643-9EAC-756862B7F7F0@istaff.org> References: <544B44BD.7030805@cisco.com> <734aafb2601d4c7f9fa3184daa6dddb1@EX13-MBX-13.ad.syr.edu> <544D3DC3.5000409@cisco.com> <544D4437.7080108@meetinghouse.net> <20141027180404.407AB1A88F0@ietfa.amsl.com> <232BE25A-BB7A-46F0-BFF0-00141D96A95F@istaff.org> <20141028155201.E12071A8BC4@ietfa.amsl.com> <259C8736-D095-4E37-8827-7E460BA8BCCA@istaff.org> <20141029010206.2BA47170E7B@mail-11-pao.dyndns.com> To: "JFC Morfin (LERDA)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/qiSuxiRAWEjrFS7bhl0xDx5inkA Cc: Jefsey , "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 01:34:08 -0000 On Oct 28, 2014, at 10:01 PM, JFC Morfin (LERDA) = wrote: >=20 > At 20:23 28/10/2014, John Curran wrote: >> On Oct 28, 2014, at 12:51 PM, Jefsey wrote: >> > ... >> > 3) More importantly, I suggest everyone to carefully note that if = the IETF has removed itself from the PSO it is NOT by its own decision, = but due to the UNILATERAL decision of ICANN to remove the PSO from its = own organization. =46rom this experience why would IETF trust any = agreement with ICANN, even agreed and signed with/by other major SDOs = (such ITU and W3C)? >>=20 >> = >> ' The IAB is in general agreement with this recommendation = (that "The Protocol Supporting Organization should be dissolved."), as = the IAB sees no merit in the continuation of the PSO, as currently = chartered. ' >=20 > John, > Thank you! May I suggest you read a little further than the polite = diplomatic language.=20 Your earlier suggestion (that "all this be discussed at the PSO") was=20 invalid, as the PSO has not existed for the last 10 years or so. Your assertion which followed ("the IETF has removed itself from the PSO=20= it is NOT by its own decision, but due to the UNILATERAL decision of = ICANN=20 to remove the PSO from its own organization") was also incorrect, as is plainly shown by ICANN evolution and reform committee making a proposal=20= for elimination of the PSO, and the IAB indicating concurrence with = same. Finally, your most recent assertion ("The more it changes, the more it = is=20 the same?") based on the IAB response letter is also flawed, since = ICANN's=20 understanding that it performs protocol parameter assignments per the = IETF's=20 authority became quite clear upon receipt of the IAB feedback, and this = is evidenced even now by its own documentation surrounding the IANA = Stewardship=20 transition,=20 e.g. = " * This announcement does not call into question the role of ICANN, = IETF, and the RIRs in the IANA Functions. These bodies continue to hold policy = authority=20 for the protocol parameters, IP addresses, and name spaces, = including=20 responsibility to ensure the faithful registry administration by = ICANN=20 according to those policies." Note - you do not have to have any first-hand experience in these = matters to=20 provide thoughtful analysis, however, it is necessary to research the = actual=20 events prior to commentary if you wish to be taken seriously. Thanks, /John Disclaimer: my views alone. From nobody Tue Oct 28 19:14:22 2014 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9561A040C; Tue, 28 Oct 2014 19:14:13 -0700 (PDT) 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_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 O_ubRuK8xa7U; Tue, 28 Oct 2014 19:14:06 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB2B1A016A; Tue, 28 Oct 2014 19:13:58 -0700 (PDT) Received: from 253.216.130.77.rev.sfr.net ([77.130.216.253]:57913 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XjIlp-0005zt-KB; Tue, 28 Oct 2014 19:13:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Oct 2014 03:13:48 +0100 To: John Curran ,"Jefsey" From: JFC Morfin In-Reply-To: <928B3AAC-8D52-4643-9EAC-756862B7F7F0@istaff.org> References: <544B44BD.7030805@cisco.com> <734aafb2601d4c7f9fa3184daa6dddb1@EX13-MBX-13.ad.syr.edu> <544D3DC3.5000409@cisco.com> <544D4437.7080108@meetinghouse.net> <20141027180404.407AB1A88F0@ietfa.amsl.com> <232BE25A-BB7A-46F0-BFF0-00141D96A95F@istaff.org> <20141028155201.E12071A8BC4@ietfa.amsl.com> <259C8736-D095-4E37-8827-7E460BA8BCCA@istaff.org> <20141029010206.2BA47170E7B@mail-11-pao.dyndns.com> <928B3AAC-8D52-4643-9EAC-756862B7F7F0@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 - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/gghMEn8mqARozUCaTwAYkGo1guU Cc: Jefsey , "ianaplan@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 02:14:13 -0000 At 02:33 29/10/2014, John Curran wrote: >Note - you do not have to have any first-hand experience in these matters to >provide thoughtful analysis, John, I certainly agree with you on the ultimate result. This is not my point. My point is on who is initiating the change, how it proceeds, for whose convenience, and how it is dicussed. >however, it is necessary to research the actual >events The way you introduced the documents, probably looking each time at the next step to show me wrong ... > prior to commentary if you wish to be taken seriously. ... actually shows me right to those who do not consider the past environment as going to be perpetuated. Something you seem to bet. In such a case I would certainly be wrong. The point is that the technical environment is going to change due to the "MYCANN plugs-in". Not so much the one I advocate: the others. My ICANN/ICP-3 conformant MPI project is only a way for the Libre and the various RFC 6852 communities to be able to understand, experiment, possibly enhance, and counter the introduction of various State rogue MPIs. Do you really believe that any serious Gov is going to bet its national cyberspace and entire economy on non-US oversigthen ICANN's fancies? There is the real world, and the I*core's one. This later world was credible as long as it was under NTIA oversight. As a Dan Tapscott/Lynn StAmour "Global Solution Network" subject to FCC rulings; I am sorry, it is not credible anymore to a Governement and to any serious operator. I know this is not something you wish/like to be told, but you know this is true. We will soon see what Putin and Xi Dada think about it. jfc