ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

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

  • To: Marika Konings <marika.konings@xxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] For your review - Updated recommendations
  • From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
  • Date: Fri, 11 Feb 2011 14:31:29 +0000

Why would it even deserve to be in the notes?
Unless it was clearly pointed out that the entire thing was considered a 
surplus waste of time I couldn't support that


On 11 Feb 2011, at 14:23, Marika Konings wrote:

> Would it be an acceptable compromise if the language as proposed in the
> latest draft of the recommendations is included in the notes section
> instead of a separate recommendation? In this way it could serve as a
> reminder, but is not called out separately as a recommendation that
> requires specific action.
> 
> Just a suggestion.
> 
> Marika
> 
> On 11/02/11 14:47, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:
> 
>> i'm inclined to lean with James' point on this one.
>> 
>> if the RAA already covers it, leave it be.  if the RAA *doesn't* cover
>> it, that's a different kettle of fish.
>> 
>> mikey
>> 
>> 
>> On Feb 11, 2011, at 7:06 AM, Alan Greenberg wrote:
>> 
>>> 
>>> James, I believe that the language that was introduced in the new RAA
>>> about specific reseller obligations did just that. We have had
>>> registrars claim the since the RAA identified those obligations, others
>>> are not applicable. That is why the more inclusive language was
>>> suggested.
>>> 
>>> Alan
>>> 
>>> At 11/02/2011 12:46 AM, James M. Bladel wrote:
>>>> Thinking about Rec #5 a bit more, and wondering if including this
>>>> language could possibly be -worse- than redundant.
>>>> 
>>>> This is a bit abstract, so please bear with me:  but I was concerned
>>>> that if we made a point in this (or other) PDPs to explicitly state
>>>> something that is already held to be true, then we could introduce
>>>> inconsistencies, and inadvertently weaken the "generic" provision that
>>>> is already in the RAA.
>>>> 
>>>> Just a thought...
>>>> 
>>>> J.
>>>> 
>>>> 
>>>> -------- Original Message --------
>>>> Subject: RE: [gnso-pednr-dt] For your review - Updated recommendations
>>>> From: "Mason Cole" <masonc@xxxxxxxxxxxxx>
>>>> Date: Thu, February 10, 2011 7:16 pm
>>>> To: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>,
>>>> "James M. Bladel" <jbladel@xxxxxxxxxxx>
>>>> Cc: "Alan Greenberg" <alan.greenberg@xxxxxxxxx>, "Marika
>>>> Konings" <marika.konings@xxxxxxxxx>, "Diaz,Paul"
>>>> <pdiaz@xxxxxxxxxxxxxxxxxxxx>, "PEDNR" <gnso-pednr-dt@xxxxxxxxx>
>>>> 
>>>> 
>>>> +2
>>>> 
>>>> -----Original Message-----
>>>> From: Michele Neylon :: Blacknight [mailto:michele@xxxxxxxxxxxxx]
>>>> Sent: Wednesday, February 09, 2011 3:11 PM
>>>> To: James M. Bladel
>>>> Cc: Alan Greenberg; Marika Konings; Diaz,Paul; PEDNR
>>>> Subject: Re: [gnso-pednr-dt] For your review - Updated recommendations
>>>> 
>>>> 
>>>> +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

PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
-------------------------------
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