[council] PEDNR Motion

Thu Apr 2 18:35:59 UTC 2009

I have no problem omitting the details if that 
will not later result in the PDP group being told 
that they have unilaterally widened their scope.

For the record, I still don't know how a PDP that 
is restricted to PEDNR can widen its scope by the 
reference to the RAA, but I have made my case and 
it is up to Council to decide.

Regarding contractual terms, see my last note about resellers.

Alan

At 02/04/2009 02:16 PM, Gomes, Chuck wrote:
>Alan,
>
>The purpose of PDPs is to develop policy not 
>work on contractual terms. The result of policy 
>development work may impact registry or 
>registrar contracts but that is not the purpose 
>and to focus directly on contractual terms diverts from that purpose.
>
>I agree with you that the process should be to 
>find the best possible resolution to the issues 
>defined in the SoW but that doesn't require any 
>reference to the RRA.  Moreover, the Council has 
>another work effort that focuses on RAA issues 
>so there really isn't need to mix the two.  If 
>any resolution recommended affects RAA work, so 
>be it, but that does not need to be a goal 
>because that is too broad and could unnecessarily expand the scope of a PDP.
>
>Chuck
>
> > -----Original Message-----
> > From: owner-council at gnso.icann.org
> > [mailto:owner-council at gnso.icann.org] On Behalf Of Alan Greenberg
> > Sent: Thursday, April 02, 2009 1:29 PM
> > To: GNSO Council
> > Subject: RE: [council] PEDNR Motion
> >
> >
> > 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ÃƒÂ¢Ã‚€Ã‚™, s, 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 complialiance 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
> > > >
> > > >
> > > >
> >
> >
> >
> >