From nobody Sun Nov 2 04:52: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 D17FC1A878E; Sun, 2 Nov 2014 04:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_40=-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 6j8mFuXID4wc; Sun, 2 Nov 2014 04:52:15 -0800 (PST) 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 3BFD01A8789; Sun, 2 Nov 2014 04:52:15 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:41507 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xkudg-0005Po-DE; Sun, 02 Nov 2014 04:52:12 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Nov 2014 13:52:05 +0100 To: Suzanne Woolf , Marc Blanchet From: JFC Morfin In-Reply-To: <6EF2CB0E-E705-46B9-B0AE-6F9BEB73D94E@gmail.com> References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net> <54047E4A.30503@cisco.com> <6.2.5.6.2.20140901094544.0b305698@resistor.net> <54059587.8070608@cisco.com> <6.2.5.6.2.20141024004255.0b5ef5d8@resistor.net> <4C1255B9-68C3-45D5-A618-2C7553386DF4@gmail.com> <54522E43.5020709@acm.org> <545428AC.3090802@gmail.com> <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org> <54546F63.1060708@cisco.com> <54547321.8010203@cisco.com> <6EF2CB0E-E705-46B9-B0AE-6F9BEB73D94E@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/YbEK0rpimrZElP7_FoNrP-wLzEk Cc: ianaplan@ietf.org, David Conrad , Eliot Lear , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] A draft for your review 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, 02 Nov 2014 12:52:17 -0000 Suzanne, IANAL but I know that contracts are protocols between people/organizations. Asking engineers to discuss contracts seems as sure as asking lawyers to write a technical standard RFC. At 16:51 01/11/2014, Suzanne Woolf wrote: >On the first-- as already pointed out, we've got existing IETF >authority (the MoU) and process (RFC 6761, with all the accompanying >machinery of writing drafts and making the case for a change in the >relevant registry under its rules). We've also got the machinery to >change that process if it's inadequate: normal IETF process for >updating or obsoleting an RFC, a WG whose charter includes such >namespace issues (DNSOP), and an IAB liaison statement sent to ICANN >specifically on this topic, also under IETF process and an existing >liaison relationship (https://datatracker.ietf.org/liaison/1351/). I >can speak as DNSOP co-chair that we're interested in input, because >applying RFC 6761 has already proven problematic and people keep >writing drafts that attempt it. And I can't speak for the IAB, but >response to the liaison statement would probably be welcome too. > >If people feel coordination on a specific "technical use names" >issue is needed, there are mechanisms in place today to do it. If >people feel better coordination process is needed (such as might >follow from a clearer definition of "technical use names"), there >are mechanisms in place today to create them too, and even recent >suggestions (the DNSOP re-charter, the IAB liaison statement) that >people might want to consider invoking them. I am afraid I do not see in which manner having mechanisms to achieve something makes it so that all of this will be achieved. RFC 2860 is clear about this: in case of a standing disagreement, RFC 2860 Section 4.3, Note: "In the event ICANN adopts a policy that prevents it from complying with the provisions of this Section 4 with respect to the assignments described in (a) - (c) above, ICANN will notify the IETF, which may then exercise its ability to cancel this MOU under Section 2 above." This language does not permit ICANN to be accountable concerning the NTIA's demand: "Maintain the security, stability, and resiliency of the Internet DNS". The IETF has the ultimate capacity of decision and, therefore, responsibility (actually ISOC has it through the appeal process). >At 17:52 01/11/2014, Andrew Sullivan wrote: >But that didn't happen, which suggests to me that the division of >labour, again, is working. IMHO, to make the past the guarantee of your future is to ensure that you will be fooled. >At 18:53 01/11/2014, David Conrad wrote: >Given the IETF has delegated administration via RFC 2860, I would >have thought it useful to formally include the delegatee in >discussions related to the resource (either domain names or IP >addresses) being discussed, not just have the decision be solely >dependent on the IESG's opinion. David, is this truly the "status quo" :-)? If I understand you, what ICANN wants is to control things through RFC 2960bis. I have 255 classes that I can use and IETF has a few thousand that it can freely affect. Perhaps it is time to contract that the ICANN/NTIA "IN" Class is the undisputed ICANN one. If there are too many or buggy TLDs in the root of that class, users will know about it and competition will play its role. jfc From nobody Sun Nov 2 14:55:10 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 6BF371A1A4A for ; Sun, 2 Nov 2014 14:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.631 X-Spam-Level: ** X-Spam-Status: No, score=2.631 tagged_above=-999 required=5 tests=[BAYES_60=1.5, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 yk0rIURL8zX2 for ; Sun, 2 Nov 2014 14:55:08 -0800 (PST) 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 C090E1A1A3F for ; Sun, 2 Nov 2014 14:55:08 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:60315 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xl438-0004mt-SN; Sun, 02 Nov 2014 14:55:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Nov 2014 23:54:48 +0100 To: Marc Blanchet ,Patrick =?iso-8859-1?Q?F=C3=A4ltstr=C3=B6m?= From: JFC Morfin In-Reply-To: <59486905-07AD-4B4B-A317-2550157421E1@viagenie.ca> References: <2684cf9cc9f6427c9657ec6db9d288d8@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <8C435D76-BF55-4B7D-AB4F-4D830C48078F@vpnc.org> <8D65923B-A5FC-46C2-8E79-B8E7FF955645@frobbit.se> <59486905-07AD-4B4B-A317-2550157421E1@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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/sIwh0795NaqlaG63nb3CXyxKoys Cc: Variant IDN Project , Sally Costerton , David Olive , "iucg@ietf.org" Subject: Re: [iucg] [vip] [Blog Post] Making Progress on Internationalized Domain Names 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, 02 Nov 2014 22:55:09 -0000 At 20:05 02/11/2014, Marc Blanchet wrote: >agree on many comments. > >Am I right thinking that this blog post was done=20 >=C2=AB fast =C2=BB to be live during the discussions of=20 >PP, in order to tell the ITU =C2=AB this problem is=20 >well underway and you don=E2=80=99t need to be=20 >involved =C2=BB ? I=E2=80=99m saying that because maybe=20 >it is better to not be withdrawn, but instead=20 >just fixed, so that the underlying message is kept? Dear Marc, I understand your point. However, any way you do=20 it, the message has been sent, understood, and=20 already been noticed. ICANN is not a reliable=20 focal point for information about IDNs. Trying to=20 correct it too visibly would only underline and confirm the point. IMHO the new message should be two folded in=20 order to be true, credible and positively accepted: 1. that the IETF Internet IDN technology is sound, reliable and being used. 2. However, the IDNs use and governance call for=20 a multistakeholder tuning and information among=20 the international naming, internet users, ccTLD,=20 ITU, Libre, and ICANN communities, wth the IETF=20 technical assistance and IAB guidance. jfc=20 From nobody Mon Nov 3 06:40:52 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 13BE01A0382; Mon, 3 Nov 2014 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if1OxHduglvr; Mon, 3 Nov 2014 06:40:47 -0800 (PST) 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 8745E1A036D; Mon, 3 Nov 2014 06:40:47 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:43774 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XlIoI-0006Zg-5B; Mon, 03 Nov 2014 06:40:46 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Nov 2014 15:40:39 +0100 To: Andrew Sullivan ,ianaplan@ietf.org From: JFC Morfin In-Reply-To: <20141102131212.GB26870@mx1.yitter.info> References: <54522E43.5020709@acm.org> <545428AC.3090802@gmail.com> <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org> <54546F63.1060708@cisco.com> <54547321.8010203@cisco.com> <6EF2CB0E-E705-46B9-B0AE-6F9BEB73D94E@gmail.com> <20141102125219.1BD2D1A8795@ietfa.amsl.com> <20141102131212.GB26870@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - 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/ZSdGzGHz9YU1kfggbBi2zV6KDbE Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] A draft for your review 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, 03 Nov 2014 14:40:49 -0000 At 14:12 02/11/2014, Andrew Sullivan wrote: >On Sun, Nov 02, 2014 at 01:52:05PM +0100, JFC Morfin wrote: > > > > >At 17:52 01/11/2014, Andrew Sullivan wrote: > > >But that didn't happen, which suggests to me that the division of labour, > > >again, is working. > > > > IMHO, to make the past the guarantee of your future is to ensure that you > > will be fooled. > >I too have read Hume on induction. It's worth noting that, despite >his position, he would retire to the Poker Club and play billiards and >backgammon. Andrew, I suppose you are referring to David Hume? I have never cast a glance on a page of his, yet. But you are right, I should. I am just basing myself on programmer experience. A bug is something which worked and does not anymore because of a small change somewhere, and it is usually difficult to find as it is in essence unexpected. Here, the bug seems to be from RFC 2860 Section 4.3 in the context of the ICANN reading "IANA" where the NTIA spells "DNS", and the double BUG of the USG wanting to Be Unilaterally Global and of the oligarchy's dream of a Business Unregulated Governance. >But anyway, I wasn't looking for a guarantee. I understand that. And this is what I object to. We are not discussing a poker game or a billiards trick shot, but rather the stability of the world's economy and more precisely of the protection of my users. This is why I am looking for a guarantee, or at least the strongest protection I can get. >I think you'll note >that my sentence makes assertions in the present tense ("is working"). >It is possible that the future will be quite different; at that point, >it seems to me, we'd have to respond according to what changed. >Others seem to hope that they can write down, in advance, a procedure >for every possible case. That is, IMO, complete folly. I agree. >What we need >are mechanisms that allow actors to work effectively, which includes >good incentives to work out differences co-operatively. I beg to differ with you; here's the WG's thinking here on two points: 1. status quo of an auto-corrected mechanism is not acceptable if you remove the correction mechanism (US NTIA) 2. this is why we do not want a mechanism, but a principle. We are halfway through from the (Govs) regulation to the (market) competition principle. The last remnant of the Govs monopolies is supposed to go away. Under those conditions there are two possibilities: - competition, i.e. several ICANNs and everyone can choose the one they think the best. - new state regulation, i.e. ITU. The decision is: - either, as per US/MS oligarchy status quo, in the IETF hands (RFC 2860 Section 4.3), the IPR owner being the IETF Trust and ultimate decision maker ISOC with a few weeks to six months of delays that no one can accept. - either in MYCANN Plug-ins developers (States, ISPs, Business, Libre), users (people), sponsors (States). >The only ways I know to provide those incentives are to provide >another authority Yes. - ITU is the most obvious candidate of the Dubai majority. - I favor a Libre's fringe to fringe internet use oriented task force. >or to provide power of independent action. Yes: the MYCANN Plug-ins. >Some argue that the NTIA has been serving the former function; >I think that interpretation is a little fanciful, but I don't have some >transcendental access to the truth _sub specie aeternitatus_. From a 37 years of experience of the international network perspective, I partly agree that this is not as direct as "NTIA makes it all". In fact, I do not see where the USG is quitting the function. I only see a political trick, an actual transfer from an NTIA contract to a Congress delegation to the FCC. I understand that Americans contributors may think NTIA and FCC are the same. Still the USG is in the lead, and the same statUS quo is, therefore, possible, i.e. the way the Chairs read the Charter. I am afraid that this cannot work. Not anymore. After RFC 6852, Dubai, Snowden, the NDN consortium, SDN works, etc. the FCC cannot be the only NTIA's heir. The Multitude with the MYCANN Plug-ins will become peoples (Libre plug-ins), nations (States plug-ins) and other kinds of global communities (cf. RFC 6852: Google, Apple, Microsoft, USCC, etc.?) innovatively competing for better interconnectivity as per the modern paradigm for standardization; and WSIS consensus for a person centered information society. >I think >that the potential of independent action is a more powerful way to >focus the minds of the various actors in the case of ill behaviour, >and a meaningless detail when actors are collaborating as well as they >have been. Correct. However, this is not something to happen in the future. This is something happening right ***now***, right in ***here***. 1. Either, through Eliot's Draft, the IETF behaves boldly, coordinates the collaboration it has established with ICANN and RIRs, and tell the world in front of the NTIA and ITU: "trust me, I am the boss of my technology and I prove it in standardizing a unique, IANA embedded, ICANN fed, multiclass, multitechnology, multilinguistic MYCANN Plug-in, and this is my decision as per RFC 2860 Section 4.3., period" 2. or the focus will be on the effectiveness of independent actions in the MYCANN Plug-ins area and a possible upper layers internet use task force aggregation. If the Chairs continue to read the Charter the way Leslie told me, whatever the Draft will suggest, the world will decide on its own, I only hope that the potential of independent action is a more powerful way to focus the minds of the various actors in this case, that is, if it is ill behavior, or help aggregating a new solution. This will be to the IESG/IAB to decide if this WG does not want or does not succeed in convincing the Libre, State, Business independent would-be actors (MYCANN Plug-ins designers, developers, disseminators) that the IETF is firmly in the lead. >At 22:50 01/11/2014, Andrew Sullivan wrote: > > proposed text. If the IETF (or IESG or IAB) gets too wrapped up in > > itself, we will screw up. > >Certainly true. But it is surely equally true that, if we allow >technical needs that we might have to be driven by other groups' >priorities, we'll have to stop work. Nowadays, technical requirements are driven by global communities' (plural) economics for the good of humanity. This is RFC 6852 - endorsed/signed by many who are on this list. Please note that I do not disagree with that respective RFC's pragmatism, but I appealed it because of its lack of ultimate conflict resolution and accountability mechanism that we are facing here. Unfortunately, I did not have the time to complete the appeal process and submit it to the RFC 6852's convenor (ISOC) before the NTIA started using it and ICANN intelligently used the NTIA's political wake up call to put technologies in competition (however, in contempt to the internet governance's "governees", igniting a technical competition between its own proposition and the Libre and national capacities). Best jfc From nobody Tue Nov 4 03:09:39 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 85C8B1A0075; Tue, 4 Nov 2014 03:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj3E0Ifuxly5; Tue, 4 Nov 2014 03:09:31 -0800 (PST) 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 5888D1A1A15; Tue, 4 Nov 2014 03:09:31 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:56786 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XlbzN-0007nK-TQ; Tue, 04 Nov 2014 03:09:30 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 12:09:21 +0100 To: John Curran ,Eliot Lear From: Jefsey In-Reply-To: References: <8127BEFF-899D-43F0-9DD8-104D181A90F7@istaff.org> <54579370.5000609@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - 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/dc0glvMadssEZRN4HpmaV1qjTlY Cc: ianaplan@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Minor nit draft-ietf-ianaplan-icg-response-02 regarding "the Internet DNS" 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, 04 Nov 2014 11:09:37 -0000 At 16:09 03/11/2014, John Curran wrote: > it is quite likely that the merits of the current (and now > proposed) arrangements are obvious to everyone on this mailing list. Sorry. But this is not the case as far as I am concerned. >There is, however, some probably that the proposal received by NTIA for >the transition of the stewardship of the IANA functions will be read by many >not on the IANAplan list, and the text matters to the extent that any of their >perceptions are important. This is why I am afraid your text will not fly with those you obviously do not care about. If you did your target would be to try to show me how wrong I am. I am afraid contempt never led to consensus. Cheers jfc PS. I suppose that most in the world support the PP14 Indian motion (which does not consider the DNS) as as such should be outside this debate. From nobody Tue Nov 4 04:01:13 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 964A81A1AEE; Tue, 4 Nov 2014 04:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deoP0dPBQ2Ap; Tue, 4 Nov 2014 04:01:07 -0800 (PST) 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 C58B21A1AD6; Tue, 4 Nov 2014 04:01:07 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:58744 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XlcnK-0000Hl-G6; Tue, 04 Nov 2014 04:01:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 13:00:59 +0100 To: Miles Fidelman ,ianaplan@ietf.org From: Jefsey In-Reply-To: <5458052D.2030806@meetinghouse.net> References: <20141103183007.GP27751@mx1.yitter.info> <20141103212831.GF28565@mx1.yitter.info> <5457FBA7.6050908@cisco.com> <20141103222618.GB28757@mx1.yitter.info> <5458052D.2030806@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: 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/-Gz9P89SA5GE2OsP9L2_C03Tulw Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call) 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, 04 Nov 2014 12:01:08 -0000 At 23:43 03/11/2014, Miles Fidelman wrote: >As far as the USG is concerned, ICANN is a contractor - nothing >more, nothing less. No. This is what ICANN wants you to think. 1) ICANN is the planned successor for DNS Key functions 2) this being said it considers that the NTIA has to relinquish the whole IANA contract so it may control the RIRs before Putin builds his WIR. If it does not it will file a complaint with the FCC showing how it embarasses its DNS key function's owner role and create havoc in the address space allocation. jfc From nobody Tue Nov 4 06:34:45 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 04E851A88FC; Tue, 4 Nov 2014 06:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkZmTw60OhKi; Tue, 4 Nov 2014 06:34:40 -0800 (PST) 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 6824B1A8904; Tue, 4 Nov 2014 06:34:40 -0800 (PST) Received: from dhcp-27-213.ripemtg.ripe.net ([193.0.27.213]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XlfBu-0002HH-8v; Tue, 04 Nov 2014 14:34:38 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 193.0.27.213 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/y2ehsa7Y/cFd5ogIhcCfl 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: <20141104110940.861161A1AA7@ietfa.amsl.com> Date: Tue, 4 Nov 2014 14:34:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8127BEFF-899D-43F0-9DD8-104D181A90F7@istaff.org> <54579370.5000609@cisco.com> <20141104110940.861161A1AA7@ietfa.amsl.com> To: Jefsey X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/S7e_HGmxQzALbX6Wjveq_7gBWTk Cc: ianaplan@ietf.org, "iucg@ietf.org" , Eliot Lear Subject: Re: [iucg] [Ianaplan] Minor nit draft-ietf-ianaplan-icg-response-02 regarding "the Internet DNS" 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, 04 Nov 2014 14:34:42 -0000 On Nov 4, 2014, at 11:09 AM, Jefsey wrote: >=20 > At 16:09 03/11/2014, John Curran wrote: >> it is quite likely that the merits of the current (and now proposed) = arrangements are obvious to everyone on this mailing list. >=20 > Sorry. > But this is not the case as far as I am concerned. Then it is good that you have taken a moment to express such on the = list. >> There is, however, some probably that the proposal received by NTIA = for >> the transition of the stewardship of the IANA functions will be read = by many >> not on the IANAplan list, and the text matters to the extent that any = of their >> perceptions are important. >=20 > This is why I am afraid your text will not fly with those you = obviously do not care about. If you did your target would be to try to = show me how wrong I am. jfc - Actually, my goal was only to point out a potential issue with the = present ID (due to a "plain english" reading of words from NTIA, words which have = often=20 been used in a more creative manner to encompass the entire Internet = identifier=20 system); it was not to promote any particular text. When asked, I = provided text=20 solely for elucidation of the issue - feel free to suggest alternative = text if=20 you also consider it an issue. If you don't feel its an issue, then = that's also good to know. Thanks! /John Disclaimer: my views alone. From nobody Tue Nov 4 07:31: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 C60D31A8A15; Tue, 4 Nov 2014 07:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lguoWBycCVp; Tue, 4 Nov 2014 07:31:33 -0800 (PST) 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 26F781A8A10; Tue, 4 Nov 2014 07:31:33 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:1593 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xlg4x-0005OE-NI; Tue, 04 Nov 2014 07:31:32 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 16:31:25 +0100 To: Marc Blanchet , "Leslie Daigle (TCE)" From: Jefsey 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/MOglXctFws5bsqhjn4MlMDuBDiE Cc: "Ianaplan@Ietf. Org" , "iucg@ietf.org" Subject: [iucg] Draft submission interlude 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, 04 Nov 2014 15:31:34 -0000 Dear Chairs, I just discovered a cute IETF trick. One cannot submit drafts during the last-call period if adequately chosen :-) IETF: >The cut-off time for the I-D submission was 00h UTC, 2014-10-28. >The I-D submission tool will be reopened at 00h local time at the >IETF meeting location, 2014-11-10. Chair: >given the proposed timeline agreed during our last interim meeting >and based on that the outstanding issues should have been addressed >in the -02 version, this message starts a working group last call on >draft-ietf-ianaplan-icg-response-02. This working group last call >will end november 11, 23h59 UTC. Given that our meeting is scheduled >on november 10th, it would be useful if people send their comments >prior to the meeting so they can be addressed or discussed before or >during the meeting. Should I add the draft to my appeal ? What is the most constructive solution that will not irritate my co-writers? jfc From nobody Tue Nov 4 07:33:09 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 7C8B71A89A9; Tue, 4 Nov 2014 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNCNYHrFXRXP; Tue, 4 Nov 2014 07:33:07 -0800 (PST) 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 C99101A8A07; Tue, 4 Nov 2014 07:33:07 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:1618 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xlg6U-0005Ti-Kd; Tue, 04 Nov 2014 07:33:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 16:32:59 +0100 To: John Curran From: Jefsey In-Reply-To: References: <8127BEFF-899D-43F0-9DD8-104D181A90F7@istaff.org> <54579370.5000609@cisco.com> <20141104110940.861161A1AA7@ietfa.amsl.com> 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/oE8Gl7o0vXuXfgddRBKDmKp9LRo Cc: ianaplan@ietf.org, "iucg@ietf.org" , Eliot Lear Subject: Re: [iucg] [Ianaplan] Minor nit draft-ietf-ianaplan-icg-response-02 regarding "the Internet DNS" 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, 04 Nov 2014 15:33:08 -0000 At 15:34 04/11/2014, John Curran wrote: >Actually, my goal was only to point out a potential issue with the present ID >(due to a "plain english" reading of words from NTIA, words which have often >been used in a more creative manner to encompass the entire Internet >identifier >system); it was not to promote any particular text. When asked, I >provided text >solely for elucidation of the issue - feel free to suggest >alternative text if >you also consider it an issue. If you don't feel its an issue, then >that's also >good to know. Dear John, I must say I am not so much interested in an alternative text, but in an alternative approach corresponding to the IETF WG/charter rather than to the ICANN one, even if Richard considers correctly enough that "we are ICANN". I must say that 9 years ago I spent two hours face to face with Houlin Zhao on the geographic/sovereign packet switch networks addressing, when Brian was lobbying against it. Time is coming. I disapprove the current USG smart campaign based upon extended reading of plain control intents. This is an issue. As I said, it is now, and here. And decision is at hand. Among us, as the concerned/capable people are here - a few as speakers and most as silent or indirect readers. Not so easy to determine, but my guess is that ICANN has now lost global control because of their creative manner to read "plain english" words. As we put it in French: "qui trop embrasse mal étreint", "Do not bite off more than you can chew". Cheers! jfc From nobody Tue Nov 4 08:57: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 C665A1A914E; Tue, 4 Nov 2014 08:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 EFwOxjjPAMjx; Tue, 4 Nov 2014 08:57:44 -0800 (PST) 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 A24021A0AFE; Tue, 4 Nov 2014 08:57:44 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:3528 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XlhQN-00048e-87; Tue, 04 Nov 2014 08:57:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 17:57:36 +0100 To: Marc Blanchet From: Jefsey In-Reply-To: References: <20141104153134.DC7D51A8A13@ietfa.amsl.com> 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/jfscAddKqvlIwZY8Ga3vp3hjw0A Cc: "Ianaplan@Ietf. Org" , "Leslie Daigle \(TCE\)" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Draft submission interlude 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, 04 Nov 2014 16:57:45 -0000 At 16:49 04/11/2014, Marc Blanchet wrote: >Le 2014-11-04 à 10:31, Jefsey a écrit : > > Dear Chairs, > > I just discovered a cute IETF trick. One cannot submit drafts > during the last-call period if adequately chosen :-) > >these dates are unrelated. Moreover, the chairs proposed the >timeline during the Interim meeting and people agreed on the timeline. Yes. This is why it is a cute trick by the stakeholders who know about IETF details, have paid time to attend Interim meetings, and - as John enlighted it - share the ICANN reading. A majority occlusion smart trick. MOST. >Marc Charter says; "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.". You said you read the "may" as a "will". But the Last-call will be finished before I can post the proposals I_D. So, I have asked the chairs what is the most productive way to patch the difficulty. You give the feeling there is none. This is not really motivating for my team. An incentive for a stand-alone MYCANN plug-in development rather than the cooperation I try to motivate. jfc >. > > > > > IETF: > >> The cut-off time for the I-D submission was 00h UTC, 2014-10-28. > >> The I-D submission tool will be reopened at 00h local time at > the IETF meeting location, 2014-11-10. > > > > Chair: > >> given the proposed timeline agreed during our last interim > meeting and based on that the outstanding issues should have been > addressed in the -02 version, this message starts a working group > last call on draft-ietf-ianaplan-icg-response-02. This working > group last call will end november 11, 23h59 UTC. Given that our > meeting is scheduled on november 10th, it would be useful if people > send their comments prior to the meeting so they can be addressed > or discussed before or during the meeting. > > > > Should I add the draft to my appeal ? > > What is the most constructive solution that will not irritate my > co-writers? > > > > jfc > > _______________________________________________ > > Ianaplan mailing list > > Ianaplan@ietf.org > > https://www.ietf.org/mailman/listinfo/ianaplan From nobody Tue Nov 4 10:20:14 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 BCC661A1B8C; Tue, 4 Nov 2014 10:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 oTF8RfxODI3h; Tue, 4 Nov 2014 10:20:10 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294951A1B74; Tue, 4 Nov 2014 10:20:10 -0800 (PST) Received: from aran.int.lexiconix.com ([::ffff:173.71.212.244]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 04 Nov 2014 13:20:08 -0500 id 0006C0D4.545918D8.000001A8 Message-ID: <545918D7.90402@thinkingcat.com> Date: Tue, 04 Nov 2014 13:20:07 -0500 From: "Leslie Daigle (TCE)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Jefsey , Marc Blanchet References: <20141104153135.21DEC1A8A16@ietfa.amsl.com> In-Reply-To: <20141104153135.21DEC1A8A16@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/jw3whyEF3V75_BHN4TJaEvC1y-c Cc: "Ianaplan@Ietf. Org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Draft submission interlude 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, 04 Nov 2014 18:20:12 -0000 As Marc has noted, the coincidence in dates was just that -- a coincidence. I will observe that the point of the Internet-Draft cutoff before an IETF meeting is to allow participants time to read relevant material and engage in discussion before and at the IETF meeting. The same can be said for a last call: if you have a different proposal, it should have been surfaced sufficiently in advance of the end of the last call to allow WG participants to read it and engage in thoughtful discussion. It's not the pre-meeting I-D blackout that is a problem here; any alternative proposals are late at this point. Certainly, the fact that we were on this timeline and that the existing draft was to be considered this group's key work item is not a surprise -- my note to the WG on October 3 (quoted below, for convenience [1]) made that quite clear. As Andrew has suggested, engaging in discussion here to determine support for whatever proposals you have is the important step, as it goes to the question of establishing working group consensus. That consensus is what matters, not the document you could publish in the 39 hours between the end of the I-D publication moratorium and the end of the WGLC. Leslie. [1] [I wrote to the IANAPLAN WG, on October 3, 2014:] > In order to respect the timeline of the Working Group and deliver an > IETF response by the January 15, 2015 deadline, it is our expectation > the group will choose to adopt draft-lear-iana-icg-response as a > working group document, next week. Discussion during the virtual > interim meeting will focus on reviewing that document, discussing > issues raised to date, and using the high bandwidth opportunity to > propose resolutions to them. > > As always, any proposed decisions made during the meeting will be > reconfirmed on the mailing list. > > Nonetheless, with a view to the timeline, we recognize that we need > to get the working group document pretty much in shape and taken care > of _before_ the Honolulu meeting, so that remaining issues can be > worked on at IETF 91 and finalized shortly thereafter. On 11/4/14 10:31 AM, Jefsey wrote: > Dear Chairs, I just discovered a cute IETF trick. One cannot submit > drafts during the last-call period if adequately chosen :-) > > IETF: >> The cut-off time for the I-D submission was 00h UTC, 2014-10-28. >> The I-D submission tool will be reopened at 00h local time at the >> IETF meeting location, 2014-11-10. > > Chair: >> given the proposed timeline agreed during our last interim meeting >> and based on that the outstanding issues should have been addressed >> in the -02 version, this message starts a working group last call >> on draft-ietf-ianaplan-icg-response-02. This working group last >> call will end november 11, 23h59 UTC. Given that our meeting is >> scheduled on november 10th, it would be useful if people send their >> comments prior to the meeting so they can be addressed or discussed >> before or during the meeting. > > Should I add the draft to my appeal ? What is the most constructive > solution that will not irritate my co-writers? > > jfc _______________________________________________ Ianaplan mailing > list Ianaplan@ietf.org > https://www.ietf.org/mailman/listinfo/ianaplan -- ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- From nobody Tue Nov 4 10:42: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 C21F61A6F8C; Tue, 4 Nov 2014 10:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-vW0_nqMaPq; Tue, 4 Nov 2014 10:42:16 -0800 (PST) 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 5D8161A6F7F; Tue, 4 Nov 2014 10:42:00 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:7634 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xlj3G-0003qo-Ub; Tue, 04 Nov 2014 10:41:59 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 19:41:52 +0100 To: Andrew Sullivan ,ianaplan@ietf.org From: Jefsey In-Reply-To: <20141104172108.GH29487@mx1.yitter.info> References: <20141104153134.DC7D51A8A13@ietfa.amsl.com> <20141104165749.903E21A9153@ietfa.amsl.com> <20141104172108.GH29487@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - 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/DSFmePtbF2h1zUKlW4FGcMX0PQA Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Draft submission interlude 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, 04 Nov 2014 18:42:17 -0000 At 18:21 04/11/2014, Andrew Sullivan wrote: >On Tue, Nov 04, 2014 at 05:57:36PM +0100, Jefsey wrote: > > This is why it is a cute trick by the stakeholders who know about IETF > > details > >I think you're making an unwarranted _ad hominem_ attack. No. It is the sophomore's dicovery of a astute trick that experienced chairs and draft writers most probably know quite well. >This is not >some conspiracy. The important dates around IETF meetings are >well-publicised well in advance. Frankly, Andrew, I am not that much interested in IETF meetings and never realized that the IETF contributions were frozen for two weeks everytime of few people where paid a travel to drink a few beers together. >It could well be true that there are participants in this discussion >that are unfamiliar with those details of IETF processes. I find it >virtually impossible to believe that M. Morfin, who has exercised >several parts of the IETF procedures repeatedly, is so uninformed. My experience with the IETF is much more with appeals than with Drafts. Drafts are subject to BCP 78 copyright and I am a Libre person believing in Creative Commons. I am however surprised that people who are familiar as you are and others here, never warned me while I repatedly said I will introduce a draft and an appeal once the debate would have produced enough inputs for my contribution to be the most constructive withn the allowed time bracket (before Nov 8 for appealing the charter, Nov 20 for appealing the Chair's reading of the Charter). You will note that the Draft under last-call was introduced the last possible day. So everyone was aware of the date constraint when it was decided (what seems normal as most will travel to the IETF meeting). > > But the Last-call will be finished before I can post the proposals I_D. So, > > I have asked the chairs what is the most productive way to patch the > > difficulty. > >Why don't you outline _briefly_ your views in a mail to the list, note >that you missed the posting deadline, put your draft up somewhere >else, and post your draft as soon as posting is permitted again next >Monday? This is what I am unfortunately going to do if there is no other alternative. However, since my Draft substantially differs from the only one discussed by the WG, was annouced well in advance, and parallels with an appeal, many will take it as a vexation, Something I did not intend. So, the best is to take it with a smile as I do in order to calm people down, those who accepted to share in a positive draft and who are upset tonight. > The usual way to respond to a last call is not an alternative >draft, but if you think the existing draft is really that bad the >usual way is in fact to respond to the last call by saying, "This is >so bad that I will offer a completely alternative proposal." This is something I politely and exactly announced a long ago. My concern is that my position is a compromise that was difficult to obtain and which also depends on Busan parallel talks and votes. Do you know what happens on Nov 10th when I am supposed to be able to introduced the Dratf? >If that's _not_ what you're saying, then you can provide detailed >comments to the list, and not an alternative draft. I did that, too. But who cares? The list is so deeply attached to what I/we consider as an inadequate reading of the Charte and of the real world situation that I need to appeal it to have no regret. I just tried to cooperatively contribute to a more realistic understanding of my own world's position and orientation. After all this may help on the long range to better understand that we cannot mutually easily understand between global communities. No offence taken, but somewhat tired :-) ... jfc From nobody Tue Nov 4 10:57:00 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 C310E1A6F5D; Tue, 4 Nov 2014 10:56:54 -0800 (PST) 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 uf36ibtKHdhp; Tue, 4 Nov 2014 10:56:51 -0800 (PST) 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 03BAC1ACDAF; Tue, 4 Nov 2014 10:56:51 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:7937 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XljHe-0004v9-8E; Tue, 04 Nov 2014 10:56:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Nov 2014 19:56:43 +0100 To: "Leslie Daigle (TCE)" , Marc Blanchet From: Jefsey In-Reply-To: <545918D7.90402@thinkingcat.com> References: <20141104153135.21DEC1A8A16@ietfa.amsl.com> <545918D7.90402@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/dEGv7bDzW5U909U_5EyKIDvuaYo Cc: "Ianaplan@Ietf. Org" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Draft submission interlude 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, 04 Nov 2014 18:56:54 -0000 At 19:20 04/11/2014, Leslie Daigle (TCE) wrote: >I will observe that the point of the Internet-Draft cutoff before an >IETF meeting is to allow participants time to read relevant material and >engage in discussion before and at the IETF meeting. The same can be >said for a last call: if you have a different proposal, it should >have been surfaced sufficiently in advance of the end of the last >call to allow WG participants to read it and engage in thoughtful >discussion. It's not the pre-meeting I-D blackout that is a problem >here; any alternative proposals are late at this point. Leslie, I commented to Andrew. Let say this is an unfortunate misunderstanding about IETF proceedings and petty constraints we did not think of and were not reminded. It only underlines that the present ICANN/IETF/ISOC technical governance system in addition to our Libre organizations governance, in addition to the ITU organization, in addition to the national/european and civil society governance, in addition to the defense of our users interests, is inadequate to address multilateral issues in a proper manner. Too many things/changes/positions in too short a time. This experience only confirms most of my friends' position that what counts is not anyone position, any group consensus, but working and accepted code. I tried to show them that participating to a common preparation effort could also politically help. Turns out I have failed .... >Certainly, the fact that we were on this timeline and that the >existing draft was to be considered this group's key work item is >not a surprise -- my note to the WG on October 3 (quoted below, for >convenience [1]) made that quite clear. Sure. Considering this draft as this group's key work is a main point in my appeal. However, appealing is just to obtain the IESG to tell you to consider otherwise as you smartly accepted to consider it. I fully understand that a "fait accompli" strategy is a good way to oppose us. It only results in several races against the clock. A two weeks unexpected delay is a surprise for us, that many others had taken into consideration. Thats all. Best jfc >As Andrew has suggested, engaging in discussion here to determine >support for whatever proposals you have is the important step, as it >goes to the question of establishing working group consensus. That >consensus is what matters, not the document you could publish in the >39 hours between the end of the I-D publication moratorium and the >end of the WGLC. > >Leslie. > > >[1] >[I wrote to the IANAPLAN WG, on October 3, 2014:] >>In order to respect the timeline of the Working Group and deliver an >>IETF response by the January 15, 2015 deadline, it is our expectation >>the group will choose to adopt draft-lear-iana-icg-response as a >>working group document, next week. Discussion during the virtual >>interim meeting will focus on reviewing that document, discussing >>issues raised to date, and using the high bandwidth opportunity to >>propose resolutions to them. >> >>As always, any proposed decisions made during the meeting will be >>reconfirmed on the mailing list. >> >>Nonetheless, with a view to the timeline, we recognize that we need >>to get the working group document pretty much in shape and taken care >>of _before_ the Honolulu meeting, so that remaining issues can be >>worked on at IETF 91 and finalized shortly thereafter. > > > >On 11/4/14 10:31 AM, Jefsey wrote: >>Dear Chairs, I just discovered a cute IETF trick. One cannot submit >>drafts during the last-call period if adequately chosen :-) >> >>IETF: >>>The cut-off time for the I-D submission was 00h UTC, 2014-10-28. >>>The I-D submission tool will be reopened at 00h local time at the >>>IETF meeting location, 2014-11-10. >> >>Chair: >>>given the proposed timeline agreed during our last interim meeting >>>and based on that the outstanding issues should have been addressed >>>in the -02 version, this message starts a working group last call >>>on draft-ietf-ianaplan-icg-response-02. This working group last >>>call will end november 11, 23h59 UTC. Given that our meeting is >>>scheduled on november 10th, it would be useful if people send their >>>comments prior to the meeting so they can be addressed or discussed >>>before or during the meeting. >> >>Should I add the draft to my appeal ? What is the most constructive >>solution that will not irritate my co-writers? >> >>jfc _______________________________________________ Ianaplan mailing >>list Ianaplan@ietf.org >>https://www.ietf.org/mailman/listinfo/ianaplan > >-- > >------------------------------------------------------------------- >Leslie Daigle >Principal, ThinkingCat Enterprises >ldaigle@thinkingcat.com >------------------------------------------------------------------- From nobody Wed Nov 5 07:19: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 3AD141A88FC; Wed, 5 Nov 2014 07:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EL16UooujPO; Wed, 5 Nov 2014 07:19:30 -0800 (PST) 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 5ECB11A8769; Wed, 5 Nov 2014 07:19:30 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:38485 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xm2Mr-0001zM-7s; Wed, 05 Nov 2014 07:19:29 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Nov 2014 16:19:22 +0100 To: ianaplan@ietf.org From: Jefsey In-Reply-To: <545A208A.7040304@meetinghouse.net> References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@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: 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/v9fhTU_OuGAwBIz4ympgBNs7AJc Cc: gene@iuwg.net, "iucg@ietf.org" Subject: [iucg] A Libre IUser community Draft 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, 05 Nov 2014 15:19:31 -0000 In order to permit a normal work of this WG that has committed to consider proposals from other communities, and due to the I_D sumission cut-off period, we have formally created a small Libre IUWG at http://iuwg.net and published the draft we had prepared as a contribution of an RFC 6852 global community/NTIA stakeholder. This unexpected WG will formalize in the coming days. No to slow down the compromise process we have only updated a few words in our draft to address the issue in the perspective a separate WG shares with the IETF IRT our own names, numbers and parameters referent registries for our users. You will find the draft at the http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.00.pdf I understand that you will want to consider during the Nov 10 meeting if you amalgamate our positions within a WG/IANAPLAN revised draft or if we will have to advance our positions separately. Best jfc From nobody Wed Nov 5 08:07:20 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 611D41A8981 for ; Wed, 5 Nov 2014 08:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB6v3eHI0aug for ; Wed, 5 Nov 2014 08:07:08 -0800 (PST) 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 C4BB41A8969 for ; Wed, 5 Nov 2014 08:07:06 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:39665 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xm36u-00060v-ME; Wed, 05 Nov 2014 08:07:05 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Nov 2014 17:06:56 +0100 To: governance@lists.igcaucus.org,BestBits , discuss@1net.org,"ianatransition@icann.org" From: Jefsey 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/oKbddAQzyGoY8q9SQ6AzyFBx6HY Cc: gene@iuwg.net, "iucg@ietf.org" Subject: [iucg] [Ianaplan] A Libre IUser community Draft 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, 05 Nov 2014 16:07:12 -0000 Dear all, In order to permit a normal work of the IETF/WG/IANAPLAN that has committed to consider proposals from other communities, and due to the I_D sumission cut-off period we had not anticipated, we have formally created a small Libre IUWG at http://iuwg.net to publish and complete the draft we had prepared as a contribution from an RFC 6852 small global community/NTIA stakeholder. This unplaned WG will formalize in the coming days/weeks. To please Jay Daley: we are Libre members of the Montpellier area where we hold the RMLL in july, members of few friendly specialized lists of mine, a Libre development lab in the cyberagora field, the founders of a small communities/villages oriented Libre non-profit Digital Services Provider under incroporation, etc.. So, it is likely that our IP addresses will sometimes be in the same geographical area, and probably from our own AS (planned for Jannuary 2015). :-) No to slow down the clear compromise process we propose we have only updated a few words in our draft 0.0, (prepared for an IETF/WG) in order to address the issue in the perspective that a separate WG or SDO shares with the IETF, IRT our own names, numbers and parameters referent registries for our users. You will find the draft at the http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.00.pdf We understand that the WG/IANAPLAN will consider in a meeting on Nov 10 if they want to amalgamate (some of) our positions within a WG/IANAPLAN revised draft or if we will have to advance our positions separately. We will therefore not discuss them outsie of the WG/IANAPLAN until their decision, but we can provide additional inputs. Please note that our focus is not on the political aspects of the US Governance of the Internet (NTIA vs FCC) but on our best interests in the global ITU, IG, Russia/China, Libre/Oligarchic, regalian/business/civil, etc multi-macro/micro-stakeholder context, and mostly on the various MYCANN plug-ins developments being considered or under way. Best jfc From nobody Wed Nov 5 11:07: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 D950E1A1B5C; Wed, 5 Nov 2014 11:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le9IBjVIXtMi; Wed, 5 Nov 2014 11:06:56 -0800 (PST) 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 E64771A1A30; Wed, 5 Nov 2014 11:06:56 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:43898 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xm5ux-0004r7-9a; Wed, 05 Nov 2014 11:06:55 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Nov 2014 20:06:47 +0100 To: Andrew Sullivan ,ianaplan@ietf.org From: JFC Morfin In-Reply-To: <20141105180238.GX30379@mx1.yitter.info> References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <9FDE1247-717D-487F-BC0E-E30FEA33536F@gmail.com> <545A5859.1060505@meetinghouse.net> <545A6358.1000304@meetinghouse.net> <20141105180238.GX30379@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - 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/-M96F6rkAeKTF_zyzUtge31OWI4 Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call) 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, 05 Nov 2014 19:06:58 -0000 At 19:02 05/11/2014, Andrew Sullivan wrote: >I'm sorry, but for the purposes of stating what "the IETF wants", the >IETF is not more than the consensus-calling process that we use for >everything else. There is exactly one way for the IETF to say what >"it" wants, and that is to do a consensus call. Dear Andrew, I have no problem with you not understanding what your different colleagues may say, and in expessing your our thinking as a reference other may oppose, etc. This is a philosophical form of more emotive debate (beliefs vs beliefs). I must confess I prefer a scientific form of debate, where critics are meant to add to a common progress. However, both approaches are blocked when the accepted consensus is opposed like you do here. I think it is worth to underline it when it clearly occurs such in your position above, when compared with the RFC 3935 (IETF mission statement) section 3 which is the base of most's reasoning in terms of decision preparation by this WG "3. The Need for a 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. There are many reasons for this, including the near-impossibility of getting an informed consensus opinion on a complex subject out of a community of several thousand people in a short time. 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.)" Which position should we accept as accept as a reference for this WG's work? jfc From nobody Wed Nov 5 18:18:00 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 090541A015B; Wed, 5 Nov 2014 18:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=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 Ahdceit6a8n3; Wed, 5 Nov 2014 18:17:54 -0800 (PST) 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 1E35D1A0147; Wed, 5 Nov 2014 18:17:54 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:52160 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XmCe0-0005Wx-9m; Wed, 05 Nov 2014 18:17:53 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Nov 2014 03:17:59 +0100 To: "Leslie Daigle (TCE)" , Miles Fidelman From: JFC Morfin In-Reply-To: <545A8BF2.3000701@thinkingcat.com> References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <9FDE1247-717D-487F-BC0E-E30FEA33536F@gmail.com> <545A5859.1060505@meetinghouse.net> <545A8BF2.3000701@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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/UMuj0TERsRHH1aV6ELEIZm4S8zY Cc: ianaplan@ietf.org, gene@iuwg.net, "discuss@0net.org List" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Where this WG fits Re: control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call) 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, 06 Nov 2014 02:17:57 -0000 Dear Leslie, why not to accept that at this stage no one can=20 say what is the scope of the WG, what will happen=20 at the end of the day, who should be a=20 participant, what are understood or accepted by=20 them ... because there is no consensus, too many "beliefs" rather than= facts. And if there was a consensus, it should be=20 negociated. Then (next week) a probable counter=20 proposition by Russia+China supported by BRICS.=20 etc. makes us sure that the status-quo will have=20 to be updated. How many Russian, Chinese citizens in this WG? Why not just to consider our Charter and mission=20 statement for what they say and not for what=20 ICANN or anyone else may say. In any coming=20 ***unknown*** political, multilateral,=20 multistakeholder, and middleware situation, the=20 internet will still have to work and possibly to=20 work better. That is the IETF job. We should only=20 be interested by that, and incidently to make=20 sure ISOC, ICANN, RIRs, ITU, IANA, IUsers, etc.=20 etc. have obtained from us the technical capacity=20 to help us and our users so they design, use and=20 manage the Internet in order that it works better.. My Draft just says that, in the way the charter,=20 the NTIA, ICANN say it (look at the text, the=20 largest part comes from them). My helpers were=20 worried by the cut-off issue. Actually it helps:=20 our Draft is a non-IETF one, so it is not bound=20 by BCP_78. Nor by any other consensus that our's.=20 It is CC BY SA, and if you look at our young site=20 we had to set-up to publish the Draft, we can=20 start considering there, the real issues of the real world. As IUsers, we are no lawyers, no politicians, no=20 gurus, just Libre developpers and/or=20 involved/independent Internet users. And we=20 expect only one thing from the IETF: the=20 technical capacity to continue to run the digital=20 part of our business and life the way we are used=20 and want to do it. i.e. in not being racketed=20 anymore by the "ICANN industry", not to be=20 subject to an "US jurisdiction", not to be=20 "protected by the NSA", not to be worried about=20 the Chinese back-doors, not to be involved in the=20 Russian strategy and hackers, not to be harassed=20 by civil society activists, not to have to be=20 concerned by Indian and Brazilian, and etc. and etc. new propositions. Just to live in digital peace with an "IG proof"=20 technology allowing us to be digitally autonomous !. Either you tell the IETF to focus on that, or we=20 will understand you want us to do it by our own.=20 No worry, but don't tell us afterward you dont=20 like it as you kept telling about NATs. jfc At 21:43 05/11/2014, Leslie Daigle (TCE) wrote: >Miles, > >The IAOC needs to know what the IETF wants in=20 >order to build the administrative structures to=20 >provide it. In other contexts, the IAOC has=20 >been pretty tightly circumscribed to not "invent" things for the IETF. > >In that light, I believe the purpose of this=20 >working group is to develop consensus around the=20 >needs of the community to support the IETF's=20 >work and protocols, going forward. As a=20 >developer (of standards, or software using=20 >standards), or deployer of networks, or other=20 >producer/consumer of technical protocol=20 >parameters, what are the requirements of the system post-NTIA transition? > >That may not be protocol engineering, but it is=20 >a fairly technical task. It is not defining the=20 >form of the final implementation to meet those=20 >requirements (lawyering, contracting, etc). As=20 >a technical task, I believe it is possible for a=20 >working group format to achieve the outcome. > >To your specific points: > > a. this working group has to overtly address issues, and recruit > > experience, that are not normally within IETF WG purview, or, > >Per the above, I don't believe that is=20 >necessary. Notably, in this group's charter: > >[From http://datatracker.ietf.org/wg/ianaplan/charter/ ] >"Fully documenting the interaction between the IETF and the operator >of IETF protocol parameters registries may require detailed terms of >agreements or other details of procedures that are normally delegated >to and handled by the IAB or IAOC." > > > > > b. we need to have some OTHER, clearly defined, open, consensus process > > for addressing this set of issues; that includes strong representation > > from those with governance, regulatory, legal, and contractual matters > > in the Internet context (starting with the IAB, IAOC, IETF trust, and= ISOC) > >That question is outside the scope of this=20 >WG. If you feel it is necessary, I would=20 >suggest that you could take it up (in person, or=20 >remotely) at the Admin Plenary at IETF91, next week. > >Leslie. > >On 11/5/14 12:03 PM, Miles Fidelman wrote: >>Suzanne, >> >>Thank you for the thoughtful comments, but.. I would take issue with you >>on a couple of items - see below... >> >>Suzanne Woolf wrote: >>>Colleagues, >>> >>>I want to thank Miles and Andrew for this exchange; it suggests a >>>potentially useful insight on where we might be talking past each other. >>> >>>Much of this conversation, and a number of other apparent >>>disagreements inside the WG, seem to me to come from a disconnect >>>between a) people who have experience of the IETF and its structures >>>because they do work in the environment the IETF creates and b) people >>>who don't, whose knowledge of the processes and activities described >>>in draft-ietf-ianaplan are less immediate. >> >>I don't believe this is an accurate representation of the situation. >> >>I think it's more that at least several of us are questioning how well >>standard IETF structures and procedures apply to the task at hand - >>i.e., crafting a consensus proposal that responds to the the ICG, and to >>the NTIA - and doing so through an open, transparent, consensus process. >>(As I believe NTIA and the ICG are asking for.) >> >>> >>>To many IETF participants with experience in getting work done within >>>the organizational structures we're talking about, there are some >>>fairly clear assumptions that can easily be made about the role of the >>>WG and of the IETF and related groups. One is that the WG's job, per >>>the charter, is not to tell the IAB and the IAOC exactly what to say, >>>to the ICG or ICANN or anyone else; it's to establish consensus on the >>>desired outcomes and basic tradeoffs, so the consensus can be >>>implemented by contracts, other means of establishing shared >>>understanding such as liaisons and MoUs, business processes of the >>>IANA, procedural documents that may be RFCs, etc. Another is that the >>>IAB and the IAOC can reasonably be trusted to do this because it's >>>what they're asked and chosen by the community to do, by a nomcom >>>chosen from the community and under criteria the community has every >>>opportunity to influence. It's also generally assumed-- because we've >>>seen it over the years-- that the IAB and the IAOC have every >>>reasonable help in doing their jobs from lawyers and other >>>professionals. Some of the confidence is from feeling we know the >>>people and the processes that gave them their current >>>responsibilities; some is because there are appeal and recall >>>processes also defined in case we got it really wrong. >> >> >>It strikes me that, as others have also pointed out, that governance, >>legalities, and contracts are NOT typically working group matters. Which >>is a different matter entirely from whether they are central issues that >>must be addressed in a response to the ICG. >> >>Rather, these matters are delegated to "organs" of the IETF that don't >>seem to generally operate through the same consensus process as IETF's >>primary standards making activities. >> >>Which leaves a very big gap between the task at hand, the issues to be >>addressed, and a consensus process for arriving at a proposal to the >>ICG, and follow-on discussions and negotiations on behalf of the IETF as >>"our" proposal is merged with those of the other stakeholder communities. >> >>Leaving such matters to the IAB and IOAC, after the WG develops a draft, >>does not seem an adequate approach, in that: >>- as Richard points out - lawyers tend to do a better job with clear >>direction (personally, I'd make the same observation about contracting >>officers) >>- GIGO: the working group is talking engineering, while this is >>primarily a legal & contractual matter - a draft written by engineers is >>not necessarily a good basis for a response that should (IMHO) be framed >>in contractual language >>- "trusting the IAB and the IOAC" is neither open, transparent, nor by >>consensus (irregardless of whether we, in fact, trust them) >> >> >>As I see it, either: >> >>a. this working group has to overtly address issues, and recruit >>experience, that are not normally within IETF WG purview, or, >> >>b. we need to have some OTHER, clearly defined, open, consensus process >>for addressing this set of issues; that includes strong representation >>from those with governance, regulatory, legal, and contractual matters >>in the Internet context (starting with the IAB, IAOC, IETF trust, and= ISOC) >> >> >>Otherwise, IMHO, IETF is not carrying the water in responding to the >>RFP; and more substantively, risks undesirable outcomes in a post-NTIA >>world. >> >>Respectfully, >> >>Miles Fidelman >> >> >> >> >>> >>>And some of the confidence comes from understanding that a failure of >>>this process, or the IETF/ICANN relationship, would be a massive, >>>painful inconvenience, best avoided in any way reasonably possible-- >>>but not an existential threat to the ability of the IETF to do its work. >>> >>>It seems to me that many of the participants here (Andrew, Eliot, >>>Leslie, Brian, etc.) have shared these underlying assumptions, so that >>>even when they've disagreed on the specific outcomes we're looking >>>for, they've agreed on the level of detail and the tradeoffs ("need to >>>have" vs. "nice to have") that should be specified in this document >>>and within this WG's charter. >>> >>>It also seems that other participants have wanted to have an entirely >>>different conversation, on first principles such as the need for >>>lawyers to negotiate contracts. >>> >>>On Nov 4, 2014, at 8:22 PM, Miles Fidelman >>> wrote: >>> >>>>Andrew Sullivan wrote: >>>>>On Tue, Nov 04, 2014 at 04:51:12PM -0500, Miles Fidelman wrote: >>>>> >>>>>>When it comes to legal, contractual, and governance matters - the >>>>>>IETF is >>>>>>more than it's working groups, it includes the IAB, IESG, IAOC, etc >>>>>>(as >>>>>>components of the IETF); the ISOC (as "parent" or whatever of the >>>>>>ISOC); and >>>>>>arguably the "protocol parameters community" is more than just the >>>>>>IETF. >>>>>>These perspectives are reflected, at best, informally, in the >>>>>>charter and >>>>>>discussions of the WG. >>>>>It seems to me that the IETF has managed to set up all those >>>>>organizations except for ISOC. So what about the IETF makes you think >>>>>that it is incapable of drawing conclusions about organizations and >>>>>institutional arrangements? >>>> >>>>I'm not. I'm observing several things: >>>>- the outside world (or the plain observer) does not see the >>>>granularity - and things like "the IETF will ask the IAOC to conclude >>>>supplemental agreement" are just incredibly murkey reading >>>>- the WG charter has excluded a bunch of topics that one would expect >>>>to see in a complete response to the ICG RFP - particularly legal and >>>>contractual stuff >>>>- the WG charter seems to focus on a subset of the issues requested >>>>by the RFP >>>>- other components of the IETF - like the IAOC, the IAB are not >>>>really involved in the discussion (e.g., nobody seems to want to have >>>>any lawyers involved in the discussion) - and I have yet to see any >>>>discussion of how those components/perspectives are going to be >>>>incorporated into the formal response to the ICG >>> >>>As above, and I think Andrew said but perhaps not quite explicitly >>>enough: the IAB and the IAOC are trusted to get the implementation >>>details covered in a reasonable, workable way because it's the job >>>they were appointed to, after consideration of their qualifications >>>for it; because of past experience, including some difficult moments >>>in other relationships of the IETF with IANA and RFC Editor operators; >>>and because the community can kick them out if we really don't like >>>what they're doing. >>> >>>What's become clear in this exchange and others is that those >>>assumptions are not making it into the document, and remain opaque for >>>those not experienced with the processes and structures. >>> >>>For example, I'm not worried about whether the IAOC will consult real >>>lawyers when it comes to drafting contract language, and no, it's not >>>because I think real lawyers aren't needed. It's because I know they >>>are, if the appropriate vehicles for doing what we want turn out to >>>include contracts, and that the IAOC doesn't need you or me to tell >>>them so, they need us to tell them what we want them to accomplish >>>with the help of those lawyers. >>> >>>I think a lot of the experienced IETF participants here aren't worried >>>about it either. >>> >>>But we need to be concerned that you are. >>> >>>>>I note that the IAB's opinion is explicitly called out in the existing >>>>>draft; and speaking with my IAB hat on just for a moment, I can tell >>>>>you that the IAB is in fact paying attention to this document and that >>>>>it cannot be published with the claim that the IAB agrees with it >>>>>unless the IAB does in fact agree. >>>>> >>>>>The IAOC, of course, is going to need to be able to implement such >>>>>advice as the WG delivers. So we can expect that the diligent members >>>>>of the IAOC will also undertake relevant review. >>>> >>>>But where are the members of the community being engaged in that >>>>discussion. This all sounds more like "we'll wave our hands over >>>>things and adjust/bless them." That's not an open process. >>> >>>This *is* "where=85.the members of the community [are] being engaged in >>>that discussion." This seems to be preferable to having everyone on >>>this mailing list in the room negotiating contract language, even >>>assuming further contract language is needed beyond what we have >>>today. Forgive me if that sounds flippant, but I think there's a >>>serious underlying question there too: at what point do you think it's >>>appropriate for the community to say "OK, guys, here's the outcomes we >>>want, the basics of how to get there, and some tradeoffs we regard as >>>important, now *you* go do *your* job of implementing it" to the >>>people it's appointed? >>> >>>>>It strikes me that there seem to be some who would like to claim that >>>>>more grown-up or professional or serious or what-have-you procedures >>>>>-- basically, "more like I would prefer" -- are needed for this >>>>>effort. But the argument for that conclusion appears to be simply >>>>>repetition of the claim. One needs rather a better argument than >>>>>abusive _ad hominem_ ("wishy washy" and so on) to be convincing. >>>> >>>>Well, how about the WG charter limiting the scope of discussions to a >>>>subset of the ICG RFP? >>> >>>The one that assumes the IAOC and the IAB will do their jobs, and that >>>we'll be able to tell if they're not? >>> >>>I'll agree that that could be better documented. The charter reads >>>just fine to me, given the assumptions I'm comfortable making from >>>experience, but that doesn't mean it's easily explained to others. I'm >>>tentatively convinced that there should be more in the final >>>deliverable from the IETF to the ICG on why the IETF consensus is >>>suitable in scope and suitable as instructions to the IAOC (which is >>>responsible for contractual relationships on behalf of the IETF, >>>including the RFC Editor, the IANA, and the secretariat) and the IAB >>>(which has overall responsibility for those functions on behalf of the >>>IETF, and is expected to consult with the IETF on those >>>responsibilities, as it has here). >>> >>>But I think it would be a failure in a number of ways for this WG to >>>spend its time on "legal and contractual stuff," or for the IAOC and >>>the IAB to be bound by the results if we did. >>> >>> >>>best, >>>Suzanne >>> >>> >>>_______________________________________________ >>>Ianaplan mailing list >>>Ianaplan@ietf.org >>>https://www.ietf.org/mailman/listinfo/ianaplan >> > >-- > >------------------------------------------------------------------- >Leslie Daigle >Principal, ThinkingCat Enterprises >ldaigle@thinkingcat.com >------------------------------------------------------------------- > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan From nobody Thu Nov 6 05:46: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 431571A6EFF; Thu, 6 Nov 2014 05:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.831 X-Spam-Level: X-Spam-Status: No, score=0.831 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mPT5kkosedA2; Thu, 6 Nov 2014 05:46:14 -0800 (PST) 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 E7A971A6F02; Thu, 6 Nov 2014 05:46:12 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:59028 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XmNO7-00012h-HZ; Thu, 06 Nov 2014 05:46:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Nov 2014 14:46:03 +0100 To: "Ianaplan@Ietf. Org" From: JFC Morfin In-Reply-To: <7F52A930-DD6F-4D0D-8278-A021CF8A466C@istaff.org> References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <7F52A930-DD6F-4D0D-8278-A021CF8A466C@istaff.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1825716813==.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/OplbygwO_B6TkLVOImPyvh5wOcQ Cc: iuwg@iuwg.net, gene@iuwg.net, "iucg@ietf.org" Subject: [iucg] Delay in my IESG appeal 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, 06 Nov 2014 13:46:15 -0000 --=====================_1825716813==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Colleagues, Since I have been unexpectedly led to create the http://iuwg.net site, I intend to activate this unplanned WG for an Intelligent Internet Use and to utilize this Libre's Internet Use global community representation spark in order to competitively foster some technical governance innovations (as per RFC 6852). As such, my priority does change: - from expecting the IETF to protect the IUsers in taking the lead of the technical governance evolution through an update of the IETF/WG/IANAPLAN Charter - to managing our own protection ourselves in cooperation with the IETF, ICANN, ITU, USG, BRICS, SCO, EU, NTIA/FCC, etc. strategies. This is why my appeal to the IESG will focus on the way the IESG should provide adequate guidance to the IETF/WG/IANAPLAN Chairs. The starting point of this appeal is, therefore, the ongoing reading of the "status quo" strategy sponsored by the Chairs, in opposition to my own reading of the IETF position expressed in the Charter, of which the implications have to be considered better (hence the endless debate on issues like iana.org). This is going to give me more time: - to extend my draft (now http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf. Taking advantage from Olaf Kolkman remark on BCP 59). - evaluate the consequences of the Nov 10 IETF/WG/IANAPLAN meeting. - evaluate the consequences of the Nov 10 Putin-Xi Jinping meeting. - evaluate the consequences of the ITU PP 14. - evaluate the first feedback of my draft concerning the network master and master model and plug-ins. I hope that this may eventually lead to a convergence between Eliot's Draft and mine. I am aware that it will most probably call for IESG/IAB/ISOC involvement since I am not permitted to directly discuss it at the ietf@ietf.org last call level. jfc --=====================_1825716813==.ALT Content-Type: text/html; charset="us-ascii" Dear Colleagues,

