ICANN ICANN Email List Archives

[soac-mapo]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [soac-mapo] charter and mission

  • To: soac-mapo@xxxxxxxxx
  • Subject: Re: [soac-mapo] charter and mission
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Sat, 10 Jul 2010 15:23:00 -0400

> There are also internationally agreed conventions against racial and gender 
> discrimination which provide a positive basis for excluding certain names. 

These are the sorts of thing that fall under the MAPO exception process.  And I 
would argue pretty much the only things that legitimately fall under the MAPO 
clause as originally recommended and as current defined (though inflammatory 
phrases may as well in some rare occasions).  but other than the MAPO objection 
procedure, how else do you expect these to be objected to.

that is why I argue that the current condition are both necessary and 
sufficient.

What specifically makes it unworkable?

a.



On 10 Jul 2010, at 14:05, Milton L Mueller wrote:

> 
> Agree with W. Drake's understanding of the origin and purpose of this group.
> 
> My view (and that of NCUC from the beginning) was that MAPO as constructed by 
> staff was and is unworkable. Robin Gross may want to dig up the numerous 
> memos we sent to staff back in the 2007 time frame and add them to Richard 
> Tindal's list of source materials. As the US govt's GAC rep explained in 
> Brussels, MAPO is grounds for a national _exemption_ to international 
> recognition of names, it is not a global, uniform standard for deciding which 
> names are or are not acceptable. Since there is no global standard for 
> morality and public order, we should simply drop that term (whether we like 
> to call it MOPO or MAPO). 
> 
> However, rather than "replacing" MAPO with something else, I am hoping that 
> this group can come to an agreement that we simply don't need anything to 
> replace it. This does not mean that anything goes in the top level name 
> space. It simply means that there already are agreed international 
> conventions and standards, coupled with ICANN procedures, that meets whatever 
> legitimate concerns are out there. 
> 
> As several people pointed out during the GAC meeting, there is an objection 
> process when names are associated with communities or linguistic groups. 
> 
> There are also internationally agreed conventions against racial and gender 
> discrimination which provide a positive basis for excluding certain names. 
> 
> Let us also not forget that freedom of expression guarantees are part of the 
> enumerated international agreements that must be respected by this process.
> 
> --MM
> 
> 
>> -----Original Message-----
>> From: owner-soac-mapo@xxxxxxxxx [mailto:owner-soac-mapo@xxxxxxxxx] On
>> Behalf Of Avri Doria
>> Sent: Friday, July 09, 2010 6:51 PM
>> To: soac-mapo@xxxxxxxxx
>> Subject: Re: [soac-mapo] Re: some source documents
>> 
>> 
>> 
>> Hi,
>> 
>> We all volunteered for this group.
>> 
>> Do we have a charter?
>> 
>> Do we have a mission?
>> 
>> Are we here to provide arguments that the MAPO solution in DAGv4 is
>> sufficient and shouldn't be messed with?
>> 
>> Or do we have some other purpose?
>> 
>> 
>> I admit I was rather shaken up when GAC resurrected the subject with the
>> lines that they did not understand the solutions and had not been
>> consulted.  I know I consulted them at the time, I can't say anything
>> about why they don't understand it now.
>> 
>> So while I think it might be useful to try and explain why the DAGv4
>> MAPO solution is  sufficient, I do not know if that is our mission.
>> 
>> I should note that my arguments for DAGv4 being both necessary and
>> sufficient are my own and not supported by NCSG.  We have not polled on
>> it lately and I expect we would be of  mixed viewpoint.  At the time
>> that the new GTLD recommendations were voted on, NCUC was very much
>> against the MAPO recommendations and made no secret of it.
>> 
>> Oh yeah, one other question: do we have wiki space to start stashing the
>> reference materials?
>> 
>> a.
> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy