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

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Dec 2014 13:53:43 -0500

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

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 19 Dec 2014 09:17:41 +0100

Dear Jari,

Thank you for this and please see embedded comments below.

Best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: jeudi, 18. décembre 2014 19:54
> To: Ianaplan@Ietf. Org
> Cc: [email-masked]; IETF-Discussion
> list
> Subject: [Ianaplan] last call and IESG processing summary for
> draft-ietf-ianaplan-icg-response
>
>
> 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:
>
>

Please add that I requested that changes be made to that writeup so as to
reflect correctly my statements.

SNIP

>
> 	• 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).

Please correct that to state that I requested that the co-chairs provide a
justification for the rough consensus call.  Unless I missed something, the
co-chairs did not provide that justification.

>Richard was requesting a rationale for why
> the conclusion was what it was, or perhaps rather disagreeing
> with the rationale that was provided.

No, I was requesting a justification of the rough consensus call.

SNIP

>
> 	• The IAOC has indicated that they are comfortable with the
> direction the document gives for the IAOC.

Please add here (or wherever else you think it would fit):

* Richard Hill requested that the IESG defer its decision on this draft
until the submission by the co-chairs of their justification for the rough
consensus call.

---

From: JFC Morfin <[email-masked]>
Date: Fri, 19 Dec 2014 12:04:22 +0100

At 19:53 18/12/2014, Jari Arkko wrote:
>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."

Dear Jari,

It is difficult to understand this sentence since the "this" is not 
explained as being that from now on, the IETF will still be working 
for the future internet ,in its own way and for its own mission but 
will not be exclusive or responsible for it any more.

This responsibility is here understood as per RFC 3935: "when the 
IETF takes ownership of a protocol or function, it accepts the 
responsibility for all aspects of the protocol, even though some 
aspects may rarely or never be seen on the Internet.  Conversely, 
when the IETF is not responsible for a protocol or function, it does 
not attempt to exert control over it, even though it may at times 
touch or affect the Internet."

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

The IAB still has to commit in this document. However, eventually 
ISOC will be the one having to decide, since the I_D means that ISOC 
would not own the internet anymore (in the RFC 3935 meaning hereinabove).

This would be (1) the end of the "status quo" strategy and (2) the 
affirmation of the "permissionless innovation" paradigm, without any 
proposition regarding:

- the replacement and an extension of the former IAB guidance role in 
the resulting multitechnology competitive environment on an 
economical, and probably political, basis.
- The way the IETF should adapt its mission of influencing peer SDOs 
and global communities in such a way as to make the Internet work better.

The two mails of Andrew Sullivan and the comment of Pete Resnick show 
that this new context and its resulting Tao is not familiar yet among 
every IETF leaders. Now, as a non-IETF technically competing WG, I 
need to have the practicalities of this new situation explained and 
how IETF stakeholders intend to adapt to the MYCANN/CORPCANN/GOVCANN 
middlewares and the multitechnology environment that we will face and 
build together.

We need to know if the IAB/IETF, or someone else they would accept, 
intends to launch a normative multistakeholder coordination effort 
that we could adhere to. OpenStand is only a set of principles, not 
an active "concertance" as in a concerted everystakeholder 
governance. Otherwise, it is likely that the technical referent 
structure will temporarily be ICANN and will end up as being the ITU-I.

A twenty years long process to accept the inevitable: in our world 
only sovereignty or concertance (see above) can last.
Best
jfc

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Dec 2014 09:53:55 -0500

Jefsey,

Perhaps because we have corresponded more over the years, unlike
Jari, I understood your comments and the note excerpted below
confirmed my understanding.  Part of that understanding is that
the vast majority of your text and comments below are about your
vision for computer-enabled networking going forward and where
you think the IETF and other bodies fit in that model.  While
the I-D does contain some description of parts of how the IETF
works and, in particular, how it relates to the IANA function,
it doesn't make normative changes to IETF  (or IAB, ISOC, etc.)
relationships to the present or future Internet beyond the very
narrow issues of IANA relationships and oversight.  No matter
what you might read into what is said, for it to do so would be
out of scope for the WG and would represent changes to which
some of us would object strenuously, especially if those changes
were hidden in discussions of NTIA-IANA relationships and the
conditions and implications of changes in them.

Details below.

--On Friday, December 19, 2014 12:04 +0100 JFC Morfin
<[email-masked]> wrote:

