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
>
>
>