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