[CRISP-TEAM] Invitation to a panel discussion with the ICANN Board on 25 April

[Izumi Okutani]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the feedback Bill.

I also had a chance to have Skype chat with Nurani and she suggested to add meeting the target date of the submission is important which I agree.
(This topic is listed as one of the points to cover in the panel but it worth reiterating it and to emphasise)

On 2015/04/25 14:26, Bill Woodcock wrote:
> 
>> On Apr 24, 2015, at 1:15 PM, Izumi Okutani <izumi at nic.ad.jp> wrote:
>> - In terms of the transition process, transparency is extremely important. This importance has been confirmed community discussions at RIR forums.
>>   We have requested the RIRs to be transparent in the process and trus the RIRs will stand by this.
>>   We expect further coordination is to come throught the ICG but in case there rises any situation to consider changes to the proposals developed from the community, it should be communicated in transparent manner to the community
>>   with rationale on what this reconsideration is needed. It would be helpful if ICANN Board can gives this assurance in any area ICANN would be involved.
> 
> Agreed, exactly as you���re putting it.

Noted thanks.
I will say tranparency is "essential " instead of "important".

>> - From this timing, close communication between the three operational communities is needed, not necessarily only through the ICG.
>>   If each of the operational communities would highlight and publicly share what needs coordination with other operational communities, it would be very helpful.
>>   From the numbers, it is IPR. We have shared this at ICANN52 but if there is additional better way in communicating this, happy to consider it.
>>   The numbers are open to talk and communicate with the chairs of the other operational communities as a way of deepning the understanding of each others situation.
>>   With the note that coordination should be take place through the ICG and no decisions are to be made.
> 
> Honestly, I don���t see that there���s much to be gained from leaning on this point.  I think that we should acknowledge that there are specific, but minor, interdependencies, such as the need to publish numbers allocations via the in-addr DNS, but that these are fundamentally trivial technical issues, with equally trivial solutions.
> 
> See Pindar���s last posting to the IANAXFER list which touches on the benefits of staggering the three transitions; I agree entirely with that.

I totally agree with Pindar's point as well.

I also don't feel the need to communicate with other communites on the CRISP proposal except for IPR issue. It is more for us to be able keep track of the names discusssions.
I can perhaps bring this to the last point I mention.

>> - In terms of the condition of the transition, stability is the priority. to do this, keep changes to the minimum, focus on elements what is affected by the stewardship transition from the NTIA.
>>   There seems to be misunderstanding that the numbers community wishes to move away from the ICANN.
> 
> If such a misunderstanding exists, please reiterate, from the CRISP document:
> 
> III.A.1.        ICANN to continue as the IANA Numbering Services Operator via a contract with the RIRs
> 
> To maintain stability and continuity in operations of the IANA Numbering Services, very minimal changes to the arrangements listed in Section 2.2 are proposed, including the identification of the proposed initial IANA Numbering Services Operator. As noted in numerous NRO communications over the past decade, the RIRs have been very satisfied with the performance of ICANN in the role of the IANA Numbering Services Operator. Taking this into account, and considering the Internet Number Community���s strong desire for stability and a minimum of operational change, the Internet Number Community believes that ICANN should remain in the role of the IANA Numbering Services Operator for at least the initial term of the new contract.

I am not sure if I will have time to exactly quote word by word but I will refere to it and paraphrase.

> And, if relevant, extract from the ARIN meeting just concluded:

OK, thanks. I am not likely to refer to this but helpful to have a quote from ARIN discussions.

> "All five RIRs are clear that we have full confidence in ICANN and that ICANN has done an excellent job. I would like to point out that there was a time when ICANN was unable to meet even the most basic SLAs. They hired David Conrad to fix that problem, and he did an excellent job. Barbara Roseman was also a big part of making that happen, taking ICANN from being an organization with very long lead times���after which you had to poke them again and figure out where the ball had gotten dropped���to one that performs like an operational organization with a ticketing system and time-to-respond and so forth.  So the situation is one in which we have full confidence at this point.���
> 
>> We simply want to have the ability for the numbers community to chose the IANA operator.
>>   This is what the NTIA IANA contract says today, and we are simply replacing this to the community, as a part of the stewarship transition to the bottom up, global, multistakeholder community.
> 
> Exactly.
> 
>>   As a related point, concerns have been expressed on this may destabilize the system or lead.
>>   It is hard to imagine a situation where the numbers community would wish to move to the IANA operator at the risk of operational stability, as this would affect the services they will be receiving.
>>   This balance will be kept even more than the NTIA as it is in the numbers community to maintain stable and reliable operation.
> 
> Exactly.
> 


Izumi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVO4VtAAoJEG3QU4wBYACihmQP/j3WTZIvlVVBH5dmn0cgCRMG
uNCSGDF664omSCgNzkplrp5EayuS4fsnPe0ZkaMetpf+4daG7sZtnk2JyA+3KQ9f
/AAWmbXU2oo7QhCBY/WOx8m3cX4oPZEQhH9qSAIbh5G7ZpA7LT7mnbWWBY1Bgx0x
YfDbNIuG3wdvZPtkuCvxduNKd4Doagl9cB1zOFBBw+hpZgn3MV4Fzf0j99CKMn90
0VnDhsuveP7iMfQarjZXE/TvlBeFGulT3soYJLDMXkfgBJuxx2+XUQLGi1nUvBIK
MokLLzB55UvE0iydNrQQz2YrMl8DyXUxF5ZL4HEZK219XbgbDGc2vkTWct7Tz9Lj
iwMmk7CWGRoPOqG6g1kePiNojAruSxD0bsJhuX8SrRe5ki3XsEUVnGV9W1A34nGn
HvfMZxiZK8kvLRyudgV0gn1Y2eC/iMjaQ3DWBi9sMBJsl+PAEONfV/5WMA7JrA6G
A1fK64hbVFmUXp3LYt8pMRl3YPJJGp7k6Hr6srL1pEdpum5NxyyYr/N4+eZcqQQA
tT4rfZi1uKRSOfiGJCGmLPz4GYWuqbyDtwStRgoYA2Ie0CLLksPuaqN/FDkvZwKo
tdGjKko0KCD8asbo2fOf0M+/9DxIvw+qkdbxLkXEPOpKJrJwpeu70To1rA3m5VoT
DyKb+h481UzN5GD8nwHg
=gP1/
-----END PGP SIGNATURE-----