ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

Re: [gnso-pednr-dt] For your review - Updated recommendations

  • To: "James M. Bladel" <jbladel@xxxxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] For your review - Updated recommendations
  • From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
  • Date: Wed, 9 Feb 2011 23:10:46 +0000

+1

On 9 Feb 2011, at 23:03, James M. Bladel wrote:

> 
> Alan & Team:
> 
> 
> Reviewing my notes on Rec #5, many of the registrars on this group
> (Jeff, Michele and myself) expressed that it was not appropriate for a
> PDP to issue (what amounts to) an opinion about the RAA, and that it was
> redundant/unnecessary.  
> 
> Here's my (ever colorful) take at the time:
> 
> James Bladel: Okay. Well I'm going to go ahead and vote with Jeff on
> this one that I think that, you know, if a reseller, you know, sneezes
> and doesn't blow his nose that we're responsible for that. I mean,
> that's just understood in this business that we're responsible for what
> our resellers do. So I don't think calling that out in specific
> policies... 
> 
> So I am opposed to Rec #5 in any form, current or proposed.
> 
> Thanks--
> 
> J.
> 
> 
> 
> -------- Original Message --------
> Subject: RE: [gnso-pednr-dt] For your review - Updated recommendations
> From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
> Date: Wed, February 09, 2011 4:20 pm
> To: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>, PEDNR
> <gnso-pednr-dt@xxxxxxxxx>
> Cc: Marika Konings <marika.konings@xxxxxxxxx>
> 
> A few comments...
> 
> At 09/02/2011 04:55 PM, Diaz, Paul wrote:
> In the interest of keeping things interesting, I cannot support the
> addition of "explicit" to Recommendation #4.  When did ICANN get into
> the practice of (re)interpreting contract law?  I’m not even sure if my
> company will support Recommendation #4 in general (I’ve asked my
> counsel for input), but am completely against including verbiage that
> tries to regulate what a registration agreement can or cannot contract
> between two private parties.
> I wasn't attempting to suggest that ICANN regulate what is in the
> registration agreement (any more than it already does in several cases).
> My reference was that a post expiration change to whois triggered solely
> by the registrant accepting the "assignment" clause in a registration
> should not alter their ability to renew as intended prior to the end of
> the 8-day period.
> 
> 
> I also oppose the addition of “Through either Policy or Compliance
> Advisory” to Recommendation #5.  An Advisory does NOT carry the weight
> of Consensus Policy.  In fact, ICANN has issued ill-conceived advisories
> in the past, and has either had to back-pedal or simply ignore their own
> advice.  ICANN is supposed to be a bottom-up policymaking organization:
> I do not want to confer rulemaking authority to the Staff.
> Sorry, I was reacting to (I think James's) comment that this does not
> belong in the RAA coupled with the legal opinion that it was already an
> assumed fact.
> 
> 
> A nit: we need to be careful about typos, especially misuse of key
> terms like “register,” “registrar,” and/or “registrant” (see Rec 5
> below).
> Indeed!  Hopefully between now and the final report, we will eliminate
> any of those.
> 
> Alan
> 
> 
> P
> 
> 
> From: owner-gnso-pednr-dt@xxxxxxxxx [
> mailto:owner-gnso-pednr-dt@xxxxxxxxx] On Behalf Of Alan Greenberg
> Sent: Wednesday, February 09, 2011 11:10 AM
> To: Marika Konings; PEDNR
> Subject: Re: [gnso-pednr-dt] For your review - Updated recommendations
> 
> Marika, thanks for the quick work. This is good. See notes below.
> 
> Alan
> 
> At 09/02/2011 05:57 AM, Marika Konings wrote:
> 
> Dear All,
> 
> Please find attached an updated version of the recommendations document
> in which I've attempted to capture yesterday's discussion and
> suggestions. You are strongly encouraged to review this document and
> provide your feedback on the mailing list as soon as possible. As a
> reminder, these are the main action items:  
> + Recommendation #1: Michael to confirm whether language is specific
> enough to ensure exception for sponsored gTLD registries. (Michael
> Young) 
> 
> My recollection, and I am not sure if it was on a conference call or a
> private discussion, that Michael had thought that with the unsponsored
> exception, it was ok. I beleive that he had added the second
> "unsponsored" to make the intent clear.
> 
> 
> + Recommendation #2: Review proposed alternative wording: 'Define
> Registered Name Holder at Expiration” (RNHaE) as the entity or
> individual that is eligible to renew the domain name registration
> immediately prior to expiration'. (All) 
> 
> I would say "... the entity that WAS eligible..." but otherwise I am ok
> with this.
> 
> 
> + Recommendation #3: Review proposed alternative wording:  'If a
> registrar offers registrations in a gTLD that supports the RGP, the
> Registrar must allow the Registered Name Holder at Expiration to redeem
> the Registered Name after it has entered RGP'. (All) 
> 
> Much better than the previous wording.
> 
> 
> + Recommendation #4: Review proposed alternative wording: 'The
> Registered Name Holder at Expiration cannot be prevented from renewing a
> domain name registration as a result of WHOIS changes made by the
> registrar that where not at the Registered Name Holder at Expiration’s
> request'. (All) 
> 
> I suggest "The Registered Name Holder at Expiration cannot be prevented
> from renewing a Registered Name after expiration as a result of WHOIS
> changes made by the registrar that where not at the Registered Name
> Holder at Expiration’s explicit request."
> 
> That fixes the "Registered Name" terminology, says we are only talking
> about post-expiration renewal, and makes the request "explicit" I do not
> suggest that we complicate the recommendation itself, but suggest that
> it the comments we clearly say that an agreement included in a
> registration agreement allowing the registrar to reassign, sell or
> auction the RN post expiration does not constitute an "explicit"
> request.
> 
> 
> + Recommendation #5: Review proposed alternative wording: 'All RAA
> provisions applicable to Registrars dealing with registrar- registrant
> interactions must be carried out by a registrar. If a registrar choses
> to use a reseller, the register nevertheless remains responsible for its
> obligationsunder the RAA. (All) 
> 
> I am not sure that this wording addresses the concern that Jeff raised
> about a some terms varying per reseller. In our discussions, we said
> that in such cases, the reseller may be the one that fulfills this
> requirement on behalf of the registrar. Will Legal Counsel accept the we
> replace the end of the first sentence by "... carried out by a registrar
> or reseller."? The next sentence then makes more sense.
> 
> Typos: chooses for choses and registrar for register.
> 
> Also, I was thinking about this last night, and wondered what people
> think about prefixing this recommendation with "Through either Policy or
> Compliance Advisory, reiterate the ..."  That makes our recommendation
> more flexible. Perhaps based on comments we can refine this in the final
> report, but this lays out that we are divided about whether this belongs
> in the RAA or not.
> 
> 
> + Recommendation #6: James to circulate alternative language for
> consideration. (James Bladel) 
> + Recommendation #7: Review proposed modification. (All) 
> + Recommendation #9: Review proposed modification. (All) 
> 
> I would remove the phrase "and supported by registrars and ALAC" in
> middle of the paragraph. It no longer is needed with ICANN now being
> responsible, and it removes the sole reference to ALAC as opposed to
> others.
> 
> Recommendation 11. I would say "It is the intention to have an
> exception policy allowing Registrar to substitute alternative
> notification patterns, but this still needs to be defined."
> 
> Rec. 12 should be deleted and the rest renumbered. 
> 
> 
> + Recommendation #15, 15a and 15b:  WG members are requested to review
> these recommendations and provide feedback on whether the integrated
> version is preferred (15) or two separate recommendations (15 a & b).
> (All) 
> 
> I prefer two, as this one is simply to long and complex. I submitted
> revised wording for the 2nd one last night limiting its applicability to
> if the name is still renewable (no point in taunting a registrant if it
> isn't).
> 
> 
> + Recommendation #16: Berry/Mikey to provide alternative wording for
> consideration. (Berry Cobb / Mike O'Connor) 
> 
> In the text, the deletion made by Michael should be reinstated.
> 
> 
> 
> The objective is to finalize this language as soon as possible for
> inclusion in the proposed Final Report. As discussed yesterday during
> the call, we are trying to get the language as 'perfect' as possible,
> but there will still be an opportunity to fine-tune wording following
> the review of public comments and prior to finalization of the report.
> 
> With best regards,
> 
> Marika
> 
> 

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845





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

Privacy Policy | Terms of Service | Cookies Policy