Since I have been unexpectedly led to create the http://iuwg.net site, I intend to activate this unplanned WG for an Intelligent Internet Use and to utilize this Libre's Internet Use global community representation spark in order to competitively foster some technical governance innovations (as per RFC 6852).

As such, my priority does change:

- from expecting the IETF to protect the IUsers in taking the lead of the technical governance evolution through an update of the IETF/WG/IANAPLAN Charter
- to managing our own protection ourselves in cooperation with the IETF, ICANN, ITU, USG, BRICS, SCO, EU, NTIA/FCC, etc. strategies. 

This is why my appeal to the IESG will focus on the way the IESG should provide adequate guidance to the IETF/WG/IANAPLAN Chairs. The starting point of this appeal is, therefore, the ongoing reading of the "status quo" strategy sponsored by the Chairs, in opposition to my own reading of the IETF position expressed in the Charter, of which the implications have to be considered better (hence the endless debate on issues like iana.org).

This is going to give me more time:

- to extend my draft (now http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf . Taking advantage from Olaf Kolkman remark on BCP 59).
- evaluate the consequences of the Nov 10 IETF/WG/IANAPLAN meeting.
- evaluate the consequences of the Nov 10 Putin-Xi Jinping meeting.
- evaluate the consequences of the ITU PP 14.
- evaluate the first feedback of my draft concerning the network master and master model and plug-ins.

I hope that this may eventually lead to a convergence between Eliot's Draft and mine. I am aware that it will most probably call for IESG/IAB/ISOC involvement since I am not permitted to directly discuss it at the ietf@ietf.org last call level.

jfc
--=====================_1825716813==.ALT-- From nobody Thu Nov 6 07:31:04 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 575121A8917; Thu, 6 Nov 2014 07:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH2a_sqt_F1o; Thu, 6 Nov 2014 07:31:01 -0800 (PST) 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 06EE51A890F; Thu, 6 Nov 2014 07:31:00 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:61028 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XmP1X-00047v-8e; Thu, 06 Nov 2014 07:30:59 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Nov 2014 16:30:51 +0100 To: 'Andrew Sullivan' ,ianaplan@ietf.org From: Jefsey In-Reply-To: <20141106144333.GA33081@mx1.yitter.info> References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <0d10ba336c984561a1a5d6d81db5f26c@EX13-MBX-13.ad.syr.edu> <20141106144333.GA33081@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - 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/_OiJSXNA70D-G05NlTLAl2yG8_c Cc: iuwg@iuwg.net, gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call) 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, 06 Nov 2014 15:31:02 -0000 At 15:43 06/11/2014, 'Andrew Sullivan' wrote: >Yet you apparently believe that the IETF can extort ICANN, which is >what is actually being proposed: they have property, and some are >proposing that they have to give it to us without compensation. Andrew, All this has actually been addressed by the NTIA (Karen Rose) and signed 14 years ago. Please read my draft version 01. http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf. This is probably where the confusion introduced by Fiona Alexander comes from. This is BCP 52. The problem is not with ICANN but with the IETF. - RFC 3172 section 3 should be reminded to participants, WG Chairs, RFC authors, ADs - RFC 3172 Section 5 to the IAB (e.g. Russ Housley Liaison statement of 2014/09/15 - https://datatracker.ietf.org/liaison/1351). Best jfc From nobody Sat Nov 8 12:28:41 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 000681A0151; Sat, 8 Nov 2014 12:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.344 X-Spam-Level: ** X-Spam-Status: No, score=2.344 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497, URIBL_RHS_DOB=1.514] 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 ltU3vMWApJ7e; Sat, 8 Nov 2014 12:28:37 -0800 (PST) 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 B00111A00B8; Sat, 8 Nov 2014 12:28:37 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:1640 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XnCce-0007wq-0Z; Sat, 08 Nov 2014 12:28:36 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 08 Nov 2014 21:28:25 +0100 To: Miles Fidelman From: JFC Morfin In-Reply-To: <545D62C7.4000109@meetinghouse.net> References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <7F52A930-DD6F-4D0D-8278-A021CF8A466C@istaff.org> <545B9F8A.6090502@meetinghouse.net> <545D3CB2.6080905@meetinghouse.net> <20141107235830.205AFCC0E2@server1.neighborhoods.net> <545D62C7.4000109@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: 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/wdYpWbJSp-tjLviDMaEoAyAmePo Cc: ianaplan@ietf.org, iuwg@iuwg.net, gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call) 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, 08 Nov 2014 20:28:39 -0000 At 01:24 08/11/2014, Miles Fidelman wrote: >The thing is, it is not, in any way, shape, manner, or form, a >response to the ICG RFP. Absolutely correct. Please tell me where ICG RFP is mentionned in this WG's Charter. Richard made the point that this WG is to think as if it was ICANN. This is what I oppose. This WG is not ICANN (proof: it has no embedded lawyer). http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf is pertinent. >>IAB/ICANN/NTIA RFC 3172 (BCP 52) >>https://tools.ietf.org/rfc/rfc3172.txt >>. In particular Section 5. This is the response called both by the WG Charter and the ICG: (1) we have an existing solution and the Charter wants status quo. We only have to internally generalize this solution to the multi-SDo multi-repository multi-stakeholder context acknowledged by IEEE, IAB, IETF, ISOC, W3C, NTIA, ITU (RFC 6852; March 14, 2014 statement; Busan) (2) since we do not want to change that general solution we can only answer "no" to every demand for any specific change. (3) our charter is therefore to consider the global changes that might require a change in the agreed existing general solution: no ICG request is formulated appropriately. (4) possibly, in order to spur the IETF slowliness in internally implementing that solution, we might suggest the IESG/IAB to: - create a WG/ARPA to publish an RFC 3172bis in order to update the BCP 52 - and organize a NonWG/ARPA mailing list to manage .arpa as per this BCP 52. Best jfc From nobody Sat Nov 8 12:28:46 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 ECDF41A0195; Sat, 8 Nov 2014 12:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.345 X-Spam-Level: ** X-Spam-Status: No, score=2.345 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497, URIBL_RHS_DOB=1.514] 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 2wQ32GWDEphE; Sat, 8 Nov 2014 12:28:39 -0800 (PST) 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 132371A0167; Sat, 8 Nov 2014 12:28:39 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:1640 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XnCcg-0007wq-4w; Sat, 08 Nov 2014 12:28:38 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 08 Nov 2014 21:14:04 +0100 To: Seun Ojedeji , Miles Fidelman From: JFC Morfin In-Reply-To: References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <7F52A930-DD6F-4D0D-8278-A021CF8A466C@istaff.org> <545B9F8A.6090502@meetinghouse.net> <545D3CB2.6080905@meetinghouse.net> <20141107235830.205AFCC0E2@server1.neighborhoods.net> <545D62C7.4000109@meetinghouse.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2022658949==.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/TTSyginbD7qzR_j7kGy_-XOI-Gc Cc: ianaplan@ietf.org, gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call) 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, 08 Nov 2014 20:28:42 -0000 --=====================_2022658949==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 18:12 08/11/2014, Seun Ojedeji wrote: >I have not gone through the document but I have a similar thought >about Jefsey's writeup. I feared it would attempt to address a lot >beyond scope; reading it and reconfirming my fears would be a great >deal for me. ;) ? There are two topics. 1. the respect of the Charter, as per the reading of the Chairs. 2. the support of the internet users' technical needs as a result of the NTIA announcement, NETmundial meetings, ICANN strategy, resulting IGF, ITU and SCO ongoing debates and the MYCANN Plug-ins consequent projects and expected announcements. As a member of this WG, and the Non-WG IUCG@IETF facilitator, my plan was to do two things after having carefully followed and participated to the WG debate: 1. to introduce an I_D as a community proposals the Chairs have committed to consider as per the Charter. 2. to introduce an appeal to the IESG for this WG to really consider what the IETF is to do in order to adjust to the transition. The cut-off period has not permitted my Draft to be introduced as an I_D in due time. I, therefore, had to create a crash IUWG site where I published and continue to maintain the draft with a forming Libre small group of IUsers. The mails of Andrew, Miles, and you are clear enough; in spite of the Chair's commitment, and the NTIA demand for a multistakeholder approach, the intent does not seem to discuss it as a Libre IUser community contribution. As a result, 1. my Draft http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf no longer only focuse on what the IETF should do but what the IUWG will do to allow IUsers to match the US transition in an unstable situation of contested dominance - during a multistakeholder, multitechnology, multilinguistic, multirepository, and multilateral evolution of the World Digital Ecosystem. This includes the introduction of a separate IETF Draft on Monday responding to the WG/IANAPLAN Charter: how the IETF can protect the status quo and adequately respond to RFPs such as the one received from the IGC. 2. the young IUWG is forming and, therefore, still uncertain about my appeal, due to the lack of a joint appeal process in the RFC 6852 context (the reason for my NTIA interrupted appeal to ISOC). It might be built as an appeal copied as a joint RFP to the other SDOs and affected WGs and coalitions. jfc >Cheers! >sent from Google nexus 4 >kindly excuse brevity and typos. >On 8 Nov 2014 01:24, "Miles Fidelman" ><mfidelman@meetinghouse.net> wrote: >Jefsey, >Sorry to be blunt, but it's been a long day.... >Actually, I HAVE read your draft. The thing is, it is not, in any >way, shape, manner, or form, a response to the ICG RFP. As someone >who spends most of may day job, writing proposals, my basic reaction >is to ignore a document that is unresponsive to the RFP. >Beyond that, as a matter of general "style" - and a problem I >continue to have with the WG draft - is that documents that rely >heavily on cross references to other documents are incredibly >difficult to follow. >Miles Fidelman >Jefsey wrote: >Seun, Richard, Miles, John, >This WG calls for a few "iana.cool" brains. If you do not want to >read my draft (1) please at least read the IAB/ICANN/NTIA RFC 3172 >(BCP 52) >https://tools.ietf.org/rfc/rfc3172.txt >. In particular Section 5. >Cheers. >jfc >(1) >http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf > >   IMHO this is the one which will prevail as it is not NTIA, >nor SCO, nor EU, nor ICANN, nor ITU, nor NETmundial, etc. oriented. >Just interested in intelligent internet use capability. >At 23:06 07/11/2014, Seun Ojedeji wrote: >Miles, it think you are referencing that url as if the operating >systems services are syncing off the iana.org > site. >If that domain changes today, it does not take anything other than a >update to reflect the new reference url does it? >What would be disastrous is if there happens to be 2 authoritative >parameter source with different entries; as an example http >referenced as port 80 and as another port on the other site. >How to avoid that is not just by locking up the name >iana.org but by locking up to a >single source of authority. >Cheers! >sent from Google nexus 4 >kindly excuse brevity and typos. >On 7 Nov 2014 22:42, "Miles Fidelman" ><mfidelman@meetinghouse.net >> wrote: >  David Conrad wrote: >    Miles, >    On Nov 6, 2014, at 6:19 AM, Miles Fidelman >    <mfidelman@meetinghouse.net >    > wrote: >      More specifically, I'm concerned with avoiding any >      confusion or operational disruption in the event of >      future conflicts among the parties involved in oversight, >      management, and/or performance of the IANA functions - >      particularly in the case where a transition of contractor >      might occur on less then friendly terms. >      Under such situations, it seems at least possible, if not >      likely, that litigation might ensue and/or that parties >      might operate competing registries - causing operational >      confusion at a minimum, and possibly more serious >      disruptions to smooth operation of the net. >    We're talking about the protocol parameter registries, right? >    I'm honestly curious: could you describe the "serious >    disruptions to smooth operation of the net" or "operational >    confusion" that would occur in the event of future conflicts >    relating to the IANA trademark and/or IANA.ORG >    domain? > >  Kind of depends on the degree to which various developers depend >  on the various registries published under iana.org >  , and perhaps on the degree to which anybody >  relies on automatic download of registry contents. >  For example, the /etc/services file in Debian includes this >  statement: >  #Updated from >http://www.iana.org/assignments/port-numbers > >  >  I expect other operating systems do similar things. A lot of >  systems could break, rather precipitously, if iana.org >  went offline, or the file were moved somewhere >  else, or the file were corrupted - particularly if it happened >  just before a major release cycle. >  To me, that would be a "serious disruption" or at the very least >  "operational confusion" >  Miles Fidelman >  --   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 > >  >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan ><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 > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan --=====================_2022658949==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 18:12 08/11/2014, Seun Ojedeji wrote:
I have not gone through the document but I have a similar thought about Jefsey's writeup. I feared it would attempt to address a lot beyond scope; reading it and reconfirming my fears would be a great deal for me. ;)

?
There are two topics.

1. the respect of the Charter, as per the reading of the Chairs.

2. the support of the internet users’ technical needs as a result of the NTIA announcement, NETmundial meetings, ICANN strategy, resulting IGF, ITU and SCO ongoing debates and the MYCANN Plug-ins consequent projects and expected announcements.

As a member of this WG, and the Non-WG IUCG@IETF facilitator, my plan was to do two things after having carefully followed and participated to the WG debate:

1. to introduce an I_D as a community proposals the Chairs have committed to consider as per the Charter.
2. to introduce an appeal to the IESG for this WG to really consider what the IETF is to do in order to adjust to the transition.

The cut-off period has not permitted my Draft to be introduced as an I_D in due time. I, therefore, had to create a crash IUWG site where I published and continue to maintain the draft with a forming Libre small group of IUsers. The mails of Andrew, Miles, and you are clear enough; in spite of the Chair's commitment, and the NTIA demand for a multistakeholder approach, the intent does not seem to discuss it as a Libre IUser community contribution.

As a result,

1. my Draft http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf no longer only focuse on what the IETF should do but what the IUWG will do to allow IUsers to match the US transition in an unstable situation of contested dominance - during a multistakeholder, multitechnology, multilinguistic, multirepository, and multilateral evolution of the World Digital Ecosystem. This includes the introduction of a separate IETF Draft on Monday responding to the WG/IANAPLAN Charter: how the IETF can protect the status quo and adequately respond to RFPs such as the one received from the IGC.

2. the young IUWG is forming and, therefore, still uncertain about my appeal, due to the lack of a joint appeal process in the RFC 6852 context (the reason for my NTIA interrupted appeal to ISOC). It might be built as an appeal copied as a joint RFP to the other SDOs and affected WGs and coalitions.

jfc



Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.
On 8 Nov 2014 01:24, "Miles Fidelman" < mfidelman@meetinghouse.net> wrote:
Jefsey,
Sorry to be blunt, but it's been a long day....
Actually, I HAVE read your draft.  The thing is, it is not, in any way, shape, manner, or form, a response to the ICG RFP.  As someone who spends most of may day job, writing proposals, my basic reaction is to ignore a document that is unresponsive to the RFP.
Beyond that, as a matter of general "style" - and a problem I continue to have with the WG draft - is that documents that rely heavily on cross references to other documents are incredibly difficult to follow.
Miles Fidelman
Jefsey wrote:
Seun, Richard, Miles, John,
This WG calls for a few "iana.cool" brains. If you do not want to read my draft (1) please at least read the IAB/ICANN/NTIA RFC 3172 (BCP 52) https://tools.ietf.org/rfc/rfc3172.txt < https://tools.ietf.org/rfc/rfc3172.txt>. In particular Section 5.
Cheers.
jfc
(1) http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf
     IMHO this is the one which will prevail as it is not NTIA, nor SCO, nor EU, nor ICANN, nor ITU, nor NETmundial, etc. oriented. Just interested in intelligent internet use capability.
At 23:06 07/11/2014, Seun Ojedeji wrote:
Miles, it think you are referencing that url as if the operating systems services are syncing off the iana.org <http://iana.org> site.
If that domain changes today, it does not take anything other than a update to reflect the new reference url does it?
What would be disastrous is if there happens to be 2 authoritative parameter source with different entries; as an example http referenced as port 80 and as another port on the other site.
How to avoid that is not just by locking up the name iana.org <http://iana.org> but by locking up to a single source of authority.
Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.
On 7 Nov 2014 22:42, "Miles Fidelman" < mfidelman@meetinghouse.net < mailto:mfidelman@meetinghouse.net>> wrote:
    David Conrad wrote:
        Miles,
        On Nov 6, 2014, at 6:19 AM, Miles Fidelman
        < mfidelman@meetinghouse.net
        < mailto:mfidelman@meetinghouse.net>> wrote:
            More specifically, I'm concerned with avoiding any
            confusion or operational disruption in the event of
            future conflicts among the parties involved in oversight,
            management, and/or performance of the IANA functions -
            particularly in the case where a transition of contractor
            might occur on less then friendly terms.
            Under such situations, it seems at least possible, if not
            likely, that litigation might ensue and/or that parties
            might operate competing registries - causing operational
            confusion at a minimum, and possibly more serious
            disruptions to smooth operation of the net.
        We're talking about the protocol parameter registries, right?
        I'm honestly curious: could you describe the "serious
        disruptions to smooth operation of the net" or "operational
        confusion" that would occur in the event of future conflicts
        relating to the IANA trademark and/or IANA.ORG
        <http://IANA.ORG> domain?

    Kind of depends on the degree to which various developers depend
    on the various registries published under iana.org
    <http://iana.org>, and perhaps on the degree to which anybody
    relies on automatic download of registry contents.
    For example, the /etc/services file in Debian includes this
    statement:
    #Updated from http://www.iana.org/assignments/port-numbers
    < http://www.iana.org/assignments/port-numbers>
    I expect other operating systems do similar things.  A lot of
    systems could break, rather precipitously, if iana.org
    <http://iana.org> went offline, or the file were moved somewhere
    else, or the file were corrupted - particularly if it happened
    just before a major release cycle.
    To me, that would be a "serious disruption" or at the very least
    "operational confusion"
    Miles Fidelman
    --     In theory, there is no difference between theory and practice.
    In practice, there is.   .... Yogi Berra
    _______________________________________________
    Ianaplan mailing list
    Ianaplan@ietf.org < mailto:Ianaplan@ietf.org>
    https://www.ietf.org/mailman/listinfo/ianaplan
    < https://www.ietf.org/mailman/listinfo/ianaplan>
_______________________________________________
Ianaplan mailing list
Ianaplan@ietf.org
https://www.ietf.org/mailman/listinfo/ianaplan < 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

_______________________________________________
Ianaplan mailing list
Ianaplan@ietf.org
https://www.ietf.org/mailman/listinfo/ianaplan
--=====================_2022658949==.ALT-- From nobody Mon Nov 10 10:47: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 A98811A1B35; Mon, 10 Nov 2014 10:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.145 X-Spam-Level: *** X-Spam-Status: No, score=3.145 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497, URIBL_RHS_DOB=1.514] 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 w1FFe1i3mphl; Mon, 10 Nov 2014 10:47:27 -0800 (PST) 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 D97F21A1A4D; Mon, 10 Nov 2014 10:47:27 -0800 (PST) Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:61791 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xntzq-0001nh-Au; Mon, 10 Nov 2014 10:47:26 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Nov 2014 19:47:13 +0100 To: Marc Blanchet , "Leslie Daigle (TCE)" From: Jefsey In-Reply-To: <2CE0BB78-AC2A-498F-A2B2-1299530120C0@viagenie.ca> References: <2CE0BB78-AC2A-498F-A2B2-1299530120C0@viagenie.ca> 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/R1h-5qX3BhGPfg71O81sorK7BnM Cc: "Ianaplan@Ietf.org" , gene@iuwg.net, "iucg@ietf.org" Subject: [iucg] WG Meeting and Last-Call - my draft 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, 10 Nov 2014 18:47:28 -0000 Dear Chairs, I do not know the time of the WG meeting. Therefore I have posted the draft of my strict IETF Charter perspective I_D at http://iuwg.net/index.php/Intlnet_Draft_on_IANA_transition. 1. It is still to be reviewed for its final form and English by our local group (NB. Most of the text comes from the horses mouth: NTIA, IAB, IETF, ICANN, Charter). 2. it will be registered after this review as an I_D now the cut-off period is finished. However it will still be during the last-call period, this may be after your meeting. Moreover if I have formating issues. This I_D concludes to NO change, one domain name registration agreed 15 years ago by all the parties, a few hints to IAB and IAOC. It addresses the ICANN accountability issue and takes the IUWG input into account. jfc From nobody Thu Nov 13 16:05:50 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 5224A1A0027; Thu, 13 Nov 2014 16:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccov8pxqSq7q; Thu, 13 Nov 2014 16:05:44 -0800 (PST) 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 2EE6E1A0035; Thu, 13 Nov 2014 16:05:44 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:56214 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xp4OV-0006Yh-1E; Thu, 13 Nov 2014 16:05:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Nov 2014 01:05:43 +0100 To: John C Klensin ,Jefsey , Milton L Mueller , "'ianaplan@ietf.org'" From: JFC Morfin In-Reply-To: <93047D4E3CF3CA3A709DA2E0@JcK-HP8200.jck.com> References: <14B467E80161CC85704EE8DC@JcK-HP8200.jck.com> <01d5c1a7b4104d0984e87700a3992cd2@EX13-MBX-13.ad.syr.edu> <93047D4E3CF3CA3A709DA2E0@JcK-HP8200.jck.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/hxl1lAgL6Y75fPmB0uBqO2mBpqs Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Protocol parameter registries and the ARPA TLD 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, 14 Nov 2014 00:05:45 -0000 At 20:34 13/11/2014, John C Klensin wrote: >If you dislike the current arrangements and structure or wish to >challenge the legitimacy of NTIA's current role and hence the >mechanisms by which they wish to consider changing it, I think >that is fine (whether I agree or not). But that is a different >discussion from the one before this WG and you should probably >find a different and more appropriate place to have it. Dear John, this is the IETF. What I (and activists, gurus, or politicians) may ***think*** or be familiar with is of strickly no interest. What counts is the way things ***are*** and what ***users*** will think, demand and pay for. And what laws and contracts permit. The points I raised (whatever I may think about them) are things one may argue over the impact, but not about the reality. The purpose of this WG is not to subjectively guess, hope, wish, think, etc. it is to objectively plan how to make sure that - whatever the users, money, industries, Govs and other stakeholders will do - the IETF will still be able to best contribute to the real whole world's TCP/IP oriented needs, so the internet keeps working better. I do not see that plan being discussed, analyzed, and documented. This means that your suggestion to discuss it at a "different and more appropriate place" may become a necessity However, unless we want to take the ***risk to fragment the network middle layers (end to end)***, such a (or several) WG replacement or IETF fork need to be: (1) triggered by this WG (it seems this is going to be a non full consensus the case), (2) reviewed by an IETF Last Call, (3) and confirmed by the IESG, (4) the IAB, (5) and then ISOC to make sure everyone is in argeement. The NTIA has decided it could not delay such a risk any more, has decided to engage in its initially decided 2000 strategy to prevent it, and asked stakeholders a plan, this WG is to contribute from an IETF point of view (cf. Charter). I supposed all of us wished and responsibly wish (cf. the RFC 3935 definition) to keep this risk under realistic and reasonable control. Unfortunately, this is not what I observe. I will carefully review the version 03 of the proposed draft, but I fear I will be obliged to oppose it as supporting/discussing only one strategy, based upon an incomplete assessment of the reality (we mutually documented it), that/what IMHO contradicts our Charter and is neither in the best interest of the IETF, nor of the technology, of the users and therefore of humanity. This is worrying. jfc From nobody Sun Nov 16 09:50:53 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 9D7F01A06FD; Sun, 16 Nov 2014 09:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIKBkQEsx5pY; Sun, 16 Nov 2014 09:50:49 -0800 (PST) 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 D97631A066B; Sun, 16 Nov 2014 09:50:49 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:43708 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xq3yG-0006on-QP; Sun, 16 Nov 2014 09:50:45 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Nov 2014 18:50:30 +0100 To: Stephen Farrell , Milton L Mueller From: Jefsey In-Reply-To: <5468C28F.3040103@cs.tcd.ie> References: <54679341.8000008@cs.tcd.ie> <15deb4f243aa456387d5a734a44192cb@EX13-MBX-13.ad.syr.edu> <5468C28F.3040103@cs.tcd.ie> 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/ebGcbAPO9dacNMqqfj5s4v4_JF4 Cc: "ianaplan@ietf.org" , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Proposed text reflecting IETF91 discussion 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, 16 Nov 2014 17:50:51 -0000 At 16:28 16/11/2014, Stephen Farrell wrote: >That's utter nonsense. Dear Stephen, let keep calm, please. Please understand why it makes far more sense than you seem to feel. I just hope you will bear with me for the length of this mail. I am speaking here in copying the IUCG@IETF, i.e. as an IETF User. So, - it will be clear I am not "one of you". Actually "you" banned me for that. - the IANA plus its complementary and missing sites are your interface with us. What I can say is that we are unpleased with the IANA current venue for two simple reasons: 1) you never consider what we would need to see, only what you want to say there. This may not be a good way to manage an interface. 2) you only contracted with ICANN and we are not pleased with that monopoloy because it does not respect the many multistakeholder rights of our RFC 6852 global communities. We have learned to live with this. We accept that if your whole thing could be better for us, it is a great success, and has resulted in a "huge bounty" (cf. RFC 6852). However, we tend to identify both issues as reverberating the NTIA oversight - (1) through the USCC/industry procurement/Anglo-Saxon cultural proximity for the IETF, - (2) its contractual renewal live/death power on ICANN. We are offered two serious/important responses by authorities we respect: 1) the NTIA transition to the FCC, by Strickling/Obama 2) the IAB statement on the technology transition toward a Confidential Internet, by Russ Housley. Both may have a fundamental impactd on the quality of the IETF deliveries and on our daily digital operations. This means that we are pleased but also that we have important concerns when - we observe through this WG's debate that you only consider "your" interest in maintaining your own operational status-quo. - while we look for an innovative, security oriented, steady technology development and a better control on our digital operations. Unfortunately, at the end of the day we are those who pay, nationally vote for our Govs, and incidently develop our own technology and run our operations.i.e. the IANA Users. 1. We understand you do not like our Govs, we understand we are not much related to the Libre. This was more and more reciprocal ***until*** both the USG and the IAB made their two major steps ahead. Now with NETmundial and the architectural possibilities being open by the offer of cooperation of the IAB, we are ready to consider/cooperate for the better. 2. As you say we see our own face of the interface, and we may be wrong. In such a case it is up to you to help us, as we try to help you in spending time working in here. Not to tell us "we know better, don't disrupt". Please do not keep us in the situation where we feel in agreement with the NTIA and IAB, and as result, in opposition with you and (due to that) with ICANN. Would it not be amazing if you made us to chose ICANN between "you" and them! jfc >It's entirely obvious that there are a number of people on this >list (yourself included) who are coming at this with a different >viewpoint from the many people on this list that I know are very >much involved in writing RFCs that make changes to IANA protocol >parameters. > >Those people (again yourself included) have I think provided good >inputs in various ways, I'm sure the editors could provide all the >details, but on this specific topic seem to me to be just wrong >and continually missing the point that the IETF does not need to >get all lawyered up to provide the ICG with the IETF's proposal >or feedback. > >ISTM that you are attempting to cast doubt on the process just >because you and a few others are in the rough on one topic. And >as I said above, that's utter nonsense. In open processes like >the IETF's you just don't always get what you want, no matter >how often you (or Richard IMO) metaphorically try to throw the >toys out of the cradle. > >S. > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan From nobody Sun Nov 16 12:06:47 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 AEC571A1ACA; Sun, 16 Nov 2014 12:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.131 X-Spam-Level: ** X-Spam-Status: No, score=2.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_ABOUTYOU=0.5, 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 VnvyWY2dJA6G; Sun, 16 Nov 2014 12:06:14 -0800 (PST) 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 4E6851A1ADB; Sun, 16 Nov 2014 12:06:14 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:47173 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xq65K-0000NP-Nl; Sun, 16 Nov 2014 12:06:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Nov 2014 21:05:55 +0100 To: "Peterson, Jon" , Milton L Mueller ,"rhill@hill-a.ch" , Alissa Cooper From: Jefsey In-Reply-To: References: <2A9AA299-83BE-4984-B6DC-957B67C253FF@cooperw.in> <128d7c1fc7a0469fb964ba4f36f9f6d4@EX13-MBX-13.ad.syr.edu> 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/gUbFyWSYEj8qhGKUkzJnX2DCw48 Cc: "ianaplan@ietf.org" , gene@iuwg.net, "iucg@ietf.org" , Eliot Lear Subject: Re: [iucg] [Ianaplan] Proposed text reflecting IETF91 discussion 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, 16 Nov 2014 20:06:15 -0000 At 20:04 16/11/2014, Peterson, Jon wrote: >Please, just let us resolve this - to us, relatively trivial >technical matter - to our own satisfaction. Jon, many of your points technically stand. But please remember that supposedly your own satisfaction is to make the internet run better, what is something the Internet users appreciate. This means that this WG's rough consensus appreciated by the Chairs is subject to the IETF last-call rough consensus, which is subject to the IESG decision which is subject to appeals which are subject to use. The real issue is that the ultimate referent authority for IETF and ICANN appeals was the USG through the NTIA, most probably advised by the IETF rough consensus, and US industrial interests and that is what is transitionning. - The question was raised by RFC 6852, - then it was raised by the WCIT vote in Dubai - then it was raised by Edward Snowden - then it was raised by the Montevideo declaration - then it was raised by the NTIA statement, - then it was raised by the Geneva Davos NETmundial, - then it was raised by President Obama a few days ago, - then it was again raised by the IAB the next day. You discuss issues related to a now ***obsolete/condemned*** Internet. The internet we are interested in seeing properly redesigned, run and managed is an Internet you did not develop, says the IAB. It is a secure internet. This is why we currently do not trust you. This WG is not about the ICG (show me the term in its Charter). It is about you making us to trust you are motivated in responsibly designing the internet we are promised. We certainly understand the difficulty and the Loc/ID missing presentation layer, etc. issues. And are ready to help you achieving the task; but do not start by ignoring, bashing or attacking us. This is counter productive and pushes us to do the job by ourselves, with our Govs, and to fork. Implicitely the external world broad consensus (cf. RFC 6852) would be pleased if the referent was - at least temporarily - the IAB, what may not please ICANN. However, this consensus can only be temporary due to: - the terms of the BCP 78, i.e. the internet licence which is not a CC license or public domain; - the USG which wants to stay more equal than its 191 fellow governments. - the technical solutions that will be found to make the internet secure (is this possible) or to build a secure internet. Now, you can ignore me and my mails. I just send them to help and try to avoid the losses for many of you that a messy fork would represent. I/we fully understand that Neustar would be hurt by the secure internet DNS Class the Libre is planning to test, in the case it became a non-business equal open reality. However, it you really want to defend the Neustar interests, and the whole Naming ICANN "industry", please cooperate, try to find and document new trusted services. We have been proposed a multistakeholder approach by the current oversight holder. We have been proposed a secure internet design support by the architectural board. We only see you discussing your own status-quo. What do you want us to think. Even with the best good will? Tell us, tell us .... jfc From nobody Sun Nov 16 14:57:04 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 6B3DD1A1B79; Sun, 16 Nov 2014 14:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzyrmxY8yPg5; Sun, 16 Nov 2014 14:56:48 -0800 (PST) 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 53D741A014D; Sun, 16 Nov 2014 14:56:48 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:50886 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xq8kQ-0004CL-Oq; Sun, 16 Nov 2014 14:56:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Nov 2014 23:56:45 +0100 To: Andrew Sullivan ,ianaplan@ietf.org From: JFC Morfin In-Reply-To: <20141116203736.GB4455@mx1.yitter.info> References: <2A9AA299-83BE-4984-B6DC-957B67C253FF@cooperw.in> <128d7c1fc7a0469fb964ba4f36f9f6d4@EX13-MBX-13.ad.syr.edu> <20141116203736.GB4455@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - 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/fVbxztljnOutxsyHa_XMlQFI2-c Cc: gene@iuwg.net, "iucg@ietf.org" Subject: [iucg] RFC 7282: the conclusion. 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, 16 Nov 2014 22:56:49 -0000 At 21:37 16/11/2014, Andrew Sullivan wrote: >I think the minutes show, and the chairs' reactions indicate, that the >views supporting the statements you are unhappy with having removed >from the Internet Draft were in fact well exposed and discussed in the >room. The WG just didn't agree. That happens; it's what "rough >consensus" looks like. "Sometimes, a show of hands can be useful; sometimes, it can be quite damaging and result in terrible decisions. Sometimes, using a device like a "hum" can avoid those pitfalls; sometimes, it is just a poorly disguised vote." (RFC 7282) "We believe in rough consensus and running code". Dear Andrew, I am sure you realize that the minutes of the meeting room in Hawaii only concern a rough consensus of non-secure-internet designers. How many of them where Libre engineers footing their own T&L? This is not consensus, but "concensus", if you permit me the pun. Now, since it seems it will be hard to reach a rough consensus before we have completed the whole appeal process, and that this XG's dbate is already between ICG members, the IUWG.NET's approach looks faster: to help study, document and develop an accepted running code. This means a secure internet based upon a MYCANN plug-in. Russ has declared the new internet has to be secure. Obama has decided the FCC was to make it neutral. It seems the transition has been settled and we just to have it completed. We just need to complete and test the code as per ICANN/ICP-3 and submit it to the RFC 6852 global communities' competition for innovation. Will the ICANN, Google, Apple, USCC, Chinese, NSA, Russian, European, Libre, Civil Society, etc. MYCANN Plug-in be the more innovating and accepted one by the users? Competition will tell! The contest is open. jfc From nobody Mon Nov 17 06:31: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 B17CF1A6ED9; Mon, 17 Nov 2014 06:31:19 -0800 (PST) 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 earnMchXf2rU; Mon, 17 Nov 2014 06:31:16 -0800 (PST) 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 2827C1A3B9E; Mon, 17 Nov 2014 06:31:16 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:1184 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XqNKk-0003aQ-K8; Mon, 17 Nov 2014 06:31:15 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Nov 2014 15:30:59 +0100 To: Andrew Sullivan ,ianaplan@ietf.org From: JFC Morfin In-Reply-To: <20141116213738.GE4455@mx1.yitter.info> References: <2A9AA299-83BE-4984-B6DC-957B67C253FF@cooperw.in> <128d7c1fc7a0469fb964ba4f36f9f6d4@EX13-MBX-13.ad.syr.edu> <20141116213738.GE4455@mx1.yitter.info> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_266776108==.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/_4bOnrmu-RPi8vzZaiODF6cgvNk Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Proposed text reflecting IETF91 discussion 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, 17 Nov 2014 14:31:20 -0000 --=====================_266776108==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Dear Andrew, Your analysis of the WG's attitudes is excellent! This helps me a lot in explaining why I am "elsewhere" rather than in your scheme, why I think everyone is right, and where consensus is and why. The IETF has an engineering culture, the IAB an architectural culture, and mine is difficult to follow for both. This is because it is an architectonical culture. - Engineers work out detailed solutions within architectures; - Architects choose global solutions that fit a common architectony; - Architectonicians' job is to try to build an architectony, i.e. to comprehend and document how things work. This means that they are partly mathematicians, partly philosophers, partly politicians, etc. This is the Greek meaning of "archi", regarding what is below (and common to) everything. In particular due to cybernetics, logic, quantum physics, meshed networking, globalization, multilinguistics, multistakeholderism, etc. this is the intermultidisciplinarity of the "(g)locality problem". Architectonics has dramatically progressed in the last 125 years and networking has contributed a lot (in particular in the agoric [meshed logic] way of thinking that addresses complexity). The target is to understand how our fractally deterministic chaos (nature, society, events, politics, groups, IETF decisions, etc.) works. E.g. how I obtained the RFC 4646 consensus I wanted. This is called "SOC", self-organized criticality, studied from the Per Bak or Abelian sand pile model. http://en.wikipedia.org/wiki/Abelian_sandpile_model. This should be conceptually linked to: - the "n-body" issue of Poincaré - the Catastrophe Theory of René Thom - the metamaths of Gregory Chaitin - Jon Postel's principle of robustness (RFC 1122) - Randy Bush's and David Meyer's principle of simplicity (RFC 3439) to lead to what one might call the "Leibnitz Principle": "the simplest the premise, the richest the emergence". E.g.: the bit/big-bang => the universe. This means that the target is to find and address the IETF's NTIA transition "least common factor". This is what I am interested in. It looks like the status quo, it smells like the status quo but it is not the status quo. I think this is nearly completed already (if an inadequate draft does not confuse everything – in that case it will be rebuilt outside of the IETF). On Sept. 30, 2014, IAB has been recorded in the IANA as the .arpa TLD manager. In order to complete the 2000 NTIA prepared transition and best settle the IETF position, IAB only has to register "iana.arpa" and make it parked at "iana.org" and use it. Everything else will follow in due time. IAB has no army to enforce its positions. It has the .arpa TLD where it is sovereign. These are its "Pope's divisions of Stalin". jfc At 22:37 16/11/2014, Andrew Sullivan wrote: >I think this is exactly right. But I think part of the controversy >may be that some disagree about the consequences. Let me >describe two caricature positions, neither of which represents any >actual person AFAICT, to suggest where the poles of disagreement are >in my opinion. > >Some of us, it appears, think that this is an extremely delicate >matter for the protocol parameters registries as well as for other >registries. It appears to me that those who think this feel strongly >that it is important now to arrange the adoption of several >provisions. It appears that those holding this position think that >the existing arrangements are open to negotiation in order to achieve >some of these other ends. > >Others of us, it appears, think that the existing arrangements for the >protocol parameters registries are perfectly adequate, and the only >goal here is to do every possible thing to ensure that those >arrangements don't change an iota as a result of the transition. It >appears to me that those who think this feel strongly that there are >no new provisions to be made, though there might be things that >currently follow as a result of the NTIA-ICANN agreement; those >provisions need to be documented. It appears that those holding this >position think that there is nothing more important than avoiding >opening any existing agreement for any kind of negotiation. > >Now, having drawn those cartoon versions of the positions, it seems to >me that most of us fall somewhere in between these views. It also >seems to me that the closer one is to the first of these, the more one >might be uncomfortable with some of the changes from -02 to -03. My >own impression is that the WG mostly leans toward the second end of >the spectrum. If that's correct, then a couple things fall out. > >First, "How do we understand the transition's significance and >implications?" Under this view, there is not a great significance, >and the implications are matters of detail (important detail, but just >details all the same). Second, "What can we do to transition the >process without screwing it up?" Under this view, the answer is to do >as little as possible, because the existing arrangements are good and >working, and we have always believed that the main protection to the >protocol parameters registries lay with the IETF's established (and >sometimes used) ability to manage the publication of its registries as >it sees fit. > >Best regards, --=====================_266776108==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear Andrew,

