I don’t have a fixed view or preference on that Narelle. Webforms can be a bit unfriendly, but we could make one available for those who want it, while also allowing text/document responses. For now I think the important thing is to confirm whether this is the approach we want to take, and to complete the document. 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 On 25 Jul 2014, at 4:25 pm, Narelle Clark <narelle.clark@accan.org.au> wrote:

This RFP is going to be distributed online via a web based form, yes?

N

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Paul Wilson Sent: Friday, 25 July 2014 2:04 PM To: ICG Internal Subject: [Internal-cg] Redraft of RFP

Thanks to comments from a few of you, here's a further draft of the RFP.

My feeling is that a very structured approach is needed, and I hope that we can gather all the needed information in this way. From the IP addressing community, I think we could provide a detailed and complete response in this format, but other will need to be able to do so too.

I hope this is useful.

Paul.

Dear All Thank you very much for initiatives. However, these draft must be further discussed at out f2f meeting in ,I hope 06 september to cover view points of every body once discussed in detail. I do not recommand its release until it is finally approved by ICG Regards K.ARASTEH

Actually Paul, while it would be nice to release something before 6 September, I don't see it as critical that we do. It would be better to make the RFP something that we discuss directly at our next f2f. The reason earlier release is not so significant is that the names communities have not even chartered their Cross Community Working Group. There is no way that the CCWG would be in a position to respond to an RFP in the month of August anyway. So I would rather spend more time on the RFP and get it right. (There is also, of course, a chance that spending more time on it will make it more muddled, as seems to have happened to our co-chairs discussion, but I will work hard to fend off clutter and muddle and other barnacles that might accrete on it as we discuss it more). --MM -----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Paul Wilson Sent: Monday, July 28, 2014 2:38 AM To: Kavouss Arasteh Cc: ICG Internal Subject: Re: [Internal-cg] Redraft of RFP Dear Mr Arasteh I believe we were aiming to release a CFP (in some form) by the end of July; and certainly it will introduce a long delay if we wait until 6 September. I do agree that this process needs more work, and sorry not to have been able to advance it further myself; but I also think it is important to release something much sooner than 6 September. My suggestion would be to revise the current document, and get it into a form which is suitable for release as a draft. This would serve both to provide guidance, and to solicit feedback from the communities. If released in the next week or two, we could receive that feedback in time for our September meeting. Paul. On 28 Jul 2014, at 8:36 am, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:

Dear All Thank you very much for initiatives. However, these draft must be further discussed at out f2f meeting in ,I hope 06 september to cover view points of every body once discussed in detail. I do not recommand its release until it is finally approved by ICG Regards K.ARASTEH

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

Thanks Milton, I’m sure you have some good points. The balance of "specific vs generic" is going to be difficult (it certainly has been for me). Perhaps we can ensure that the call is expressed in a way which is as permissive and flexible and possible, which also providing helpful and specific guidance. Anyway, I look forward to your edits, which I hope will include other specific suggestions which have been shared. 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 On 26 Jul 2014, at 2:47 am, Milton L Mueller <Mueller@syr.edu> wrote:

Paul, I still think this needs work. I will submit an edited version as soon as I can. My main issue is twofold:

A) In many ways this is too specific, and the specificity reflects assumptions about the nature of the proposals we will get that may not be applicable in certain situations. E.g., when you talk about the "frequency" of an accountability mechanism you seem to be assuming some kind of committee-style oversight similar to the ATRT, and excluding other kinds of accountability mechanisms, such as appeals processes or structural solutions which do not rely on such committees. In some ways, this template needs to be made more generic.

B) Section 3 on oversight does not distinguish adequately between oversight of policy development and oversight of implementation.

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Paul Wilson Sent: Friday, July 25, 2014 12:04 AM To: ICG Internal Subject: [Internal-cg] Redraft of RFP

Thanks to comments from a few of you, here's a further draft of the RFP.

My feeling is that a very structured approach is needed, and I hope that we can gather all the needed information in this way. From the IP addressing community, I think we could provide a detailed and complete response in this format, but other will need to be able to do so too.

I hope this is useful.

Paul.