>...
> It is difficult to understand this sentence since the "this"
> is not explained as being that from now on, the IETF will
> still be working for the future internet ,in its own way and
> for its own mission but will not be exclusive or responsible
> for it any more.

The document changes nothing in that area, including any notions
of exclusivity and/or responsibility.   I don't know whether we
would agree about how "exclusive or responsible" things are
intended or desired to be today (or how they are practiced), but
I am quite certain that this document changes nothing in those
areas.

> This responsibility is here understood as per RFC 3935: "when
> the IETF takes ownership of a protocol or function, it accepts
> the responsibility for all aspects of the protocol, even
> though some aspects may rarely or never be seen on the
> Internet.  Conversely, when the IETF is not responsible for a
> protocol or function, it does not attempt to exert control
> over it, even though it may at times touch or affect the
> Internet."

That statement has little or nothing to do with the IANA
function, the IETF-IANA relationship, or IANA oversight.  The
present draft does not change anything about it, even to
reaffirm it.

> The IAB still has to commit in this document. However,
> eventually ISOC will be the one having to decide, since the
> I_D means that ISOC would not own the internet anymore (in the
> RFC 3935 meaning hereinabove).

I do not believe that any of IETF, the IAB, or ISOC have claimed
at any time to "own the Internet".   Even if they had, there is
nothing in this document that would change or ratify that
status.   Because the document changes nothing in those areas,
your subsequent assertions about 'the end of the "status quo"
strategy' and 'affirmation' are just simply not relevant.

>...
> Now, as a non-IETF
> technically competing WG, I need to have the practicalities of
> this new situation explained and how IETF stakeholders intend
> to adapt to the MYCANN/CORPCANN/GOVCANN middlewares and the
> multitechnology environment that we will face and build
> together.
> 
> We need to know if the IAB/IETF, or someone else they would
> accept, intends to launch a normative multistakeholder
>...

Whether you "need" those things or not, and whether you can
demand that the IETF or IAB respond to those needs, they simply
have nothing to do with the substantive subject matter of this
document or the scope of the WG.

best regards,
    john

---

From: JFC Morfin <[email-masked]>
Date: Mon, 22 Dec 2014 06:11:30 +0100

Dear John,

Thank you for your kind, open, and constructive comment. It would 
help sustain a long discussion. I will try to make a general and 
"short" response.

Your mail actually confirms for me that the IETF fork between the 
pre-RFC 6852 IETF and the post-RFC 6852 IETF,
- which has actually been enacted at the IAB level,
- as resulting from a change in the very nature of the 
catenet/internet relationships,
is not yet perceived from within the IETF culture, while it starts 
being progressively enacted and played on, on the technical (new 
upper layers technologies), economic (WEP, Google, Dyn, Netflix, 
Libre, etc.), military, and political (Europe, BRICS) planes.

My effort is simply to make ISOC formally endorse the risk that I 
might be right in considering the Lynn St-Amour/Don Tappscott 
analysis conducted by GSN for the USG 
(<http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/>http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/) 
as self-contradictory. This was the purpose of my appeal concerning 
RFC 6852's lack of common referent to replace the IAB that was 
interrupted by the NTIA.

Lynn/Don's analysis could be very briefly described as being - within 
the RFC 6852 paradigm and the "permissionless innovation" framework - 
the meme stating that "Multi-stakeholder governance has come of age 
and is now fully independent from control by any government, or 
governmental organizations like the UN. It is the very embodiment of 
the vision of a free enterprise system that is managed by its 
participants." ... most probably within the ISOC framework, that 
ICANN seems to alternatively prefer to be the NMI (which I feel is 
slightly more consistent with RFC 6852).

This does not stand. For a simple reason that I know very well: me.

Lynn's meme stands on the "multi-stake-holder" concept. I know that 
the network, the world and, the universe stands on the 
"omni-stake-holder" reality.

Andrew (who I certainly did not insult!) expressed this very well, as 
you just did it: my inputs have not been considered. For a very 
simple mathematical reason which is:

"omni - multi = Libre +  Jefseys".

Look,
- I am discussing TCP/IP Class IN AMERICANN + MYCANNs + GOVCANNs + 
CORPCANNs global reality.
- you are discussing the "ICANN, IANA(*), IETF,  IAOC, IETF Trust, US 
Law, Jon Postel, etc." local virtuality. This virtuality could only 
be credible if there was someone at the iana.arpa helm. The purpose 
of this I_D is to show that there is no one.

