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

Milton L Mueller <mueller@syr.edu> Mon, 10 November 2014 15:08 UTC

Return-Path: <mueller@syr.edu>
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 81C531A903E for <ianaplan@ietfa.amsl.com>; Mon, 10 Nov 2014 07:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.494
X-Spam-Level:
X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 1rkjESP_BuGr for <ianaplan@ietfa.amsl.com>; Mon, 10 Nov 2014 07:08:27 -0800 (PST)
Received: from smtp2.syr.edu (smtp2.syr.edu [128.230.18.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2401A903B for <ianaplan@ietf.org>; Mon, 10 Nov 2014 07:08:26 -0800 (PST)
Received: from EX13-MBX-16.ad.syr.edu (ex13-mbx-16.ad.syr.edu [128.230.108.156]) by smtp2.syr.edu (8.14.7/8.14.7) with ESMTP id sAAF8Ofo007147 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Nov 2014 10:08:24 -0500
Received: from EX13-MBX-13.ad.syr.edu (128.230.108.144) by EX13-MBX-16.ad.syr.edu (128.230.108.156) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 10 Nov 2014 10:08:23 -0500
Received: from EX13-MBX-13.ad.syr.edu ([128.230.108.144]) by EX13-MBX-13.ad.syr.edu ([128.230.108.144]) with mapi id 15.00.0847.030; Mon, 10 Nov 2014 10:08:12 -0500
From: Milton L Mueller <mueller@syr.edu>
To: "'\"Martin J. Dürst\"'" <duerst@it.aoyama.ac.jp>
Thread-Topic: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
Thread-Index: AQHP960u8Q3qkgXVCEGyOQLXbJCufpxPyGuAgAA0/ACAAADXAIAAAw4AgACLogCAACs6gIAAQCaAgAA80ACAAAfPgIAACgwAgAAESYCAAAOpgIAAAgIAgAAA6YCAAAWHAIAAKOGAgAASLoCAAErKAIAAeYcA///QxKCAAF0DAIAAEmbAgABygACAAAd4AIAAEC6AgABvMACAAdrLgIAAcS4AgAFb7wCAAAQkgIAADh8AgACEXwCAAAg3AIAAOEaAgAAP1ACAACe2AIAAXVqAgAAlooCAAFL2AIAAB8sAgAAOdACAAKMWAIAAKJEw
Date: Mon, 10 Nov 2014 15:08:11 +0000
Message-ID: <967bd4c3d170439f92555000d7b18331@EX13-MBX-13.ad.syr.edu>
References: <631e3e3d29c843bd9c23151c63612989@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> <059f2b06a7b44f09b7568d8966861fb8@EX13-MBX-13.ad.syr.edu> <D0824FAD.137A42%jon.peterson@neustar.biz> <E314302D-5179-4899-9DB7-A3AF18C134E8@gmail.com> <20141108155153.GB37292@mx1.yitter.info> <D083864D.138D18%jon.peterson@neustar.biz> <A6D94EF5-BD92-4080-8C18-E415B D0BB880@isi.edu> <C78A1523-316F-46A1-9FCE-D0D205679C84@gmail.com> <13B26DE5-315D-453F-B89B-377CCD338ED9@isi.edu> <A7BD5ECF-11E4-42F1-A2B7-BF9B399635C3@gmail.com> <14D42443-53E7-49FA-88DD-7F4BB6BC2DF4@istaff.org> <545F69FB.5000501@meetinghouse.net> <7B719509-5A93-4B85-B7E2-262DDCB64461@istaff.org> <D0850842.138E23%jon.peterson@neustar.biz> <85D607E0-4D3A-499E-87D1-036E0349D80E@gmail.co m> <CBBA1B51-145B-407D-A7E0-0E8CA7F7EFAF@istaff.org> <54606A9C.6040700@it.aoyama.ac.jp>
In-Reply-To: <54606A9C.6040700@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.230.182.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-11-10_03:2014-11-10,2014-11-10,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411100117
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/sYTbEjnyZUpNL9DWDK0QqfONWIM
Cc: "'ianaplan@ietf.org'" <ianaplan@ietf.org>
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: Mon, 10 Nov 2014 15:08:29 -0000


> -----Original Message-----
> 
> > On Nov 9, 2014, at 10:59 AM, Bernard Aboba
> <bernard.aboba@gmail.com> wrote:
> >>
> [BA] A good portion of the complexity here is we are talking about a
> domain name and trademark that is relevant to multiple communities.

That sounded reasonable at first, but when I think about the names community, or at least the ongoing process of RZF management and modifications, I see little reason why they would care about the IANA domain or trademark per se. 
I could see why the numbers community cares about the .arpa domain, but not so much the IANA domain. 
Perhaps the IETF _is_ the best place for those resources to live. 

[MD] 
> Quite correct - the IANA mark and domain appears relevant to the
[snip] 
> Internet number community due to the publication of delegated
> number registries per RFC7020 and RFC7249; and to the DNS community due
> to their use with respect to administration of one particular protocol
> registry, i.e. the DNS root zone.
> 
> This actually points to a solution for at least part of the problem of
> what to do in the odd case that these communities would delegate
> their registries to different operators:
> 
> One community (or its registry operator) operates iana.org, and
> redirects the relevant pages for the registries of the other operators to
> the actual pages. As an example, if the protocol parameters registry
> kept iana.org, it would delegate (almost?) everything below
> http://www.iana.org/domains to the DNS community, and so on.
> 
> Such a delegation can be made as an internal redirect (the actual
> data/pages come from elsewhere, but are served by iana.org) or as an
> external redirect (if somebody goes to e.g.
> http://www.iana.org/domains, then s/he's redirected to the site of
> the other operator).
> 
> This shows that having different organizations take care of the
> different registries and still sharing iana.org is possible. This of course
> requires that they agree to do that.
> 
> But my guess is that agreeing to share iana.org is much easier that to
> agree e.g. about reserved labels (such as .local) in the root zone. The
> later is crucial for the functioning of the Internet, and if that can be
> agreed on, then an agreement on the former should also be possible.
> 
> So I very much think that the question of "But what if the registry
> operator function is split up?" cannot be used as an argument for not
> talking about the trademark and domain name transfer.

Interesting approach. Sounds feasible to me.