Re: [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response

Abdussalam Baryun <abdussalambaryun@gmail.com> Sun, 21 December 2014 03:29 UTC

Return-Path: <abdussalambaryun@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 904B41A00F0; Sat, 20 Dec 2014 19:29:59 -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 n17icw_qfd9A; Sat, 20 Dec 2014 19:29:55 -0800 (PST)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A088C1A011E; Sat, 20 Dec 2014 19:29:55 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id c9so2230504qcz.5; Sat, 20 Dec 2014 19:29:54 -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=mY2zeBsSkNn0jTNAYtzAoz1DQtHi87J742kJ/Doao7w=; b=CQwUwxFbZYtv3n8BzdYvNtx0472b411GVb0yyNU5/TKTrBtt3lk16Iw9sELGo39MBl Y8yvX++1nnGklcKudtW0kXhGdDYlscF/fGp0rJ7T0d9qir8haV8kYjMyFEGFvfSq/XYe 5lYqTyZD+kphN5iOmjfaoEv3/PhuWrW7yDY+BKzONQx9DNVl+rMIRHijSytu4BtAW5Fo be4/w8wABkE+7qaEV81RjVGaZfviaXUgEgqNHwcuSatct6iGdpMi1J3vdocHNBGLvNsV KmS3Az6acv4Xpoj20JDxJfY13OrOHRq90jOUxAG2hrz6V2614Wr92nK75Ju40dlfI/h6 lrfw==
MIME-Version: 1.0
X-Received: by 10.224.3.137 with SMTP id 9mr27265469qan.64.1419132594793; Sat, 20 Dec 2014 19:29:54 -0800 (PST)
Received: by 10.140.98.212 with HTTP; Sat, 20 Dec 2014 19:29:54 -0800 (PST)
In-Reply-To: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net>
References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net>
Date: Sun, 21 Dec 2014 05:29:54 +0200
Message-ID: <CADnDZ89ix-3bRVccuj5b+AczKFHYUH4HLvmYOXGTzWRpvjg8KQ@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="001a11c2480a33b301050ab18e47"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/m9betHZZtbmi9NSj6hyghsaqTeU
X-Mailman-Approved-At: Tue, 30 Dec 2014 13:45:50 -0800
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>, "draft-ietf-ianaplan-icg-response.all@tools.ietf.org" <draft-ietf-ianaplan-icg-response.all@tools.ietf.org>, IETF-Discussion list <ietf@ietf.org>
Subject: Re: [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response
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: Sun, 21 Dec 2014 03:29:59 -0000

My general comments:

In IETF response there is no information about its date or the date of
respond. IMHO the date is very important for a such info-document.


AB> There is no reference for the following paragraph as what are the
current arrangements exactly;
{

IANA protocol parameters registry updates will continue to function
   day-to-day, as they have been doing for the last decade or more.  The
   IETF community is very satisfied with the current arrangement with
   ICANN.

}

  AB> In London 89 was there a meeting for WG or for community? In
paragraph below, There is no reference to community discussions or minutes
of meeting, just a chair discuss !!!!

So if the IETF community discussed that can mean a WG, so we should specify
its name. See below paragraph;
{

In developing our response we have been mindful of the following
   points that the IETF community has discussed over the last year
   [ProtoParamEvo14].  Discussions during the IETF 89 meeting in London
   led to the following guiding principles for IAB efforts that impact
   IANA protocol parameter registries.  These principles must be taken
   together; their order is not significant.

  }

In general, this draft needs to be careful with references and point to the
community discussions and minutes, and must reference the WG that discussed
the draft.

Regards

AB

IETF Participant from Africa

On Thursday, December 18, 2014, Jari Arkko <jari.arkko@piuha.net> wrote:

> This is a summary of the last call and conclusion from the IESG processing
> of this draft.
>
> This document has attained rough consensus of the IETF Working Group and
> of the IETF community as a whole, as judged first by the chairs and then by
> the sponsoring Area Director, and then by the IESG in accordance with RFC
> 2026 in the December 18 IESG telechat. The IESG has approved the draft,
> although the formal approval will be a few days away to make sure the new
> version did not miss anything. If you see an issue that has been missed or
> change that is not correctly implemented, please report it to us by Dec 29,
> 2014.
>
> Over the course of the development of the document, several suggestions
> were raised that did not enjoy sufficient support to be included. Two main
> ones worth mentioning include
>
>         • A suggestion for a stronger statement over what terms the IAOC
> should negotiate.
>
>         • A suggestion that "iana.org" and other associated marks be
> transferred to the IETF trust.
>
> At the end of the working group process, although there was not unanimous
> support for the results, the working group chairs concluded that rough
> consensus existed in the working group. The document shepherd’s summary of
> the WG consensus for this document can be found here:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/shepherdwriteup/
>
> During IETF last call, additional people voiced support for the document.
> There were several editorial comments that resulted in changes, as well as
> some discussion of more substantial comments some of which resulted in text
> changes. There was some discussion of comments already discussed earlier in
> the process, and but no new objections were raised during the IETF last
> call. A summary of the last call comments can be found from the end of this
> e-mail.
>
> A new draft version has been prepared by the editors per discussions on
> the mailing list and with the sponsoring AD. The new draft version and
> associated changes can be found here:
>
>  https://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-07
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-ianaplan-icg-response-07.txt
>
> However, a further version will be soon forthcoming with also (a)
> suggested text from IAB added to Section 5 and (b) description of how and
> what level of consensus the draft reached.
>
> During the IETF last call and IESG evaluation, the following points were
> made:
>
>         • Positive evaluation from Christer Holmberg, Melinda Shore,
> Alissa Cooper, Richard Barnes, and Ted Lemon. Currently, there is a Yes
> position from 12 Area Directors.
>
>         • Editorial comments from Brian Carpenter, Sean Turner, Pete
> Resnick, Adrian Farrell, Spencer Dawkins, Alissa Cooper, Alia Atlas,
> Richard Barnes, and Christer Holmberg. These have resulted in text changes.
>
>         • A comment from Pete Resnick around the use of full text from
> IETF mission statement RFC. This has resulted in a text change.
>
>         • A comment from Sean Turner about some missing parts in the
> response. This has resulted in text changes.
>
>         • Agreement with the general message, but a question and a concern
> from John Levine around roles in policy disputes, and contracts in case of
> changes in who is the IANA operator. These were resolved through discussion
> with Eliot Leor, Brian Carpenter, and Jari Arkko. This resulted in text
> changes.
>
>         • Discussion on the availability of text for Section 5 and how
> that can be handled process-wise, started by Adrian Farrell. Suggested
> resolution is to use the text that IAB wants to indicate, "The IAB supports
> the response in this document". The text is now out in the working group
> list, which it was not before. A new document version is needed to add this
> text.
>
>         • Discussion on the role of the document after IESG approval, and
> whether the goal was to get IESG review or approval. The sponsoring AD
> believes that it is important to use our normal approval process, and
> ensure that the IESG agrees with the consensus assessments in this case.
> Whether the document gets published as an RFC or not is somewhat
> immaterial, because the main purpose of providing an IETF view on the
> matter is to collect several views together from different organisations to
> gather a complete transition proposal.
>
>         • Discussion of the rationale for concluding rough consensus from
> Richard Hill (responses from Marc Blanchet, Andrew Sullivan, Milton Muller,
> Jari Arkko, Brian Carpenter, John Curran, and Jefsey). Richard was
> requesting a rationale for why the conclusion was what it was, or perhaps
> rather disagreeing with the rationale that was provided.
>
>         • Recommendation to the IAOC to create stronger supplemental or
> replacement agreements between the IETF and ICANN, by Milton Muller and the
> Internet Governance Project. The recommendation recognises the rough
> consensus behind the current proposal that specifies requirements but does
> not call out explicit agreement mechanisms, but suggests that the stronger
> agreements would be extremely significant. The recommendation goes on to
> "provide information to the IETF's leadership regarding what the unresolved
> issues were, why it is important to resolve them, and how it might respond
> to them with supplemental agreements". The recommendation also states that
> the advocated actions are in line with the current IANAPLAN draft. The IAOC
> has taken this input for consideration. It should be noted that these
> recommendations were discussed as part of the WG deliberations, however.
> The WG consensus did not agree with the recommendations.
>
>         • Jefsey has noted that he intends to file a future appeal on this
> topic, around the responsibilities of the IETF and RFC 6852. Jefsey notes
> "My point will not be to change it, but to make sure that the IESG, and
> IAB, and ISOC, fully and publicly declare that they understand, accept and
> decide that this is what they mean." It is not clear that there is anything
> to do about this at the moment, particularly when at least the sponsoring
> AD does not understand the provided feedback; this is an IETF document that
> will, as it gains approval, will have been processed by the IESG and will
> explicitly note that the IAB supports the described transition. Response by
> Andrew Sullivan on December 15 indicates that he does not believe any
> changes to the document or the summaries produced by the WG officials were
> necessary.
>
>         • The IAOC has indicated that they are comfortable with the
> direction the document gives for the IAOC.
>
> Jari Arkko, the sponsoring Area Director for
> draft-ietf-ianaplan-icg-response
>