Subject: [Ianaplan] Adrian Farrel's No Record on draft-ietf-ianaplan-icg-response-06: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Dec 2014 02:45:00 -0800

Adrian Farrel has entered the following ballot position for
draft-ietf-ianaplan-icg-response-06: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for working on this document and capturing the consensus of
the comments you received.

I have a few editorial points and some minor questions I hope you will
have time to consider.

---

The Shepherd write-up says...

  The I-D should not be published as an RFC immediately after approval.
  Instead, the IESG should hold it and transmit its approved status
  through its appointees to the ICG. If discussion with the ICG results
  in proposals to change the proposal, such changes will need to be
  discussed in the WG.

The advantage of this approach is that a bis to an RFC is not required.
This would save RFC Editor time, and possibly avoid confusion later. But
this seems a minimal benefit.

On the hand, I don't see how discussions with the ICG would result in 
changes to IETF consensus material. Maybe the point is that the ICG
might have questions about the clarity or about missing material.

The process here may be slightly out of alignment. Getting external 
review is normally handled prior to, or during IETF last call. Very
occasionally it is also handled immediately after IESG last call.
Having external review after approval for publication seems to be
running things a bit late.

Perhaps what you wanted to achieve was IESG review rather than IESG
approval?

---

idnits throws some issues and warnings. These are not mentioned in the
Shepherd Writeup, but I don't think any work is actually needed.

--
   
This document includes language that was natural in the I-D as it was
under development, but would be inappropriate in a published RFC.

Title
Strike "Draft"

Abstract
Strike the final sentence.

I do not believe that Section 5 is appropriate in an IETF Stream 
document.

---

Section 1 para 1 talks says

   They solicited proposals regarding post-
   transition arrangements from the three functional areas

In a paragraph mentioning many groups of people, it would be helpful to
be explicit instead of saying "They...". I think you mean "The ICG...".

It is unclear at this stage of the document what a "functional area" is
and it is hard to understand whether the word "from" is intended (the
three functional areas should provide proposals about the whole set of
transition arrangements) or is intended to read "for" (proposals should
be made relating to the transaction arrangements for each of the 
functional areas).

Although this does not change the response itself, clarity would be
helpful.

---

Section 1

The paragraph...
   As if to demonstrate the last point, the following text was included
   in a footnote in the original RFP:
...is either bdly placed or badly worded. It appear that the original 
RFP was attempting to demonstrate that there are small changes to the 
content of the questions asked in order to match the RFC format. I doubt
that this is what you are trying to say!

---

Section 1

Please indent the final paragraph to make it more clear that it is
quoted from another document.

---

I wondered whether RFC 7120 needed to be referenced.
I also wondered whether the Errata Report system should be indicated.

Both of these have mechanisms that cause changes in registries without
necessitating RFCs.

---

Page 11
s/organizaitons/organizations/

---

Page 11

   IETF community is quite satisfied

The conflict between common usage and correct (British - cf. Jane 
Austen) meaning of "quite" makes this ambiguous. I suggest you use an
alternative such as "reaosnably", "very", or "completely".

NB. You use the correct definitive usage in bullet 3 on page 13.

---

Page 12

   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.

This text appears to be saying that the consensus embodied in this 
document is that these principles are a result of the London 
discussions. It does not imply that there is consensus on these 
principles themselves. If the latter was intended, then some rewording
may be beneficial, such as:

   The IAB carries out a number of activities that impact IANA protocol 
   parameter registries.  The following principles guide how the IAB
   carries out these activities.  These principles must be taken 
   together; their order is not significant.

However, the later use of the first person plural is then very 
ambiguous. When you write...

   We think the structures that sustain the protocol parameters
   registries function need to be...

...who is "we". Is it the IAB or is it the community? So perhaps you are
just using this document to record the IAB's views on things without any
IETF consensus. That would be fine, but perhaps it would be better to 
put that material in an IAB RFC or an IAB Statement, and reference it
from this document.

Lastly, the text doesn't really read like guiding principles. It is more
some general observations and afirmations. So you might want to change
the term. Indeed, you conclude the response with

   These principles will guide the IAB, IAOC, and the rest of the IETF
   community as they work with ICANN to establish future IANA
   performance metrics and operational procedures.

...which is counter to the initial statement that these are guiding
principles for IAB efforts.

---

Page 15

   The policies
   and procedures are outlined in the documents we named above.

