Paul: I still think we need to make a better delineation between operational and non operational communities. I agree that we should not strictly limit the number of submissions from operational communities. If a subcommunity of an operational community thinks that they need to make a separate proposal so be it. That should not also be an invitation to non-operational communities to submit proposals. They are welcome to submit comments on our process, on our RFP, on the operational community processes (not transparent, not inclusive..). But the role of non-operational communities should be to comment within the operational community processes and then upon publication of the proposal drafts to comment on them. There could also be the possibility of their commenting on aspects of the issues which they feel are most important to them - for example what the minimum of accountability should be. But our text still sounds like we will consider complete proposals, which I don't think we should accept... Joe On 8/19/2014 7:30 AM, Paul Wilson wrote:

Apologies for the delay, a new RFP revision is now online:

https://www.dropbox.com/s/4d2izh5jobgyu48/IANA%20Transition%20RFP%20v08.docx

Paul

On 19 Aug 2014, at 8:52 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Dear all,

I am in the process of reconciling all inputs on the latest RFP document, and will have a clean version available in Dropbox shortly.

My intention is to go run this document sequentially during tonight’s meeting, seeking ICG members’ views and suggestions.

Thanks,

Paul.

________________________________________________________________________ Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100

See you at APNIC 38! http://conference.apnic.net/38

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

Paul: Done. It is uploaded as docx as version 09. Also proposed some minor clarity changes to the preamble and added a comment responding to Martin's nervousness. We can't have Martin being nervous. Milton L Mueller Laura J and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Paul Wilson Sent: Tuesday, August 19, 2014 10:05 AM To: ICG Subject: Re: [Internal-cg] Further RFP revision

Milton, thanks for your comments on the "section 0" part. this adds some needed clarity about the whole orientation of this process.

If you can, please make further edits to the version 8 document linked below.

Paul.

On 19 Aug 2014, at 9:30 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Apologies for the delay, a new RFP revision is now online:

https://www.dropbox.com/s/4d2izh5jobgyu48/IANA%20Transition%20RFP% 20v08.docx

...

Paul

On 19 Aug 2014, at 8:52 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Dear all,

I am in the process of reconciling all inputs on the latest RFP document,

and will have a clean version available in Dropbox shortly.

...

...

My intention is to go run this document sequentially during tonight's

meeting, seeking ICG members' views and suggestions.

...

Thanks,

Paul.

---

______________

...

...

Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100

See you at APNIC 38! http://conference.apnic.net/38

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

I took one more stab at this — v10 attached and uploaded. There was some new text in v09(jha) about how people should feel free to comment to us about transparency, completeness, etc. I think that is true as a general matter, but that is not what we are asking for specifically in this RFP. That is what we will ask for — from anyone who cares to answer — after we have the proposal components submitted (by December :)). So I removed that text. I also found the new first paragraph quite confusing — it said we are issuing this RFP “for consideration” by all parties, which makes it sound like we’re asking people to comment on the RFP itself, rather than submit proposals. So, I did some editing on the first two paragraphs, and also tried to work in the good suggestion from Manal that we re-emphasize that we will direct comments to the operational communities where we can. Here is how the first two paragraphs read now: "The IANA Stewardship Transition Coordination Group (ICG) is seeking complete formal responses to this Request for Proposals (RFP) from the “operational communities” of IANA (i.e., those with direct operational or service relationships with IANA; namely names, numbers, protocol parameters). Other interested and affected parties are strongly encouraged to provide their inputs through open processes run by these operational communities. Other parties may provide comments to the ICG on particular aspects that may be covered by proposals that may be of significant interest to them, for review by the ICG as time and resources permit. The ICG will direct comments received from other parties to the relevant operational communities as appropriate. During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups.” In section 0, I edited “change” to “address” in "Identify which category of the IANA functions this submission proposes to change” since some communities might propose no changes. In section 4 I still think there are three bullet points that need elaboration, of just one sentence each, because they are not clear on their face: ·Continuity of service requirements ·Risks ·Service integration aspects For example, “Risks” seems so vague that each community could write a novel about them and not be complete. What are we really looking for here? Thanks, Alissa On 8/19/14, 8:50 AM, "joseph alhadeff" <joseph.alhadeff@oracle.com> wrote:

