April 2009 - council - lists.icann.org

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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(a)mcgill.ca> Date: Thu, April 02, 2009 10:02 am To: "GNSO Council" <council(a)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(a)icann.org> >Date: Thu, April 02, 2009 8:15 am >To: Tim Ruiz <tim(a)godaddy.com> >Cc: Alan Greenberg <alan.greenberg(a)mcgill.ca>, GNSO Council ><council(a)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

1 0

RE: [council] PEDNR Motion
by Alan Greenberg April 2, 2009

April 2, 2009

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(a)icann.org> >Date: Thu, April 02, 2009 8:15 am >To: Tim Ruiz <tim(a)godaddy.com> >Cc: Alan Greenberg <alan.greenberg(a)mcgill.ca>, GNSO Council ><council(a)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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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(a)icann.org> Date: Thu, April 02, 2009 8:15 am To: Tim Ruiz <tim(a)godaddy.com> Cc: Alan Greenberg <alan.greenberg(a)mcgill.ca>, GNSO Council <council(a)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

1 0

RE: [council] PEDNR Motion
by Tim Ruiz April 2, 2009

April 2, 2009

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 <marika.konings(a)icann.org> Date: Thu, April 02, 2009 4:20 am To: Alan Greenberg <alan.greenberg(a)mcgill.ca>, GNSO Council <council(a)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

2 1

Re: [council] PEDNR Motion
by Alan Greenberg April 2, 2009

April 2, 2009

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

2 1

PEDNR Motion
by Tim Ruiz April 1, 2009

April 1, 2009

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

1 0

RyC GNSO Travel Funds Position
by Gomes, Chuck April 1, 2009

April 1, 2009

The RyC approved the following position regarding travel funding for Sydney today. Travel Funding for Sydney - RyC Position 1 Apr 09 At this time the RyC requests full travel funding for one person to attend and participate in the ICANN Sydney meetings in June 2009. For the funding associated with the remaining three slots allocated to the RyC for the current fiscal year, the RyC recommends any FY09 travel funds allocated to the RyC left over at the end of June be rolled over to FY10 for use by the RyC for future travel needs for GNSO activities. Regarding the use of DNSO funds still remaining on ICANN books, the RyC believes that a good use of those funds for the benefit of the whole community in the long term would be to use them for improving the capacity for remote participation in an effective manner and thereby minimizes the heavy dependence on in-person participation. We believe that this would scale much better and be a much more fiscally responsible approach over the longer term than continuing to try to subsidize travel expenses for what likely will be a growing need of GNSO participants in the future. Chuck

1 0