(*) the NTIA has never talked about transferring all the IANA 
functions, and the Charter never mentioned the IGC.

The publication of the I_D will not create the fork between your BCP 
78 IETF and the RFC 6852/3935bis IETF: it was  created two years ago 
by OpenStand. And officialized one year ago by RFC 6852  I will only 
make it clear that the IETF people have not noticed. They have to 
notice it; otherwise, the transition will not be seamless and 
constructive. This is the purpose of my appeal.

- either it is accepted, and we know who the proprietor of the 
technical rights and duties concerning the Internet is: and the IAB 
will have to help upgrading the IETF culture.
- or it is denied and ISOC and (USG) will have made it clear that 
they wish for the IETF to only  remain one of the contributors to the 
TCP/IP technology middle layers within a multitechnology digital context.

My only concern is that the IETF situation resolution does not cause 
too much hassle to the permissionless innovation 
contribution/contributors - and that they can positively cooperate to 
the IETF in being identified for what they do.

jfc

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Dec 2014 20:41:26 +0200

Richard,

Thanks for your note. (Reproduced at the end of this e-mail for the benefit of 
others, just in case we still have an issue with the list not accepting your 
e-mails. I apologize for the trouble on that, by the way.)

I wanted to acknowledge the reception of your note, and the reception of the 
earlier requests, including the one requesting the co-chairs to provide (further)
justification for their conclusions. I also wanted to say that those were 
considered as a part of the process. A big part of the IESG’s role in
approving output from the IETF is making sure that the community
has been heard and that there’s broad backing for the particular output.
In this case the IESG has been comfortable with the making the decision
it has made, having considered the community discussions, including
your request. Personally, I am quite comfortable with the decisions in
the WG and IESG stages, and believe that they reflect community
(rough) consensus.

Hope this helps,

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Dec 2014 20:42:01 +0200

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

I wanted to send an update, pointing people to the final updated draft version 08 that was posted on December 22nd.

The diffs from -07 to -08 are here:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ianaplan-icg-response-08

And the diffs to the version that was in last call are here:
http://www.ietf.org/rfcdiff?url1=draft-ietf-ianaplan-icg-response-06&url2=draft-ietf-ianaplan-icg-response-08

As noted, I plan to make the final approval step of this draft before the end of the year.

Jari Arkko

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 27 Dec 2014 10:19:52 +0100

Dear Jari,

Thank for this, and please see embedded comments below.

Best,
Richard

> Sent: jeudi, 25. décembre 2014 19:41
> To: [email-masked]
> Cc: Ianaplan@Ietf. Org; IETF-Discussion list
> Subject: Re: [Ianaplan] last call and IESG processing summary for
> justification for their conclusions.

Since you say "further justification", it seems that I missed something,
because I don't recall seeing the justification from the co-chairs for the
rough consensus call.  Perhaps you could point me to it?

>I also wanted to say that those were
> your request.

I don't recall seeing any statement from any IESG member to the effect that
he or she had considered my request not to proceed to approve the draft
until the co-chairs had provided a justification for the rough consensus
call.  Perhaps I missed some relevant statements explaining why my request
was considered but rejected.

>Personally, I am quite comfortable with the decisions in

See above.

And please note that the changes I requested to the sheperd write-up with
respect to my statements have not been made (see below), so that write-up
does not correctly reflect what I said during the disussions.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 28 Dec 2014 15:46:45 -0500

Hi Richard,

I thought I'd already covered this in detail, but a quick glance
didn't bring it up for me so I might not have explained this.  My
apologies.  See below.

> does not correctly reflect what I said during the disussions.

The shepherd's write up is how the shepherd communicates to the IESG,
and is not a consensus document or a product of the WG.  It is instead
a process document.  My understanding of the point of this document
(especially using the new-form template, which is the one I used) is
that it is to inform the IESG about the state of the WG's consensus,
and in particular to alert them to any areas of particular controversy
and difficulty.  If the IESG is concerned, they generally follow up
with the shepherd to learn more.

While it is important that the write-up not misrepresent the state of
consensus, it need not provide a lot of detail about what the
objections of indviduals are.  In this particular case, since during
IETF LC you raised your concerns with the way the write-up expressed
your objections, your concerns are on the record anyway.  There is
therefore no reason to alter the write-up, in my opinion.  

