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

"Peterson, Jon" <jon.peterson@neustar.biz> Fri, 07 November 2014 23:07 UTC

Return-Path: <jon.peterson@neustar.biz>
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 B901E1A1A57 for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 15:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level:
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Fv99Mks0JnqW for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 15:07:15 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 BAA7C1A1A96 for <ianaplan@ietf.org>; Fri, 7 Nov 2014 15:07:14 -0800 (PST)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sA7MrUnA012164; Fri, 7 Nov 2014 18:07:12 -0500
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1qh5sdg4v7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 07 Nov 2014 18:07:11 -0500
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 18:07:11 -0500
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: John Curran <jcurran@istaff.org>
Thread-Topic: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
Thread-Index: AQHP960iQbkZx6Ao80Cv4+wEz5Ij95xPyGuAgAA0/ACAAADXAIAAAw4AgACLogCAACs6gP//uiCAgADC1gCAAAfPgIAACgwAgAAESoD//32igIAAiAgAgAAA6YCAAAWHAIAAKOGAgAASLoCAAErKAIAAeYgAgAAktgCAAAkQAIAAaaqAgAAbPACAAAd4AIAAZEGA//+U/oAAVsNggP//ld8AgACgnQD//5QagIAAiHGA//989oCAAI1YAP//f+UA
Date: Fri, 07 Nov 2014 23:07:10 +0000
Message-ID: <D0828DA8.137EFD%jon.peterson@neustar.biz>
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> <059f2b06a7b44f09b7568d8966861fb8@EX13-MBX-13.ad.syr.edu> <D0824FAD.137A42%jon.peterson@neustar.biz> <bcb86b6995de41feba256567c114265d@EX13-MBX-13.ad.syr.edu> <D0826BB8.137BBD%jon.peterson@neustar.biz> <545D42ED.3010201@cisco.com> <D08284A2.137E31%jon.peterson@neustar.biz> <96ABCDA5-74A9-4930-B1D6-5A0119802457@istaff.org>
In-Reply-To: <96ABCDA5-74A9-4930-B1D6-5A0119802457@istaff.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [192.168.128.84]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <45F841F8B9C0D04A8AC23FFE255033A9@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7615 signatures=670576
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.8393425671448e-10 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.997275880753101 urlsuspect_oldscore=0.997275880753101 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.997275880753101 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411070193
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/ehOMc0lwMx71rOHWp5ihNwGFGX8
Cc: Milton L Mueller <mueller@syr.edu>, Miles Fidelman <mfidelman@meetinghouse.net>, Eliot Lear <lear@cisco.com>, "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: Fri, 07 Nov 2014 23:07:22 -0000

Probably language along these lines is viable, sure. This sounds much in
the same spirit as the Alissa/Eliot text regarding "backwards
compatibility." My ear does twitch a little at the "ongoing cooperation in
the use of the IANA domain name and marks," in so far as I'm not sure that
I'd call the administration of the IANA domain name today "cooperative,"
though certainly our use of the IANA function is. Similarly, there must be
a legal dimension (Eric Burger, you listening, man?) to our use of "IANA
Considerations" in RFCs that has some bearing on IANA as a trademark, but
I'd hesitate to stake an IETF consensus position on that.

Jon Peterson
Neustar, Inc.

On 11/7/14, 2:45 PM, "John Curran" <jcurran@istaff.org> wrote:

>On Nov 7, 2014, at 2:19 PM, Peterson, Jon <jon.peterson@neustar.biz>
>wrote:
>> 
>> Heh. I am not insisting that iana.org MUST NOT be transferred to the
>>IETF
>> Trust. Honestly, I think it would be a hassle for us at the end of the
>> day, but if for some reason that is the best outcome for the Internet
>> community, there would be no grounds to prohibit it. I'm just saying
>>that
>> for the purposes of this document, I don't want our ICG response to ask
>> for it, and certainly not to demand it.
>
>Jon - 
>
>  Would you object to the IETF's ICG response proposing (under Section
>III)
>  that "there needs to be a mechanism providing for ongoing cooperation
>  in the use of the IANA domain name and marks, supporting usage by the
>  IETF as they are presently used for the protocol parameter registries."
> ?
>
>  That would appear to be quite a different statement than proposing that
>  something must be transferred, but still allows identification of the
>  potential issue.
>
>Thoughts?
>/John
>
>Disclaimer: My views alone
>
>