Any reason not to repeat the citation for clarity?

---

Question V "Support and enhance the multistakeholder model"

I don't feel that the response addresses multistakeholerism in the the
transition. it talks about how great the IETF is (which is true) but
not about the transition proposal. 

To some extent you could argue that the proposal is that the IETF should
retain substantial control, and so talking about the IETF's model is
relevant, but this does not jump out of the text. Furthermore, there are
elements of the contract and oversight that surely need to be stated.

---

As mentioned by others, the response to question VI needs further work.
You should probably have drafted this and included it with a caveat so 
that the community could see what you proposed to deliver. In any case
you need:

   >>> o The steps that were taken to develop the proposal and to
   >>>   determine consensus.
- WG last call
- IETF last call
- IESG evaluation

   >>> Links to announcements, agendas, mailing lists, consultations and
   >>> meeting proceedings.
- Publication request
- IETF last call announcement
- IESG ballots
- IESG approval announcement

   >>> An assessment of the level of consensus behind your community's
   >>> proposal, including a description of areas of contention or
   >>> disagreement.
- Text! (Before the provision of this text, it is hard for the IESG to
  ballot)

---

Section 4 might benefit from observing that part of one of the questions
was:

   >>> "Maintain the security, stability, and resiliency of the
   >>>  Internet DNS;"

So security is a specific as well as a general concern.

---

As previously mentioned, section 5 is odd. 

---

Some of your reference are normative. That is, in some cases you do not
answer questions with direct text, but say "This is explained in [Foo]."
That makes [Foo] a normative reference.

