[Internal-cg] Redraft of RFP

Russ Mundy mundy at tislabs.com
Fri Aug 1 22:14:07 UTC 2014


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 at 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 at 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 at 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 at icann.org [mailto:internal-cg-bounces at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Proposal Requirements v5-RM1edit.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 29626 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140801/398d7218/ProposalRequirementsv5-RM1edit.docx>


More information about the Internal-cg mailing list