[Chapter-delegates] [IANAxfer] [isoc-advisory-council] NISTCG Streaming live now
Eric Burger
eburger at standardstrack.com
Thu Jul 17 07:59:52 PDT 2014
That there are three communities of interest: names (brands), numbers (RIRs), and protocols (IETF).
On Jul 17, 2014, at 10:46 AM, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
> Hello Eric,
>
> On Thu, Jul 17, 2014 at 2:59 PM, Eric Burger <eburger at cs.georgetown.edu> wrote:
> As far as Milton is concerned, users do not count. :-(
>
> Following remotely as well, may i know what part of Milton's comment implied your conclusion above.
>
> Cheers!
>
> On Jul 17, 2014, at 6:31 AM, Narelle Clark <narelle at isoc-au.org.au> wrote:
>
>>
>> Milton Mueller Charter Proposal
>>
>> Draft charter for the IANA Stewardship Transition Coordination Group
>>
>>
>> V 2.1 (July 16, 2014)
>>
>>
>> The IANA transition coordination group (ICG) has one deliverable, a proposal to the U.S. Commerce Department National Telecommunications and Information Administration (NTIA) regarding the transition of NTIA’s stewardship of the IANA functions to the Internet community.
>>
>>
>> The group’s mission is to coordinate the development of a proposal among the communities affected by the IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, each poses distinct organizational, operational and technical issues, and each tends to have distinct communities of interest and expertise. For those reasons it is best to have work on the three categories of IANA parameters proceed autonomously in parallel and be based in the respective communities of interest.
>>
>>
>> The coordination group has four main tasks:
>>
>>
>> (i) Act as liaison to the three communities of interest (names, numbers, protocols)
>>
>> (ii) Assess the outputs of the three communities of interest for workability, compatibility and consensus
>>
>> (iii) Assemble a complete proposal for the transition
>>
>> (iv) Information sharing and public communication
>>
>>
>> Describing each in more detail:
>>
>>
>> (i) Liaison
>>
>> Members of the ICG will ensure that the communities from which they are drawn are working on their part of the transition plans. This involves informing them of requirements and schedules, tracking progress, and highlighting the results or remaining issues. The role of a coordination group member during this phase is to provide status updates about the progress of his or her community in developing their component, and to coordinate which community will develop a transition proposal for each area of overlap (e.g., special-use registry)
>>
>>
>> (ii) Assessment
>>
>> When the group receives output from the independent groups it will discuss and assess their workability, assess their compatibility and interoperability with the proposals of the other groups, and verify their levels of support in the respective communities. The ICG might at some point detect problems with the component proposals. At that point the role of the ICG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues. In assessing consensus, the coordination group will rely to some extent on its members to reflect to the rest of the group the support levels within the member's own community, but the group is also authorized to engage in independent assessments, such as public notice and comment periods.
>>
>>
>> (iii) Assembling and submitting a complete proposal
>>
>> The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended scope, meet the intended criteria, that there are no missing parts, and that the whole fits together. The ICG will then develop a draft final proposal that achieves consensus within the ICG itself. The ICG will then put this proposal up for public comment involving a reasonable period of time for reviewing the draft proposal, analyzing and preparing supportive or critical comments. The ICG will then review these comments and determine whether modifications are required. If not, and the coordination group agrees, the proposal will be submitted to NTIA. If changes are required to fix problems or achieve broader support, the ICG is authorized to make minor amendments in consultation with the affected communities of interest. If, in the ICG’s opinion, broad public support for the proposal as articulated by the NTIA is not present, the parts of the proposal that are not supported return to the liaison phase.
>>
>>
>> (iv) Information sharing
>>
>> The ICG should serve as a central clearinghouse for public information about the IANA stewardship transition process. Its secretariat should maintain an independent website, under its own domain, where status updates, meetings and notices are announced, proposals are stored, the ICG members are listed, etc.
>>
>>
>>
>>
>>
>> On Thu, Jul 17, 2014 at 8:27 PM, Narelle Clark <narelle at isoc-au.org.au> wrote:
>>
>> Charter discussion happening now. Two proposals so far. IETF and Milton Mueller
>>
>> IETF Proposal:
>> The coordination group has one deliverable, a proposal to the NTIA regarding the transition of NTIA’s stewardship of IANA functions to the multi-stakeholder community.
>>
>> The coordination group performs, as its name implies, coordination, among the communities that are affected by IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, they have their own communities of interest; it is easiest to have these communities proceed on the work in parallel.
>>
>> The coordination group has three main tasks:
>>
>> (i) Ensuring that the relevant communities are working on their part of the transition plans
>>
>> This involves informing, tracking progress, and highlighting the results or remaining issues.
>>
>> The role of a coordination group member during this phase is just
>>
>> - providing status updates about the progress of his or her community in developing their component,
>>
>> - coordinating which community will develop a transition proposal for each area of overlap (e.g., special-use registry)
>>
>> - reflecting to the rest of the coordination group the consensus within the member's own community.
>>
>> (ii) Assemble a complete proposal for the transition.
>>
>> This can begin when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal."
>>
>> The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended full scope, meet the intended criteria, that there are no missing parts, and that the whole fits together.
>>
>> The CG might at some point detect problems with the component proposals.
>>
>> At that point the role of the CG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues.
>>
>> This step concludes when the coordination group achieves rough consensus that all conditions have been met.
>>
>> (iii) Information sharing and communication.
>>
>> This should be performed continuously throughout the process.
>>
>>
>>
>> On Thu, Jul 17, 2014 at 6:29 PM, Narelle Clark <narelle at isoc-au.org.au> wrote:
>>
>> All
>> The first face-to-face meeting of the IANA coordination group is taking
>> place July 17-18 in London, UK. Information about the remote participation
>> is available here: https://www.icann.org/news/announcement-2014-07-16-en
>>
>> The draft agenda is below. All times are local (UTC+1). The names of the
>> coordination group members are listed here:
>> https://www.icann.org/resources/pages/coordination-group-2014-06-17-en
>>
>>
>> == Day 1 ==
>>
>> 9:00 - 9:15
>> Introduction and level-setting. (Alissa)
>> Live streaming, administrivia, and logistics.
>> Brief explanation of why we are gathered to meet.
>> Agenda bash.
>>
>> 9:15 - 10:45
>> Introductions. (Alissa)
>> It would be useful to hear from each rep about:
>> - What group appointed them
>> - What that group does and who participates in it
>> - How that group does its work and what its decision processes are
>> - Whether they are "representing" their groups or participating as
>> individuals in the CG
>> - How they view their group's work in relation to the coordination group's
>> work
>>
>> 10:45 - 11:00
>> Break.
>>
>> 11:00 - 12:30
>> Charter of the CG. (Jari)
>> It would be good to obtain a shared understanding in the whole group of
>> the role and
>> charter of the CG. Charter proposals circulated in advance of July 17
>> would help here --
>> on the IETF/IAB side we may be able to work one up based on the IAB's
>> April 29 comments.
>>
>> 12:30 - 13:30
>> Lunch.
>> Continued discussion of charter.
>>
>> 13:30 - 15:00
>> Transition scope and expectations about work in the communities. (Paul)
>> It would be good to clarify the CG's understanding of the scope of the
>> work of the
>> transition, what the community processes need to produce, and where/how
>> areas of overlap
>> will be handled. We will want to communicate this publicly if we get
>> agreement on it.
>>
>> 15:00 - 16:15
>> Coordination group participation. (Lynn)
>> Having hopefully developed some shared understanding of the charter of the
>> CG and the work
>> expected in the communities, it would be good to verify that the
>> composition of the CG is
>> suitable for its tasks and to resolve any outstanding questions concerning
>> group
>> representation in the CG.
>>
>> 16:15 - 16:30
>> Break.
>>
>> 16:30 - 17:30
>> Self-organization. (Joseph)
>> Initial discussion about how the CG wants to organize itself, e.g., do we
>> want a chair
>> and/or vice-chair, do we need to form sub-groups for any particular tasks,
>> how will we
>> select people for these things. I think it would be good to talk about
>> this on the first
>> day and try to come to some conclusions, and then make the decisions on
>> the second day. If
>> people know they would like to serve in a particular role, they could make
>> that known to
>> the group.
>>
>> 17:30 - 18:00
>> Parking lot for items we want to come back to before day 2 or in case we
>> run over time.
>>
>>
>> == Day 2 ==
>>
>> 9:00 - 9:45
>> Parking lot for leftover charter/community work/CG participation
>> discussion items from
>> yesterday.
>>
>> 9:45 - 10:15
>> Internal and external communications needs. (Martin)
>> Whether the CG needs public and/or private mailing lists for its own work,
>> whether we
>> should stand up our own web site, where that site should be hosted, what
>> we would use the
>> web site for, what we think about ICANN's web-based platform and whether
>> it should
>> continue to exist and/or be replaced by other list(s).
>>
>> 10:15 - 10:30
>> Break.
>>
>> 10:30 - 11:45
>> Secretariat tasks and selection. (Daniel)
>> ICANN will be selecting an independent secretariat for the CG. To make
>> this selection,
>> they will need an RFP. So the CG needs to agree on what the secretariat's
>> responsibilities
>> will be, and possibly needs to come up with that RFP (or work on it
>> together with ICANN).
>> Again having a draft RFP going into the meeting might be a useful thing.
>>
>> 11:45 - 12:45
>> Lunch.
>> Self-organization, continued. (Joseph)
>> If we're ready by this point, we could solicit candidates for chair/vice
>> chair/whatever
>> other positions we think we need and hear from them each briefly about
>> what they would
>> bring to the role(s).
>>
>> 12:45 - 13:30
>> Complete self-organization.
>>
>> 13:30 - 14:15
>> Timeline. (Russ H.)
>> It would be good to get some agreement about the drop-dead date for the
>> final proposal to
>> be submitted to NTIA (assuming they need some lead time to review it and
>> socialize it
>> within the USG before the contract actually expires). We can then work
>> backwards from
>> there and set goals for when it would be good to have the community
>> discussions come to a
>> close. As with the charter, it would be helpful for someone to come up
>> with a proposal for
>> this in advance of the meeting. Jari has provided a proposal for this.
>>
>> 14:15 - 15:00
>> CG meeting/conference call schedule. (Milton)
>> We need to figure out how often we'd like to have calls and when our
>> face-to-face meetings
>> will be. This would be another good item to have a proposal for in advance.
>>
>> 15:00 - 15:45
>> Parking lot for any item we need to come back to.
>>
>> 15:45 - 16:00
>> Break.
>>
>> 16:00 - 16:30
>> Parking lot for any item we need to come back to.
>>
>> 16:30 - 17:00
>> Summary and wrap-up.
>>
>> --
>>
>>
>>
>> Narelle Clark
>> President and Board Member
>> Internet Society of Australia
>> ph: 0412 297 043
>> int ph: +61 412 297 043
>> narelle at isoc-au.org.au
>> www.isoc-au.org.au
>> The Internet is for Everyone!
>>
>>
>>
>> --
>>
>>
>>
>> Narelle Clark
>> President and Board Member
>> Internet Society of Australia
>> ph: 0412 297 043
>> int ph: +61 412 297 043
>> narelle at isoc-au.org.au
>> www.isoc-au.org.au
>> The Internet is for Everyone!
>>
>>
>>
>> --
>>
>>
>>
>> Narelle Clark
>> President and Board Member
>> Internet Society of Australia
>> ph: 0412 297 043
>> int ph: +61 412 297 043
>> narelle at isoc-au.org.au
>> www.isoc-au.org.au
>> The Internet is for Everyone!
>> _______________________________________________
>> Isoc-advisory-council mailing list
>> Isoc-advisory-council at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/isoc-advisory-council
>
>
> _______________________________________________
> IANAxfer mailing list
> IANAxfer at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/ianaxfer
>
>
>
>
> --
> ------------------------------------------------------------------------
> Seun Ojedeji,
> Federal University Oye-Ekiti
> web: http://www.fuoye.edu.ng
> Mobile: +2348035233535
> alt email: seun.ojedeji at fuoye.edu.ng
>
> The key to understanding is humility - my view !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20140717/921e45f4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20140717/921e45f4/attachment.asc>
More information about the Chapter-delegates
mailing list