NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mawaki Chango <[log in to unmask]>
Reply To:
Mawaki Chango <[log in to unmask]>
Date:
Wed, 6 Dec 2006 10:02:17 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (115 lines)
Hi,

--- Milton Mueller <[log in to unmask]> wrote:

> >>> Mawaki Chango <[log in to unmask]> 12/5/2006 3:20 PM >>>
> >Policy Recommendation C: 
> >There should be a reasonable expectation of renewal for 
> >all registry agreements.  
> >
> >Policy Recommendation D:
> >There should be a renewal expectancy for all registry agreements. 
> >
> >Policy Recommendation E:
> >There should be a presumption of renewal for all registry 
> >agreements
> >
> >NCUC: The constituency initially coined the option D, but may have
> to
> >consider C which is new and implies there will be a competitive
> bid
> >before renewal.
> 
> Our position on this was worked out. 
> We opposed competitive bidding, except for .net. 
> So we would favor D combined with G (see below). Except that
> "market
> power" is not really the problem with .net, so G would have to be
> reworded. Basically, it is acceptable to rebid the TLDs that
> VeriSign
> had legacy control of and were supposed to be re-assigned under the
> agreement that led to the reassignment of .org. (i.e., .net) 
> That does not include .com, which they get to keep under the same
> renewal expectancy. 
> 

Ye, but as I was saying the option C was not explicitly offered at
the time, so I thought it could be useful to double-check. As per the
discussion in the SP meeting and on the TF list, the main question is
rebid or not, and if so to what extent. But I beleive this is being
addressed/clarified in the context of the TF.


> >Policy Recommendation J:
> >Consensus policies should always be applied to all gTLD
> registries.
> >On an individual basis, during the contract negotiation, a
> registry
> >could present a situational analysis and justification, which
> should
> >be posted for public comment before acceptance/inclusion in the
> >contract, for an exception/or modification from a particular
> >consensus policy, due to unique circumstances of how a particular
> >policy would affect that registry. Such an exception will not
> create
> >any prejudice for extension to any other gTLD registry. 
> >
> >NCUC: J (SP consensus)
> 
> yuk. that's horrible. too discretionary. I would favor something
> like a
> modified Policy Recommendation I: "Consensus policies should apply
> to
> all gTLD registries after the nearest contract term ends."
> (Shouldn't
> change a contract in mid-stream. After the contract ends if they
> don't
> like it they can get out.)

Yes, however, there is that concern I still hear every now and then
that some existing contracts (may) have provisions for
automatic/presumptive renewal (for the last instance, see Jordyn's
point during the GNSO Council public forum,) so that the later
policies will never apply as long as renewal is concerned. This
really needs to be seriously analyzed and clarified, because people
sometimes make statement with no basis but scare other people and
prevent a serious reflection and possible change. Obviously, legal
issues are involved and it might be another battle ground for
lawyers. For example, one can argue, as a last resort, that there are
certainly provisions for terminating the contract (on ICANN request,)
and then ICANN can rebid it under the new consensus policy in effect.
But then the concern might be that, as a consequence, another lawsuit
be filed against ICANN for the sole reason, precisely, of
circumventing the contract, etc.

> >5b. Determine whether any policy is necessary to ensure
> >non-discriminatory access to registry data that is made available
> to
> >third parties. 
> >
> >Policy Recommendation R: 
> >There should be a policy to ensure non-discriminatory access to
> >registry data that is made available, but that policy should
> include
> >safeguards on protection against misuse of the data. 
> 
> Hmm, why make it avvailable at all?

Third time yes, but the registry are or may be using the data at
their own discretion, possibly releasing it to whomever it pleases
them. The possible outcome of this policy could be to avoid such
discriminatory use. The other options would then be i) status quo,
with possible discriminatory use, or ii) policy for prohibiting any
use!

Regards,

Mawaki



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

ATOM RSS1 RSS2