ietf
[Top] [All Lists]

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

2014-12-20 21:30:22
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(_dot_)arkko(_at_)piuha(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>