RE: [council] PEDNR Motion
Alan,
Please see my comments inserted below.
Chuck
> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Alan Greenberg
> Sent: Thursday, April 02, 2009 3:40 PM
> To: Tim Ruiz; GNSO Council
> Subject: RE: [council] PEDNR Motion
>
>
> Tim, I will let Marika definitively address that.
> But here is my understanding.
>
> There are two types of "out-of-scope":
>
> - Those that are deemed by legal council to be out of the
> GNSO scope, and those require a higher threshold to initiate a PDP.
Chuck: I do not know to what you are referring regarding the latter, 'those
require a higher threshold to initiate a PDP'. Please explain.
>
> - Those that are out-of-scope of the picket fence. If deemed
> to be within Council scope as above, they do not require the
> higher threshold, but of course cannot be used to set a
> consensus policy.
Chuck: Again, where does the 'higher threshold' concept come from. In the case
of possible consensus policies, if the Council recommends a consensus policy
with a supermajority vote, then the threshold for the Board rejecting it is
higher than it is if the Council recommends it with a simple majority vote. Is
that what you are referring to?
>
> I was told that the entire PEDNR issue is within GNSO scope,
> and it was worded as such based on that advice. But clearly
> only parts are within the picket fence of the RAA.
>
> All of this is not what I understood going into this process,
> but *IF* I got it right, that is the current interpretation
> according to staff.
>
> Alan
>
> At 02/04/2009 02:43 PM, Tim Ruiz wrote:
>
> >If that's the type of thing we want this group to look at then it
> >requires a different threshold of approval, correct? It's not
> >appropriate to try and include out of scope things with in
> scope things
> >because the latter has a lower threshold of approval to get started.
> >
> >So perhaps that's the fundamental question. But I suggest
> this motion
> >stick with what's in scope.
> >
> >Tim
> >
> > -------- Original Message --------
> >Subject: RE: [council] PEDNR Motion
> >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
> >Date: Thu, April 02, 2009 1:14 pm
> >To: GNSO Council <council@xxxxxxxxxxxxxx>
> >
> >
> >Tim, We are talking to different ends. I am talking about changes to
> >how compliance is measured or enforced.
> >
> >I will give a specific and current example. The February 2009
> >Contractual Compliance Semi-Annual Report. One of the measures was
> >whether Registrars were honoring the Deletion and Renewal Consensus
> >Policy. This was carried out by reviewing Registrar web sites.
> >
> >ICANN Counsel has confirmed the a Registrar cannot avoid their
> >contractual obligations by simply sub-contracting the
> responsibilities
> >to others. This is explicitly reinforced in the recently
> approved RAA
> >Amendments. The Registrar is responsible if their
> subcontractor is not
> >adhering to the agreement.
> >
> >However, compliance staff have routinely said that they
> cannot consider
> >reseller issues, because ICANN does not have a contract with these
> >resellers. However, if one is to try to audit a registrar who has
> >sub-contracted obligations to a reseller, one must look at whether
> >their resellers are doing the job properly - there is no
> other way for
> >ICANN to independently conduct such an audit. Requiring that
> ICANN at
> >least sample resellers for those Registrars who use them should be
> >mandatory.
> >
> >To this end, I may be mistaken, but I don't believe that the
> RAA (old
> >or new) requires that Registrars disclose to ICANN who their
> resellers
> >are. Yet without this information, how can ICANN even
> pretend that they
> >are auditing their contracts. Adding such a requirement is
> exactly the
> >kind of issue that could only be addressed under the "advice
> for future
> >RAA amendments" type of PDP output.
> >
> >Alan
> >
> >At 02/04/2009 01:44 PM, Tim Ruiz wrote:
> > >Alan,
> > >
> > >My amendment uses the verbiage right out of the issues
> report. But to
> > >answer you question directly, I don't see any reason to include it.
> > >
> > >As Staff suggests in the issues report, the TF or WG
> should consider
> > >information from compliance Staff about how related
> current policy is
> > >enforced (related RAA provisions and related consensus policies).
> > >This information could be used by the group to craft
> consensus policy
> > >or consensus policy changes that complaince Staff could
> actually enforce.
> > >That's an expected consideration in any policy
> developement work and
> > >doesn't really need to be spelled out.
> > >
> > >Tim
> > >
> > > -------- Original Message --------
> > >Subject: RE: [council] PEDNR Motion
> > >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
> > >Date: Thu, April 02, 2009 12:06 pm
> > >To: "GNSO Council" <council@xxxxxxxxxxxxxx>
> > >
> > >
> > >Tim, we may agree to differ on this.
> > >
> > >In your proposed replacement motion, you also dropped and
> reference
> > >to the PDP process making recommendations to ICANN
> compliance staff.
> > >Do you have a reason for excluding this as well?
> > >
> > >Alan
> > >
> > >At 02/04/2009 12:03 PM, Tim Ruiz wrote:
> > >
> > > >Alan,
> > > >
> > > >That makes no sense whatsoever. What RAA changes could they
> > > >recommend that would be out of scope that would solve an
> in scope
> > > >issue they are considering? And why would they do that
> if the issue
> > > >is in scope? Why not just put it in terms of a consensus policy?
> > > >And how could a change to the RAA be less invasive than
> a consensus
> > > >policy, for all practical purposes they have the same effect?
> > > >
> > > >What this runs the risk of is the TF or WG skewing off. Any
> > > >situation where an out of scope change to the RAA would
> resolve an
> > > >in scope issue would be so extremely rare (and I assert
> impossible)
> > > >that it is not worth running this risk.
> > > >
> > > >Tim
> > > >
> > > > -------- Original Message --------
> > > >Subject: RE: [council] PEDNR Motion
> > > >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
> > > >Date: Thu, April 02, 2009 10:41 am
> > > >To: "GNSO Council" <council@xxxxxxxxxxxxxx>
> > > >
> > > >
> > > >Tim, two issues:
> > > >
> > > >First, just because we say that the group can make
> RECOMMENDATION
> > > >on ways the PEDNR issues could best e addressed through a future
> > > >RAA (non-picket fence) change does NOT give them the latitude to
> > > >address non-PEDNR issues. Although it is certainly
> jumping the gun
> > > >to consider PDP outcomes, one could imagine that a
> possible outcome
> > > >is a recommendation that a PEDNR issue would best be
> addressed by
> > > >some specific contractual term of the RAA. Not within the picket
> > > >fence, not binding, but a bit of advice that could then not be
> > > >lost, but used as per the (hopefully existent) process of RAA
> > > >amendment.
> > > >
> > > >I am not really expecting such "RAA-suggestion"
> > > >outcomes. But if it becomes obvious to the WG that this is the
> > > >least invasive away of addressing a problem, they should
> be allowed
> > > >to suggest it without them being accused of broadening
> their scope.
> > > >That is all it was meant to do.
> > > >
> > > >I understand that there are some people who want to use a "thin
> > > >edge of the wedge" to address every RAA issue under the
> sun, but I
> > > >think that Staff have crafted a pretty narrow definition here.
> > > >
> > > >Alan
> > > >
> > > >At 02/04/2009 11:24 AM, Tim Ruiz wrote:
> > > >
> > > > >It's unfortunate that Staff supported such a concept, and I
> > > > >personally believe it is seriously flawed. If we don't
> form WGs
> > > > >with specific focus we run the risk of them running on
> and on -
> > > > >getting sidetracked in multiple directions.
> > > > >
> > > > >Clearly, a PDP WG could come back and say: "We do not
> recommend
> > > > >any policy at this time, but suggest that the following be
> > > > >considered as a best practice..." That's much
> different than the
> > > > >WG spending time hashing out potential changes to the RAA. For
> > > > >one thing, if the issue is in scope they don't have
> to. A consensus policy IS a change to the RAA.
> > > > >If they conclude there is not a need for a policy,
> then why would
> > > > >they consider RAA changes? That is either a
> contradiction, or it
> > > > >gets them off looking at things they were not
> chartered to consider.
> > > > >
> > > > >For the PEDNR PDP being contemplated, Staff Council
> deemed it in scope.
> > > > >So if the PDP WG is formed it will look at possible
> new policy or
> > > > >policy changes (both of which are in effect changes to
> the RAA),
> > > > >and perhaps they will also consider best practices.
> But what is
> > > > >the point of looking at other RAA changes? The issue they are
> > > > >chartered for is deemed in scope so they don't need to
> - they can
> > > > >recommend a policy. If they are looking at RAA changes
> for something else, why?
> > > > >
> > > > >
> > > > >Tim
> > > > >
> > > > > -------- Original Message --------
> > > > >Subject: RE: [council] PEDNR Motion
> > > > >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
> > > > >Date: Thu, April 02, 2009 10:02 am
> > > > >To: "GNSO Council" <council@xxxxxxxxxxxxxx>
> > > > >
> > > > >
> > > > >I slept in a bit today, and apparently I missed the
> start of the party!
> > > > >
> > > > >Let me try to clarify things. First, there are two variants of
> > > > >PDPs, both of which can be "in scope for GNSO
> consideration". I
> > > > >must admit that I was not clear on some of this when the
> > > > >discussions started, but I think/hope that what I have below
> > > > >reflect the opinions of both Marika and ICANN Counsel.
> > > > >
> > > > >1. Those that formulate a consensus policy for adoption by the
> > > > >Board. Clearly the resultant policy must also be with
> the scope
> > > > >of the definition of consensus policy within the applicable
> > > > >contract (within the "picket fence").
> > > > >
> > > > >2. Those that give advice to the Board. They may be completely
> > > > >off-topic from contract allowed consensus policies.
> The new gTLD
> > > > >policy is such an example. It is not binding on contracted
> > > > >parties. Such PDPs can even be deemed out of scope for
> the GNSO.
> > > > >The Contractual Terms PDP06 was an example - it
> required a higher
> > > > >threshold to start.
> > > > >
> > > > >During the discussions that led to where we are today (both in
> > > > >the DT and before), and as indicated in the Issues Report. The
> > > > >problems that we are discussing may be addressed through a
> > > > >variety of mechanisms. Council has been very leery of WGs that
> > > > >enlarge their charters while operating, so it was felt
> important
> > > > >to make it clear that all forms of output are allowed in this
> > > > >case. The Motion was an attempt at saying that there
> is no reason
> > > > >to limit a PDP to just one type of output if its deliberations
> > > > >lead it to belive that several are needed to address
> the problem
> > > > >properly.
> > > > >
> > > > >a) those which are within the picket fence in the RAA could
> > > > >result in a consensus policy recommendation to the Board.
> > > > >b) those that would require changes to the RAA but are
> outside of
> > > > >the picket fence and would have no more import than
> other input
> > > > >from the community into future revisions. But
> importantly, they
> > > > >would not be lost as they would be if they could not be one
> > > > >aspect of the output of the PDP.
> > > > >We have too much work to do to analyze problems and
> then simply
> > > > >discard the results.
> > > > >c) there could be recommendation for changes in
> compliance made
> > > > >to the Board for implementation by ICANN compliance staff.
> > > > >d) there could be recommendations for best practices for
> > > > >Registrars, which would be no more than just that -
> > > > >recommendations not binding on anyone unless
> Registrars choose to
> > > > >follow them.
> > > > >
> > > > >The entire intent to be able to address the problem that users
> > > > >see from a holistic point of view and look for the best way to
> > > > >address it, with the least amount of "thou shalt do".
> > > > >
> > > > >We always have the worry about a PDP being hijacked
> and discuss
> > > > >issues which were not included in the Issues Report or the
> > > > >Charter. In this case, Staff has written the
> recommendation which
> > > > >were quoted in the motion pretty restrictively. As the
> submitter
> > > > >of the request for Issues Report, I actually wish they
> had given
> > > > >more latitude. But that *IS* what they said, and the
> DT decided
> > > > >to not attempt to change them.
> > > > >
> > > > >Alan
> > > > >
> > > > >
> > > > >At 02/04/2009 09:40 AM, Tim Ruiz wrote:
> > > > > >Marika,
> > > > > >
> > > > > >You're not getting the point. A PDP charter should, in my
> > > > > >opinion, either directly or indirectly be directed
> NOT to get
> > > > > >sidetracked with consideration of *other* RAA changes.
> > > > > >Otherwise it implies considering issues that the PDP was not
> > > > > >formed to consider. If a PDP is engaged on an *in
> scope* issue
> > > > > >that could result in a consensus policy then it
> should focus on
> > > > > >that issue. We cannot have working groups going off in any
> > > > > >direction desired, and that's exactly what will
> happen if we don't keep them focused on the issue they were
> formed to consider.
> > > > > >
> > > > > >Tim
> > > > > >
> > > > > > -------- Original Message --------
> > > > > >Subject: Re: [council] PEDNR Motion
> > > > > >From: Marika Konings <marika.konings@xxxxxxxxx>
> > > > > >Date: Thu, April 02, 2009 8:15 am
> > > > > >To: Tim Ruiz <tim@xxxxxxxxxxx>
> > > > > >Cc: Alan Greenberg <alan.greenberg@xxxxxxxxx>, GNSO Council
> > > > > ><council@xxxxxxxxxxxxxx>
> > > > > >
> > > > > >Apologies Tim, but I did not mean to imply that staff is
> > > > > >encouraging PDPs to include possible RAA changes. I
> > understood the reason as to why
> > > > > >the drafting team decided to include
> > examples of other possible outcomes
> > > > > >of a PDP, such as a recommendation for RAA changes,
> to be that
> > > > > >the drafting team wanted to emphasize that consensus
> policy or
> > > > > >consensus policy changes are not the the only
> possible outcomes of a PDP.
> > > > > >
> > > > > >In reviewing some of the issues, a WG might decide
> that changes
> > > > > >to a consensus policy are not appropriate but
> > instead a recommendation for a
> > > > > >best practice or RAA change might be more suitable. You are
> > > > > >absolutely right that anything but consensus policy changes,
> > > > > >are recommendations and therefore not enforceable.
> This is how
> > > > > >I interpreted the reference to possible RAA changes.
> If this WG
> > > > > >were to make a recommendation for changes to the
> RAA, and the
> > > > > >GNSO would support this recommendation, it is my
> understanding
> > > > > >that it would be passed on to the appropriate parties, WG
> > > > > >and/or ICANN body to
> > consider this recommendation and follow
> > > > > >the applicable procedures which might result in
> changes to the
> > > > > >RAA, or not.
> > > > > >
> > > > > >Again, apologies for the confusion.
> > > > > >
> > > > > >Best regards,
> > > > > >
> > > > > >Marika
> > > > > >
> > > > > >On 4/2/09 2:42 PM, "Tim Ruiz"
> > > > > ><https://email.secureserver.net/tim@xxxxxxxxxxx> wrote:
> > > > > >
> > > > > > Marika,
> > > > > >
> > > > > >Thanks for the explanation. But why is Staff
> encouraging PDPs
> > > > > >to include possible RAA changes? A consensus policy IS an
> > > > > >enforceable change to the RAA. The only other reason
> would be
> > > > > >to change something not within the scope of the RAA picket
> > > > > >fence. Such things should NOT be part of a PDP.
> > > > > >
> > > > > >A PDP should be specifically for *policy*
> development. If the
> > > > > >GNSO wants to consider things not within scope of the picket
> > > > > >fence it should not initiate a PDP. It can very well form a
> > > > > >group to consider such things if it chooses with the
> > > > > >understanding that the outcome will not be a mandate
> but only a
> > > > > >suggestion or possibly a recommended (but not
> enforceable) best
> > > > > >practice. Mixing these things together is NOT a
> productive way to approach our work.
> > > > > >
> > > > > >In fact, we are forming such a group to discuss
> further changes
> > > > > >to the RAA. That group will no doubt discuss things
> not within
> > > > > >the RAA's picket fence as well as some things that
> are. For me,
> > > > > >if this PDP is going to proceed with the
> understanding that it
> > > > > >will include dicussion/examination of changes to the
> RAA, then
> > > > > >I see no point in purusing any other discussion of the RAA.
> > > > > >
> > > > > >That all said, I would like to ask for the
> following, intended
> > > > > >friendly ammendment to the PEDNR motion:
> > > > > >
> > > > > >Replace the main paragraph of the RESOLVE portion with this:
> > > > > >
> > > > > >to initiate a Policy Development Process (PDP) to
> address the
> > > > > >issues identified in the Post-Expiration Domain Name
> Recovery
> > > > > >Issues Report. The charter for this PDP should
> instruct the Working Group:
> > > > > >(i) that it should consider recommendations for best
> practices
> > > > > >as well as or instead of recommendations for
> Consensus Policy;
> > > > > >(ii) that to inform its work it should pursue the
> > availability of further information
> > > > > >
> > > > > >from ICANN compliance staff to understand how current RAA
> > > > > >provisions and consensus policies regarding deletion,
> > > > > >auto-renewal, and recovery of domain names during
> the RGP are
> > > > > >enforced; and (iii) that it should specifically
> consider the following questions:
> > > > > >
> > > > > >Also, I would suggest that the last bullet/question
> be deleted
> > > > > >since the last paragraph really covers it. So to be
> clear, if
> > > > > >my proposed amendment is accepted as friendly the RESOLVE
> > > > > >portion of the motion would read:
> > > > > >
> > > > > >GNSO Council RESOLVES:
> > > > > >
> > > > > >to initiate a Policy Development Process (PDP) to
> address the
> > > > > >issues identified in the Post-Expiration Domain Name
> Recovery
> > > > > >Issues Report. The charter for this PDP should
> instruct the Working Group:
> > > > > >(i) that it should consider recommendations for best
> practices
> > > > > >as well as or instead of recommendations for
> Consensus Policy;
> > > > > >(ii) that to inform its work it should pursue the
> > availability of further information
> > > > > >
> > > > > >from ICANN compliance staff to understand how current RAA
> > > > > >provisions and consensus policies regarding deletion,
> > > > > >auto-renewal, and recovery of domain names during
> the RGP are
> > > > > >enforced; and (iii) that it should specifically
> consider the following questions:
> > > > > >
> > > > > >-- Whether adequate opportunity exists for registrants to
> > > > > >redeem their expired domain names;
> > > > > >-- Whether expiration-related provisions in typical
> > > > > >registration agreements are clear and conspicuous enough;
> > > > > >-- Whether adequate notice exists to alert registrants of
> > > > > >upcoming expirations;
> > > > > >-- Whether additional measures need to be implemented to
> > > > > >indicate that once a domain name enters the Auto-Renew Grace
> > > > > >Period, it has expired (e.g. hold status, a notice
> on the site
> > > > > >with a link to information on how to renew or other
> options to be determined).
> > > > > >
> > > > > >The GNSO Council further resolves that the issue of
> logistics
> > > > > >of possible registrar transfer during the RGP shall be
> > > > > >incorporated into the charter of the IRTP Part C charter.
> > > > > >
> > > > > >
> > > > > >Tim
> > > > > >
> > > > > > -------- Original Message --------
> > > > > >Subject: Re: [council] PEDNR Motion
> > > > > >From: Marika Konings
> > > > > ><https://email.secureserver.net/marika.konings@xxxxxxxxx>
> > > > > >Date: Thu, April 02, 2009 4:20 am
> > > > > >To: Alan Greenberg
> > > > > ><https://email.secureserver.net/alan.gree
> > nberg@xxxxxxxxx>, GNSO Council
> > > > > ><https://email.secureserver.net/council@xxxxxxxxxxxxxx>
> > > > > >
> > > > > >Tim, please note that the recommendation you quoted from the
> > > > > >Issues Report specifically relates to
> > > >
> > ‘the
> > desired outcomes stated by ALAC in
> > > > > >its
> > request’,
> some of which
> > go
> > > > beyond the issues recommended for a
> > > > > >PDP. As noted by Alan, the drafting team
> > and staff did discuss whether a
> > > > > >pre-PDP WG would be appropriate, but agreed that further
> > > > > >research and consultation could be done as part of a
> PDP as the
> > > > > >issues recommended for inclusion in a PDP have been narrowly
> > > > > >defined. As stated in the motion, the drafting team does
> > > > > >believe it is important to highlight in the charter that the
> > > > > >outcomes of a PDP are not limited to recommended changes to
> > > > > >consensus policy, but could also include recommendations
> > > > > >regarding e.g. best practices, compliance, possible
> RAA changes or further dialogue.
> > > > > >
> > > > > >On a different note, but related to the
> Post-Expiration Domain
> > > > > >Name Recovery Issues Report, I would like to draw your
> > > > > >attention to a deletion and renewal consensus policy
> audit in
> > > > > >relation to the Expired Domain Deletion Consensus
> Policy that
> > > > > >was
> > > > carried out by the
> > > > ICANN’s
> > > > > >compliance team recently (see further
> > details attached). Follow-up audit
> > > > > >activity is being carried out as a result of the
> non-compliance
> > > > > >identified in the audit. As a result of this follow-up, the
> > > > > >compliance team estimates that the number of non-compliant
> > > > > >registrars is about 30-40% less today then when the
> report was published.
> > > > > >
> > > > > >With best regards,
> > > > > >
> > > > > >Marika
> > > > > >
> > > > > >On 4/2/09 5:11 AM, "Alan Greenberg"
> > > > >
> ><https://email.secureserver.net/alan.greenberg@xxxxxxxxx> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >The drafting team did discuss this. The conclusion was (and
> > > > > >staff concurred if I remember correctly) that any further
> > > > > >consultation could reasonably be done as part of the PDP. We
> > > > > >also talked about a public forum in Sydney, the
> exact contents
> > > > > >of which would depend on how far along the WG
> (presuming we use a WG) had gotten.
> > > > > >
> > > > > >I guess the question came down to whether we felt that some
> > > > > >policy development and non-policy recommendations
> were required
> > > > > >regardless, and whether the outcomes of pre-PDP consultation
> > > > > >would change the details of the recommendations to
> be put in a
> > > > > >PDP charter. The answer to the first question was
> yes, we did
> > > > > >feel that PDP action was required, and we did not think that
> > > > > >the specific recommendations would change. How a WG
> addresses
> > > > > >the issues may well change, but since it did not appear that
> > > > > >the results of such consultation would alter the PDP
> charter, there did not seem to be any reason to delay.
> > > > > >
> > > > > >Although not discussed, I would envision a call for input on
> > > > > >some targeted questins as an early part of the process.
> > > > > >
> > > > > >Alan
> > > > > >
> > > > > >At 01/04/2009 06:09 PM, you wrote:
> > > > > >
> > > > > > >I was re-reading the issues report and was
> reminded of this
> > > > > > >Staff
> > > > > > >recommendation:
> > > > > > >
> > > > > > >"In relation to the desired outcomes stated by ALAC in its
> > > > > > >request, ICANN staff notes that while most, if not all,
> > > > > > >outcomes might be achieved by the recommendations
> identified
> > > > > > >by the ALAC, it would be helpful for all
> > > parties concerned to engage in a more
> > > > > > >fulsome dialogue on
> > > > > > >the extent and detailed nature of the concerns to
> determine
> > > > > > >whether these are shared desired outcomes and if so, how
> > > > > > >these
> > > could best be addressed in policy
> > > > > > >work going
> > > > > > >forward, including a more robust
> > > discussion of the merits and drawbacks
> > > > > > >of various solutions
> > > > > > >to address agreed concerns. The GNSO Council might
> consider
> > > > > > >such an activity, which could take the form of one or more
> > > public workshops at an upcoming ICANN
> > > > > > >meeting, for
> > > > > > >example, as a precursor for the launch of a PDP as
> it would
> > > > > > >help to define and focus the policy development process on
> > > > > > >one or more specific proposed changes.
> > > > > > >While this could
> > > > > > >also be explored by a working group
> > > following the launch of a PDP, staff
> > > > > > >recommends
> > > > > > >further fact finding first to figure out what
> policy options
> > > > > > >might exist, and then conduct a PDP to assess the
> impact of
> > > > > > >those policy options and confirm community support for a
> > > > > > >preferred policy choice."
> > > > > > >
> > > > > > >I don't recall that we discussed whether
> > > we should follow this advice or
> > > > > > >not. Alan, is there
> > > > > > >a reason why your motion initiates a PDP instead
> of the fact
> > > > > > >finding that the Staff suggests be done first?
> > > > > > >
> > > > > > >
> > > > > > >Tim
>
>
>
>