ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [council] PEDNR Motion


Thanks Marika.
 
I am curious as to why the word 'generally' was used in the following sentence: 
"However, if a PDP recommends binding new obligations on registries or 
registrars, these generally would need to be on topics that are inside the 
picket-fence in order to be enforceable."?
 
Chuck


________________________________

        From: Marika Konings [mailto:marika.konings@xxxxxxxxx] 
        Sent: Wednesday, April 08, 2009 3:49 PM
        To: Gomes, Chuck; Alan Greenberg; GNSO Council
        Subject: Re: [council] PEDNR Motion
        
        
        As some of you requested feedback from staff, I would like to let you 
know that ICANN Legal Counsel has confirmed that the question of within scope 
/outside of scope relating to the initiation of a PDP relates to whether an 
issue is within scope of GNSO policy-making (i.e. within ICANN’s mission and 
linked to gTLDs). In the case of PEDNR, the issues fall within ICANN’s mission 
and are related to gTLDS, so no higher threshold is required for the initiation 
of a PDP. However, if a PDP recommends binding new obligations on registries or 
registrars, these generally would need to be on topics that are inside the 
picket-fence in order to be enforceable.
        
        A working group charter should outline narrowly defined issues to be 
addressed by a WG that should not be broadened without the explicit agreement 
of the GNSO Council. However, in examining these narrowly defined issues and 
exploring potential solutions, it is appropriate for a WG to explore the best 
solution possible whether it is a proposed new registry or registrar obligation 
or some other sort of recommendation/solution.
        
        Apologies for the delay in responding.
        
        Best regards,
        
        Marika
        
        
        On 4/2/09 11:55 PM, "Chuck Gomes" <cgomes@xxxxxxxxxxxx> wrote:
        
        

                
                
                Thanks Alan.  I forgot about that.
                
                Chuck
                
                > -----Original Message-----
                > From: owner-council@xxxxxxxxxxxxxx
                > [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Alan 
Greenberg
                > Sent: Thursday, April 02, 2009 5:46 PM
                > To: GNSO Council
                > Subject: RE: [council] PEDNR Motion
                >
                >
                > I am referring to the voting threshold needed to INITIATE a
                > PDP.  According to the Bylaws Annex A 3.c
                >
                > "A vote of more than 33% of the Council members present in
                > favor of initiating the PDP will suffice to initiate the PDP;
                > unless the Staff Recommendation stated that the issue is not
                > properly within the scope of the ICANN policy process or the
                > GNSO, in which case a Supermajority Vote of the Council
                > members present in favor of initiating the PDP will be
                > required to initiate the PDP."
                >
                > Although the start of it was before my time, I was told that
                > PDP06 (gTLD Contractual Conditions) was deemed by ICANN Legal
                > Counsel to be outside of GNSO Scope and required the higher 
threshold.
                >
                > In this present case, the Issues Report says and I have had
                > it confirmed that the issue is within scope of the GNSO.
                >
                > Alan
                >
                >
                > At 02/04/2009 05:16 PM, Gomes, Chuck wrote:
                > >Alan,
                > >
                > >Please see my comments inserted below.
                > >
                > >Chuck
                > >
                > > > -----Original Message-----
                > > > From: owner-council@xxxxxxxxxxxxxx
                > > > [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Alan 
Greenberg
                > > > Sent: Thursday, April 02, 2009 3:40 PM
                > > > To: Tim Ruiz; GNSO Council
                > > > Subject: RE: [council] PEDNR Motion
                > > >
                > > >
                > > > Tim, I will let Marika definitively address that.
                > > > But here is my understanding.
                > > >
                > > > There are two types of "out-of-scope":
                > > >
                > > > - Those that are deemed by legal council to be out of the 
GNSO
                > > > scope, and those require a higher threshold to initiate a 
PDP.
                > >
                > >Chuck: I do not know to what you are referring regarding the 
latter,
                > >'those require a higher threshold to initiate a PDP'. 
                > Please explain.
                > >
                > > >
                > > > - Those that are out-of-scope of the picket fence. If
                > deemed to be
                > > > within Council scope as above, they do not require the 
higher
                > > > threshold, but of course cannot be used to set a 
consensus policy.
                > >
                > >Chuck: Again, where does the 'higher threshold'
                > >concept come from.  In the case of possible consensus
                > policies, if the
                > >Council recommends a consensus policy with a supermajority
                > vote, then
                > >the threshold for the Board rejecting it is higher than it 
is if the
                > >Council recommends it with a simple majority vote.  Is that 
what you
                > >are referring to?
                > >
                > > >
                > > > I was told that the entire PEDNR issue is within GNSO
                > scope, and it
                > > > was worded as such based on that advice. But clearly only
                > parts are
                > > > within the picket fence of the RAA.
                > > >
                > > > All of this is not what I understood going into this 
process, but
                > > > *IF* I got it right, that is the current interpretation
                > according to
                > > > staff.
                > > >
                > > > Alan
                > > >
                > > > At 02/04/2009 02:43 PM, Tim Ruiz wrote:
                > > >
                > > > >If that's the type of thing we want this group to look
                > at then it
                > > > >requires a different threshold of approval, correct? 
It's not
                > > > >appropriate to try and include out of scope things with 
in
                > > > scope things
                > > > >because the latter has a lower threshold of approval to
                > get started.
                > > > >
                > > > >So perhaps that's the fundamental question. But I suggest
                > > > this motion
                > > > >stick with what's in scope.
                > > > >
                > > > >Tim
                > > > >
                > > > >   -------- Original Message --------
                > > > >Subject: RE: [council] PEDNR Motion
                > > > >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
                > > > >Date: Thu, April 02, 2009 1:14 pm
                > > > >To: GNSO Council <council@xxxxxxxxxxxxxx>
                > > > >
                > > > >
                > > > >Tim, We are talking to different ends. I am talking
                > about changes
                > > > >to how compliance is measured or enforced.
                > > > >
                > > > >I will give a specific and current example. The February 
2009
                > > > >Contractual Compliance Semi-Annual Report. One of the
                > measures was
                > > > >whether Registrars were honoring the Deletion and
                > Renewal Consensus
                > > > >Policy. This was carried out by reviewing Registrar web 
sites.
                > > > >
                > > > >ICANN Counsel has confirmed the a Registrar cannot avoid 
their
                > > > >contractual obligations by simply sub-contracting the
                > > > responsibilities
                > > > >to others. This is explicitly reinforced in the recently
                > > > approved RAA
                > > > >Amendments. The Registrar is responsible if their
                > > > subcontractor is not
                > > > >adhering to the agreement.
                > > > >
                > > > >However, compliance staff have routinely said that they
                > > > cannot consider
                > > > >reseller issues, because ICANN does not have a contract
                > with these
                > > > >resellers. However, if one is to try to audit a
                > registrar who has
                > > > >sub-contracted obligations to a reseller, one must look
                > at whether
                > > > >their resellers are doing the job properly - there is no
                > > > other way for
                > > > >ICANN to independently conduct such an audit. Requiring 
that
                > > > ICANN at
                > > > >least sample resellers for those Registrars who use them
                > should be
                > > > >mandatory.
                > > > >
                > > > >To this end, I may be mistaken, but I don't believe that 
the
                > > > RAA (old
                > > > >or new) requires that Registrars disclose to ICANN who 
their
                > > > resellers
                > > > >are. Yet without this information, how can ICANN even
                > > > pretend that they
                > > > >are auditing their contracts. Adding such a requirement 
is
                > > > exactly the
                > > > >kind of issue that could only be addressed under the 
"advice
                > > > for future
                > > > >RAA amendments" type of PDP output.
                > > > >
                > > > >Alan
                > > > >
                > > > >At 02/04/2009 01:44 PM, Tim Ruiz wrote:
                > > > > >Alan,
                > > > > >
                > > > > >My amendment uses the verbiage right out of the issues
                > > > report. But to
                > > > > >answer you question directly, I don't see any reason
                > to include it.
                > > > > >
                > > > > >As Staff suggests in the issues report, the TF or WG
                > > > should consider
                > > > > >information from compliance Staff about how related
                > > > current policy is
                > > > > >enforced (related RAA provisions and related consensus
                > policies).
                > > > > >This information could be used by the group to craft
                > > > consensus policy
                > > > > >or consensus policy changes that complaince Staff could
                > > > actually enforce.
                > > > > >That's an expected consideration in any policy
                > > > developement work and
                > > > > >doesn't really need to be spelled out.
                > > > > >
                > > > > >Tim
                > > > > >
                > > > > > -------- Original Message --------
                > > > > >Subject: RE: [council] PEDNR Motion
                > > > > >From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
                > > > > >Date: Thu, April 02, 2009 12:06 pm
                > > > > >To: "GNSO Council" <council@xxxxxxxxxxxxxx>
                > > > > >
                > > > > >
                > > > > >Tim, we may agree to differ on this.
                > > > > >
                > > > > >In your proposed replacement motion, you also dropped 
and
                > > > reference
                > > > > >to the PDP process making recommendations to ICANN
                > > > compliance staff.
                > > > > >Do you have a reason for excluding this as well?
                > > > > >
                > > > > >Alan
                > > > > >
                > > > > >At 02/04/2009 12:03 PM, Tim Ruiz wrote:
                > > > > >
                > > > > > >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. 
                > > gree> > nberg@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 utcomes stated by ALAC in
                > > > > > > > >its
                > > > >
                > >
                > 
requestâÂÂÂÂÃ
                > > ‚€ÃƒƒÃ‚‚™,
                > >
                > > > some of wh 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
                > > > >ƒâ€šÃ‚â„¢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 >>>