Best regards and many happy returns for 2015,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Tue, 30 Dec 2014 13:47:42 +0100

> > does not correctly reflect what I said during the disussions.

At 21:46 28/12/2014, Andrew Sullivan wrote:

On Sat, Dec 27, 2014 at 10:19:52AM +0100, Richard Hill wrote:
 > And please note that the changes I requested to the shepherd write-up with
 > does not correctly reflect what I said during the discussions.

Richard,

This already created an unintended controversy between Andrew and me.

Andrew is correct when he says:

>a process document.

The shepherd's role seems, therefore, to be an informant for the IESG 
whose mission is to control that the Chairs respect the charter.

>  My understanding of the point of this document

i.e. not about the dissensus arguments.

>and difficulty.

only about the dissensus areas and risks of appeal (that last 
reporting would be left to the Chairs?) - If they want more: the 
records are available. Every AD can state a "DISCUSS" position. 
However, this is their personal decision, not one you can request or 
demand. This is a multilayer process.

>If the IESG is concerned, they generally follow up

Please remember that the concern is only about an existing dissensus, 
not about its reasons.
If the dissensus does not lead to the risk of appeal, or was not 
considered as sufficient to impeach a rough consensus, it is of no 
further interest. One cannot constantly repeat the defeated objections.

>objections of individuals are.

What the "IETF born" leaders tried to tell you is that what counts is 
only the rough consensus. Like 51% in a democratic vote.

In our case, the rough consensus was actually pre-decided by the 
Charter (status quo). This reflects a ***new*** IETF environment. 
This pre-decided rough consensus seems, therefore, to be the 
IETFcore's reading of what RFC 6852 OpenStand principles call a 
"broad consensus". This is why I say that this is an IETF fork. This 
***new IETF*** branch has its own different governance rules.

The only possibility left is to make the coup leaders to acknowledge 
their coup.

This is difficult, as usually a coup is to take control, assume 
responsibilities, get power. In this case, it is the contrary, an 
abdication. For two reasons:

* a good one - technology developments leads the internet to share 
the catenet with other technologies; IETF cannot claim monoresponsibility.

* a bad one  - the IETF does not want to be responsible for 
accommodating these new technologies to the existing practices, 
solutions, standards, and systems. One fully understands why: they do 
not want to be accountable for an ICANN economy. They are 
manufacturer/industry oriented. Up to RFC 6852 ICANN was accountable 
to IETF and still is to IAB - but they do not want that responsibility alone.

Before being a decentralized toy for a sovereign financial entity - 
it is a distributed open network with cross-accountability mechanisms 
and real time operations. Up to the politicians to address the issue.

Any solution to this situation calls for a clean sheet status report. 
This means

1. to make IESG, IAB, and ISOC to publicly commit on what they are, 
their mission is, the responsibilities they assume or not.
2. As a consequence to get the other stakeholders (in an 
omnistakeholder approach) state in the same manner who they are, what 
they need, what they want to achieve and how.

This can only be obtained through an appeal process, technically 
documenting why the WG/IANAPLAN, which was pre-decided rough 
consensus by a virtual charter, puts the IETF technology in jeopardy 
and transfers the Internet technology governance to the WEF. In 
calling for press attention through the introduced delay.

* Either ISOC will have to say "yes", and things will be clear. There 
will be a wefnet and an interplus competing over the ITU catenet.
* Or ISOC will say "no", and the OpenStand principles will have to be 
completed and co-signed by the ITU and the IUse community.
* Or ISOC will not respond and lose legitimacy - at least as far as 
IUse/Libre communities will be concerned.

>In this particular case, since during
>your objections, your concerns are on the record anyway.

Richard, Andrew is rightfully only concerned by the rough consensus 
decision legitimacy along with the IETF rules. Your objections are on 
the records not as objections (for their value) but to prove that you 
were able to express them and that the rough consensus process was respected.

The IESG does not discuss objections. The IESG is told that there is 
a rough consensus and verifies that there is no conflict with other 
IETF efforts.

This is a perfectly balanced process, because if ***you*** think that 
the matter of your objections has not been considered enough you can 
call on the IESG/IAB to discuss these objections through an appeal process.

Either you agree with the Chairs' rough consensus declaration, or you 
appeal. This is now your decision.

You can appeal either (1) against the Chairs' declaration or (2) 
against the produced document or (3) both.