I have uploaded v9(jha) with a few suggested edits to further clarify the operational vs impacted communities comment process... Also a question of whether testing should be limited to Section III - are those the only changes contemplated that could impact stability and functionality?

I think we are getting pretty close to a final draft...

Joe On 8/19/2014 11:05 AM, Milton L Mueller wrote:

...

Paul: Done. It is uploaded as docx as version 09. Also proposed some minor clarity changes to the preamble and added a comment responding to Martin's nervousness. We can't have Martin being nervous.

Milton L Mueller Laura J and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/

...

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Paul Wilson Sent: Tuesday, August 19, 2014 10:05 AM To: ICG Subject: Re: [Internal-cg] Further RFP revision

Milton, thanks for your comments on the "section 0" part. this adds some needed clarity about the whole orientation of this process.

If you can, please make further edits to the version 8 document linked below.

Paul.

On 19 Aug 2014, at 9:30 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Apologies for the delay, a new RFP revision is now online:

https://www.dropbox.com/s/4d2izh5jobgyu48/IANA%20Transition%20RFP% 20v08.docx

...

Paul

On 19 Aug 2014, at 8:52 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Dear all,

I am in the process of reconciling all inputs on the latest RFP document,

and will have a clean version available in Dropbox shortly.

...

...

My intention is to go run this document sequentially during tonight's meeting, seeking ICG members' views and suggestions. Thanks,

Paul.

---

______________

...

...

Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100

See you at APNIC 38! http://conference.apnic.net/38

---

Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

---

Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

Dear All .. I have inserted a few suggestions to v10 circulated earlier by Alissa .. Suggestions are mainly on the below paragraph (also attached in track changes and loaded to the dropbox), where it now reads: "During the development of their proposals, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups, the operational communities are required to consult and work with other affected parties; likewise, in order to help ICG maintain its light coordination role, other affected parties are strongly encouraged to participate in community processes, where substantial discussions and decisions will be taking place. Information on ongoing community processes can be found at <insert url where we can compile references to all ongoing processes and may add to it later if needed.>" The main idea is to have more balanced and more convincing wording with respect to the 'other affected parties' .. I also believe that we should provide some guidance (one stop shop that includes gathered info) on where 'other affected parties' can participate .. Hope this sounds reasonable .. Kind Regards --Manal -----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Narelle Clark Sent: Friday, August 22, 2014 4:33 AM To: Alissa Cooper; joseph alhadeff; internal-cg@icann.org Subject: Re: [Internal-cg] Further RFP revision Other comments on the rest of the document likely to follow... but for now see below...

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Friday, 22 August 2014 10:40 AM

I took one more stab at this — v10 attached and uploaded. <snippage> In section 4 I still think there are three bullet points that need elaboration, of just one sentence each, because they are not clear on their face:

·Continuity of service requirements ·Risks ·Service integration aspects

For example, “Risks” seems so vague that each community could write a novel about them and not be complete. What are we really looking for here?

