<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [council] PEDNR Motion
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@xxxxxxxxxxxxxx
> [mailto:owner-council@xxxxxxxxxxxxxx] 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@xxxxxxxxx>
> Date: Thu, April 02, 2009 10:41 am
> To: "GNSO Council" <council@xxxxxxxxxxxxxx>
>
>
> Tim, two issues:
>
> First, just because we say that the group can make
> RECOMMENDATION on ways the PEDNR issues could best e
> addressed through a future RAA (non-picket fence) change does
> NOT give them the latitude to address non-PEDNR issues.
> Although it is certainly jumping the gun to consider PDP
> outcomes, one could imagine that a possible outcome is a
> recommendation that a PEDNR issue would best be addressed by
> some specific contractual term of the RAA. Not within the
> picket fence, not binding, but a bit of advice that could
> then not be lost, but used as per the (hopefully existent)
> process of RAA amendment.
>
> I am not really expecting such "RAA-suggestion"
> outcomes. But if it becomes obvious to the WG that this is
> the least invasive away of addressing a problem, they should
> be allowed to suggest it without them being accused of
> broadening their scope. That is all it was meant to do.
>
> I understand that there are some people who want to use a
> "thin edge of the wedge" to address every RAA issue under the
> sun, but I think that Staff have crafted a pretty narrow
> definition here.
>
> Alan
>
> At 02/04/2009 11:24 AM, Tim Ruiz wrote:
>
> >It's unfortunate that Staff supported such a concept, and I
> personally
> >believe it is seriously flawed. If we don't form WGs with specific
> >focus we run the risk of them running on and on - getting
> sidetracked
> >in multiple directions.
> >
> >Clearly, a PDP WG could come back and say: "We do not recommend any
> >policy at this time, but suggest that the following be
> considered as a
> >best practice..." That's much different than the WG spending time
> >hashing out potential changes to the RAA. For one thing, if
> the issue
> >is in scope they don't have to. A consensus policy IS a
> change to the RAA.
> >If they conclude there is not a need for a policy, then why
> would they
> >consider RAA changes? That is either a contradiction, or it
> gets them
> >off looking at things they were not chartered to consider.
> >
> >For the PEDNR PDP being contemplated, Staff Council deemed
> it in scope.
> >So if the PDP WG is formed it will look at possible new policy or
> >policy changes (both of which are in effect changes to the RAA), and
> >perhaps they will also consider best practices. But what is
> the point
> >of looking at other RAA changes? The issue they are chartered for is
> >deemed in scope so they don't need to - they can recommend a
> policy. If
> >they are looking at RAA changes for something else, why?
> >
> >
> >Tim
> >
> > -------- Original Message --------
> >Subject: RE: [council] PEDNR Motion
> >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
> >Date: Thu, April 02, 2009 10:02 am
> >To: "GNSO Council" <council@xxxxxxxxxxxxxx>
> >
> >
> >I slept in a bit today, and apparently I missed the start of
> the party!
> >
> >Let me try to clarify things. First, there are two variants of PDPs,
> >both of which can be "in scope for GNSO consideration". I must admit
> >that I was not clear on some of this when the discussions
> started, but
> >I think/hope that what I have below reflect the opinions of
> both Marika
> >and ICANN Counsel.
> >
> >1. Those that formulate a consensus policy for adoption by
> the Board.
> >Clearly the resultant policy must also be with the scope of the
> >definition of consensus policy within the applicable
> contract (within
> >the "picket fence").
> >
> >2. Those that give advice to the Board. They may be completely
> >off-topic from contract allowed consensus policies. The new
> gTLD policy
> >is such an example. It is not binding on contracted parties.
> Such PDPs
> >can even be deemed out of scope for the GNSO. The Contractual Terms
> >PDP06 was an example - it required a higher threshold to start.
> >
> >During the discussions that led to where we are today (both
> in the DT
> >and before), and as indicated in the Issues Report. The
> problems that
> >we are discussing may be addressed through a variety of mechanisms.
> >Council has been very leery of WGs that enlarge their charters while
> >operating, so it was felt important to make it clear that
> all forms of
> >output are allowed in this case. The Motion was an attempt at saying
> >that there is no reason to limit a PDP to just one type of output if
> >its deliberations lead it to belive that several are needed
> to address
> >the problem properly.
> >
> >a) those which are within the picket fence in the RAA could
> result in a
> >consensus policy recommendation to the Board.
> >b) those that would require changes to the RAA but are
> outside of the
> >picket fence and would have no more import than other input from the
> >community into future revisions. But importantly, they would not be
> >lost as they would be if they could not be one aspect of the
> output of
> >the PDP.
> >We have too much work to do to analyze problems and then
> simply discard
> >the results.
> >c) there could be recommendation for changes in compliance
> made to the
> >Board for implementation by ICANN compliance staff.
> >d) there could be recommendations for best practices for Registrars,
> >which would be no more than just that - recommendations not
> binding on
> >anyone unless Registrars choose to follow them.
> >
> >The entire intent to be able to address the problem that
> users see from
> >a holistic point of view and look for the best way to
> address it, with
> >the least amount of "thou shalt do".
> >
> >We always have the worry about a PDP being hijacked and
> discuss issues
> >which were not included in the Issues Report or the Charter. In this
> >case, Staff has written the recommendation which were quoted in the
> >motion pretty restrictively. As the submitter of the request
> for Issues
> >Report, I actually wish they had given more latitude. But that *IS*
> >what they said, and the DT decided to not attempt to change them.
> >
> >Alan
> >
> >
> >At 02/04/2009 09:40 AM, Tim Ruiz wrote:
> > >Marika,
> > >
> > >You're not getting the point. A PDP charter should, in my opinion,
> > >either directly or indirectly be directed NOT to get
> sidetracked with
> > >consideration of *other* RAA changes. Otherwise it implies
> > >considering issues that the PDP was not formed to
> consider. If a PDP
> > >is engaged on an *in scope* issue that could result in a consensus
> > >policy then it should focus on that issue. We cannot have working
> > >groups going off in any direction desired, and that's exactly what
> > >will happen if we don't keep them focused on the issue
> they were formed to consider.
> > >
> > >Tim
> > >
> > > -------- Original Message --------
> > >Subject: Re: [council] PEDNR Motion
> > >From: Marika Konings <marika.konings@xxxxxxxxx>
> > >Date: Thu, April 02, 2009 8:15 am
> > >To: Tim Ruiz <tim@xxxxxxxxxxx>
> > >Cc: Alan Greenberg <alan.greenberg@xxxxxxxxx>, GNSO Council
> > ><council@xxxxxxxxxxxxxx>
> > >
> > >Apologies Tim, but I did not mean to imply that staff is
> encouraging
> > >PDPs to include possible RAA changes. I understood the
> reason as to
> > >why the drafting team decided to include examples of other
> possible
> > >outcomes of a PDP, such as a recommendation for RAA changes, to be
> > >that the drafting team wanted to emphasize that consensus
> policy or
> > >consensus policy changes are not the the only possible
> outcomes of a PDP.
> > >
> > >In reviewing some of the issues, a WG might decide that
> changes to a
> > >consensus policy are not appropriate but instead a
> recommendation for
> > >a best practice or RAA change might be more suitable. You are
> > >absolutely right that anything but consensus policy changes, are
> > >recommendations and therefore not enforceable. This is how I
> > >interpreted the reference to possible RAA changes. If this
> WG were to
> > >make a recommendation for changes to the RAA, and the GNSO would
> > >support this recommendation, it is my understanding that
> it would be
> > >passed on to the appropriate parties, WG and/or ICANN body to
> > >consider this recommendation and follow the applicable procedures
> > >which might result in changes to the RAA, or not.
> > >
> > >Again, apologies for the confusion.
> > >
> > >Best regards,
> > >
> > >Marika
> > >
> > >On 4/2/09 2:42 PM, "Tim Ruiz"
> > ><https://email.secureserver.net/tim@xxxxxxxxxxx> wrote:
> > >
> > > Marika,
> > >
> > >Thanks for the explanation. But why is Staff encouraging PDPs to
> > >include possible RAA changes? A consensus policy IS an enforceable
> > >change to the RAA. The only other reason would be to
> change something
> > >not within the scope of the RAA picket fence. Such things
> should NOT
> > >be part of a PDP.
> > >
> > >A PDP should be specifically for *policy* development. If the GNSO
> > >wants to consider things not within scope of the picket fence it
> > >should not initiate a PDP. It can very well form a group
> to consider
> > >such things if it chooses with the understanding that the outcome
> > >will not be a mandate but only a suggestion or possibly a
> recommended
> > >(but not enforceable) best practice. Mixing these things
> together is
> > >NOT a productive way to approach our work.
> > >
> > >In fact, we are forming such a group to discuss further changes to
> > >the RAA. That group will no doubt discuss things not
> within the RAA's
> > >picket fence as well as some things that are. For me, if
> this PDP is
> > >going to proceed with the understanding that it will include
> > >dicussion/examination of changes to the RAA, then I see no
> point in
> > >purusing any other discussion of the RAA.
> > >
> > >That all said, I would like to ask for the following, intended
> > >friendly ammendment to the PEDNR motion:
> > >
> > >Replace the main paragraph of the RESOLVE portion with this:
> > >
> > >to initiate a Policy Development Process (PDP) to address
> the issues
> > >identified in the Post-Expiration Domain Name Recovery
> Issues Report.
> > >The charter for this PDP should instruct the Working Group:
> > >(i) that it should consider recommendations for best practices as
> > >well as or instead of recommendations for Consensus
> Policy; (ii) that
> > >to inform its work it should pursue the availability of further
> > >information
> > >
> > >from ICANN compliance staff to understand how current RAA
> provisions
> > >and consensus policies regarding deletion, auto-renewal,
> and recovery
> > >of domain names during the RGP are enforced; and (iii)
> that it should
> > >specifically consider the following questions:
> > >
> > >Also, I would suggest that the last bullet/question be
> deleted since
> > >the last paragraph really covers it. So to be clear, if my
> proposed
> > >amendment is accepted as friendly the RESOLVE portion of
> the motion
> > >would read:
> > >
> > >GNSO Council RESOLVES:
> > >
> > >to initiate a Policy Development Process (PDP) to address
> the issues
> > >identified in the Post-Expiration Domain Name Recovery
> Issues Report.
> > >The charter for this PDP should instruct the Working Group:
> > >(i) that it should consider recommendations for best practices as
> > >well as or instead of recommendations for Consensus
> Policy; (ii) that
> > >to inform its work it should pursue the availability of further
> > >information
> > >
> > >from ICANN compliance staff to understand how current RAA
> provisions
> > >and consensus policies regarding deletion, auto-renewal,
> and recovery
> > >of domain names during the RGP are enforced; and (iii)
> that it should
> > >specifically consider the following questions:
> > >
> > >-- Whether adequate opportunity exists for registrants to redeem
> > >their expired domain names;
> > >-- Whether expiration-related provisions in typical registration
> > >agreements are clear and conspicuous enough;
> > >-- Whether adequate notice exists to alert registrants of upcoming
> > >expirations;
> > >-- Whether additional measures need to be implemented to indicate
> > >that once a domain name enters the Auto-Renew Grace Period, it has
> > >expired (e.g. hold status, a notice on the site with a link to
> > >information on how to renew or other options to be determined).
> > >
> > >The GNSO Council further resolves that the issue of logistics of
> > >possible registrar transfer during the RGP shall be
> incorporated into
> > >the charter of the IRTP Part C charter.
> > >
> > >
> > >Tim
> > >
> > > -------- Original Message --------
> > >Subject: Re: [council] PEDNR Motion
> > >From: Marika Konings
> > ><https://email.secureserver.net/marika.konings@xxxxxxxxx>
> > >Date: Thu, April 02, 2009 4:20 am
> > >To: Alan Greenberg
> > ><https://email.secureserver.net/alan.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
>
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|