[Internal-cg] Fwd: Timeline

Patrik Fältström paf at frobbit.se
Thu Jul 10 17:59:00 UTC 2014


By accident a few messages ended up being fork:ed out from the mailing list.

Here they are (with approval by the involved parties).

   Patrik

Begin forwarded message:

> From: Patrik Fältström <paf at frobbit.se>
> Subject: Re: [Internal-cg] Timeline
> Date: 10 July 2014 19:28:02 +0200
> To: Jari Arkko <jari.arkko at piuha.net>
> Cc: joseph alhadeff <joseph.alhadeff at oracle.com>, Alissa Cooper <alissa at cooperw.in>
> 
> I have the same view, or similar, as Jari.
> 
> I think the primary goal MUST be the transition. Not accountability or otherwise changes of ICANN or something else.
> 
> That said, when looking at the transition, there might be implications that for example changes might be "wanted" in the PDP that ICANN runs for ccTLDs. The tricky part will then be to identify which ones of those changes are actual show stoppers for the transition, and what are things that can be put on hold and be done in parallell to the transition.
> 
> Because of this, I find it be extremely important to have consensus in the group that the coordination group must have as a goal to answer the quite well defined scope that is given to it, and nothing more. If nothing else, the current contract between NTIA and ICANN can and should be the scope.
> 
>   Patrik
> 
> On 10 Jul 2014, at 19:10, Jari Arkko <jari.arkko at piuha.net> wrote:
> 
>> Hi Joe,
>> 
>> (Adding Alissa and Patrik who I think both might have views on this.)
>> 
>> My answer: We do not yet have such a delineation.
>> 
>> We need to come up with our own scope definition.
>> 
>> My personal favourite scope is to divide it to the communities/customers and say, “do whatever you think is necessary for the NTIA stewardship to transfer to the community”. The answers on accountability might differ between names and protocol numbers, for instance. We at the IETF already have contracts and the usual escalation procedures to deal with non-performance/failure of IANA, for instance. And ICANN isn’t responsible for protocol parameters policies, so it might be that we do not need so much from the ICANN accountability process. But that is definitely not the case for names.
>> 
>> Jari
>> 
>> On 10 Jul 2014, at 20:04, joseph alhadeff <joseph.alhadeff at oracle.com> wrote:
>> 
>>> Jari:
>>> 
>>> Is there a delineation of mandates and any proposal for coordination between the accountability work and our work?  There could be areas of overlap...
>>> 
>>> Joe
>>> On 7/10/2014 1:00 PM, Jari Arkko wrote:
>>>> I thought it would be useful to start discussion of some of the topics that the group needs to deal with. I’m sending you some thoughts on the timeline of events looking forward. This is a rough draft and for discussion purposes only. Please comment!
>>>> 
>>>>>>>> 
>>>> What is described below reads as one timeline, but it may be important to understand that we actually have multiple parallel efforts: protocol parameters, addresses, and names. These efforts have several points of linkage, but allowing parallel operation is probably a good idea. As a result, the timeline may run at slightly different speeds for the different parts.
>>>> 
>>>> The NTIA has said that the September 2015 deadline is not firm, and that they could extend contracts and prolong the process beyond that. I do believe, however, that there are several reasons why getting done by then is at least useful if not even necessary. First of all, I think we all need a goal. And open-ended timelines lead to open-ended discussions. Second, people, administrations, political climate, etc. may change. So I think we should work towards September 30, 2015. But of course, we also want a good proposal to go forward.
>>>> 
>>>> In thinking about what is needed before completion, I think see at least the following tasks:
>>>> 
>>>> 1. Communities: Communities coming up with plans.
>>>> 
>>>> 2. Coordination and alignment. This includes possible iteration and even going back to the communities. It also includes, possibly, some acceptance phase with the global community for the assembled plan. For instance, the assembled complete plan should probably be something that the customers of IANA are happy with. In other words, coordination can be lead by the coordination group, but it likely includes a lot of work also in the communities.
>>>> 
>>>> 3. Test run. We may want to show off that the system can actually run in the proposed way for a while.
>>>> 
>>>> 4. NTIA evaluation and approval process.
>>>> 
>>>> The community processes are in my opinion the most important ones, and should involve most of the work. In addition, they tend to run for long times. For instance, the simplest IETF last call would be a month already. We also want to give time to the NTIA to do what they need to do. And we should not optimistically assume that there is no need to adjust and iterate over the initially submitted plans. Which may include some additional time confirming with various communities that changes are OK.
>>>> 
>>>> I’m a little unclear how much testing/demonstration we need. Arguably, the IETF probably runs the system it needs already. But there are other parts where some re-organisation and re-thinking is needed. Not really clear to me how much confidence building would be needed for those parts. Does anyone have thoughts on this?
>>>> 
>>>> In general, I think we should run this process as the much ourselves as possible, and have everything (including criteria fulfilment) very clearly spelled out for the NTIA, rather leaving any substantial work for them. But they’ll still need some time to process. And we might again need to come back and change something.
>>>> 
>>>> I guess what I’m coming to is trying to get going pretty early, so that we can iterate in later stages.
>>>> 
>>>> The tasks are obviously overlapping. For instance, the coordination group should do coordination from day 1, by understanding what the communities are doing and pointing out if they are going into conflicting directions or if there are parts that are not being addressed.
>>>> 
>>>> So here is one possible overall timeline:
>>>> 
>>>> Step 1: Communities' work - ready by Dec 30, 2014 (6 months)
>>>> 
>>>> Step 2: Coordination and alignment, including iteration - ready by March 30, 2015 (+3 months)
>>>> 
>>>> Step 3: Acceptance and communication - ready by May 30, 2015 (+2 months)
>>>> 
>>>> Step 4: Testing - ready by July 30, 2015 (+ 2 months)
>>>> 
>>>> Step 5: NTIA evaluation and acceptance - ready by September 30, 2015 (+2 months)
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140710/7018d4b7/signature.asc>


More information about the Internal-cg mailing list