[Narelle Clark] When I put these things in originally, the intention was to ensure communities had considered, and properly assessed, the real operational impact of any transition. It comes from years of experience writing (and receiving responses to) engineering tenders for services supply in telcos. When something changes, it has to move from state A to state B, and hence continuing service may be interrupted. Stuff that literally cannot be shut off should be identified and a transition mapped. My view was that the communities should assess whether there were direct operational impacts like these to be considered. There may not be, but they should at least think about ensuring appropriate systems exist, or at least oversight of such processes where they do exist. The existing contract has a raft of stuff about very real operational matters. The trick is ensuring that we get back proposal wording at the 'meta-level' (meta-meta-level?), ie oversight, rather than the operational itself. Service integration aspects likewise is one triggered from thinking about direct and functional operational issues. This is the "do you have an API in operation and if so where?" question. I'm not aware of any being in place in this system right now, but you never know... some sort of automated interface might be flushed out in this process of assessment! Again, the trick will be to ensure that we get back proposal wording at the 'meta-level' (meta-meta-level?), ie oversight, rather than the operational itself. My thinking on risk was expressing a hope the communities would do a risk assessment of sorts. Preferably a formal one. We could therefore request a copy of any formal risk assessment process undertaken. [I would not want to prescribe one as that opens another array of assessment possibilities, and I understand from my standards work that the model for risk assessment is currently evolving to one better suited to complex systems, interdependency, and shades of probability, rather than direct likelihood and ratings.] Otherwise it is potentially incumbent on us to trigger a risk assessment process. Does that make these items clearer? Narelle _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

Alas, there are still some unresolved issues here. I still have to insist that the first and second paragraphs contain language that cover the same topic, but provide different meanings and thus open to door to conflicting interpretations that could cause us trouble. We need to choose one or the other of the meanings and delete the other. Here is an exegesis: From the middle of paragraph 1: "Other parties may provide comments to the ICG on particular aspects that may be covered by proposals that may be of significant interest to them, for review by the ICG as time and resources permit. The ICG will direct comments received from other parties to the relevant operational communities as appropriate." Paragraph 2: "During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups." My view is that the material from paragraph 1 must be deleted so as to not confuse people and undermine the message in paragraph 2. As it is written now, the material in paragraph 1 invites parties to provide "comments" to us on "proposals" (note the _plural_ form) that are being considered by the operational communities. To me, this seems to invite people to provide ongoing commentary on the ideas being considered by the operational communities as they develop a proposal or consider alternatives. That is not what we want. We want finished, agreed proposals. Paragraph 2 is much clearer about what we want. It "strongly encourages" affected parties to participate in the operational community process for the same of "consensus support from a broad range of...groups," but it does not completely close the door to the receipt of finished alternative proposals where consensus is not possible. I really think that section of paragraph 1 and paragraph 2 are articulating separate models of response and we cannot allow the RFP to be released with such a critical ambiguity in it. I also made a few minor changes, related to labeling IIA as Policy source and the second bullet point under IIB I also responded to Martin's comments about his nervousness. My point is that various proposals might come up with different ways of excluding or separating policy from IANA implementation. Since we can’t use the existing method (NTIA contract) to do so, this section is simply asking them to explain the implications of their changes for existing policy arrangements. However, we may be able to finesse this issue, because it says almost the same thing as bullet point 2 in section II B. So do we need it at all? Finally, a word about "testing." I don't know what kind of a parallel universe the rest of you live in, but in the world I have become familiar with as a social scientist, there is no "testing" of legal and institutional accountability arrangements. We can project or estimate based on past experience, but that is all. If there are technical and operational changes called for by a proposal, yes, we can talk about pre-testing them in some kind of laboratory set up. But asking people to "test" what will happen if the NTIA is not there and some other accountability mechanism is, is asking for the impossible. So I have altered the language to deal with this.

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Thursday, August 21, 2014 8:40 PM To: joseph alhadeff; internal-cg@icann.org Subject: Re: [Internal-cg] Further RFP revision

I took one more stab at this — v10 attached and uploaded.

There was some new text in v09(jha) about how people should feel free to comment to us about transparency, completeness, etc. I think that is true as a general matter, but that is not what we are asking for specifically in this RFP. That is what we will ask for — from anyone who cares to answer — after we have the proposal components submitted (by December :)). So I removed that text.

I also found the new first paragraph quite confusing — it said we are issuing this RFP “for consideration” by all parties, which makes it sound like we’re asking people to comment on the RFP itself, rather than submit proposals. So, I did some editing on the first two paragraphs, and also tried to work in the good suggestion from Manal that we re-emphasize that we will direct comments to the operational communities where we can. Here is how the first two paragraphs read now:

