[UA-discuss] What are the main things to do in UASG?

Don Hollander don at i2.org.nz
Tue Feb 17 01:44:40 UTC 2015


Thanks Edmon.

Some comments:

I would like to see some group look at measurement and possibly some certification of compliance.   By having a well considered measure of compliance, we can test the situation today and every six months (or so) and we can do this both globally and within each geographic region as well as within relevant industry sectors.   

I also wonder what industry bodies are looking at these issues, if any.   

There are some topics that are not covered in RFCs but have been/are being determined by individual developers.  It would be useful, I think, to have forum for discussion.  

I think your task force would also benefit from a technical group that provides technical solutions for people who need to actually fix the code.  This could include documentation of the issues and solutions aimed at:  Software Engineer; Systems Architect; CIO.     Somewhere else there needs to be information prepared for CEOs and Sales & Marketing Executives.    And, as you suggest, related but more targeted messages to other groups.

I also hope that we find anoint UA Ambassadors that can take the message to their circles of influence - be that geographic, industry, technology, or whatever.   (Local Rotary Groups?)  We need to make sure that they are well versed and well equipped.   Training for these folks, where possible, can happen at an ICANN Meeting.

Don




> On 17/02/2015, at 1:50 pm, Edmon Chung <edmon at registry.asia> wrote:
> 
> Some thoughts on a non-exhaustive list of items for consideration for a fuller charter:
>  
> a. scope
> - work closely with ICANN staff team to continue to drive the efforts
> - prioritization of efforts by ICANN and for recommendation to community
> - identification of collaborative opportunities
> - oversee the development of informational materials for various stakeholders (including coordinating with industry efforts)
> - studying the need and requirements for appropriate repositories (and coordinate for its development/deployment by ICANN or collaboration with appropriate industry efforts)
> - follow up with the deployment of ICANN internal policies to support UA
> - development of measurements/indices/surveys/etc. to measure UA readiness
> - continue to track progress of UA
> - inviting non-ICANN community to the initiative and proactively reaching out to non-ICANN community events/initiatives
>  
> b. structure
> - suggest: 3 co-chairs or 1 chair and 2 co-chairs (think a flatter organization rather than “vice” chairs seem more collaborative)
> - taskforce (sub groups): 2 coordinators (instead of called chairs) for each taskforce
>  
> c. format / activities
> - face-to-face meetings at ICANN meetings
>             1. steering group meetings
>                         - track progress of activities by ICANN staff and taskforces
>                         - calibration/recalibration of priorities
>                         - review/revise action plans
>             2. public meetings
>                         - invite non-ICANN community participants to share experiences
>                         - update community on progress and activities of UASG
>                         - continue to recruit participation in on-going activities
> - mailing list discussions
> - conference calls as need be in between ICANN meetings
> - coordination of activities outside of ICANN (by community members as well as ICANN staff)
>  
>  
> As for Taskforces (sub-groups), think we should consider the following:
>  
> A. information materials development / coordination
> B. business community & consumer outreach
> C. technical & academia community outreach
> D. government & ngo community outreach
> E. stocktaking of issues / measuring / tracking of progress
>  
> Reason I think B/C/D should be separate I because the messaging may be quite different, and the set of people interested may also be different.  While outputs/works from A and B/C/D would obviously intertwine, I see that in the initial stages, B/C/D would work independently to start the awareness phase, while A completes its work by collating industry experience and best practices.  Thereupon, in following stages, B/C/D can take the work products of A to further disseminate.
>  
> Above is a quick download of some of my thoughts, hope it is not too long and convoluted.
>  
> Edmon
>  
>  
>  
>   <>
> From: ua-discuss-bounces at icann.org <mailto:ua-discuss-bounces at icann.org> [mailto:ua-discuss-bounces at icann.org <mailto:ua-discuss-bounces at icann.org>] On Behalf Of Christian Dawson
> Sent: Tuesday, February 17, 2015 1:45 AM
> To: Nelson, Nick
> Cc: UA-discuss at icann.org <mailto:UA-discuss at icann.org>
> Subject: Re: [UA-discuss] What are the main things to do in UASG?
>  
> Totally agree with the concept of needing to know why we’re here, but I saw #3 slightly differently. A charter will define a broad scope and include a definition of the broad problem set. I’m taking a crack at that broad "Mission, Purpose and Need” in the draft Charter I’m taking first draft on.
>  
> What we’ll need at stage 3 is a deep dive into the scope of the issue - it’s various components and stakeholders. I think that’s a distinctly different project and worthy of its own point. 
>  
> So ultimately I agree, but think we can cover "Mission, Purpose and Need” sufficiently in the draft Charter to get by.
>  
> C
>  
>  
>> On Feb 16, 2015, at 9:39 AM, Nelson, Nick <nicknels at amazon.com <mailto:nicknels at amazon.com>> wrote:
>>  
>> I'm coming in a bit late but that gives me good perspective and I think the total list from Ram is accurate. However, I'd argue that both Christian is right with defining structure and charger, but also first - we should define the Problem space. 
>> 
>> The problem space to me is ultimately why we're all here right. "What are we trying to solve for?" and even more so, "How is this group going to benefit the ultimate end-user?" 
>> 
>> From: ua-discuss-bounces at icann.org <mailto:ua-discuss-bounces at icann.org> [ua-discuss-bounces at icann.org <mailto:ua-discuss-bounces at icann.org>] on behalf of Christian Dawson [dawson at i2coalition.com <mailto:dawson at i2coalition.com>]
>> Sent: Monday, February 16, 2015 9:22 AM
>> To: Ram Mohan SMTP
>> Cc: UA-discuss at icann.org <mailto:UA-discuss at icann.org>
>> Subject: Re: [UA-discuss] What are the main things to do in UASG?
>> 
>> Ram,
>>  
>> I think this is a good list with one proposed change. I am 3-4 pages into a draft charter for people to look at, which proposes a structure. I’d say we need an agreed-on structure before we pick leaders to fill defined roles, so I suggest flipping 1 and 2.
>>  
>> I probably can’t get far enough along to put my draft charter up for review until tomorrow - chairing a small anti-SPAM working group on SPAM in the Cloud at M3AAWG today. (If anybody else from this group is at M3AAWG come find me and we can chat/complain about timezones together.)
>>  
>> -Christian
>>  
>>> On Feb 14, 2015, at 11:21 AM, Ram Mohan <rmohan at afilias.info <mailto:rmohan at afilias.info>> wrote:
>>>  
>>> Team,
>>> Trying to get an inventory of the main tasks in front of the UASG, in chronological order:
>>>  
>>> 1.       Group leadership
>>> 2.       Group structure and charter
>>> 3.       Definition of problem space
>>> 4.       Prioritization of problem space
>>> 5.       Definition of approach to problem spaces
>>> 6.       Delegation of work
>>> 7.       Execution of work
>>> 8.       Follow-through
>>>  
>>> Appreciate input.
>>>  
>>> -Ram
>>>  
>>> ------------------------------------------------------------------------------
>>> Ram Mohan
>>> Executive Vice President & CTO
>>> Afilias |Ireland|Canada|USA|India
>>> o: +1.215.706.5700 x103; m: +1.215.431.0958; f: +1.215.706.5701
>>> Skype: gliderpilot30

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/mailman/private/ua-discuss/attachments/20150217/c749ea6b/attachment.html>


More information about the UA-discuss mailing list