[Internal-cg] Charter version 3

[Patrik Fältström]

After thinking a bit more, maybe we should look at things differently.

Lets start looking at the various policy development processes that exists. Each one of them should ultimately result in a policy that is received by IANA as the policy implementer. At least we have today what the NRO comes up with, what IETF comes up with and what I possibly in a sloppy way call "what gnso + ccnso comes up with". We also have .ARPA that IAB have the PDP for etc.

I.e. what we should accept, and recognize, is that we have multiple PDPs, and they vary in clarity regarding how clear their instructions are to IANA. It is also (at least to me) very different how the handover of the policy to IANA is done, how clear it is, whether IANA can say "ok, we accept this" or not, and how objective the decisions IANA is to make (according to the policy that after all the PDP has created).

Further, and this might be key, because of this, each PDP might have a different view on how oversight is to happen. How it is validated whether IANA actually follows the policy that is developed by the PDP in question.

Now, because there are such differences, and possibly during the lifetime of this CG discovered there are IANA actions that the community believe completely falls between chairs, we need to find a reasonable mechanism for (as Daniel puts it) some of these PDPs (or homes of the PDPs) that to some degree have done their homework, and some that still have many things to do.

This, I think, also falls into the discussion of accountability of ICANN, which I personally would like to split into "improvements of the PDPs ICANN run for the ccTLDs and gTLDs" and more general "accountability" issues that ICANN have with the contracted and non-contracted parties, where of course ICANN to be (stay?) accountable must prove they are implementing whatever improvements needed for the PDPs ICANN host.

That said, the tricky part for us in the CG is to understand what issues are show stoppers for the whole transition, for a transition of a part of the IANA function (if possible) and what can be "not done yet" while still we suggest transition to move forward.


I.e. instead of starting with parameters, and dividing them in clusters, we should look at the PDPs that control the parameters. And there are more than three -- although three are dominant.

   Patrik

On 18 jul 2014, at 08:58, demi getschko <epusp75 at gmail.com> wrote:

> Patrik + 1
> demi
> 
> 
> On Fri, Jul 18, 2014 at 7:14 AM, Patrik Fältström <paf at frobbit.se> wrote:
> 
> On 18 jul 2014, at 05:29, Daniel Karrenberg <daniel.karrenberg at ripe.net> wrote:
> 
> > My input:
> >
> > "The IANA parameters fall into three categories"
> > -->
> > "The IANA functions are divided into three main categories"
> >
> > Rationale: As I mentioned in the meeting we should not appear to be
> > limiting. For instance the IANA does provide service maintaining DNS
> > "glue" information for individual root name server operators. This is
> > related to domain names but not the same.
> 
> This is very important as IANA (as Daniel says) is doing more things than what can easily be divided in these three categories. They are also entangled with each other. This is also reflected in the contract between ICANN and NTIA.
> 
> Yes, SSAC is very close to be ready with a document describing the functions. When that is ready, it will help us.
> 
>    Patrik
> 
> 
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140718/b24a1390/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140718/b24a1390/signature.asc>