[Chapter-delegates] [IANAxfer] [isoc-advisory-council] NISTCG Streaming live now
Olivier MJ Crepin-Leblond
ocl at gih.com
Thu Jul 17 09:00:23 PDT 2014
Eric,
personally speaking, that's what also got me to feel uneasy about this
proposal.
Kindest regards,
Olivier
On 17/07/2014 16:59, Eric Burger wrote:
> 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
> <mailto:seun.ojedeji at gmail.com>> wrote:
>
>> Hello Eric,
>>
>> On Thu, Jul 17, 2014 at 2:59 PM, Eric
>> Burger <eburger at cs.georgetown.edu
>> <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto: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 <tel:%2B61%20412%20297%20043>
>>> narelle at isoc-au.org.au <mailto:president at isoc-au.org.au>
>>> www.isoc-au.org.au <http://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 <tel:%2B61%20412%20297%20043>
>>> narelle at isoc-au.org.au <mailto:president at isoc-au.org.au>
>>> www.isoc-au.org.au <http://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 <tel:%2B61%20412%20297%20043>
>>> narelle at isoc-au.org.au <mailto:president at isoc-au.org.au>
>>> www.isoc-au.org.au <http://www.isoc-au.org.au/>
>>> The Internet is for Everyone!
>>> _______________________________________________
>>> Isoc-advisory-council mailing list
>>> Isoc-advisory-council at elists.isoc.org
>>> <mailto:Isoc-advisory-council at elists.isoc.org>
>>> https://elists.isoc.org/mailman/listinfo/isoc-advisory-council
>>
>>
>> _______________________________________________
>> IANAxfer mailing list
>> IANAxfer at elists.isoc.org <mailto:IANAxfer at elists.isoc.org>
>> https://elists.isoc.org/mailman/listinfo/ianaxfer
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------------------
>>
>> /Seun Ojedeji,
>> Federal University Oye-Ekiti
>> web: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/>
>> Mobile: +2348035233535
>> //alt email: <http://goog_1872880453/>seun.ojedeji at fuoye.edu.ng
>> <mailto:seun.ojedeji at fuoye.edu.ng>/
>>
>> The key to understanding is humility - my view !
>>
>
>
>
> _______________________________________________
> IANAxfer mailing list
> IANAxfer at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/ianaxfer
--
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20140717/b198e2b5/attachment.htm>
More information about the Chapter-delegates
mailing list