RE: [council] PEDNR Motion

[Alan Greenberg <alan.greenberg@xxxxxxxxx>]

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.greenberg@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