Re: [Ianaplan] draft-ietf-ianaplan-icg-response-02 working group last call

Eliot Lear <lear@cisco.com> Wed, 05 November 2014 15:55 UTC

Return-Path: <lear@cisco.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 BF4231A898D for <ianaplan@ietfa.amsl.com>; Wed, 5 Nov 2014 07:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kJVciNgAaM_8 for <ianaplan@ietfa.amsl.com>; Wed, 5 Nov 2014 07:55:24 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0641A8988 for <ianaplan@ietf.org>; Wed, 5 Nov 2014 07:55:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5403; q=dns/txt; s=iport; t=1415202923; x=1416412523; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=EyDgRyrxk08NEovu8Bj1yddY+UQJWdW8y4mJeTocRHA=; b=fCVD7m1f74AUDxnduMSTOCXANaXrwxiwedFsvxEUHlcudTArzh2z1TZl Ptr3DnsFVnZx2Elm9bNcH7MxkesnMQF6knm1FtrXr2FS1e0s9QJ9iURbX lSyPgstJHwbt+goC+fznMlhRfKT7NF7RnZEHrtcDtjPlwsJl/d720Q6cE 8=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArMEAPdGWlStJssW/2dsb2JhbABch0HRZQKBLgEBAQEBfYQDAQEDASNVEQsOExYLAgIJAwIBAgFFBgEMCAEBEIgkCbU+lSMBAQEBAQEBAwEBAQEBAQEBGpEYgneBVAWLe4g9gVKIBoExhkM7ih2ECYQZHIJ6AQEB
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="asc'?scan'208";a="231501295"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Nov 2014 15:55:20 +0000
Received: from [10.154.176.54] ([10.154.176.54]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sA5FtJA0017168; Wed, 5 Nov 2014 15:55:19 GMT
Message-ID: <545A4866.7050807@cisco.com>
Date: Wed, 05 Nov 2014 07:55:18 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ianaplan@ietf.org
References: <6ACE138D-0969-4D8F-9A64-3D1FBB96885A@viagenie.ca> <20141105010258.GB30186@mx1.yitter.info>
In-Reply-To: <20141105010258.GB30186@mx1.yitter.info>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="LcC8hrFnXXWuSjlkJlI9qV6AbalxpUO4b"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/nCxgU4SRhA9iMuSrkdrNpwu9Tm4
Subject: Re: [Ianaplan] 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 15:55:27 -0000

Hi Andrew and thanks for your review.  Responses in line.

>
> p 3:
>
>     containing the parameter values and a pointer to
>    documentation of the associated semantic intent.
>
> This is slightly problematic, because there are registry entries for
> things that explicitly do _not_ have semantic intent.  For instance,
> the private-use ranges in many protocols are available in the
> registry, but their purpose ie explicitly to have no semantics. I'd
> suggest "and a pointer to associated documentation".  I don't feel
> strongly about this comment; it just seems cleaner.

I propose to accept this change, barring any objections.  I am, however,
growing concerned that someone from the outside not actually get a good
view as to what a protocol parameter really is with our current text.  I
don't want an RFP response to turn into a tutorial, but perhaps we need
one more clear sentence to really make the point.

>
> Also p 3:
>  
>    The IANA protocol parameters registries operator maintains the
>    protocol parameters registries for the IETF in accordance with all
>    relevant IETF policies, in accordance with the Memorandum of
>    Understanding[RFC2860] and associated supplemental agreements that
>    include service level agreements (SLAs) established between the IETF
>    and ICANN[MOUSUP].
>
> This is a nit, but "in accordance" there starts to show up a lot.  How
> about, "for the IETF in conformance with all relevant…"?

I propose to accept this change, barring any substantial objection, as
it improves readibility.

>
> p 6:
>
>    there is sufficient interest, the Internet Engineering Steering Group
>    may choose to create a working group or an Area Director may choose
>    to sponsor the draft.
>
> I think insert a sentence, "Alternatively, the proposal may be in an
> area of work already chartered as an existing working group, and the
> working group may choose to take up the proposal."  I think someone
> (Suzanne?) already suggested something along these lines.

I think from a flow standpoint we would want to invert that, but the
point is well taken.  What I propose is the following:

        ... Anyone may submit such a
        proposal.  If there is sufficient interest, a working
        group whose scope includes the proposed work may choose to
        adopt it, the Internet Engineering Steering Group may
        choose to create a working group, or an Area Director may
        choose to sponsor the draft.  In any case, anyone may
        comment on the proposal as it progresses.
>
> p 8:
>
>    sent to the Internet Society Board of Trustees for confirmation.  In
>    general, members serve for two years.  The IAB selects its own
>    chair.
>
> This makes it sound like most IAB members serve for only two years.
> How about, "In general, members are appointed for terms of two years;
> they may be reappointed.  The IAB selects…"

I propose to accept this change because it makes the text more clear.

>
> p 10:
>
>    No major changes are required, however, the IETF community has
>    expressed a desire for several points to be addressed by supplemental
>    agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA
>    regime.  Over the years since the creation of ICANN, the IETF, ICANN,
>    and IAB have together created a system of agreements, policies, and
>    oversight mechanisms that covers what is needed.
>
> This ¶ is hard for me to understand.  The propositions I read here
> are, 1. No major changes; 2. Some additional points are needed in
> supplemental agreements; 3. We have a system of agreements that covers
> what's needed.  This seems incoherent.  (1) restricts the scope of (2)
> but (3) seems contradictory to (2).
>
> I agree with Alissa, moreover, that specifying exactly how the IAOC
> has to implement the desire of the WG is going a little too far.  I'm
> not even sure that IETF needs the supplemental agreement for the items
> 1 and 2 at the bottom of the page to be in effect.  In addition I
> wonder whether (2) is simply redundant to (1).  I am aware that I'm
> probably in the rough on this.  I also remain extremely dubious of the
> value of the "jurisdiction" stuff, and am not in favour of it.

This issue remains open, and I propose to address it separately.

Thanks again for your comments,

Eliot