1) I understand that in your opinion you oppose the Chairs' rough 
consensus declaration as being premature and not fully justified. It 
does not have to be documented by Andrew, but you can document it to 
the AD, the IESG, etc.

2) I do not oppose the Chairs' declaration of rough consensus myself, 
because as soon as they refused to ask for IAB guidance over the 
Charter virtual parts, the pre-decided rough consensus was shared by 
most of the members of this WG. I oppose the produced document, not 
for what it says, but for what it does not say. I oppose its 
incompleteness as being the result of a tacit anti-ITU/IUsers 
I*core/NTIA pre-consensus strategy. This strategy has now itself 
forked (between ISOC and NMI).

Andrew has nothing to do with this. He loyally tries not to choose 
among not yet fully documented sides.

There were several initial network projects in the 1960s. Three 
propositions came to gather them together. Multitechnology Tymnet, 
concatenation Catenet, TCP/IP Internet. Counter-strategically, TCP/IP 
prevailed through the "status quo" and forked through the IETF in 
abandoning the multitechnology ambition. In front of the 
multitechnology come-back, ISOC took IETF over but must technically 
fork again (this I_D) and accept "permissionless innovation" while 
its political support is economically forking (WEF).

I do not particularly wish to know who wishes to follow which fork. I 
am only interested in the multitechnological intelligent use of the 
catenet which is public, common, and private omistakeholder property.

>Best regards and many happy returns for 2015,

Ditto to everyone.
Jfc

>A
>
>--
>Andrew Sullivan
>[email-masked]
>
>_______________________________________________
>Ianaplan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 21 Dec 2014 05:29:54 +0200

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 <[email-masked]> wrote:

> 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
>
> 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:
>
>
> 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:
>
> 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.
>
>         • 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.
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Dec 2014 00:01:19 +0100

Richard,

(I am copying once again your e-mail at the end, in case
it didn’t  otherwise make it to the list archives.)

First, I wanted to say that I agree with Andrew said. 

Secondly, I wanted to assure you that your opinion
and comments are on record, have been noted and 
thought about, even in those cases where we did not 
say anything specific about them. Your specific
issue in this case was brought up in the IESG
discussion, for instance. Thanks for the feedback.

The summary that I sent (or any other similar
messages) should not be taken as a detailed list 
of everything that went on. They are high-level 
summaries, and written in my words, characterising
the situation as I see it. They are beneficial as
brief explanations, but the real record is the detailed 
discussions, e.g, on the list.

But I can change my summary to read:

"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 justification (beyond information
already available) for why the conclusion was what
it was, and deferring the IESG decision."

For what it is worth, I think there was certainly 
enough information in the thread labeled 
"draft-ietf-ianaplan-icg-response moving to next step”,
the shepherd writeup, and of course as well in the 
overall process that the working group went through.

Jari

---

---

From: JFC Morfin <[email-masked]>
Date: Wed, 31 Dec 2014 20:04:56 +0100

>it was, and deferring the IESG decision."

Thank you. This is perfectly clear. In my humble opinion, I submit that:

1) as per the IETF rules, there is an IETF rough consensus.
2) in having been pre-decided by a confusing Charter, this 
deliverable seems to proceed from the new non-documented and 
consensually approved  standard process of a post-RFC 6852 IETF fork
3) as a result, it is incomplete, which thereby puts the internet and 
its technology in jeopardy, and impacts the omnistakeholder catenet 
basis and cooperative property.
4) however, this ***can be fully addressed*** by an appeal to the 
IESG, IAB, and ISOC, each in their RFC 2026 capacity,
5) this appeal should raise questions to which positive/negative 
responses should satisfactorily complete and clarify the Draft.

RFC 2026 requires that appeals are made by individuals. I will 
initiate one. It will not oppose the rough IETF consensus delivered 
by this WG, but rather its lack of clarity outside of the IETF, in 
the light of RFC 3869, RFC 3935, RFC 6852, the NTIA Statement, the 
NMI, the MYCANN Plugs-in, etc. The need is to know if the IETF 
intends or not to put the humanity's catenet in jeopardy by not 
cooperating with non-I*core technical initiatives or existing RFC 
6852 innovations/responses by other national, global, and several communities.

This is not that easy, and this is why I certainly welcome privately 
and/or publicly useful help and comments from everyone.
Happy new year to all of you.

jfc