Re: [Ianaplan] Spencer Dawkins' Yes on draft-ietf-ianaplan-icg-response-06: (with COMMENT)
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 18 December 2014 04:59 UTC
Return-Path: <spencerdawkins.ietf@gmail.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 8170B1A01AA; Wed, 17 Dec 2014 20:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 2C9S_V-O36Pt; Wed, 17 Dec 2014 20:59:32 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629B21A01A5; Wed, 17 Dec 2014 20:59:31 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id p9so347892lbv.35; Wed, 17 Dec 2014 20:59:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d9M5olFnOyskERmtQoDdLj2czDP+7ZaLVttpjzoUwUw=; b=W59bXdFZz49CFmQyKSXkrAWiY0NhfrT5yEppTVnA0TbVryC2OogtV3J9P8xWdUhxgA ybYkMUK0U0pDe91H0VuQrgmuigY5G1SbvTNIGwFZURlepQ1gI1r4p9SQc9NU3xIyym36 IEijz5t+w2k6CeBHh0/hzzvGjqkSEJZvnYOQgbnGmwEskpvVL49BawzQfpbmmJGMtDMt pW0A0SEweUgUT6YLwt5SU+UPaVpAA8Ai2fE6pYvwjcFOdITfw5uRPnQ6fEn8+oFDykfw BcrOYd6C9UDpPutKEqsHmLvntYPq0ylXrCf05ayPtZ1ehvYJ+dhVn+2Nyt5IvY6da3n4 6Y+w==
MIME-Version: 1.0
X-Received: by 10.112.168.97 with SMTP id zv1mr243591lbb.6.1418878769808; Wed, 17 Dec 2014 20:59:29 -0800 (PST)
Received: by 10.152.185.195 with HTTP; Wed, 17 Dec 2014 20:59:29 -0800 (PST)
Received: by 10.152.185.195 with HTTP; Wed, 17 Dec 2014 20:59:29 -0800 (PST)
In-Reply-To: <549130EE.7090909@cisco.com>
References: <20141216191352.790.95915.idtracker@ietfa.amsl.com> <549130EE.7090909@cisco.com>
Date: Wed, 17 Dec 2014 22:59:29 -0600
Message-ID: <CAKKJt-d4io_WnJD2sMuG=UAWJ3t3XPNkapBBcaqFXq-7XydmNQ@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c341c80dcd45050a767505"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/BaV-55mIFGEIZUnVzGFeVjXopVU
Cc: ianaplan@ietf.org, ianaplan-chairs@tools.ietf.org, draft-ietf-ianaplan-icg-response.all@tools.ietf.org, iesg@ietf.org, ajs@anvilwalrusden.com
Subject: Re: [Ianaplan] Spencer Dawkins' 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 04:59:37 -0000
Top posting, because I'm only saying "thank you for working through my last-second comments!" Spencer On Dec 17, 2014 1:29 AM, "Eliot Lear" <lear@cisco.com> wrote: > Hi Spencer and thanks for your comments. Please see below. > > On 12/16/14, 8:13 PM, Spencer Dawkins wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for taking this task on. > > > > I have a bunch of minor suggestions. The editors are welcome to tell me > > the text has already been heavily tweaked, so I should shut up, and I'm > > already a Yes ("do the right thing"). > > > > After looking at this draft, I'm even less impressed with the way we cite > > BCPs than I was yesterday, but that's an IESG problem, and probably > > doesn't affect balloting for this draft (no editor action required). > > > > In this text: > > > > Abstract > > > > This document contains the IETF response to a request for proposals > > from the IANA Stewardship Transition Coordination Group regarding the > > protocol parameters registries. It is meant to be included in an > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > aggregate proposal that also includes contributions covering domain > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > names and numbering resources that will be submitted from their > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > respective operational communities. The IETF community is invited to > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > comment and propose changes to this document. > > > > This sentence didn't parse easily for me, and I think the problem was > > just being too passive and indirect. Perhaps something like this: > > > > Abstract > > > > This document contains the IETF response to a request for proposals > > from the IANA Stewardship Transition Coordination Group regarding the > > protocol parameters registries. The IETF response will be included in > > an > > aggregate response, along with contributions covering domain names and > > > > numbering resources from the operational communities responsible for > > those > > resources. The IETF community is invited to comment and propose > > changes to > > this document. > > I have proposed a new abstract to Adrian in a previous message that > reads as follows: > > The U.S. NTIA has solicited a request from ICANN to propose > how the NTIA should end its oversight of the IANA functions. > After broad consultations, ICANN has in turn created the IANA > Stewardship Transition Coordination Group. That group > solicited proposals for thre three major IANA functions: > names, numbers, and protocol parameters. This document > contains the IETF response to that solicitation for protocol > parameters. It is meant to be included in an aggregate > response to the NTIA alongside those for names and numbering > resources that are being developed by their respective > operational communities. > > > > In this text: > > > > 1. IETF Introduction > > > > Note that there are small changes to the content of the questions > > asked in order to match the RFC format. > > > > As if to demonstrate the last point, the following text was included > > in a footnote in the original RFP: > > > > I don't understand how the following text demonstrates "the last point" > > about small changes to the content of the questions. Were I to guess, my > > guess would be "this was a footnote, but RFCs don't have footnotes, so we > > dragged the text into the body of the document". Did I get it? > > You're not the only one to have trouble with my whimsical comment. > Proposed rewrite is as follows: > > We note that the following text was stated as footnote in the > original RFP: > > > > In this text: > > > > 2. The Formal RFP Response > > > > >>> > > >>> 0. Proposal Type > > >>> > > >>> Identify which category of the IANA functions this > > >>> submission proposes to address: > > >>> > > > > IETF Response: > > [XXX] Protocol Parameters > > > > > > > > This response states the existing practice of the IETF, and also > > represents the views of the Internet Architecture Board and the IETF. > > > > Is ^this paragraph part of the IETF Response, or an observation? I'm > > probably confused by how the "IETF Response:" line is indented. The next > > "IETF Response:" line isn't indented as much, and if this line was > > indented the same way, I'd definitely read the paragraph as part of the > > IETF Response. > > Thank you. I've corrected the indent. > > > > > > FOR THE IESG, no author response required: You have to love this > > description of BCP9 ... > > > > The Internet Standards Process is documented in [RFC2026]. That > > document explains not only how standards are developed, but also how > > disputes about decisions are resolved. RFC 2026 has been amended a > > number of times, and those amendments are indicated in [RFC-INDEX]. > > ^^^^^^^^^ > > > > Is this the best we can ask authors to do in a document that is going to > > people who don't read RFCs for a living? I'm afraid the answer from the > > IESG may be "yes" ... > > For your information, this came up in a LC comment from Brian Carpenter, > and the reference is now to point to > http://www.rfc-editor.org/info/rfc2026. > > > > > In this text: > > > > It is important to note that the IETF includes anyone who wishes to > > participate. Staff and participants from ICANN or the Regional > > Internet Registries (RIRs) regularly participate in IETF activities. > > > > I was somewhat confused about whether this is about who the IETF allows > > to participate, or about the definition of the "the IETF". Given that > > you're trying to describe who's included in non-member organization, > > perhaps this could be something like: > > > > It is important to note that the IETF does not have formal > > membership. > > The term "the IETF" includes anyone who wishes to participate in the > > IETF, > > and IETF participants may also be members of other communities. Staff > > and > > participants from ICANN or the Regional Internet Registries (RIRs) > > regularly participate in IETF activities. > > > > The working group did work on this text. However, I believe you have > raised an important point that is not clearly covered elsewhere in the > document. As such I propose replacing the current text with what you > have stated. > > IN this text: > > > > o The routing architecture has evolved over time, and is expected to > > continue to do so. Such evolution may have an impact on > > appropriate IP address allocation strategies. As and when that > > ^^^^^^^^^^^ > > happens, we will consult with the RIR community, as we have done > > in the past. > > > > "As and when" reads roughly to me. Perhaps "As", or perhaps "If and > > when"? > > I agree that "If" is better than "As". > > > > > FOR THE IESG: In this text: > > > > The IAB members are selected and may be recalled through a Nominating > > Committee (NOMCOM) process, which is described in [RFC3777]. > > > > The use of one RFC as shorthand for a multi-RFC BCP in this case is > > problematic, and this text doesn't even give the hand-waving "by the way, > > that RFC has been updated, and you can probably find the updates in the > > RFC-INDEX" that previous instances included. > > I propose to add "and its updates" after the reference. We already > mention RFC-INDEX. > > > > In this text: > > > > The IAB provides oversight of the protocol parameters registries of > > the IETF, and is responsible for selecting appropriate operator(s) > > and related per-registry arrangements. Especially when relationships > > among protocols call for it, many registries are operated by, or in > > conjunction with, other bodies. Unless the IAB or IETF has concluded > > that special treatment is needed, the operator for registries is > > currently ICANN. > > > > I don't think the last sentence is right. Is it correct to say "ICANN is > > currently the operator for all registries, except for specific registries > > where the IAB or IETF has concluded that special treatment is needed"? > > The current text reads like ICANN as the operator is all or nothing. > > Here I don't really see the difference. > > > > In this text: > > > > We think the structures that sustain the protocol parameters > > registries function need to be strong enough that they can be offered > > independently by the Internet technical community, without the need > > for backing from external parties. And we believe we largely are > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > there already, although the system can be strengthened further, and > > ^^^^^^^^^^^^^ > > continuous improvements are being made. > > > > The indicated phrase seems very breezy. Perhaps "And we believe those > > structures are strong enough now"? > > In my response to Ted Lemon, I wrote the following: > > Both of the sentences you quote themselves are quoted from a statement > > made by the chair of the IAB on behalf of the IAB, that we developed in > > consultation with the IETF community.[1] If you don't mind I would > > rather leave them as a quote of the original text, although I agree that > > the wording could have been better chosen at the time. However, perhaps > > a reference to that statement would be useful to clarify this point. > > Is this sufficient? > > > > > In this text: > > > > >>> V. NTIA Requirements > > >>> > > >>> Additionally, NTIA has established that the transition proposal > > >>> must meet the following five requirements: > > >>> > > >>> "Support and enhance the multistakeholder model;" > > >>> > > > > > > IETF Response: > > > > Everyone is welcome to participate in IETF activities. The policies > > and procedures are outlined in the documents we named above. In- > > person attendance is not required for participation, and many people > > participate in email discussions that have never attended an IETF > > meeting. An email account is the only requirement to participate. > > The IETF makes use of both formal and informal lines of communication > > to collaborate with other organizations within the multistakeholder > > ecosystem. > > > > Is it worth explicitly pointing out that there is no cost of membership? > > I would rather not go there. While it is true, one must pay an ntrance > fee if one wants to attend the f2fs. > > > > > In this text: > > > > This proposal maintains the existing open framework that allows > > anyone to participate in the development of IETF standards, including > > the IANA protocol parameters registries policies. Further, an > > implementer anywhere in the world has full access to the protocol > > specification published in the RFC series and the protocol parameters > > registries published at iana.org. Those who require assignments in > > the IANA protocol registries will continue to be able to do so, as > > ^^^^^ > > specified by the existing policies for those registries. > > > > I don't think that parses. Is this "will continue to be able to request > > these assignments"? > > I agree that the language is strained there. > > How about the following: > > > Those who require assignments in the IANA protocol > > registries will continue to have their requests satisfied, as > > specified by the existing policies for those registries. > > > > > In this text: > > > > IETF Response: > > > > The IESG established the IANAPLAN working group to develop this > > response. Anyone was welcome to join the discussion and participate > > ^^^^^^ > > in the development of this response. An open mailing list > > (ianaplan@ietf.org) was associated with the working group. In > > addition, IETF's IANA practices have been discussed in the broader > > community, and all input is welcome. > > > > I wonder if this text reflects how open the IETF is. It would be correct > > to say "Anyone on earth with access to e-mail was able to join ...". That > > might not be the right thing to say, but is the current text strong > > enough? > > I suggest that this text remain as is. "Anyone" is a pretty large set > of people. > > > In this text: > > > > Announcement of a public session on the transition: http:// > > www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html > > > > I'm not sure "public" is the right adjective. Perhaps something like > > "Announcement of a face-to-face session with provision for interactive > > remote participation? I'm asking because the URL just says there's a > > session at IETF 90, and that would make a random reader of this document > > think travel, accommodations and meeting fees would be required. > > I'd suggest that we retain the existing text, as there is adequate > explanation of IETF processes earlier in the document. > > > > > > I think discussion about the IAB Note is headed the right direction, but > > that matters. > > > > > > > > > > Regards, > > Eliot > > [1] > http://mailarchive.ietf.org/arch/msg/internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k > > >
- [Ianaplan] Spencer Dawkins' Yes on draft-ietf-ian… Spencer Dawkins
- Re: [Ianaplan] Spencer Dawkins' Yes on draft-ietf… Eliot Lear
- Re: [Ianaplan] Spencer Dawkins' Yes on draft-ietf… Spencer Dawkins at IETF