Your analysis of the WG’s attitudes is excellent!

This helps me a lot in explaining why I am "elsewhere" rather than in your scheme, why I think everyone is right, and where consensus is and why.

The IETF has an engineering culture, the IAB an architectural culture, and mine is difficult to follow for both. This is because it is an architectonical culture.

- Engineers work out detailed solutions within architectures;
- Architects choose global solutions that fit a common architectony;
- Architectonicians' job is to try to build an architectony, i.e. to comprehend and document how things work. This means that they are partly mathematicians, partly philosophers, partly politicians, etc. This is the Greek meaning of "archi", regarding what is below (and common to) everything. In particular due to cybernetics, logic, quantum physics, meshed networking, globalization, multilinguistics, multistakeholderism, etc. this is the intermultidisciplinarity of the "(g)locality problem".

Architectonics has dramatically progressed in the last 125 years and networking has contributed a lot (in particular in the agoric [meshed logic] way of thinking that addresses complexity). The target is to understand how our fractally deterministic chaos (nature, society, events, politics, groups, IETF decisions, etc.) works. E.g. how I obtained the RFC 4646 consensus I wanted.

This is called "SOC", self-organized criticality, studied from the Per Bak or Abelian sand pile model. http://en.wikipedia.org/wiki/Abelian_sandpile_model. This should be conceptually linked to:
- the "n-body" issue of Poincaré
- the Catastrophe Theory of René Thom
- the metamaths  of Gregory Chaitin
- Jon Postel's principle of robustness (RFC 1122)
- Randy Bush's and David Meyer's principle of simplicity (RFC 3439)
to lead to what one might call the "Leibnitz Principle": "the simplest the premise, the richest the emergence". E.g.: the bit/big-bang => the universe.