Folks, As part of my recent SSAC work, I have spent a fair bit of time examining the current documents that make up the NTIA/ICANN IANA Functions Contract. This leads me to raise two items that should be included in the RFP to the communities. The first item is that we should make as much use as possible of the existing Contract documentation in our RFP to the communities and in our evaluation of their responses. - The particular part of the contract I'm referring to is the ICANN Proposal [1]. When the Contract was issued to ICANN, their Proposal was made part of the contract itself thus binding them to do what they proposed. As a result, it is logical to expect that [1] is an accurate reflection of what is currently being done by ICANN in performing the IANA functions. For example, Figure 1.2-3 on page 32 and the surrounding text describes what happens in the Autonomous System (AS) Number Allocation Process. There are many other figures that provide similar detail for everything (as far as I can tell) that ICANN considers to be part of it's IANA functions. - I think making use of the ICANN Proposal will provide multiple benefits to both the ICG and the communities. First, making use of [1] as a significant point of reference for the proposals and the subsequent ICG review, it should be much easier for the communities and ICG to have a common view of what actually constitutes the IANA functions (& easier to identify what's not part of the functions). Secondly, there is a great deal of detail already contained within [1] that the communities should not have to reproduce in their proposals (if they did, this would likely result in a bunch of inconsistencies). Also, if [1] does not reflect actual, current practice, that would be useful information for the communities and the ICG to consider. Thirdly, if the communities' proposals identify what changes need to occur from the current processes by reference to [1], it should be much easier for the ICG to identify if there are conflicts between the various proposals as well as where the proposals may overlap. The other item related to the IANA Functions Contract is if another contract or some equivalent or comparable document is thought to by required by the respective communities to provide some sort of legal framework. There certainly have been a number of discussions about the need for some sort of legal framework that would replace the current Contract with NTIA so it seems that it would be good for the ICG to ask the communities provide their views on the need for something else in the future (after the NTIA contract ends). I also share Russ Housley's concern with the 'provide alternatives' sentence is probably not appropriate so I have deleted it in the edited version of the RFP (that should be attached). It seems to me that by having a primary reference of [1], we can eliminate the need to ask for alternatives from the communities. Russ [1] available at: <http://www.ntia.doc.gov/other-publication/2012/icann-proposal> I've also placed copies of the files in our NTIA Documents on DropBox On Jul 31, 2014, at 6:39 PM, Paul Wilson <pwilson@apnic.net> wrote:

Hi Milton,

are you still planning to send a revision? I don’t have anything form you so far.

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

On 26 Jul 2014, at 2:47 am, Milton L Mueller <Mueller@syr.edu> wrote:

...

Paul, I still think this needs work. I will submit an edited version as soon as I can. My main issue is twofold:

A) In many ways this is too specific, and the specificity reflects assumptions about the nature of the proposals we will get that may not be applicable in certain situations. E.g., when you talk about the "frequency" of an accountability mechanism you seem to be assuming some kind of committee-style oversight similar to the ATRT, and excluding other kinds of accountability mechanisms, such as appeals processes or structural solutions which do not rely on such committees. In some ways, this template needs to be made more generic.

B) Section 3 on oversight does not distinguish adequately between oversight of policy development and oversight of implementation.

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Paul Wilson Sent: Friday, July 25, 2014 12:04 AM To: ICG Internal Subject: [Internal-cg] Redraft of RFP

Thanks to comments from a few of you, here's a further draft of the RFP.

My feeling is that a very structured approach is needed, and I hope that we can gather all the needed information in this way. From the IP addressing community, I think we could provide a detailed and complete response in this format, but other will need to be able to do so too.

I hope this is useful.

Paul.

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

Daniel, Thanks for the comments, perhaps I should provide a bit more background on the thinking that led me to make the suggestion to ask the communities to make direct references when appropriate: First, since our primary (only job) as the ICG is to assemble a single proposal to the NTIA for replacing the NTIA functions, referencing the NTIA contract (that contractually does include the ICANN Proposal) should make the single (integrated) proposal delivered by the ICG much more understandable by NTIA. This seems rather important since NTIA will be the ones that decide on whether or not the single proposal is satisfactory - it needs to be understandable by them. Second, since the ICANN Proposal is part of the NTIA contract (NTIA did this by way of a process that's common in US Govt contracts), it should accurately accurately reflect a the current IANA processes carried out by ICANN IANA functions staff (it would also be beneficial to know if current practice differs from the contract requirements). We want the communities to describe the current processes and the ICANN Proposal provides excellent detail about (if you'll excuse some SSAC terminology) how ICANN provides the "Policy Implementor" functions. Additionally, it should be much easier for the communities to describe what they want to see changed from the current operation. I don't see any risk of the ICG being accused of prejudice if all communities are asked (not required) to make reference to what should be current practice. Thirdly, if the various communities describe their current and desired processes for the IANA functions through references to a single reference point (i.e., the ICANN Proposal), it should make the ICG's job of identifying conflicts and inconsistencies much more achievable. I have had several experiences evaluating RFP responses (including ones where the selectees were supposed to work together compatibly and without conflicts) and I can say with certainty that it is nearly impossible to identify conflicts, let alone determine compatibility, unless the proposals are asked to relate to some common point of reference - I'm suggesting that the ICANN Proposal portion of the current NTIA contract be that common point of reference. Russ On Aug 4, 2014, at 1:01 PM, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:

