[Internal-cg] Questions from webinars

Lynn St.Amour Lynn at LStAmour.org
Fri Aug 21 14:22:02 UTC 2015


Hi Mohamed,

Thanks much for your response.  As the ability to change IFO is a key part of the OC proposals (and a central component of accountability), we should be clear on this, so calling it out is important.  At the same time, the ICG evaluated all the proposals - separately and combined - including the criteria that the transition "maintain the security, stability, and resiliency of the Internet DNS", and the ICG said it believes the proposals (combined) support this.  

You also ask if we should "propose mechanism/rules that ensure proper implementation of IFO change if it happened".  This was meant to be addressed in the "Proposed Post-Transition Oversight and Accountability" Section of each proposal.  This section was to describe what changes each community was proposing (or might implement) in light of the transition and it was to cover appropriate oversight and accountability requirements.  Some relevant text from the Protocol Parameters Proposal is included below, as an example (1).   

Given the additional clarity coming regarding the PTI and associated structures (and OC participation (or not) in those structures), it may be helpful to add an agenda point on this for our Sept. meeting.

Hope this covers your concerns well enough for now, and I note your support for Alan's formulation.

(1) For example, in the Protocol Parameters proposal, Paragraph 3062 says:

<quote>
	"However in the absence of the NTIA contract a few new arrangements may be needed in order to ensure the IETF community’s expectations are met. Those expectations are the following:

	- The protocol parameters registries are in the public domain. It is the preference of the IETF community that all relevant parties acknowledge that fact 	as part of the transition.

	- It is possible in the future that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledge that it will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition to subsequent operator(s), should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use the protocol parameters registries or other resources currently located at iana.org."

<end quote>

Best,
Lynn

On Aug 20, 2015, at 7:31 PM, Mohamed El Bashir <mbashir at mbash.net> wrote:

> Thanks Lynn for the draft answer, Alan formulation is good.
> 
> My concern is the last part of the answer :" including choosing/changing the IANA functions operator for their part of the IANA functions", I am not disputing the OC right to make such decisions based on the results of its evaluation of IFO performance for their related functions,  But I am a bit concerned regarding the possibility of one OC changing/splitting the IANA functions unilaterally in the absence of a proper coordination mechanism, such a change might impact the stability and security of the Internet ( not fulfilling one of NTIA requirements ).
> 
> As our mandate is to produce a harmonized combined final proposal, shouldn't we consider the unity of IANA function is an objective and propose mechanism/rules that ensure proper implementation of IFO change if it happened.
> 
> Kind Regards,
> Mohamed
> 
> ( sent from a tablet device apologies for any misspellings)
> 
>> On Aug 20, 2015, at 8:34 PM, Mueller, Milton L <milton.mueller at pubpolicy.gatech.edu> wrote:
>> 
>> I like Alan's reformulation too.
>> --MM
>> 
>>> -----Original Message-----
>>> helpful.  Alan, I think your reformulation adds a lot of clarity to the original
>>> question, and helps to clarify the respective roles of the 3 OCs.
>> 
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at mm.ianacg.org
>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org




More information about the Internal-cg mailing list