This means that the target is to find and address the IETF's NTIA transition "least common factor". This is what I am interested in. It looks like the status quo, it smells like the status quo but it is not the status quo.

I think this is nearly completed already (if an inadequate draft does not confuse everything – in that case it will be rebuilt outside of the IETF). On Sept. 30, 2014, IAB has been recorded in the IANA as the .arpa TLD manager. In order to complete the 2000 NTIA prepared transition and best settle the IETF position, IAB only has to register "iana.arpa" and make it parked at "iana.org" and use it. Everything else will follow in due time.

IAB has no army to enforce its positions. It has the .arpa TLD where it is sovereign. These are its “Pope's divisions of Stalin”.

jfc

At 22:37 16/11/2014, Andrew Sullivan wrote:
I think this is exactly right.  But I think part of the controversy
may be that some disagree about the consequences.  Let me
describe two caricature positions, neither of which represents any
actual person AFAICT, to suggest where the poles of disagreement are
in my opinion.

Some of us, it appears, think that this is an extremely delicate
matter for the protocol parameters registries as well as for other
registries.  It appears to me that those who think this feel strongly
that it is important now to arrange the adoption of several
provisions.  It appears that those holding this position think that
the existing arrangements are open to negotiation in order to achieve
some of these other ends.

Others of us, it appears, think that the existing arrangements for the
protocol parameters registries are perfectly adequate, and the only
goal here is to do every possible thing to ensure that those
arrangements don't change an iota as a result of the transition.  It
appears to me that those who think this feel strongly that there are
no new provisions to be made, though there might be things that
currently follow as a result of the NTIA-ICANN agreement; those
provisions need to be documented.  It appears that those holding this
position think that there is nothing more important than avoiding
opening any existing agreement for any kind of negotiation.

