Re: [iucg] [Ianaplan] IANAPLAN virtual meeting

"Leslie Daigle (TCE)" <ldaigle@thinkingcat.com> Tue, 23 September 2014 01:58 UTC

Return-Path: <ldaigle@thinkingcat.com>
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 88EF41A1B8B; Mon, 22 Sep 2014 18:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 NlqFLpF8UNxA; Mon, 22 Sep 2014 18:58:27 -0700 (PDT)
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 6CE871A03A5; Mon, 22 Sep 2014 18:58:27 -0700 (PDT)
Received: from angora-2.local ([::ffff:173.71.212.143]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 22 Sep 2014 21:58:24 -0400 id 00060002.5420D3C1.00006939
Message-ID: <5420D3C0.7000206@thinkingcat.com>
Date: Mon, 22 Sep 2014 21:58:24 -0400
From: "Leslie Daigle (TCE)" <ldaigle@thinkingcat.com>
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: JFC Morfin <jefsey@jefsey.com>, Marc Blanchet <marc.blanchet@viagenie.ca>
References: <EFB23F8E-A8E0-4513-93E2-9D01A165DAE1@viagenie.ca> <20140923004910.C34E1A0647@zoidberg.ecotroph.net>
In-Reply-To: <20140923004910.C34E1A0647@zoidberg.ecotroph.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/zrjz9IxHtT0OOCgxijTWDh26ah8
X-Mailman-Approved-At: Wed, 24 Sep 2014 15:49:40 -0700
Cc: "ianaplan-chairs@tools.ietf.org" <ianaplan@ietf.org>, iab@iab.org, iesg@ietf.org, "iucg@ietf.org" <iucg@ietf.org>
Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iucg>, <mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg/>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 01:58:29 -0000

M. Morfin,

The appropriate time for such substantive suggestions for charter 
changes would have been during the initial WG chartering process.

At this time, the status quo is in fact what the WG is chartered to 
ensure, and what the WG chairs will be pursuing unless or until the IESG 
directs us otherwise.

Leslie.

On 9/22/14 8:07 PM, JFC Morfin wrote:
> At 15:46 22/09/2014, Marc Blanchet wrote:
>> The IANAPLAN WG will hold a 2 hour interim virtual meeting October
>> 6th, 10h00am Eastern. The main agenda item is the first deliverable of
>> the working group, where an individual draft will be discussed and
>> reviewed to be adopted by the working group.
>
> Marc and Leslie,
>
> Prior to this virtual global meeting, I would like to request an
> IANAPLAN IETF/WG charter update in two directions.
>
> A. This charter states both:
>
> 1. "The IANAPLAN working group is chartered to produce an IETF consensus
> document that describes the expected interaction between the IETF and
> the operator of IETF protocol parameters registries." This implies (as
> the context clearly shows it) that a single operator is to be considered.
>
> 2. The working group will assume that the following documents will
> continue to be in effect: ... RFC 6220 - Defining the Role and Function
> of IETF Protocol Parameter Registry Operators.
>
> Point 1 considers a single operator, something that point 2 formally
> contradicts in considering and pertinently documenting the need for
> multiple operators. This calls for a clarification, not only due to the
> demanded contradiction, but because I am most probably not alone among
> Libre and States R&D organizations (RDOs) in planning:
>
> a. to draft within the coming months the description of a general
> internet model,
> - addressing the second motivation of the IEN 48, 1978 Vint Cerf's
> ARPANET internetworking project (better known as the internet project
> embodied by the IETF)
> - that would be compliant with the RFC 6220 text and rationale in
> extending its MDRS (metadata registry system) support of the IEN 48
> first motivation documentation (IANA)
> - to every "new networking technology to be introduced into the existing
> catenet while remaining functionally compatible with existing systems"
> in order to "allow[] for the phased introduction of new and obsolescence
> of old networks without requiring a global simultaneous change".
>
> b. to develop, test, and deploy MDRS tools in order,
> - to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN
> 48 "loose sense" of the local meaning "peculiar to the particular
> network" rather than "a network of limited geographic extent.")
> - to operate their own Information Centers (VGNICs) for the
> Administration of their Names and Numbers (the MYCANN project in my case),
> - at least - outside of any other consideration - in order to have
> available a failsafe plan for their net in case of ICANN failure,
> unaccountable divergence or incapacity to keep coordinated the RFC 6852
> multi-global community landscape.
>
> B. Since 1977, the US (FCC and then NTIA) as a single point of network
> failure was a reliable enough situation that RFC 6852 is dissolving and
> the NTIA is going to terminate on Sept. 30, 2015.
>
> The mission of the IETF is to make sure that the end to end datagram
> exchanges can continue to perform in a the new context "where the
> economics of global markets, fueled by technological advancements, drive
> global deployment of standards regardless of their formal status" so its
> "standards support interoperability [and] foster global competition",
> even in the case they "are [only partly] voluntarily adopted globally".
>
> I do not think this is possible if the Milestones are not reviewed in
> order to permit a seamless transition by Sept. 30, 2015. To that end,
> the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies
> an IETF general final call by April 30, 2015 and WG final call by March
> 31, 2015.
>
> The charter must not appear as an incitement to the status quo while
> criticality is a possibility, and this way to legitimate
> self-organization that is not concerted.
>
> jfc
>
>
> .
>
>
>
>
>
>
>
>
>
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------