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

Alissa Cooper <alissa@cooperw.in> Thu, 18 December 2014 00:12 UTC

Return-Path: <alissa@cooperw.in>
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 130521A007A for <ianaplan@ietfa.amsl.com>; Wed, 17 Dec 2014 16:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 cA7-gch_nFBB for <ianaplan@ietfa.amsl.com>; Wed, 17 Dec 2014 16:12:48 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA931A0041 for <ianaplan@ietf.org>; Wed, 17 Dec 2014 16:12:48 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 30B052069D for <ianaplan@ietf.org>; Wed, 17 Dec 2014 19:12:48 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 17 Dec 2014 19:12:48 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=44IT0b3+ZBEwDrzuSUq/OLTd8ac=; b=vTyeXvZgJgmO4Pnb1gdXD GfUT1GDVpgNAoOwCKhOhWFUPTG9YJAJWg8hEZTjTgRVURCZzgE6m7ofi+69MKkfi 5f8iZ1QBAF9P+FflU0/RtqnLZSxFskWL2TWAHma/gKdHe/+pRwyjEV8ptA+jFj6E 0I6sLQCjOxCpGMfaIerYmE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=44IT0b3+ZBEwDrzuSUq/OLT d8ac=; b=aw+MBVJNv5q/QnN05zxjlQnO3XeX/o9GnoN8upOcM8bSKlwN9ihRX0A VzrE2T1WHQMbxCxKEmwRDTvhGbDxnhwIYuZqEf8erem1I2dYyBDYra68s7b6nK7Y bfN9l7EvwuTBC0M0QMV5WtgMjfrc9lbSZPm58u9I/nO0rr3a65DI=
X-Sasl-enc: uWRCbf7bnA+uD+AxtsVND/UwBhFOztMhUc+fnF7l1MvA 1418861567
Received: from [10.35.132.83] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 9AFC0C00280; Wed, 17 Dec 2014 19:12:46 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <5491FF62.2090708@cisco.com>
Date: Wed, 17 Dec 2014 16:13:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <03C70205-37C9-4070-B899-DF963AB32786@cooperw.in>
References: <20141216203016.30629.80174.idtracker@ietfa.amsl.com> <5490A0F1.3050300@cisco.com> <56079496-4DAE-42B9-AF32-3178FF9610B6@cooperw.in> <5491FF62.2090708@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/Q3_LTGonsIgQ7ehriM2A7Tvn3zc
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: Thu, 18 Dec 2014 00:12:51 -0000

Ok, this all works for me. Thanks.
Alissa

On Dec 17, 2014, at 2:10 PM, Eliot Lear <lear@cisco.com> wrote:

> 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
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan