This is my personal copy of charter edits. I did not yet have a chance to work with Milton and others because I took too long in crafting this, but we will have a breakfast meeting to do a version 4. Just wanted to share the latest in case you have comments (and insomnia). I’m sure version 4 will be more reasonable, after breakfast :-) Jari
Jari and Charter Drafting Team: I look forward to seeing the proposed changes coming out of the breakfast meeting. I want to be sure, however, that we not be called upon to "approve" the charter during our meeting tomorrow. Especially considering that our list still is closed -- an issue that is getting some attention and hopefully will be rectified shortly -- it would be imprudent for us to approve a charter that the community has neither seen nor had an opportunity to comment. At best, we should come out of this meeting with a proposed charter that is ready for review by each of our organizations and by the community in general. Best, Jon On Jul 17, 2014, at 6:26 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
This is my personal copy of charter edits. I did not yet have a chance to work with Milton and others because I took too long in crafting this, but we will have a breakfast meeting to do a version 4. Just wanted to share the latest in case you have comments (and insomnia). I’m sure version 4 will be more reasonable, after breakfast :-)
<charterv3.docx>
Jari
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
In my reality we had consensus that the archives of the list should be open. Can we get that implemented asap and definitely before the meeting ends? It should be a simple switch in the mailing list software. In my opinion we should get consensus at the meeting that this is the substance of the charter we want to work from and that we want to get on with it. As long as that is clear we can formally adopt it soon after, hopefully without a physical meeting and possibly with some fine-tuning. Daniel
On 18 Jul 2014, at 04:37, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
In my reality we had consensus that the archives of the list should be open. Can we get that implemented asap and definitely before the meeting ends? It should be a simple switch in the mailing list software.
+1 Jari
I support it. This is my commitment of working with the group I'm representing. Best regards Wolf-Ulrich -----Ursprüngliche Nachricht----- From: Jon Nevett Sent: Friday, July 18, 2014 2:35 AM To: Jari Arkko Cc: <internal-cg@icann.org> Subject: Re: [Internal-cg] Charter version 3 Jari and Charter Drafting Team: I look forward to seeing the proposed changes coming out of the breakfast meeting. I want to be sure, however, that we not be called upon to "approve" the charter during our meeting tomorrow. Especially considering that our list still is closed -- an issue that is getting some attention and hopefully will be rectified shortly -- it would be imprudent for us to approve a charter that the community has neither seen nor had an opportunity to comment. At best, we should come out of this meeting with a proposed charter that is ready for review by each of our organizations and by the community in general. Best, Jon On Jul 17, 2014, at 6:26 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
This is my personal copy of charter edits. I did not yet have a chance to work with Milton and others because I took too long in crafting this, but we will have a breakfast meeting to do a version 4. Just wanted to share the latest in case you have comments (and insomnia). I’m sure version 4 will be more reasonable, after breakfast :-)
<charterv3.docx>
Jari
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - --- "(ii) Assess the outputs of the three communities of interest for workability, compatibility and consensus" strike "workability" as per consensus and to be compatible with the changes made later in the text. - --- "The ICG also recommends the interested parties to be involved as early as possible in the relevant community processes." - ---> "The ICG recommends that all interested parties get involved as early as possible in the development of these plans. No-one should wait until the following stage and bring their input only to the CG." Rationale: clarity and explicitness - --- (iii) Assembling and submitting a complete proposal Re-structure such that the main flow is the ideal one and exceptions are called out as exceptions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQIVAwUBU8iUmNDY5Emqa716AQJamhAAo1EFK9k00w+OlwF8DvyEYvnoPR+itRb3 E5Xx0y9uUKTeYV0BingBoJ+aXqK72F2ejnwJaZa1rkZT6pnGAIXcKNxyL8nXDGXI 6tEH0IvdBrkf4A8tJ9GzwFDbCmWFn4wX8gU5b5dqIe/0Y0VkDnWW8IuaW+sHhY1s ZlzA6JgkcHR+0ZvfMwjtV0KyPaHe4vQy+6xdVIb3O6ZfjBOiufT4tCv02yT6k1Ac ovMZlhrhkTDJoQvwEZa431GW9vqNNmT+NtVWwgvxT+X5+s0gTJS54/yL4JzFeS3L ejnuAzvuavsL5KQWodJOtyjkD6nimKBQW8+EwMqAfHhLIPLMJFHgv01fiJ8T2Iow Y3QTrHFZSi6z4om7E9T9hPOmNaCUbtyQdVubjuCBKQfQTJtagHJf1960CpotE2fe bH/U7F7GfvxQbvPsspn1MHrlc06KRWMVwzV9ktCoMHzAznzL9EoBshBfhCETqsQh qxz59PON1VlyRwZwsGbJfB9r+wkBoBc70oK5fGgnQEAFgdMZQgdg8tKdB3wnQDb+ ooacQDdHoFYINZAQH7Y5rXWv8BoFaIp+ONQb6sRt15cwVaePNmZf7aDMnT6Sgf/L xXeZKoXcL1mr/UZDec0H84lH8akWW11+sp3R+YZ47mPzjvQO/47yaWqnrehqz+ZZ gKweyuwPOIs= =Mv+4 -----END PGP SIGNATURE-----
On 18 jul 2014, at 05:29, Daniel Karrenberg <daniel.karrenberg@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
Patrik + 1 demi On Fri, Jul 18, 2014 at 7:14 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 18 jul 2014, at 05:29, Daniel Karrenberg <daniel.karrenberg@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@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
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@gmail.com> wrote:
Patrik + 1 demi
On Fri, Jul 18, 2014 at 7:14 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 18 jul 2014, at 05:29, Daniel Karrenberg <daniel.karrenberg@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@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Thanks Patrik, I think this is a very helpful way to structure our continued discussion. It appropriately acknowledges the varied nature of the functions and their associated policy development processes. The key question for each community will be identifying the delta between what exists today and what each group believes needs to exist for their respective processes once NTIA disengages. The first step is to define and understand the starting point. Keith Sent from my iPhone On Jul 18, 2014, at 8:14 AM, "Patrik Fältström" <paf@frobbit.se<mailto:paf@frobbit.se>> wrote: 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@gmail.com<mailto:epusp75@gmail.com>> wrote: Patrik + 1 demi On Fri, Jul 18, 2014 at 7:14 AM, Patrik Fältström <paf@frobbit.se<mailto:paf@frobbit.se>> wrote: On 18 jul 2014, at 05:29, Daniel Karrenberg <daniel.karrenberg@ripe.net<mailto:daniel.karrenberg@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@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
Jari, colleagues: Attached please find some proposed edits. My concerns exist in four areas. 1. we do too little to explain the consultation with stakeholders and a rough consensus process as well as the fact that we will specify the formal inputs (where we specify workability disclosure etc) we will request from them 2. by focusing so directly on the three categories we again seem to define communities of interest only in terms of the customers of IANA 3. I think it is appropriate to include a statement of the importance of maintaining the stability and functionality of the Internet in relation to IANA functions throughout the transition functions 4. I think we need also need to avow that transparency is an operating principle. Finally, I think there will be some overlap with the scope language which may require editing. Best- Joe On 7/17/2014 6:26 PM, Jari Arkko wrote:
This is my personal copy of charter edits. I did not yet have a chance to work with Milton and others because I took too long in crafting this, but we will have a breakfast meeting to do a version 4. Just wanted to share the latest in case you have comments (and insomnia). I'm sure version 4 will be more reasonable, after breakfast :-)
Jari
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
participants (8)
-
Daniel Karrenberg -
demi getschko -
Drazek, Keith -
Jari Arkko -
Jon Nevett -
joseph alhadeff -
Patrik Fältström -
WUKnoben