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

Jefsey <jefsey@jefsey.com> Wed, 05 November 2014 00:24 UTC

Return-Path: <jefsey@jefsey.com>
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 902451A8742 for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 16:24:41 -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 2ZzaKovxTLLi for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 16:24:40 -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 D6E451A872C for <ianaplan@ietf.org>; Tue, 4 Nov 2014 16:24:40 -0800 (PST)
Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:14670 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from <jefsey@jefsey.com>) id 1XloOt-0004qN-Jz; Tue, 04 Nov 2014 16:24:40 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 05 Nov 2014 01:24:32 +0100
To: Miles Fidelman <mfidelman@meetinghouse.net>, "ianaplan@ietf.org" <ianaplan@ietf.org>
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <54594B3D.4040202@meetinghouse.net>
References: <545944EA.7070903@meetinghouse.net> <GLEAIDJPBJDOLEICCGMNIEOJCNAA.rhill@hill-a.ch> <D07E8620.135F82%jon.peterson@neustar.biz> <54594B3D.4040202@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/ianaplan/dNskYMnqsv1Bype67kFIr3CpqHg
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: Wed, 05 Nov 2014 00:24:41 -0000
X-Message-ID:
Message-ID: <20141105002443.17024.64022.ARCHIVE@ietfa.amsl.com>

At 22:55 04/11/2014, Miles Fidelman wrote:
>If we think such matters are "nonsense," and/or outside our scope of 
>expertise - then, by definition, we should not be the (only) ones 
>addressing them.

Two quotes of RFC 3935 - IETF Mission statement - might be of some 
help IRT this legal and multilateral engineering endeavour?

"Technical competence - the issues on which the IETF produces its 
documents are issues where the IETF has the competence needed to 
speak to them, and that the IETF is willing to listen to technically 
competent input from any source.  Technical competence also means 
that we expect IETF output to be designed to sound network 
engineering principles - this is also often referred to as 
"engineering quality"."

"Protocol ownership - when the IETF takes ownership of a protocol or 
function, it accepts the responsibility for all aspects of the 
protocol, even though some aspects may rarely or never be seen on the 
Internet.  Conversely, when the IETF is not responsible for a 
protocol or function, it does not attempt to exert control over it, 
even though it may at times touch or affect the Internet.'

jfc