On 2.08.14 0:14 , Russ Mundy wrote:

...

... The first item is that we should make as much use as possible of the existing Contract documentation in our RFP to the communitie

Russ,

I agree that communities would be well advised to study this documentation and that we should reference it on an appropriate 'resources' page.

Using any of this language directly or referencing it in our RFP is not necessary. It would only provide an opportunity to accuse us of prejudice.

We are in fact doing much more by requesting that proposals start with a description of the status-quo. This will direct the communities in the right direction and also force them to agree on their perception of the status quo.

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

Many thanks Paul for the redraft and for triggering this discussion .. I don't have editorial comments yet but I have a couple of questions/general comments: - How many categories of communities are we talking about, 2? 'customer communities of IANA' and 'others'? I can see that we keep referring to 'communities', 'customer communities of IANA', 'all communities of interest', 'other parties with specific interest', which I believe is a bit confusing to anyone who was not part of the discussions .. - I think the draft is a bit sophisticated, focusing on the 3 'customer communities of IANA' .. should we split the draft into 2 in order not to confuse everyone with the specific requirements addressed to the 3 identified IANA customers? - Regarding the 3 customer communities of IANA, I believe we are basically asking for 3 things: 1. Status Quo of current services (guided by the requested information elements) 2. Transition proposal (which I don't see explicitly requested in this draft) 3. Foreseen implications of the transition, on the current services, in light of the submitted proposal Is my understanding accurate? - Generally speaking, can proposals be as long as the submitter wishes? With the tight timeframe we have, should we be guided by NETmundial (there was a limit on the size of submissions) and encourage concise (not sure if this is the right word) proposals? Or are we confident, having already encouraged submissions through the relevant communities? - Finally, what is the deadline for finalizing this draft .. @Russ, I fully agree that ICG should not be accepting or rejecting proposals .. Unless the intention here is that communities may include distinct alternative options, all equally satisfactory to them, where ICG may then choose from the submitted alternatives based on workability and compatibility with the different proposals submitted by other communities .. Just thinking out loud .. Kind Regards --Manal -----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Russ Housley Sent: Friday, July 25, 2014 11:28 PM To: Paul Wilson Cc: ICG Internal Subject: Re: [Internal-cg] Redraft of RFP Paul: I have several small concerns, but I am _very_ worried about one sentence. I want to raise that first. Maybe that resolution will sort my smaller concerns too. I am troubled by the statement, "Where possible and appropriate,distinct alternative options should be identified". I don't want the ICG discussing alternatives. I am certain that we do not want the ICG accepting or rejecting alternatives. Maybe I am misunderstanding your intent. Russ On Jul 25, 2014, at 12:03 AM, Paul Wilson wrote:

Thanks to comments from a few of you, here's a further draft of the RFP.

My feeling is that a very structured approach is needed, and I hope that we can gather all the needed information in this way. From the IP addressing community, I think we could provide a detailed and complete response in this format, but other will need to be able to do so too.

I hope this is useful.

Paul.

<Proposal Requirements v5.docx>

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

On 26 Jul 2014, at 7:28 am, Russ Housley <housley@vigilsec.com> wrote:

Paul:

I have several small concerns, but I am _very_ worried about one sentence. I want to raise that first. Maybe that resolution will sort my smaller concerns too.

I am troubled by the statement, “Where possible and appropriate,distinct alternative options should be identified”. I don't want the ICG discussing alternatives. I am certain that we do not want the ICG accepting or rejecting alternatives.

Maybe I am misunderstanding your intent.

Well, my intent was to recognise that there may be various options involved in coming to a conclusion, and if so, these alternatives should be supplied by the communities, not invented by the ICG. If we invite singular and non-negotiable proposals from the communities, we might find ourselves without a single workable solution; so my thought was that if alternatives are available which are satisfactory to the communities concerned, then these should be spelt out so that the ICG can find a better final solution. This would indeed involve making judgements and accepting/rejecting alternatives, but I didn’t see those things ruled out by the Charter (item iii). Paul.

Russ

On Jul 25, 2014, at 12:03 AM, Paul Wilson wrote:

...

Thanks to comments from a few of you, here’s a further draft of the RFP.

My feeling is that a very structured approach is needed, and I hope that we can gather all the needed information in this way. From the IP addressing community, I think we could provide a detailed and complete response in this format, but other will need to be able to do so too.

I hope this is useful.

Paul.

<Proposal Requirements v5.docx>