"The IANA Stewardship Transition Coordination Group (ICG) is seeking complete formal responses to this Request for Proposals (RFP) from the “operational communities” of IANA (i.e., those with direct operational or service relationships with IANA; namely names, numbers, protocol parameters). Other interested and affected parties are strongly encouraged to provide their inputs through open processes run by these operational communities. Other parties may provide comments to the ICG on particular aspects that may be covered by proposals that may be of significant interest to them, for review by the ICG as time and resources permit. The ICG will direct comments received from other parties to the relevant operational communities as appropriate.

During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups.”

In section 0, I edited “change” to “address” in "Identify which category of the IANA functions this submission proposes to change” since some communities might propose no changes.

In section 4 I still think there are three bullet points that need elaboration, of just one sentence each, because they are not clear on their face:

·Continuity of service requirements ·Risks ·Service integration aspects

For example, “Risks” seems so vague that each community could write a novel about them and not be complete. What are we really looking for here?

Thanks, Alissa

On 8/19/14, 8:50 AM, "joseph alhadeff" <joseph.alhadeff@oracle.com> wrote:

...

I have uploaded v9(jha) with a few suggested edits to further clarify the operational vs impacted communities comment process... Also a question of whether testing should be limited to Section III - are those the only changes contemplated that could impact stability and functionality?

I think we are getting pretty close to a final draft...

Joe On 8/19/2014 11:05 AM, Milton L Mueller wrote:

...

Paul: Done. It is uploaded as docx as version 09. Also proposed some minor clarity changes to the preamble and added a comment responding to Martin's nervousness. We can't have Martin being nervous.

Milton L Mueller Laura J and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/

...

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Paul Wilson Sent: Tuesday, August 19, 2014 10:05 AM To: ICG Subject: Re: [Internal-cg] Further RFP revision

Milton, thanks for your comments on the "section 0" part. this adds some needed clarity about the whole orientation of this process.

If you can, please make further edits to the version 8 document linked below.

Paul.

On 19 Aug 2014, at 9:30 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Apologies for the delay, a new RFP revision is now online:

https://www.dropbox.com/s/4d2izh5jobgyu48/IANA%20Transition%20RFP%

...

20v08.docx

...

Paul

On 19 Aug 2014, at 8:52 pm, Paul Wilson <pwilson@apnic.net> wrote:

...

Dear all,

I am in the process of reconciling all inputs on the latest RFP document,

and will have a clean version available in Dropbox shortly.

...

...

My intention is to go run this document sequentially during tonight's meeting, seeking ICG members' views and suggestions. Thanks,

Paul.

---

______________

...

...

Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100

See you at APNIC 38! http://conference.apnic.net/38

---

Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

---

Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

On 22.08.14 19:14 , Elise Gerich wrote:

Alissa,

May I suggest that the language in the RFP be consistent in using “IANA functions” instead of IANA services and other substitutes? There are services that are performed by the IANA department that are not IANA functions; for example the time zone database. Using substitutes for “IANA functions” may lead to submissions that include things that are not within the IANA Functions contract with the USG.

For example in version 10, Item I. "Description of Community’s Use of IANA” could be interpreted to include all of the things done by the IANA Department within ICANN and not just the things that are done as part of the IANA Functions Contract. Another example is the use of “IANA services” as a substitute for “IANA functions”.

Thank you, -- Elise

Elise, this is a difficult one. Take the function of maintaining the service addresses of the DNS root name servers. This is not specified in the agreement between ICANN and NTIA. Yet it is something that I would consider within the scope of this process. The time zone database may be something else and no-one may be interested in the governance and accountability of that function. It does not seem possible to make the clear distinction that you propose. So the only course of action seems to be to leave the choice to the proposers. I am optimistic that this will be fine. See also my suggestion for language in another message some minutes ago. Daniel PS: In the unlikely event that I have some spare time in the coming months, I will of course write an elaborate proposal on the governance and accountability for maintaining the time zone database and insert it into the process at the latest possible moment. :-) :-) :-) :-) :-)