Re: [Ianaplan] Alissa Cooper's Yes on draft-ietf-ianaplan-icg-response-06: (with COMMENT)

Eliot Lear <lear@cisco.com> Wed, 17 December 2014 22:11 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 EE3C71A8781; Wed, 17 Dec 2014 14:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 8UaBD9tSVg1I; Wed, 17 Dec 2014 14:11:09 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF6F1A87D0; Wed, 17 Dec 2014 14:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4858; q=dns/txt; s=iport; t=1418854268; x=1420063868; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qQYGJ09+9WGdoQPAf/a7UxDNwGM21Qk+0LcaGn0MU0w=; b=KveKQ2YNvRnrHs3P3Ko4EVWin+wRlXzO0fX1Pq62Vzm+0tT2swoRNm/0 yseMDW7pp54xxzN+2yBrz6Xh2QKQAdPHeJU31hchJ5nP3PXe+JosCQnTq HJ1zdI3R+nBZfXSIGG/HPFhZ8kW3K9PYPMU/8E6ct5hP8HKbPjZfx8Ygn s=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcFAJ7+kVRIo8UY/2dsb2JhbABag1hYgwbCe4VyAoE5AQEBAQF9hA0BAQQdBksEBgEQCxgJFgsCAgkDAgECAUUGDQEFAgEBiCgNvl2WNQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3IHgmiBQQWPUoEnTYUygQuCYYIQIYdrgzgigjCBPT0xgkMBAQE
X-IronPort-AV: E=Sophos;i="5.07,596,1413244800"; d="asc'?scan'208";a="48541556"
Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 17 Dec 2014 22:11:04 +0000
Received: from [10.61.211.230] ([10.61.211.230]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBHMAm6t023014; Wed, 17 Dec 2014 22:10:48 GMT
Message-ID: <5491FF62.2090708@cisco.com>
Date: Wed, 17 Dec 2014 23:10:42 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Alissa Cooper <alissa@cooperw.in>
References: <20141216203016.30629.80174.idtracker@ietfa.amsl.com> <5490A0F1.3050300@cisco.com> <56079496-4DAE-42B9-AF32-3178FF9610B6@cooperw.in>
In-Reply-To: <56079496-4DAE-42B9-AF32-3178FF9610B6@cooperw.in>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="lvnLuErxWoASMAMkw7bvesT1qToQtCJiQ"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/jSPqUmbl0ivRHBbfSCv4hUEZiTs
Cc: ianaplan@ietf.org, ianaplan-chairs@tools.ietf.org, draft-ietf-ianaplan-icg-response.all@tools.ietf.org, IESG <iesg@ietf.org>, ajs@anvilwalrusden.com
Subject: Re: [Ianaplan] Alissa Cooper's Yes on draft-ietf-ianaplan-icg-response-06: (with COMMENT)
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, 17 Dec 2014 22:11:11 -0000

Hi Alissa,

On 12/17/14, 10:40 PM, Alissa Cooper wrote:
> Hi Eliot,
>
> On Dec 16, 2014, at 1:15 PM, Eliot Lear <lear@cisco.com> wrote:
>>> --
>>>
>>> "Please also see the references at the bottom of this document."
>>>
>>> This seems too vague. There are many references at the bottom of the
>>> document, not all of which are relevant to answering the RFP question
>>> about policy development and dispute resolution. It seems like this
>>> sentence could be deleted.
>> Amusingly nearly all of the (now normatively) referenced RFCs are
>> process documents.  I would be happy to modify the sentence to indicate
>> that.
> I think the reader of this text should be able to locate the specific list of references that document our policy development and dispute resolution processes. Whether that is done directly or by reference does not matter, but the list should be specific.

Ok, I'd go with your original suggestion, and it also follows Housley's
rule of the job is done when one can remove no more text.

>
>>> --
>>>
>>> s/with the same affiliation/with the same employment affiliation/
>> I went back to RFC 3777 to check this.  Strictly speaking it's not
>> necessarily employment.  It could be contractual, for instance.  How
>> this is defined is left to the honor of participants.  But perhaps I'm
>> looking at the wrong reference.  In any event, I would propose retaining
>> the statement as is.
> I suggested this because many readers of this document might have a broader understanding of the word “affiliation” (e.g., nationality or interest group) than what is used for IETF nomcom purposes. So I think it would help to make it more specific while still being accurate. Employment or contractual affiliation?

Yes, I understood your point.  But if RFC 3777 does not go there, I
don't think we should either.

>
>>> --
>>>
>>> "Especially when relationships
>>>   among protocols call for it, many registries are operated by, or in
>>>   conjunction with, other bodies."
>>>
>>> I think this would be clearer if it said "Especially when relationships
>>>   among protocols call for it, many registries are operated by with
>>> input and coordination from other bodies." The "operated" verb is
>>> otherwise confusing when read together with the sentence that follows.
>> In this case I believe the word "operated" is consistent with the word
>> "operator" in the next sentence.  The examplar is e164.arpa, which is
>> operated by RIPE.  It would not be correct to indicate that they just
>> provide input.  However, perhaps the real confusion is the word
>> "bodies"?  Maybe s/bodies/organizations/?
> I think the problem is “many.” Compared to how many registries are operated by ICANN, there are not “many” registries operated by other bodies. I would suggest:
>
> "Especially when relationships among protocols call for it, registries are at times operated by, or in conjunction with, other bodies.”

Fair point.  Propose to accept your change.
>
>>> --
>>>
>>> In addition to Adrian's suggestion, I think the response to Section VI of
>>> the RFP needs these direct links:
>>>
>>> IANAPLAN WG: https://datatracker.ietf.org/wg/ianaplan/charter/
>> This is present in the announcement of the working group.
> I think it warrants a direct link.
>
>>> Agenda from IETF 91: https://tools.ietf.org/wg/ianaplan/agenda
>>> Minutes from IETF 91: https://tools.ietf.org/wg/ianaplan/minutes.
>> I propose to include the above links.
>>> Agenda from the interim meeting: <fill in>
>>> Minutes from the interim meeting: <fill in>
>> I do not have pointers for these, but would happily include them if
>> someone else has them.
> They are available in the mailing list archive if not anywhere else.

Found'em.

Eliot