Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

Miles Fidelman <mfidelman@meetinghouse.net> Fri, 07 November 2014 22:22 UTC

Return-Path: <mfidelman@meetinghouse.net>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2F41A1B6B for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 14:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.881
X-Spam-Level:
X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc2cXeW2hYKE for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 14:22:38 -0800 (PST)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id EA05A1A1B5B for <ianaplan@ietf.org>; Fri, 7 Nov 2014 14:22:37 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 70053CC102 for <ianaplan@ietf.org>; Fri, 7 Nov 2014 17:22:37 -0500 (EST)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net
Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JXH38VJVxItZ for <ianaplan@ietf.org>; Fri, 7 Nov 2014 17:22:33 -0500 (EST)
Received: from new-host-3.home (pool-72-93-213-216.bstnma.fios.verizon.net [72.93.213.216]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 12013CC106 for <ianaplan@ietf.org>; Fri, 7 Nov 2014 17:22:32 -0500 (EST)
Message-ID: <545D4627.1050007@meetinghouse.net>
Date: Fri, 07 Nov 2014 17:22:31 -0500
From: Miles Fidelman <mfidelman@meetinghouse.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
MIME-Version: 1.0
CC: ianaplan@ietf.org
References: <GLEAIDJPBJDOLEICCGMNIEOJCNAA.rhill@hill-a.ch> <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> <D0805C27.136BE7%jon.peterson@neustar.biz> <7F52A930-DD6F-4D0D-8278-A021CF8A466C@istaff.org> <D080D78C.136C6E%jon.peterson@neustar.biz> <545B9F8A.6090502@meetinghouse.net> <FB588096-E8EF-4D2D-A504-3B6AE2D591BB@virtualized.org> <545D3CB2.6080905@meetinghouse.net> <CAD_dc6gScJr9QLagG2wA13zc7rQoQLWZ6Nxbo8CQWEWb1TP-cQ@mail.gmail.com>
In-Reply-To: <CAD_dc6gScJr9QLagG2wA13zc7rQoQLWZ6Nxbo8CQWEWb1TP-cQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/w0klCa_97VuRxezQ2xxqKE_oNXo
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 22:22:39 -0000

Seun,

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.
>

I doubt that the o/s is syncing in real time.  I wouldn't be surprised 
though, if, at build/packaging time, the build system does a lookup 
against the iana.org site.  I wouldn't be surprised if other iana.org 
paramter registries are used in similar ways.

> If that domain changes today, it does not take anything other than a 
> update to reflect the new reference url does it?
>

If the URL changes, then auto-build systems will break - and people will 
end up having to figure out what happened, and fix it.  That's 
"disruptive" in my book.

> 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.
>

exactly!

> 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.
>

Currently, IETF is the source of policy and authority, iana.org, as run 
by ICANN is the single source of authoritative data. Seems to me that 
the simplest way to maintain a single source of authority is for the 
ownership of ietf.org to reside with IETF, to be delegated to whatever 
contractor is managing the data at any given time. Completely 
transparent to end-users of the registry.

Do you have an alternative, simpler solution to offer?

Cheers,

Miles

> 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
>
>     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
>


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra