Re: [Ianaplan] feedback regarding the combined proposal

John C Klensin <john-ietf@jck.com> Sun, 09 August 2015 22:52 UTC

Return-Path: <john-ietf@jck.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 5763E1B2A0D for <ianaplan@ietfa.amsl.com>; Sun, 9 Aug 2015 15:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 yztE9mfNoZOD for <ianaplan@ietfa.amsl.com>; Sun, 9 Aug 2015 15:52:00 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B691B2A0C for <ianaplan@ietf.org>; Sun, 9 Aug 2015 15:52:00 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZOZRb-0000nO-9j; Sun, 09 Aug 2015 18:51:55 -0400
Date: Sun, 09 Aug 2015 18:51:50 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, Eliot Lear <lear@cisco.com>
Message-ID: <8C3E7518B3DEEE8C639A83F5@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/jFdDffxMQ-tg-MEAzeyPeq2SdrU>
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>, Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [Ianaplan] feedback regarding the combined proposal
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 09 Aug 2015 22:52:02 -0000


--On Sunday, August 09, 2015 08:11 -0700 Bernard Aboba
<bernard.aboba@gmail.com> wrote:

> On Aug 9, 2015, at 5:41 AM, Eliot Lear <lear@cisco.com> wrote:
>> 
>> If this agreement is in place, great.  That should be stated.
>> If the agreement is not yet in place, then that should be
>> stated in the transition section (Section V) of the ICG
>> summary.
> 
> [BA] The ICG proposal includes requirements for agreements.
> Compared to an actual agreement this is akin to the sound of
> one hand clapping.

Bernard,

As I listen for that particular sound, one additional
observation.  At least in my understanding, the clear intent of
part of the material quoted by Eliot

> It is the preference of the IETF community that, as
> part of the NTIA transition, ICANN acknowledge that it will
carry
> out the obligations established under C.7.3 and I.61 of the
> current IANA functions contract between ICANN and the NTIA
> [NTIA-Contract] to achieve a smooth transition to subsequent
> operator(s), should the need arise.  Furthermore, in the event
of
> a transition it is the expectation of the IETF community that
> ICANN, the IETF, and subsequent operator(s) will work together
to
> minimize disruption in the use of the protocol parameters
registries
> or other resources currently located at iana.org.

was that the above provision apply to any ICANN-related or
ICANN-derived entities created as part of the transition
process.  In particular, it would be inconsistent with that
intent and preference if we found ourselves in a position in
which PTI did not feel the same obligations toward future
possible transitions and minimization of disruption now required
of ICANN and described in those statements.  At least in
common-sense reading, I don't think the current proposal is
sufficiently clear on that subject.

best,
    john