Now, having drawn those cartoon versions of the positions, it seems to
me that most of us fall somewhere in between these views.  It also
seems to me that the closer one is to the first of these, the more one
might be uncomfortable with some of the changes from -02 to -03.  My
own impression is that the WG mostly leans toward the second end of
the spectrum.  If that's correct, then a couple things fall out. 

First, "How do we understand the transition's significance and
implications?"  Under this view, there is not a great significance,
and the implications are matters of detail (important detail, but just
details all the same).  Second, "What can we do to transition the
process without screwing it up?"  Under this view, the answer is to do
as little as possible, because the existing arrangements are good and
working, and we have always believed that the main protection to the
protocol parameters registries lay with the IETF's established (and
sometimes used) ability to manage the publication of its registries as
it sees fit. 

Best regards,
--=====================_266776108==.ALT-- From nobody Mon Nov 17 07:02: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 DB0171A8A94; Tue, 4 Nov 2014 07:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 yBxvzNoHHw9K; Tue, 4 Nov 2014 07:50:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 029F01A8A85; Tue, 4 Nov 2014 07:50:02 -0800 (PST) Received: from h226.viagenie.ca (h226.viagenie.ca [206.123.31.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0E052403BB; Tue, 4 Nov 2014 10:49:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: <20141104153134.DC7D51A8A13@ietfa.amsl.com> Date: Tue, 4 Nov 2014 10:49:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141104153134.DC7D51A8A13@ietfa.amsl.com> To: Jefsey X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/k-1rJtT_60pnY6112HhzEcp89pc X-Mailman-Approved-At: Mon, 17 Nov 2014 07:02:31 -0800 Cc: "Ianaplan@Ietf. Org" , "Leslie Daigle \(TCE\)" , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Draft submission interlude 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, 04 Nov 2014 15:50:04 -0000 Le 2014-11-04 =C3=A0 10:31, Jefsey a =C3=A9crit : >=20 > Dear Chairs, > I just discovered a cute IETF trick. One cannot submit drafts during = the last-call period if adequately chosen :-) these dates are unrelated. Moreover, the chairs proposed the timeline = during the Interim meeting and people agreed on the timeline.=20 Marc. >=20 > IETF: >> The cut-off time for the I-D submission was 00h UTC, 2014-10-28. >> The I-D submission tool will be reopened at 00h local time at the = IETF meeting location, 2014-11-10. >=20 > Chair: >> given the proposed timeline agreed during our last interim meeting = and based on that the outstanding issues should have been addressed in = the -02 version, this message starts a working group last call on = draft-ietf-ianaplan-icg-response-02. This working group last call will = end november 11, 23h59 UTC. Given that our meeting is scheduled on = november 10th, it would be useful if people send their comments prior to = the meeting so they can be addressed or discussed before or during the = meeting. >=20 > Should I add the draft to my appeal ? > What is the most constructive solution that will not irritate my = co-writers? >=20 > jfc=20 > _______________________________________________ > Ianaplan mailing list > Ianaplan@ietf.org > https://www.ietf.org/mailman/listinfo/ianaplan From nobody Mon Nov 17 07:02: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 DA8CA1A9127; Mon, 10 Nov 2014 10:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 vHpeTYDP3b-n; Mon, 10 Nov 2014 10:56:52 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67C1A86E2; Mon, 10 Nov 2014 10:56:52 -0800 (PST) Received: from dhcp-a2ea.meeting.ietf.org (dhcp-a2ea.meeting.ietf.org [31.133.162.234]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 367FA400A5; Mon, 10 Nov 2014 13:56:51 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: <2CE0BB78-AC2A-498F-A2B2-1299530120C0@viagenie.ca> Date: Mon, 10 Nov 2014 08:56:48 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CE0BB78-AC2A-498F-A2B2-1299530120C0@viagenie.ca> To: Jefsey X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/KE4vulBG3fUoYzMZqwUYwyxoY_M X-Mailman-Approved-At: Mon, 17 Nov 2014 07:02:31 -0800 Cc: "Ianaplan@Ietf.org" , "Leslie Daigle \(TCE\)" , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] WG Meeting and Last-Call - my draft 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, 10 Nov 2014 18:56:54 -0000 > Le 2014-11-10 =C3=A0 08:47, Jefsey a =C3=A9crit : >=20 > Dear Chairs, >=20 > I do not know the time of the WG meeting. Monday November 10th, 13h00 Honolulu time. > Therefore I have posted the draft of my strict IETF Charter = perspective I_D at = http://iuwg.net/index.php/Intlnet_Draft_on_IANA_transition. To be considered, you should submit your draft in the internet-drafts = directory. The window is now reopened: https://datatracker.ietf.org/submit/ Regards, Marc. >=20 > 1. It is still to be reviewed for its final form and English by our = local group (NB. Most of the text comes from the horses mouth: NTIA, = IAB, IETF, ICANN, Charter). > 2. it will be registered after this review as an I_D now the cut-off = period is finished. However it will still be during the last-call = period, this may be after your meeting. Moreover if I have formating = issues. >=20 > This I_D concludes to NO change, one domain name registration agreed = 15 years ago by all the parties, a few hints to IAB and IAOC. It = addresses the ICANN accountability issue and takes the IUWG input into = account. >=20 > jfc From nobody Mon Nov 17 11:22: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 07FF81A8A1E; Mon, 17 Nov 2014 11:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flWB7vVlfF46; Mon, 17 Nov 2014 11:22:43 -0800 (PST) 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 5A88D1A8A0D; Mon, 17 Nov 2014 11:22:43 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:7770 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XqRsn-0001wD-Ta; Mon, 17 Nov 2014 11:22:42 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Nov 2014 20:22:26 +0100 To: Miles Fidelman From: Jefsey In-Reply-To: <546A417D.4000101@meetinghouse.net> References: <2A9AA299-83BE-4984-B6DC-957B67C253FF@cooperw.in> <128d7c1fc7a0469fb964ba4f36f9f6d4@EX13-MBX-13.ad.syr.edu> <20141116213738.GE4455@mx1.yitter.info> <54692052.7000602@meetinghouse.net> <546923D1.3070006@cs.tcd.ie> <54693483.3090601@meetinghouse.net> <546939FC.8010902@cs.tcd.ie> <546940D5.80104@meetinghouse.net> <54694B77.7020008@gmail.com> <19C1077D-E020-448F-A348-DACC8B5C7D5D@gmail.com> <546A417D.4000101@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: 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/CYUpavHiKk5Dni0W5YQ7IFJtrsk Cc: "ianaplan@ietf.org" , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Proposed text reflecting IETF91 discussion 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, 17 Nov 2014 19:22:45 -0000 At 19:42 17/11/2014, Miles Fidelman wrote: >At the risk of sounding like a broken record... > >This brings us back to: >- the RFP is largely about contractual issues (what replaces the >NTIA contract), and, >- the requirement for open process >- if this is an IAOC matter, then what is the open process for >discussing things that are in the IAOC purview Miles, this seems odd to have to explain that when dealing with network engineers, but what we need is a consensual cultural network among the IETF participants about what we want to see achieved. Then things will work alone being intellectually "meshed", i.e. understood in the same way. Otherwise things will disband, both at the internet governance and at the technology planes. What all this debate shows is the same problem the IETF faces again and again. The IETF is to make the internet work better. What does "better" means? Does it means directed by ICANN, or Govs, or the people's multitude, perfect end to end non-protected transport, confidential traffic? Who is accountable to who (for dogmatic but also for technical reasons)? jfc From nobody Tue Nov 18 06:22:16 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 D5FD11A07BE; Tue, 18 Nov 2014 06:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0CU1rJUmL-C; Tue, 18 Nov 2014 06:22:09 -0800 (PST) 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 CEC301A0687; Tue, 18 Nov 2014 06:22:09 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:38590 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XqjfU-0001vG-2J; Tue, 18 Nov 2014 06:22:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2014 15:21:53 +0100 To: "Leslie Daigle (TCE)" , Marc Blanchet 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/yfNCOvsxeIibLeqidUb46OMyJ3s Cc: "Ianaplan@Ietf. Org" , gene@iuwg.net, "iucg@ietf.org" , IAB , iesg@ietf.org Subject: [iucg] I suppose the IANAPLAN WG-Last Call period is now over 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, 18 Nov 2014 14:22:11 -0000 Dear Chairs, I suppose (1) the last-call period is now over and (2) I went to the decent limit in order to demonstrate that if ...: - after this passed Last-call and the IETF Last-call (where I am not allowed to participate), - this WG deliverable does not properly consider the Internet Users' best interest as the IETF ultimate goal, - in the context of the transfer of the US oversight of the Internet issues from the NTIA to the FCC, - with the consequence that the ICANN freed up, radical monopolistic attempts are not being tempered, - by a credible accountability to either IAB, ITU or a world digital organization, - in regards to names, numbers, missing compacted and maintained standard documentation, and parameters, ... I will determinedly appeal the IESG against this deliverable and will pursue this appeal up to the ISOC level, if necessary. I believe I am on a similar line of thought with: - the IAB and its determination to build another internet, a secure internet, where I believe everyone can seriously protect their VGN (including RosettaNet) - the ISOC and its statement concerning the ICANN involvement in the NETmundial Initiative. - my country and many others. - most of the non-represented people of the world who do not know about the IETF practices but who know about their Internet use best interest. You should certainly report this to the IESG. I thank you for your help, the dedication of Eliot Lear and the contributions of the 57 other participants. jfc From nobody Tue Nov 18 07:03:06 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 372741A03FF; Tue, 18 Nov 2014 07:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0-3EIsKU5GX; Tue, 18 Nov 2014 07:01:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62A711A19F3; Tue, 18 Nov 2014 07:01:51 -0800 (PST) Received: from [IPv6:2620::230:c000:8501:6e7b:a6ca:c769] (unknown [IPv6:2620:0:230:c000:8501:6e7b:a6ca:c769]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C07E94039B; Tue, 18 Nov 2014 10:01:50 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: <20141118142212.109011A06FD@ietfa.amsl.com> Date: Tue, 18 Nov 2014 10:01:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4E80C027-0751-4E47-ADA5-985E504B4471@viagenie.ca> References: <20141118142212.109011A06FD@ietfa.amsl.com> To: JFC Morfin X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/zR8YYGeIVfoY32ds0ZQllwpQxjg Cc: "Ianaplan@Ietf. Org" , "Leslie Daigle \(TCE\)" , IAB , "iucg@ietf.org" , gene@iuwg.net, iesg@ietf.org Subject: Re: [iucg] [Ianaplan] I suppose the IANAPLAN WG-Last Call period is now over 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, 18 Nov 2014 15:02:01 -0000 > Le 2014-11-18 =C3=A0 09:21, JFC Morfin a =C3=A9crit = : >=20 > Dear Chairs, >=20 > I suppose (1) the last-call period is now over yes, since last tuesday, nov 11. > and (2) I went to the decent limit in order to demonstrate that if = ...: >=20 > - after this passed Last-call and the IETF Last-call (where I am not = allowed to participate), everybody is allowed to participate in each last call. Marc. > - this WG deliverable does not properly consider the Internet Users' = best interest as the IETF ultimate goal, > - in the context of the transfer of the US oversight of the Internet = issues from the NTIA to the FCC, > - with the consequence that the ICANN freed up, radical monopolistic = attempts are not being tempered, > - by a credible accountability to either IAB, ITU or a world digital = organization, > - in regards to names, numbers, missing compacted and maintained = standard documentation, and parameters, >=20 > ... I will determinedly appeal the IESG against this deliverable and = will pursue this appeal up to the ISOC level, if necessary. >=20 > I believe I am on a similar line of thought with: >=20 > - the IAB and its determination to build another internet, a secure = internet, where I believe everyone can seriously protect their VGN = (including RosettaNet) > - the ISOC and its statement concerning the ICANN involvement in the = NETmundial Initiative. > - my country and many others. > - most of the non-represented people of the world who do not know = about the IETF practices but who know about their Internet use best = interest. >=20 > You should certainly report this to the IESG. >=20 > I thank you for your help, the dedication of Eliot Lear and the = contributions of the 57 other participants. > jfc >=20 > _______________________________________________ > Ianaplan mailing list > Ianaplan@ietf.org > https://www.ietf.org/mailman/listinfo/ianaplan From nobody Tue Nov 18 07:32: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 8D45D1A1A8E; Tue, 18 Nov 2014 07:32:11 -0800 (PST) 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 Iy4hJpOrqpOO; Tue, 18 Nov 2014 07:32:06 -0800 (PST) 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 EDC591A1A52; Tue, 18 Nov 2014 07:31:55 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:40735 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xqkl0-0007pR-2w; Tue, 18 Nov 2014 07:31:54 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2014 16:31:39 +0100 To: Marc Blanchet From: Jefsey In-Reply-To: <4E80C027-0751-4E47-ADA5-985E504B4471@viagenie.ca> References: <20141118142212.109011A06FD@ietfa.amsl.com> <4E80C027-0751-4E47-ADA5-985E504B4471@viagenie.ca> 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/6hawmjsL8aRdcFlbPBlOMg07r_o Cc: "Ianaplan@Ietf. Org" , "Leslie Daigle \(TCE\)" , IAB , "iucg@ietf.org" , gene@iuwg.net, iesg@ietf.org Subject: Re: [iucg] [Ianaplan] I suppose the IANAPLAN WG-Last Call period is now over 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, 18 Nov 2014 15:32:11 -0000 At 16:01 18/11/2014, Marc Blanchet wrote: > > Le 2014-11-18 à 09:21, JFC Morfin a écrit : > > Dear Chairs, > > > > I suppose (1) the last-call period is now over > >yes, since last tuesday, nov 11. > > > and (2) I went to the decent limit in order to demonstrate that if ...: > > > > - after this passed Last-call and the IETF Last-call (where I am > not allowed to participate), > >everybody is allowed to participate in each last call. Not the IETF Pariah :-) Nevermind, as Gandi said: "First they ignore you, then they laugh at you, then they fight you, then you win." Cordialement jfc >Marc. > > > - this WG deliverable does not properly consider the Internet > Users' best interest as the IETF ultimate goal, > > - in the context of the transfer of the US oversight of the > Internet issues from the NTIA to the FCC, > > - with the consequence that the ICANN freed up, radical > monopolistic attempts are not being tempered, > > - by a credible accountability to either IAB, ITU or a world > digital organization, > > - in regards to names, numbers, missing compacted and maintained > standard documentation, and parameters, > > > > ... I will determinedly appeal the IESG against this deliverable > and will pursue this appeal up to the ISOC level, if necessary. > > > > I believe I am on a similar line of thought with: > > > > - the IAB and its determination to build another internet, a > secure internet, where I believe everyone can seriously protect > their VGN (including RosettaNet) > > - the ISOC and its statement concerning the ICANN involvement in > the NETmundial Initiative. > > - my country and many others. > > - most of the non-represented people of the world who do not know > about the IETF practices but who know about their Internet use best interest. > > > > You should certainly report this to the IESG. > > > > I thank you for your help, the dedication of Eliot Lear and the > contributions of the 57 other participants. > > jfc > > > > _______________________________________________ > > Ianaplan mailing list > > Ianaplan@ietf.org > > https://www.ietf.org/mailman/listinfo/ianaplan From nobody Wed Nov 19 00:46:52 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 C379C1A004D; Wed, 19 Nov 2014 00:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouPwKqssJIXe; Wed, 19 Nov 2014 00:46:48 -0800 (PST) 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 DDC0E1A001D; Wed, 19 Nov 2014 00:46:48 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:58001 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xr0uU-00017S-WA; Wed, 19 Nov 2014 00:46:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Nov 2014 09:46:45 +0100 To: Miles Fidelman , Milton L Mueller From: JFC Morfin In-Reply-To: <546C19A8.2090807@meetinghouse.net> References: <546B8544.5070109@thinkingcat.com> <7d83b91a35ff49ec93efb346dded9f38@EX13-MBX-13.ad.syr.edu> <546C0908.7040103@gmail.com> <546C19A8.2090807@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/ZQvMDJ7VmL9KMCu6dubsKhPhWM0 Cc: "ianaplan@ietf.org" , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Trial balloon: 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: Wed, 19 Nov 2014 08:46:51 -0000 At 05:16 19/11/2014, Miles Fidelman wrote: >>That seems much preferable to committing today to negotiate >>prices with a monopolist. *That* would be irresponsible. > >I've periodically wondered about this. IEEE does an awfully good >job at managing the various registries for the standards they maintain. >(Names and addresses are, of course, different beasts - by the >nature of the volume of data and transactions involved.) Miles, Milton, The IETF is to be consistant. What is discussed is a whole - let call it I*Doc - including names, numbers, documentation and parameters. Parameters are public domain. Documentation is not (subject to BCP 78). I do not know about names and numbers. They are privately owned (except these which belong to parameters) but I suppose their knowledge/use is public domain? Why would IETF pay to get someone to republish something in public domain? So the problem is only BCP 78. And in BCP 78 the provision regarding derivative works (such as IAB's demanded internetsec), what may also aspect special parameters uses. What is needed is a stable format for public domain I*Doc publications that repositories can adapt to their RFC 6852 global market because "we embrace a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status". May I remind you that "in this paradigm standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally. These voluntary standards serve as building blocks for products and services targeted at meeting the needs of the market and consumer, thereby driving innovation. Innovation in turn contributes to the creation of new markets and the growth and expansion of existing markets." This is why the few following things to do are: 1. make "http://iana.arpa" resolve.forever. 2. make ".arpa" reserved in every DNS class. 3. put RFCs and parameters in public domain with the impliction that the use of names and number is free. 4. support information on internetsec at http://internetsec.arpa 5. accustom users to use ".arpa" in makig http://ietf.arpa, http://iesg.arpa, http://irtf.arpa, and http://iab.arpa to also resolve. Then to seat and wait. jfc From nobody Thu Nov 20 09:47:06 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 8DCFE1A07BC; Thu, 20 Nov 2014 09:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmQF4QgiVZM8; Thu, 20 Nov 2014 09:47:00 -0800 (PST) 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 43E381A1AF4; Thu, 20 Nov 2014 09:47:00 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:12313 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XrVon-0006nI-SR; Thu, 20 Nov 2014 09:46:58 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2014 18:46:42 +0100 To: Milton L Mueller ,"rhill@hill-a.ch" , "Leslie Daigle (TCE)" , "ianaplan@ietf.org" From: Jefsey In-Reply-To: References: <546CE040.9030406@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/yDfqqLL6QyOZrsYfeyVJcxLlI-U Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Where (I think) we're at and a final suggestion Re: Trial balloon: 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: Thu, 20 Nov 2014 17:47:01 -0000 At 15:03 20/11/2014, Milton L Mueller wrote: >In other words, the current proposal, if understood as noted above, >does not preclude the strengthened legal and contractual measures >that Richard is calling for, it seems to leave the door open to >them. If I am wrong about that someone please correct me. All this is based neither on the charter nor on reality. It is about contracts/understandings considered as protocols, by protocol engineers, i.e. on the basis of cooperative ends. Modern policy is based upon the opposite approach which is the precautionary principle. Reality is: - http://csis.org/files/publication/141117_Lewis.pdf - http://sendsonline.org/wp-content/uploads/2011/06/Deterring-VNSA-in-Cyberspace-FINAL.pdf - http://www.rand.org/content/dam/rand/pubs/monographs/2009/RAND_MG877.pdf "Cyber attacks are possible only because systems have flaws". As long as architecture is left to engineers who ignore what architectonics may mean, and do not make difference between cyber, digital and numeric, the world is in danger. Russ Housley has engaged two steps in the NTIA planned proper direction in calling for a secure internet and assuming control of ".arpa" were the two prerequistes. I hope this WG's Draft is not going to weaken them. The next step is to make the IANA names, numbers, documentation, and protocol accessible under "http://iana.arpa". Would the IAOC be unable to organize and finance it, we will ask the Libre's community to carry the job and, this way, insure the ICANN accountability to the multitude of the internet users. jfc From nobody Thu Nov 20 11:05:31 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 E98A61A1BEE; Thu, 20 Nov 2014 11:05:29 -0800 (PST) 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 CN0O-hzIV7rp; Thu, 20 Nov 2014 11:05:25 -0800 (PST) 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 9EDE31A1BE4; Thu, 20 Nov 2014 11:05:21 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:13823 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XrX2d-0004I3-Ap; Thu, 20 Nov 2014 11:05:20 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2014 20:05:04 +0100 To: John C Klensin ,Richard Hill From: JFC Morfin In-Reply-To: <4789EB52C3A216945E0AF44A@JcK-HP8200.jck.com> References: <546B8544.5070109@thinkingcat.com> <4789EB52C3A216945E0AF44A@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_60361810==.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/SKM_O9OlVEpkHZZFoc_myxSICtM Cc: "Ianaplan@Ietf.org" , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Trial balloon: 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: Thu, 20 Nov 2014 19:05:30 -0000 --=====================_60361810==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear John and Richard, The Last Call period is over. Now, we are waiting for the Chairs to decide on the Rough Consensus that they observed. Therefore, the IESG can start an IETF Last Call and can make a decision that I will most probably appeal. Being barred from sharing in the IETF Last Call, I am now at ease to organize a Libre involvement in what is to follow. Moreover, circumstances have unexpectedly led to an early friendly fork, while I feared an unfriendly and later one. The questions are: - who will be the final Internet referent to replace the NTIA oversight? - what will be its accountability framework? I hereby identify several candidates. 1. The US arrangement is the FCC. 2. The WEF arrangement seems to be ICANN. 3. The ISOC strategy has to adapt to Fadi's/Rosetta-NETmundial initiative and hesitates. 4. The de facto one is IAB. 5. The ITU-I is the most obvious one if the I*/WEF, etc. people do not agree. 6. A mess. 7. The emergence of a global Rastafarian "overstanding" based on the RFC 6852 paradigm, ITU/USG multistakeholderism, Libre's contribution, multitude's polycracy, etc. The short-term solution is #4. I analyzed the way the IAB can still easily address the situation now. However, the IAB selection mode will not be enough unless the secure internet project takes off and gives technology leaders a respite. However, it is unlikely that the non-secure-internet IETF designer will be trusted very much by the world (nothing to with the people, but with the Tao). IMHO, the long-term solution is #7. The priority is, therefore, a precautionary approach of its emergence mechanism. To reach stability, this mechanism must be in tune with the political evolution and target the completion of the IEN 48 internet project objective, i.e. "to allow new networking technology to be introduced into the existing catenet while remaining functionally compatible with existing systems". There are currently two architectonical visions that I adhere to: - my Intersem proposition of an inter-semiotic network for the whole digital ecosystem (WDE). - Russ Housley's IAB requirement because the Intersem can only be confidential by default. The question that needs to be answered now is which architecture is the best for both of them in considering the currently installed architecture (infrastructure, governance, contracts, and usages) and existing established trends. There is a need for a major improvement for the IANA concept. I extend the concept to what I call the MDRS (the "multiple definitions on record, metadata registry, multilingual distributed referent, etc. system): in order to include a single documentation of reference, to support multilinguality (i.e. the multilingualism cybernetics), to be multitechnology, and most of all to be locally distributed and processed at everyone's machine. Now, what to do? If you want to negotiate, the best thing to do is to take the initiative and build your own independent solution. My target should, therefore, be: A. on the technical side ----------------------------- 1. to maintain an http://iana.zone site replicating the iana.org site. 2. to progressively enhance that site with the help of the community. 3. to use the IUWG as a non-BCP78 restrained Libre (CC BY SA) working site. 4. to initiate an IU experimental Intelligent Use DNS class for IUI (Intelligent Use Interface) interoperations. 5. to foster Libre development/experimentation for my local non-profit Digital Services Providers project and Lab in the: - confidentiality area - MYCANN plug-in - intelligent networking - presentation layer. 6. to discuss and experiment a polycratic governance B. on the political side ---------------------------- 1. to appeal the final IETF position if it does not match our requirements that I stipulated. 2. to develop the FSP4NET (fail safe project for the net) as an operational Libre enhanced coalition (Govs, Industry, CS) This already creates a few things that need to be done. Best jfc At 11:08 19/11/2014, John C Klensin wrote: >--On Wednesday, November 19, 2014 09:56 +0100 Richard Hill > wrote: > > >> 2) In case of future need to transition the operation of the > >> protocol parameters registries from ICANN to subsequent > >> operator(s), this transition will be smooth and have minimum > >> disruption in the use the protocol parameters registries or > >> other resources currently located at iana.org. This > >> arrangement should be comparable to current obligations > >> established under C.7.3 and I.61 of the current IANA > >> functions contract between ICANN and the NTIA [NTIA-Contract]. > > > > I think that we need to add at the end: " and it must allow > > the new IANA functions operator to use the IANA trademark and > > the IANA.ORG domain name." > >Richard, > >I'm glad you said "allow" because anything stronger would make >my somewhat-negative reaction below much more intense. >However... > >That result, independent of text, would be my preference too if >the circumstances were right. However, I think there are just >too many possible scenarios, include splitting up the IANA >function(s), that would make the text you propose more a source >of difficulties and disruptive attempts at hair-splitting (or, >in a different metaphor, baby-dividing) than a help. > >"will be smooth and have minimum disruption in the use [of] the >protocol parameters" seems to me to require availability and use >of the IANA trademark and IANA.ORG for all of the simple cases >because not having them available and using them so would be >much more disruptive. If that is correct, the added text is >potentially useful for some edge cases and, at least IMO, it is >at least as likely to be problematic for other possible cases as >to be a benefit. > >Stated differently, if any major transition in the IANA >functions operator or how those functions are organized is >needed, those who have to deal with it will have to sort out an >array of tradeoffs in which they try to minimize both short-term >disruptions (including service disruptions) while maximizing >long-term stability including references from specifications and >other documents that will not change. Those two objectives >conflict, so there are no obvious answers. I actually predict >some decisions would likely have to be made on a per-registry >basis rather than "for the IANA Function(s)". Because we >cannot predict all of the scenarios, putting in text that could >later constrain or complicate choices seems unwise unless there >is a compelling reason to do so... and I haven't heard or seen >that reason, especially in the light of comments that several of >us have made about how small a portion of the transition >problems things like the IANA name or the domain actually are >likely to be. > >best, > john > > > > > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan --=====================_60361810==.ALT Content-Type: text/html; charset="us-ascii" Dear John and Richard,

The Last Call period is over. Now, we are waiting for the Chairs to decide on the Rough Consensus that they observed. Therefore, the IESG can start an IETF Last Call and can make a decision that I will most probably appeal.

Being barred from sharing in the IETF Last Call, I am now at ease to organize a Libre involvement in what is to follow. Moreover, circumstances have unexpectedly led to an early friendly fork, while I feared an unfriendly and later one.

The questions are:
- who will be the final Internet referent to replace the NTIA oversight?
- what will be its accountability framework?

I hereby identify several candidates.

1. The US arrangement is the FCC.
2. The WEF arrangement seems to be ICANN.
3. The ISOC strategy has to adapt to Fadi's/Rosetta-NETmundial initiative and hesitates.
4. The de facto one is IAB.
5. The ITU-I is the most obvious one if the I*/WEF, etc. people do not agree.
6. A mess.
7. The emergence of a global Rastafarian “overstanding” based on the RFC 6852 paradigm, ITU/USG multistakeholderism, Libre's contribution, multitude's polycracy, etc.

The short-term solution is #4.
I analyzed the way the IAB can still easily address the situation now.
However, the IAB selection mode will not be enough unless the secure internet project takes off and gives technology leaders a respite. However, it is unlikely that the non-secure-internet IETF designer will be trusted very much by the world (nothing to with the people, but with the Tao).

IMHO, the long-term solution is #7.
The priority is, therefore, a precautionary approach of its emergence mechanism. To reach stability, this mechanism must be in tune with the political evolution and target the completion of the IEN 48 internet project objective, i.e. "to allow new networking technology to be introduced into the existing catenet while remaining functionally compatible with existing systems".

There are currently two architectonical visions that I adhere to:
- my Intersem proposition of an inter-semiotic network for the whole digital ecosystem (WDE).
- Russ Housley's IAB requirement because the Intersem can only be confidential by default.
The question that needs to be answered now is which architecture is the best for both of them in considering the currently installed architecture (infrastructure, governance, contracts, and usages) and existing established trends.

There is a need for a major improvement for the IANA concept.
I extend the concept to what I call the MDRS (the "multiple definitions on record, metadata registry, multilingual distributed referent, etc. system): in order to include a single documentation of reference, to support multilinguality (i.e. the multilingualism cybernetics), to be multitechnology, and most of all to be locally distributed and processed at  everyone’s machine.


Now, what to do?
If you want to negotiate, the best thing to do is to take the initiative and build your own independent solution. My target should, therefore, be:

A. on the technical side
-----------------------------

1. to maintain an http://iana.zone site replicating the iana.org site.
2. to progressively enhance that site with the help of the community.
3. to use the IUWG as a non-BCP78 restrained Libre (CC BY SA) working site.
4. to initiate an IU experimental Intelligent Use DNS class for IUI (Intelligent Use Interface) interoperations.
5. to foster Libre development/experimentation for my local non-profit Digital Services Providers project and Lab in the:
    - confidentiality area
    - MYCANN plug-in
    - intelligent networking
    - presentation layer.
6. to discuss and experiment a polycratic governance

B. on the political side
----------------------------

1. to appeal the final IETF position if it does not match our requirements that I stipulated.
2. to develop the FSP4NET (fail safe project for the net) as an operational Libre enhanced coalition (Govs, Industry, CS)

This already creates a few things that need to be done.

Best
jfc

At 11:08 19/11/2014, John C Klensin wrote:
--On Wednesday, November 19, 2014 09:56 +0100 Richard Hill
<rhill@hill-a.ch> wrote:

>> 2) In case of future need to transition the operation of the
>> protocol parameters registries from ICANN to subsequent
>> operator(s), this transition will be smooth and have minimum
>> disruption in the use the protocol parameters registries or
>> other resources currently located at iana.org. This
>> arrangement should be comparable to current obligations
>> established under C.7.3 and I.61 of the current IANA
>> functions contract between ICANN and the NTIA [NTIA-Contract].
>
> I think that we need to add at the end: " and it must allow
> the new IANA functions operator to use the IANA trademark and
> the IANA.ORG domain name."

Richard,

I'm glad you said "allow" because anything stronger would make
my somewhat-negative reaction below much more intense.
However...

That result, independent of text, would be my preference too if
the circumstances were right.  However, I think there are just
too many possible scenarios, include splitting up the IANA
function(s), that would make the text you propose more a source
of difficulties and disruptive attempts at hair-splitting (or,
in a different metaphor, baby-dividing) than a help.  

"will be smooth and have minimum disruption in the use [of] the
protocol parameters" seems to me to require availability and use
of the IANA trademark and IANA.ORG for all of the simple cases
because not having them available and using them so would be
much more disruptive.  If that is correct, the added text is
potentially useful for some edge cases and, at least IMO, it is
at least as likely to be problematic for other possible cases as
to be a benefit.

Stated differently, if any major transition in the IANA
functions operator or how those functions are organized is
needed, those who have to deal with it will have to sort out an
array of tradeoffs in which they try to minimize both short-term
disruptions (including service disruptions) while maximizing
long-term stability including references from specifications and
other documents that will not change.   Those two objectives
conflict, so there are no obvious answers.  I actually predict
some decisions would likely have to be made on a per-registry
basis rather than "for the IANA Function(s)".   Because we
cannot predict all of the scenarios, putting in text that could
later constrain or complicate choices seems unwise unless there
is a compelling reason to do so... and I haven't heard or seen
that reason, especially in the light of comments that several of
us have made about how small a portion of the transition
problems things like the IANA name or the domain actually are
likely to be.

best,
    john





_______________________________________________
Ianaplan mailing list
Ianaplan@ietf.org
https://www.ietf.org/mailman/listinfo/ianaplan
--=====================_60361810==.ALT-- From nobody Fri Nov 21 09:20:41 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 CCCFE1AD57F; Fri, 21 Nov 2014 09:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_40=-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 w67TPg6zjN3a; Fri, 21 Nov 2014 09:20:37 -0800 (PST) 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 ABDEE1AD55D; Fri, 21 Nov 2014 09:20:35 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:33515 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Xrrso-0003Ec-H1; Fri, 21 Nov 2014 09:20:35 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Nov 2014 18:20:17 +0100 To: "Ianaplan@Ietf.org" From: Jefsey In-Reply-To: References: <546CE040.9030406@thinkingcat.com> <9AA4B770-BF63-466A-AED5-87953EBBE96C@cooperw.in> <66ED6659-E70E-481E-A6CF-CF25A68AC46B@gmail.com> <3D6C913A-9D32-47D2-A746-6A6B251F16D9@piuha.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: 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/M4-9SPpYzfpDosAV3gaGiY7slZs Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Where (I think) we're at and a final suggestion Re: Trial balloon: 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, 21 Nov 2014 17:20:39 -0000 In case I do not have to appeal, if we want to meet the Jan 15, 2015 date, since it is likely that this WG will not change its mind and will not fullfil its charter, I also do. Richard, I fully agree with you and the RIRs. The non-secure-protocol stack internet stability calls for a trilateral ICANN, IETF, RIRs contract. However, 1) you saw that this WG, in part due to the particular culture claimed bu its members, is not discussing contracts (based on skeptiscim) but protocols (based on cooperation). The faster we are finished with this misunderstanding, the faster we will be able to address the real world situation. 2) you may have more chances to get support at the IETF Last-Call (moreover I will not be here !) 3) the context of the new-secure-protocol-stack internet will become better known in the coming year. The common best interest is to delay the NTIA transition through clear political moves, that press and politicians understand. An IESG/IAB/ISOC appeal is an example of what is always possible and will be well identified. jfc At 17:33 21/11/2014, Eric Burger wrote: >I do. > > > On Nov 21, 2014, at 10:30 AM, Jari Arkko wrote: > > > > Do you believe that is enough to move forward? I've seen quite a > lot of agreement. > > > > Jari > > > > _______________________________________________ > > Ianaplan mailing list > > Ianaplan@ietf.org > > https://www.ietf.org/mailman/listinfo/ianaplan > > > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan From nobody Mon Nov 24 02:05:00 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 47D1D1A1EFC; Mon, 24 Nov 2014 02:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrjrz0rTR0NN; Mon, 24 Nov 2014 02:04:54 -0800 (PST) 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 E459E1A1EEF; Mon, 24 Nov 2014 02:04:53 -0800 (PST) Received: from 233.20.176.95.rev.sfr.net ([95.176.20.233]:8139 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1XsqVn-0003JZ-HE; Mon, 24 Nov 2014 02:04:52 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Nov 2014 11:04:35 +0100 To: John Curran ,rhill@hill-a.ch From: JFC Morfin In-Reply-To: <6CE44206-3C21-42CE-93E7-D4989F6BF034@istaff.org> References: <6CE44206-3C21-42CE-93E7-D4989F6BF034@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: 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/1L3ZFrtTq_Uku9sGORg68IWveTg Cc: ianaplan@ietf.org, gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] I-D Action: draft-ietf-ianaplan-icg-response-04.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, 24 Nov 2014 10:04:55 -0000 At 15:32 23/11/2014, John Curran wrote: >On Nov 23, 2014, at 4:40 AM, Richard Hill wrote: > > > > Thank you for this. It does reflect the discussions on the list up to 22 > > November. But, on that date, John Curran made a proposal which received > > some support, and, at least so far, no opposition. Unless I am mistaken, > > the proposal is to replace, in Section III, the following text: ... > > > >Actually, I suggested that the WG might want to consider such text, >'if the community felt that "legally binding agreement" was important' One step forward, two steps back. I would not like to be an IAOC negotiator having that kind of public backing! I emphasized already that only a three cross agreement ICANN, IETF, and RIRs coordinated tree (with collaterals' commitments) could web the accountability framework that is necessary for non-secure internet stability. At this stage, it is far too early to know if such a contractual tensegrity can be imagined for the confidentiality oriented and security included stack internet that the IAB wants us to design and operate. Since this WG has decided not to consider the reality of its external world, the only remaining alternative to an NTIA oversight continuation (probably on a decreasing part of the internet - cf. Chinese DNS) would remain (up to the IETF Last-Call, the IESG, IAB and ISOC to eventually decide): - either an ITU-I technical/operational governance initiative that could meet a temporary approval of the USG, OECD, Brazil, WEF, ISOC, Russia, China, and SCO - or(/and progressively) an innovative use (IUse) oriented move by a Libre, Industry, and Govs enhanced coalition based upon the RFC 6852 principles. As it was actually settled at the WSIS in Tunis, if you carefully read the documents, confirmed in Sao Paulo, continued in Geneva by the WEF, by Obama before flying to Beijing and by everyone there. It is now the time to discuss the post-wg/ianaplan issues. Richard, I fail to see why you want the IETF to remain a key contributor. RFC 6852 has documented that it was only a non-directly-innovative part of the protocol community (innovation is from economic competition between global-community-markets). The IETF role is to formalize this innovation. This formalization's consecration was the publication of its parameters in the IANA (cf. UNICODE and their fight to introduce their own langtags). IETF could have retained control: based upon their own experience of their own working ways that they have decided in which they should not retain that responsibility - only to be in capacity to assist in case of conflict. Several made sure that this is really what they want - so we are sure that they will not change their mind after we have patched a fail-safe plan for ourselves. Now, what remains for the IAB to decide is if they will retain an accountability coordination role. They have already partly abdicated it with RFC 6852 in not documenting themselves as an ultimate unique referent in case of appeal. This has allowed ICANN (IoT, Rosettanet, etc.) to develop its own ambitions/responses, what leaves its own accountability in limbo. Actually, we are in 1977 again, but at a higher stratum (not from PTT monopolies to Datacoms competition) but rather from Datacoms complications to Metacoms complexity. This is an interesting time. jfc From nobody Thu Nov 27 08:30: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 E841D1A0084; Thu, 27 Nov 2014 08:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaFI2sf1uv5G; Thu, 27 Nov 2014 08:30:22 -0800 (PST) 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 CD24C1A0074; Thu, 27 Nov 2014 08:30:22 -0800 (PST) Received: from 191.104.176.95.rev.sfr.net ([95.176.104.191]:2678 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Xu1xT-0006e2-N6; Thu, 27 Nov 2014 08:30:20 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Nov 2014 17:30:09 +0100 To: rhill@hill-a.ch,"Marc Blanchet" , ,"Leslie Daigle (TCE)" From: JFC Morfin In-Reply-To: References: <1386C0EC-3EC8-42C0-B94A-F850C93FE391@viagenie.ca> 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/gtfD-Q4VCAEOM01Eq0fa42WuH-0 Cc: gene@iuwg.net, Jari Arrko , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] draft-ietf-ianaplan-icg-response moving to next step 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, 27 Nov 2014 16:30:24 -0000 At 09:57 27/11/2014, Richard Hill wrote: >I note that section 3 of RFC 7282 states: > >"The chair of a working group who is about to find that there is only rough >consensus is going to have to decide that not only has the working group >taken the objection seriously, but that it has fully examined the >ramifications of not making a change to accommodate it, and that the outcome >does not constitute a failure to meet the technical requirements of the >work. ... A valid justification needs to me [sic] made." > >Therefore, I would request that the co-chairs provide a justification for >the conclusion that rough consensus has been achieved. Richard, The way I see the things is rather simple. Vint Cerf has initiated the Internet project with two objectives and a vision. The vision was a new definition of "locality", that one may now qualify of "networked glocality". The first objective was to build its catenet, i.e. its transport stratum. The non completion of the second objective before the USA could swallow it was then discovered (due to architectural lacks vs. deployment advantages) as a national necessity. This has been taken care by the IETF and politically engineered by the USG in - pushing for its technology to be used for the world digital ecosystem main value added network, - using the ICANN single-root lie, - and in keeping the whole thing subject to the1984 born statUS-quo strategy. This was an exceptional process where the USG patched the involved global issues by transferring control from its Legislative branch's domestic/international FCC agency to its Executive NTIA agency. This exceptional situation has come to an end when Obama has directly directed the FCC on Internet neutrality domestic issues. Not the NTIA on global neutrality issues (we know why). Now, time is about an IETF's deliverables domestic/industrial/international review. Feelings are mixed. Theoritically, the IETF has the leadership, and IAB the dominance for a simple reason: the network has to work. IAB is therefore responsible for the past and the future of the Internet. However, many are technologically unhappy (most did not know why, until Snowden's and FCC/Obama's help) and for others they are happy of the money they do. Until August 22, 2012, responsibility was then with the IAB/ISOC. Since then it is to the community of technical communities addressing their community's economic requirements (cf. RFC 6852). Until a week ago responsibility for past and future internet issues was with the IETF. Russ Housley's admonition for an hardened protocol stack makes the IETF only responsible for the future internet. The Chairs' rough consensus shows that among the true "IETF natives" the consensus is that the IETF is working for the future internet, but is not responsible. The question you ask is the basis of my future appeal, once the IETF Last-Call has most probably confirmed this IETF hidden abdication. My point will not be to change it, but to make sure that the IESG, and IAB, and ISOC, fully and publicly declare that they understand, accept and decide that this is what they mean. Please note that this I_D is co-authored by the IAB Chair, former IETF Chair in 2012. This is important because it will show there is no conflict calling for a fork; but an accepted seamless transition from datacommunications to metacommunications. The same as we had that transition in 1977 from telecommunications to datacommunications. I remember the surprise of the ITU people when I went there to adhere as an US Datacommunications Operator :-). jfc