Hi Stephanie,
I believe the handbook is doable.
We can always review such soon.
- Akinbo.

On Fri, Mar 1, 2024, 4:43 PM Stephanie E Perrin <
[log in to unmask]> wrote:

> I believe I mentioned when we discussed this a while ago...I would like to
> see work on a handbook of registrants rights and obligations (with the
> emphasis on rights) recommence.  There have been a lot of changes in
> information policies since the last effort fizzled out around 15 years
> ago.  Bear in mind that many ordinary users buy their domains through
> resellers, and have no idea who the accredited registrars are, or who ICANN
> is for that matter.  Public information needs to be better, what better way
> than a handbook.  So no, we don't need just a policy status report on this
> stuff, we need a total review of how RNHs understand their rights and
> obligations.
>
> Yes, this demand is slightly off topic.  One has to do that when a
> longstanding need is being ignored....
>
> cheers Stephanie Perrin
> On 2024-02-29 8:14 p.m., Tomslin Samme-Nlar wrote:
>
> Dear members,
>
> As described below, we have discussed the potential of the Council
> requesting a policy status report (PSR) in multiple PC calls over the past
> year. To help the Council decide, 3 sets of information were requested by
> or provided to the council.
> 1. Registrar input
> 2. ICANN compliance input
> 3. ICANN org Registrant Program
>
> Based on these, the Council must now decide to proceed with one of the
> following options. Please review and we will have a discussion at our PC
> meeting in San Juan this week on what NCSG thinks is the way to go:
>
> 1. Yes, after reviewing the materials, the Council would like to request a
> Policy Status Report.
>
> 2. A Policy Status Report is not yet warranted. The Council believes
> further policy work on this is needed, but now is not the time due to
> current workload and prioritization of other more pressing work. We would
> like to revisit this decision in 2 years.
>
> 3. No, the Council is not requesting a Policy Status Report at this time,
> as the policy seems to have been implemented as intended. The Council
> commits to reconsider this decision in 5 years. If ICANN org or a group
> within the ICANN community believe imminent work on these policies is
> necessary, they are welcome to address the GNSO Council, and we will
> reconsider this decision at that time.
>
> Warmly,
> Tomslin
>
> ---------- Forwarded message ---------
> From: DiBiase, Gregory via council <[log in to unmask]>
> Date: Wed, 21 Feb 2024, 17:12
> Subject: [council] ERRP/EDDP next steps
> To: [log in to unmask] <[log in to unmask]>
>
>
> Dear Councilors,
>
>
>
> We are following up on our discussion regarding the Expired Domain
> Deletion Policy (EDDP) and the Expired Registration Recovery Policy (ERRP).
> We are deciding whether to request a Policy Status Report reviewing these
> policies. When we looked at this issue last year, ICANN Compliance noted
> some registrant confusion around existing ERRP/EDDP policy and domain
> renewal generally (see their report here
> <https://mm.icann.org/pipermail/council/2022-November/026164.html>). In
> response, Council requested information on what education materials re:
> ERRP/EDDP policy currently exist (see portion of original Council request
> below). During the last Council meeting, Brian Gutterman from ICANN org
> responded to this request from Council by outlining the current resources
> available to registrants regarding the ERPP/EDDP (see attached).
>
>
>
> Council must now decide if it should request a Policy Status Report on the
> ERRP/EDDP. As referenced above, we have the following existing inputs to
> guide us:
>
>
>
>    1.  Registrars, who were asked to flag substantial issues with the
>    policies that would warrant a near team request for policy status report
>    and did not note any issues
>    2.  ICANN Compliance, who provided a write-up
>    <https://mm.icann.org/pipermail/council/2022-November/026164.html>, noting
>    confusion with key terms in the policy and persistent registrant confusion
>    with the auto-renew grace period and aftermarket activities, et.al.
>    3. ICANN org Registrant Program, provided a catalog of the available
>    educational resources on domain name expiration and renewal (Brian’s
>    update at Council)
>
>
>
> Plus any other inputs your SOs/ACs are aware of and would like to bring to
> Council’s attention.
>
>
>
> Potential options are:
>
>
>
>    1. Yes, after reviewing the materials, the Council would like to
>    request a Policy Status Report.
>    2. A Policy Status Report is not yet warranted. The Council believes
>    further policy work on this is needed, but now is not the time due to
>    current workload and prioritization of other more pressing work. We would
>    like to revisit this decision in 2 years.
>    3. No, the Council is not requesting a Policy Status Report at this
>    time, as the policy seems to have been implemented as intended. The Council
>    commits to reconsider this decision in 5 years. If ICANN org or a group
>    within the ICANN community believe imminent work on these policies is
>    necessary, they are welcome to address the GNSO Council, and we will
>    reconsider this decision at that time.
>
>
>
> Please review this material with your SOs/ACs and we will revisit this
> topic at the April GNSO meeting.
>
>
>
> Original request from Council re: educational materials:
>
>
>
> “*In recognition of the reported ongoing registrant confusion, however,
> the Council notes that additional guidance for registrants may be
> appropriate. […] [T]he Council would like to request further information
> from ICANN org on what expiration-related educational materials are
> currently published and whether additional information can be provided
> (whether as registrant educational material referenced in Section 4.3 or
> elsewhere on ICANN’s website). Receipt of this information will be helpful
> to the Council in determining if updates to these materials or additional
> material in other forms could be helpful to combat the ongoing registrant
> confusion.”*
>
>
>
> Thanks,
>
> Greg
>
>
>
>
>
> *From: *Caitlin Tubergen <[log in to unmask]>
> *Date: *Wednesday, February 14, 2024 at 3:36 PM
> *To: *"[log in to unmask]" <[log in to unmask]>
> *Cc: *Brian Gutterman <[log in to unmask]>
> *Subject: *Re: [council] Summary of domain name renewal and expiration
> educational resources (Feb Council Agenda Item 6)
>
>
>
> Dear Councilors,
>
>
>
> Please find an updated attachment.
>
>
>
> Apologies for the additional email.
>
>
>
> Kind regards,
>
>
>
> Caitlin
>
>
>
> *From: *council <[log in to unmask]> on behalf of Caitlin
> Tubergen via council <[log in to unmask]>
> *Reply-To: *Caitlin Tubergen <[log in to unmask]>
> *Date: *Wednesday, February 14, 2024 at 10:07 AM
> *To: *"[log in to unmask]" <[log in to unmask]>
> *Cc: *Brian Gutterman <[log in to unmask]>
> *Subject: *[council] Summary of domain name renewal and expiration
> educational resources (Feb Council Agenda Item 6)
>
>
>
> Dear Councilors,
>
>
>
> Further to Agenda Item 6 for Thursday’s Council meeting, Next Steps for
> Consideration of Expired Domain Deletion Policy (“EDDP”) and Expired
> Registration Recovery Policy (“ERRP”), please find a summary of the current
> educational materials on domain name renewal and expiration attached.
>
>
>
> Brian Gutterman from ICANN org will be providing an overview of the
> materials during the Council meeting on Thursday.
>
>
>
> Kind regards,
>
>
>
> Caitlin
> _______________________________________________
> council mailing list
> [log in to unmask]
> https://mm.icann.org/mailman/listinfo/council
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
>