In this category I see (at least) 
[http://www.ntia.doc.gov/page/iana-functions-purchase-order]
[RFC6761]
[RFC6220]
[RFC5226]
[RFC2026]
[RFC2418]
[NTIA-Contract]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Dec 2014 14:01:57 +0100

Hi Adrian,

The purpose of holding the document is to include as an Appendix the
final proposal submitted to NTIA as an Appendix.  The text of the rest
of the document is meant to remain stable.

> Shepherd Writeup, but I don't think any work is actually needed.

The abstract has been rewritten based on other last call comments.

> I do not believe that Section 5 is appropriate in an IETF Stream 

Can you please state where there is a prohibition on such a section?  If
the IESG feels strongly about this, the IAB needs to know as our views
are also sought.

> be explicit instead of saying "They...". I think you mean "The ICG...".

I believe this is already readily apparent from the previous sentence.

> be made relating to the transaction arrangements for each of the 

Please see my response to Sean Turner, which I believe addresses your
point.  In addition, I've changed the words "functional areas" to
"communities".

> that this is what you are trying to say!

I propose to simplify the text to say the following:

> quoted from another document.

Done.
> Both of these have mechanisms that cause changes in registries without

There are many such possibilities.  For instance, a port number
allocation or a vendor id in various registries do not require new
RFCs.  But is there a specific part of the text that you believe would
benefit from the inclusion of those references?

> s/organizaitons/organizations/

Thanks, corrected.
> alternative such as "reaosnably", "very", or "completely".

Changed to "very".
>    together; their order is not significant.

I think this misses a key point, which is that what is presented in the
document was indeed discussed both in person and on a mailing list.  No
formal IETF consensus call was taken.  We can indicate that in this
text, but the text below was a record of that discussion, which we
wanted captured.  My preference would be to not edit that the content,
which has not changed.  What's more, the WG found no disagreement about
the content, and therefore...
> principles for IAB efforts.

... my suggestion is that if anything we modify the chapeau to mention
"the IAB, IAOC, and the rest of the IETF community".
> Any reason not to repeat the citation for clarity?

I think if anything, the above sentence should be removed, because...
> elements of the contract and oversight that surely need to be stated.

The response is attempting to state two points:

 1. how the IETF is inclusive; and
 2.  how the IETF fits in the overall picture.

Perhaps it is doing so poorly?

>    >>> o The steps that were taken to develop the proposal and to

A laundry list of links is already included in the document, and will be
updated as the process continues.  Jari has already responded to the
IESG on the other point.

> - Text! (Before the provision of this text, it is hard for the IESG to

Please see my earlier response on this point.
> So security is a specific as well as a general concern.

There was some earlier text that attempted to interpolate an answer to
the above question for protocol parameters, but my understanding of the
working group conclusion was that the question is really intended to
focus on the DNS, and therefore we should keep the answer short and simple.
> That makes [Foo] a normative reference.

On reflection, I agree.

> [http://www.ntia.doc.gov/page/iana-functions-purchase-order]

Ok, I've gone through the list.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Dec 2014 14:32:26 -0000

Hi Eliot,

Thanks for the speedy engagement.
Edited out the agreement.

> final proposal submitted to NTIA as an Appendix.  The text of the rest of
> the document is meant to remain stable.

That's cool, but not what the text says (or appears to say).
Maybe it would be possible to capture your response in the text?

> The abstract has been rewritten based on other last call comments.

Good to know, but I can only review the version in front of me and on the IESG telechat.

> Can you please state where there is a prohibition on such a section?
> If the IESG feels strongly about this, the IAB needs to know as our 
> views are also sought.

Soooo, this could be complicated or it could be simple.
This document is an IETF stream document aimed at publication with IETF consensus. Yet there is a section in the body of this document that contains no text and on which the IETF community will not get to express an opinion. That, IMHO, is not how it works.
If the IAB wishes to express an opinion on this document, that is fine. If the IAB really wants that opinion captured in this document, then I think it would be nice to share that opinion with the community as part of the process and not attempt to impose it post facto. The community can then decide whether they like that opinion being expressed in their document. The IAB has other ways to document its opinions if it likes.
Now, it is possible that the IAB is just seeking to streamline its own response to the ICG by adding a note to this document. That makes some sense, but if that opinion is different from the IETF's opinion, then why not send a separate response? And if the opinion is the same, then what is to say?

> I believe this is already readily apparent from the previous sentence.

Obviously I don't agree.
The purpose of review comments is to make the document better. Would changing "They" to "The ICG" be harmful to the document? If not, why not make the change and remove what one reader considers to be a concern?

If support for my view is needed then I point out that the whole paragraph is a list of organisations with a cascade of connectivity. "They" embedded in that paragraph could easily mean "All of the above".

> I think this misses a key point, which is that what is presented in the document
> was indeed discussed both in person and on a mailing list.  No formal IETF 
> consensus call was taken.  We can indicate that in this text, but the text below
> was a record of that discussion, which we wanted captured.  My preference
> would be to not edit that the content, which has not changed.  What's more,
> the WG found no disagreement about the content, and therefore...
>
>>some general observations and affirmations. So you might want to change

That would be a good change.

I think the problem may be the absence of tense in the statement. 
Are you trying to say "We discussed the principles that are used today to guide..."? That is doubly good and could be used to indicate why this is not consensus text of this document, but why there is consensus to publish this record of discussions.
Or you could be saying "We discussed the principles that will used to guide future..."? That is more problematic if there is no consensus.

So I don't understand it when you say "No formal IETF consensus call was taken." The IETF last call was surely a consensus call. I just can't work out whether it was a call for consensus on the content of the guidelines or a call on the accuracy of the record of the discussions.

>> I don't feel that the response addresses multistakeholerism in the
>> transition. It talks about how great the IETF is (which is true) but

I think it has done 1 perfectly in this paragraph.
I don't think that 2 is addressed in this paragraph, but that is possibly unimportant given the rest of the document.

This specific question, however, appears to be asking how this transition proposal meets the requirement to support and enhance the multistakeholder model. I think you are effectively answering how the final position (i.e. what is transitioned to) wrt the registries meets the requirement. And you have also answered how the development of this proposal met the requirement. But nothing about the transition itself.

> A laundry list of links is already included in the document, and will
> be updated as the process continues.  

I am more accustomed, at this stage in the process, to reviewing text that is as complete as possible. Containing RFC Editor notes or similar to indicate what updates will be made.

After the time the IESG approves a document for publication only copy-edit changes are freely made before publication. Changes of content require sign-off by the responsible AD and often by the community.

Since this is only simple editorial work for you at this stage, I strongly recommend doing it.

Thanks for the work,
Adrian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Dec 2014 16:35:51 +0100

Hi Adrian,

> Maybe it would be possible to capture your response in the text?

I propose placeholder in the text.  I will note- if the entirely
completed response includes pictures and other difficult to transform
things, we may wish to just leave a pointer.

> Good to know, but I can only review the version in front of me and on the IESG telechat.

I will take advice from the shepherding AD as to how and when to publish
another version.  But for your information, this is what was developed:

        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.

> Now, it is possible that the IAB is just seeking to streamline its own response to the ICG by adding a note to this document. That makes some sense, but if that opinion is different from the IETF's…

Can we say this: if the IAB intends to state other than its support for
the document, it will do its own.  But if it is merely going to state
support, so that it's all clear in one place, may we let this go through?

> If support for my view is needed then I point out that the whole paragraph is a list of organisations with a cascade of connectivity. "They" embedded in that paragraph could easily mean "All of the…

Changed to "The ICG in turn..."

> Or you could be saying "We discussed the principles that will used to guide future..."? That is more problematic if there is no consensus.

Thanks for this, as it has helped clarify the situation.  How about
something simpler, like this:

In developing our response we have been mindful of the following points
that the IETF community has discussed over the last year.

This also addresses your point about the word "principles", with which I
agree.  That gets the tense right.

> This specific question, however, appears to be asking how this transition proposal meets the requirement to support and enhance the multistakeholder model. I think you are effectively answering how…

So help me a bit.  Modulo a possible IPR release, there is no state
change in terms of governance with regard to the transition.  It is not
clear to me what text you are suggesting.

> I am more accustomed, at this stage in the process, to reviewing text that is as complete as possible. Containing RFC Editor notes or similar to indicate what updates will be made.

I had interpreted these questions as requests for documentary evidence
of how consensus WAS generated.  Thus the links below with a
description, so that they would see for themselves.
> After the time the IESG approves a document for publication only copy-edit changes are freely made before publication. Changes of content require sign-off by the responsible AD and often by the com…

As agreed with the responsible AD, we had the RFC Editor do an early
pass on this document.  Those changes are now contained in an update.  A
revised draft will be needed in order to incorporate the changes as well
as the other responses to last call comments, which are all on the
list.  I presume that the AD will review each change.  This cannot be
accomplished in an RFC Editor note because it will be the approved draft
that gets sent to the ICG.

> Since this is only simple editorial work for you at this stage, I strongly recommend doing it.

What I am saying is that I believe the links with their descriptions are
already there (modulo Pete's comments about using the right links).  
Jari will add a paragraph in addition.  What else do you believe is
necessary?

Thanks,

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Dec 2014 11:26:12 +1300

Hi Adrian,

On 16/12/2014 03:32, Adrian Farrel wrote:
..
> Now, it is possible that the IAB is just seeking to streamline its own response to the ICG by adding a note to this document. That makes some sense, but if that opinion is different from the IETF's…

We didn't invent the RFC streams in order to hobble ourselves. There
are quite a few RFCs that express joint views (RFC 1984 springs to
mind) where there was a careful process to establish IETF consensus
*and* to add the support of the IAB. It would IMNSHO be craziness
not to make this document the same; it's only a matter of convenience
to label it "IETF stream". It would be extremely confusing to the
outside world if there were two documents.

The IAB section could include some kind of mild disclaimer ("The IAB
takes sole responsibility for the contents of this section."?), but
if there is any inconsistency between the IAB and the IETF consensus,
we have *much* worse problems than the choice of RFC stream.

So, it would be helpful to see the proposed IAB text real soon now.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Dec 2014 21:37:18 -0800

> Maybe it would be possible to capture your response in the text?
...
> Now, it is possible that the IAB is just seeking to streamline its own response to the ICG by adding a note to this document. That makes some sense, but if that opinion is different from the IETF's…

First, many thanks to Adrian for his diligence in raising the issue.

Second, the issue seems to be getting complicated by some concern for
RFC Editor-related efficiencies, leading to conflation of
related-but-independent actions.

My understanding of the overall process here is that we need an IETF
consensus document and then an IAB document, which will use some/all of
the IETF document.

If only for historical purposes (but really for more than that) the IETF
consensus document should be published as an RFC in its pure form.

If the IAB wants to attach an "IAB NOTE" statement to the document, and
that statement is phrased solely as commentary, and it is labeled and
isolated appropriately, -- in the style similar to what what the IESG
sometimes does to an Independent Stream document, that's probably OK.

But that's the limit of any publication 'efficiency' that should be
attempted.

If the IAB wants substantive modification, enhancement or elaboration,
then it needs to take the published form of the IETF consensus document
and use it as it sees fit to produce an IAB stream document.

Worrying about publication "efficiencies" is an attempt at local
optimization for this special case, which doesn't really need it.

If we want to worry seriously about IETF efficiencies, there are plenty
of other, continuing ways to pursue them with much greater and
longer-lasting benefit.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 16 Dec 2014 16:05:41 +0900

> So, it would be helpful to see the proposed IAB text real soon now.

I agree with Brian here (and disagree with Dave Crocker). [I have heard 
that there's a long history of IAB and IESG relationship, with a few 
hickups. I haven't been around the IETF to experience them directly, and 
I don't care too much because there haven't been any serious hickups 
that I'd know about for something like 20 years.]

I think it's great that we have the IAB and the IESG, it allows some 
distribution of work (all these kind folks are working really hard!) and 
some checks and balances. But seen from the viewpoint of a simple foot 
soldier, it's just two committees in the same organization, elected 
through the same process. And I'm sure that seen from the outside, it's 
just the same. We would never expect any company to send a proposal for 
business or for a contract containing a separate section mentioning the 
CEO's opinion or the Board's opinion.

So I'd prefer to make it just IETF consensus. If the IAB doesn't feel 
they are part of the IETF consensus, then as Brian said, we have a 
serious problem. If the IAB feels strongly that they have to call out 
that they also agree with the document, maybe we can add a phrase 
somewhere. But given how many members of the IAB have been involved in 
editing, discussion, shepherding, and so on, I don't think even that is 
strictly necessary.

Regards,   Martin.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Dec 2014 11:26:21 -0000

Hi Brian,

Top post for simplicity.

RFC 1984 seems like a great example of how to do it right with cooperation and clarity.
This document attempts "you do your bit and then we'll add our statement and changes into your document."
I would prefer us to do it the way you recommend.

A

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 15 December 2014 22:26
> To: [email-masked]
> Cc: 'Eliot Lear'; 'The IESG'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Ianaplan] Adrian Farrel's No Record on draft-ietf-ianaplan-icg-
> response-06: (with COMMENT)
> 
> Hi Adrian,
> 
> > This document is an IETF stream document aimed at publication with IETF
> consensus. Yet there is a section in the body of this document that contains no
> text and on which the IETF community will not get to express an opinion. That,
> IMHO, is not how it works.
> > If the IAB wishes to express an opinion on this document, that is fine. If the IAB
> really wants that opinion captured in this document, then I think it would be nice
> to share that opinion with the community as part of the process and not attempt
> to impose it post facto. The community can then decide whether they like that
> opinion being expressed in their document. The IAB has other ways to document
> its opinions if it likes.
> > Now, it is possible that the IAB is just seeking to streamline its own response to
> the ICG by adding a note to this document. That makes some sense, but if that
> opinion is different from the IETF's opinion, then why not send a separate
> response? And if the opinion is the same, then what is to say?
>

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 16 Dec 2014 12:36:52 +0000

> On Dec 15, 2014, at 11:45, Adrian Farrel <[email-masked]> wrote:
> 

Not unprecedented for entities that the IAB has chartered oversight for (RFC editor and IANA operator).

See e.g.:

http://tools.ietf.org/html/rfc5855#section-4 <http://tools.ietf.org/html/rfc5855#section-4>
and
http://tools.ietf.org/html/rfc5742 <http://tools.ietf.org/html/rfc5742> Section 6

—Olaf

— — — — — — — — — —
Olaf Kolkman
(on personal title)

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Dec 2014 11:19:30 -0500

Adrian,

Thanks for all the comments. I think Eliot has worked through most of it… I’m expecting him to take much of this into account.

I wanted to comment on the question of the IAB text in Section 5. Of course, you are completely right Adrian that if the IAB wanted to say something substantial, we’d need a different process. In this case the intent is to add “The IAB supports the response in this document.” and only that. I think adding that is reasonable, and of course, should not happen in the darkness but can be done as a part of the approval process.

So - for everyone - please be aware that we are planning to add that text as a part of the updates that have been otherwise gathered during the LC.

Jari

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Dec 2014 22:05:13 -0000

Thanks again, Eliot, for pushing on with this.
 
Eliot and I chatted to complete the details of our differences. I think we're there on all of the points.
 
Perhaps the biggest issue was around my question on the first response in Question V.
 
What i intended to try to draw out was the difference between the multistakeholder aspects in the development of the proposal, and in the content of the proposal (i.e. in the structures and process that would be put in place if the proposal was accepted).
 
The current text is a good explanation of how the IETF is open and effectively a multistakeholder organisation. But it lacks the hooks to the two different points.
 
I think this can be handled easily with a little lead in text about how the proposal was developed using normal IETF processes and how the essence of the proposal is to use existing IETF processes to continue to set policy for and guide the IANA protocol registry functions.
 
With that, all of points are addressed and I can go on and place my IESG ballot.
 
Thanks to all involved,
Adrian

 

 

So help me a bit.  Modulo a possible IPR release, there is no state change in terms of governance with regard to the transition.  It is not clear to me what text you are suggesting.

---

From: Jefsey <[email-masked]>
Date: Wed, 17 Dec 2014 04:42:01 +0100

At 23:05 16/12/2014, Adrian Farrel wrote:
>The current text is a good explanation of how the IETF is open and 
>effectively a multistakeholder organisation.

My experience with the Sheperd tells otherwise. To be credible (and 
therefore efficient) it should underline that

(1) the IETF is open but deaf and is truely a stakeholder within the I*core
(2) this I_D is precisely attempting to establish relations with the 
other I*core members, SDO's and global communities (cf. RFC 6852) on 
an equal footing basis.

>But it lacks the hooks to the two different points.

Please see the two hooks above. There is a need for mutual trust. 
Everyone needs to tell the truth and build from there. RFC 6852 and 
this I_D tell: the better internet the IETF is to built is no more 
specified by the IAB, but by global communities economies competition 
oversighted by .... here is the missing mutual accountablity 
framework the OpenStand needs.

The NTIA needs to know who will be its technical interface for the 
internet, as it needs to know who will be its technical interfaces 
for the other network technology deployements under preparation. For 
the DoC the internet is due to become one mosty-US set of products 
among emerging other US permissionless promizing innovations.

>not about the transition proposal.

 From the begining the transition and Charter, the transition is to 
be addressed by a status-quo.

>elements of the contract and oversight that surely need to be stated.

Something easy to achieve in keeping control of the whelm. i.e. of 
"iana.arpa" as I advocated it to make sure about the IETF consensus 
on the matter. The consensus on the matter is that the IETF does 
***not*** want to keep control. it is an engineering force, not a 
decision power. IAB could have been. Experience shows it cannot.

>1. how the IETF is inclusive; and

Yes. It wants to be inclusive. But to do this permissionless 
inovation must be listen to. Not only the global communities/business 
leaders stakeholders. IMHO - for the time being at least - this is not the case

>2.Â  how the IETF fits in the overall picture.

The IETF does its egineering job properly. But its job is no more the 
overall catenet/people/market picture. This has to be sorted out 
between the IESG and the IAB, possibly with the help of the NTIA through ISOC.
jfc

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 17 Dec 2014 11:05:42 +0100

Please see below.

Thanks and best,
Richard

>From: Ianaplan [mailto:[email-masked]]On Behalf Of Adrian Farrel
>Sent: mardi, 16. décembre 2014 23:05
>To: 'Eliot Lear'; 'The IESG'
>Cc: [email-masked]; [email-masked]; draft-ietf-ianaplan-icg-
>[email-masked]; [email-masked]
>Subject: Re: [Ianaplan] Adrian Farrel's No Record on draft-ietf-ianaplan-icg-response-06: (with COMMENT)
>

SNIP
 
>The current text is a good explanation of how the IETF is open

The IETF is indeed open to anybody who wishes to participate.  On the other hand, I haven't found it's decision-making process to be particularly open in the present case.  On the contrary, the views of people who are not IETF insiders were, in my view, not appropriately accomodated.

> and effectively a multistakeholder organisation. 

As far as I know, the more frequently used concept of a multi-stakeholder organization is that it comprises representatives of different constituencies (the stakeholders), such as governments, businesses, civil society, etc.  The representatives are expected to present and defend the views of their constituencies.

In contrast, the IETF is comprised of individuals who speak in their own name, even if they happen to work for some organization or other.

This has been referred to as "open multi-stakeholderism", as opposed to the more frequenly encountered "representative multi-stakeholderism".

SNIP

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Dec 2014 10:20:23 +0000

Richard,

On 17/12/14 10:05, Richard Hill wrote:
> The IETF is indeed open to anybody who wishes to participate.  On the
> other hand, I haven't found it's decision-making process to be
> particularly open in the present case.  On the contrary, the views of
> people who are not IETF insiders were, in my view, not appropriately
> accomodated.

That last is plain wrong IMO. It is the case that some folks
(me particularly probably:-) pointed out a number of times that
there was an issue where those more familiar with the IETF
all seemed ok with the draft text. That (my calling it out) was
due to frequently repeated assertions (in many many emails) that
there was some problem. And where those many emails were coming
from a small number (including yourself) of people for whom the
internals of the sausage making of the IETF was new.

That does not touch on openness, but rather on differing levels
of process knowledge or familiarity or expertise (though I hate
to use that last to apply to IANA considerations discussions;-)

I fully accept that from the point of view of those who are new
to the IETF that is likely to be perceived differently, but it
is entirely correct for us to consider expertise at all stages
of all discussions. And so your quoted comment is IMO simply
incorrect but its ok that we disagree about that.

S.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Dec 2014 14:01:21 +0100

To address Adrian's point below:

On 12/16/14, 11:05 PM, Adrian Farrel wrote:
> What i intended to try to draw out was the difference between the
> multistakeholder aspects in the development of the proposal, and in
> the content of the proposal (i.e. in the structures and process that
> would be put in place if the proposal was accepted).
>
>  
>
> effectively a multistakeholder organisation. But it lacks the hooks to
> the two different points.
>
>  
>
> I think this can be handled easily with a little lead in text about
> how the proposal was developed using normal IETF processes and how the
> essence of the proposal is to use existing IETF processes to continue
> to set policy for and guide the IANA protocol registry functions.
>

I propose replacement text as follow:

OLD:

        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.

NEW:

Because the IETF is open to everyone, participation is open to all
stakeholders.  IETF processes outlined in Section I were used to
develop this proposal.  Those same processes have been and shall be
used to amend governance of the protocol parameters function.  As
mentioned previously, anyone may propose amendments to those
processes, and anyone may take part in the decision process.

This text is somewhat more directed at the question.  I do not propose
to make a distinction between the different forms of
multistakeholderism, although I agree with Richard that there are
different forms.  Our response is clearly within the bounds of what the
NTIA and the ICG has discussed.

Eliot

---

From: Jefsey <[email-masked]>
Date: Wed, 17 Dec 2014 14:31:05 +0100

>stakeholders.Â  IETF processes outlined in Section I were used to
>develop this proposal.Â  Those same processes have been and shall be
>used to amend governance of the protocol parameters function.Â  As

Dear Eliot,
the problem is deeper. The IETF deliverables are the RFCs. They are 
opened to those interested in writting them.

Once delivered and used, protocols parameters are situational advises 
on the way to be use the RFCs. Some other newcomer technologies may 
use the incumbent's technology in a specific way calling for their 
own parameters.

These other technologies are users, and the I*core is in competition 
to propose the internet solution. Until now the IAB was the defacto 
referent of the I*core. This I_D (and the way the Shepherd chose to 
report the WG) show that the IAB is no more able to assume that 
responsibility. Accepted.

The remaining problem is that in this new RFC 6852 context the real 
leader is economy, i.e. ICANN advised by the WEP rather than the ISOC 
board or the NTIA. And that the IET is not prepared to this. Nobody 
care that the IETF is open to everyone: what counts is what kind of 
use economy, utilization, politics can have of its deliverable.

In forking from the IETF I just note that your deliverables are still 
good but no more intended for the today's market where the IETF is no 
more the only source in town. As was the ITU's at the end of the 80s 
(however we still use their bandwidth oriented standards and respect 
their authority). So, as IUsers we have to find an alternative to the 
8000 RFCs complexus.

Just my 2cents in the deserto.

Deep thanks for the great dedicated work you did with this draft.

Best
jfc

>This text is somewhat more directed at the question.Â  I do not 
>propose to make a distinction between the different forms of 
>different forms.Â  Our response is clearly within the bounds of what 
>the NTIA and the ICG has discussed.
>
>Eliot
>
>_______________________________________________
>Ianaplan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ianaplan

---

From: JFC Morfin <[email-masked]>
Date: Wed, 17 Dec 2014 12:12:34 +0100

>So, it would be helpful to see the proposed IAB text real soon now.

Dear Brian,

I certainly agree with you IRT IETF/IAB. The problem (and I 
referenced this today in my response to Andrew) is that we are now 
facing a fork between design and use. It is based upon two different 
visions of the network intelligence. You are the network architect 
(RFC 1958 is the reference) and so you will easily understand that 
this problem is a problem of "meta-architecture", i.e. architectonics.

The way the internet lead users intend to use the IETF architecture 
is not only what the I*core is designing it for. People have learned 
to use networking intelligence (brainware) with the internet, and 
they now want much more. And they are in capacity to get it.

This has nothing to do with a negative opposition to the I*core's 
work; this is a positive extension of the demand's expectations, that 
many - including the NTIA - have understood. Based on experience, the 
IAB has provided a pragmatic response to this situation: it is the 
OpenStand RFC 6852, in agreement with ISOC, IETF, IEEE, and W3C and 
has emphazied "permissionless innovation" where "status-quo" prevailed.

The Use demand is not only for a better Internet it is also for (1) 
other network technologies and for (2) those technologies to be 
interoperable - actually the need is for them to intricate as they 
uncouple and can mix transport lower layers and extended services upper layers.

For thirty years (1984), the status-quo strategy has supported the 
catenet's internetting globalization (American meaning: the entire 
world). The NTIA transition is looking for its globalisation 
(catenet's initial French meaning: to every part/topic/people on an 
equal footing basis, which in its own wording the NTIA phrases as 
"multi-stake-holder"). I make it a three word term because this is the issue:

-          "multi" stands for the multitude,
-          "stake" stands for a precise list of architectonical 
tasks/categories that we have to accommodate together,
-           and "holder" stands for the strong grip of every other 
one [users of the multitude and operators of what is at stake] who 
wants to retain something on an equal footing).

What we need is an Open Multi-Stake-Holder Access to information and, 
therefore, the internet to be one Open Multi-Stake-Holder Network 
among its "permissionless innovative" pears.

The draft looked to me like an architectonical/architectural 
regression compared to RFC 6852, which is surprising since Russ is a 
co-author of both and the IAB Chair.

As an IUser ("I" standing here for Internet, IETF, networked 
Intelligence), I tended to consider the IAB as a convenient trustable 
referent. However, I was not sure that the IAB was unanimous enough 
(cf. Andrew) about the governance mechanism evolution and its own 
responsibility in the existing cross-accountability framework where 
ICANN is accountable to the IAB. I wanted to clarify that with ISOC 
through my appeal IRT. RFC 6852. The NTIA interrupted it.

1. Through my appeal IRT this I_D, I want to make sure and published, 
for everything to be clear, through an IAN Disclaimer, that the IAB 
and ISOC have fully understood and accepted that they are abandoning 
the currently built-in alternative to the NTIA oversight. The IAB may 
certainly save us time and effort in committing to this point in the I_D.

2. If this is the case, there is an architectonical issue that does 
not simply involve the coexistence of the Internet, NDN, SDN, local 
networks, etc. technologies on the catenet, but also the consistency 
of their concurrent and intermixed use by people, industries, 
countries, and cultures.

This is where the fork is. It is then not a negative but a positive 
fork. It is acknowledging that the least common decision maker (LCDM) 
is no longer the I*stakeholders but rather the IUser. This means that 
the Governance referent is no longer at the internet architectural 
stratum, but rather at the individual (person, machine, topic, etc.) 
stratum and even below.

This has at least two consequences for the IAB/IETF:

1. to accept that the debate within the I*core is to be extended to 
the U*core - U standing for Uniform,  like in URL, Universal like in 
Unicode and Users like in IUse - and actively support a 
comprehensive  multi-stakeholder governance oriented complement to RFC 6852.

2. to work, with the IUsers of the global networked intelligence, on 
the Internet technology interoperability tools - what I call the 
"Intelligence Use Interface" (IUI) and want to prototype through the 
conceptual "MYCANN plug-in" through one or several Libre FLOSS 
alternative(s) to the Google, Dyn, etc. "CORPCANNs" add-ons and to 
the various "GOVCANNs" solutions (e.g. US lead multilateral GAC ICANN).

I proposed to work on this through a liaison group (IUCG@IETF) that 
Russ has accepted. I voluntarily played it low-key in the past months 
when I saw that it could confuse the issues as long as it was 
supposed to be a liaison with users who were also involved in 
non-IETF technologies – i.e. other parallel structures.

Due to the BCP 78 proprietary IP constraints, this WG has made me 
crash create an IUWG to support a multi-technology position. This 
position is to be multitechnology oriented because the Intelligence 
Use is to cooperate in the work of every intelligence networking 
technology, not only the IETF – which is what started being the case.

This an IETF fork, not as in opposition, but as in generation

jfc