[council] PEDNR Motion

[Alan Greenberg]

I guess I don't understand why we should restrict 
the group from making such a suggestion. The aim 
of the process should be to find the best 
possible resolution to the issues raised.

That being said, I presented the outcome of the 
DT, and it was moved by Avri and I think seconded 
by you (Chuck). Motions to amend are certainly 
possible - specifically to replace "ICANN 
compliance obligations and possible RAA changes" 
with "and ICANN compliance obligations".

Tim also made another substantive change that I 
would like to hear the rationale for.

Alan

At 02/04/2009 01:17 PM, Gomes, Chuck wrote:

>Wouldn't we be better off avoiding confusing the 
>PEDNR motion with RAA issues and instead focus 
>on the motion without reference to the RAA?
>
>Chuck
>
> > -----Original Message-----
> > From: owner-council at gnso.icann.org
> > [mailto:owner-council at gnso.icann.org] On Behalf Of Tim Ruiz
> > Sent: Thursday, April 02, 2009 12:03 PM
> > To: GNSO Council
> > Subject: RE: [council] PEDNR Motion
> >
> >
> > 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 at mcgill.ca>
> > Date: Thu, April 02, 2009 10:41 am
> > To: "GNSO Council" <council at gnso.icann.org>
> >
> >
> > 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 at mcgill.ca>
> > >Date: Thu, April 02, 2009 10:02 am
> > >To: "GNSO Council" <council at gnso.icann.org>
> > >
> > >
> > >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 at icann.org>
> > > >Date: Thu, April 02, 2009 8:15 am
> > > >To: Tim Ruiz <tim at godaddy.com>
> > > >Cc: Alan Greenberg <alan.greenberg at mcgill.ca>, GNSO Council
> > > ><council at gnso.icann.org>
> > > >
> > > >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@godaddy.com> 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@icann.org>
> > > >Date: Thu, April 02, 2009 4:20 am
> > > >To: Alan Greenberg
> > > ><https://email.secureserver.net/alan.greenberg@mcgill.ca>, GNSO
> > > >Council <https://email.secureserver.net/council@gnso.icann.org>
> > > >
> > > >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@mcgill.ca> 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
> >
> >
> >