Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleRECORDINGS

Audio Recording

Zoom Recording 

GNSO transcripts are located on the GNSO Calendar


Note

Notes/ Action Items


ACTION ITEMS/HOMEWORK: Staff to draft options for preliminary recommendation language for the Working Group to review and discuss on the next call.


  1. Welcome and Chair updates
  • We are a little more than a month out from ICANN78; need to get the bulk transfer concepts wrapped up in the next couple of weeks.
  • Work Plan: We have a few weeks left to discuss bulk transfers; there was some slack – but now there is not.  Today was supposed to be about what the WG agreed on for preliminary recommendations.  If we don’t finish this topic by the end of September this PDP will be downgraded to “At Risk”.  So we have until meeting #105 to finish.

2. Continue discussion of Preliminary Agreements [docs.google.com]from Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers)

i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report [gnso.icann.org], should the required fee in Section I.B.2 of the Transfer Policy be revisited or removed in certain circumstances?  See attached slides, starting at slide 61.

i1) Preliminary Agreement #1

The Working Group recommends that a Registry Operators MAY charge a fee to implement a full domain name portfolio transfer* from one ICANN-accredited registrar to another ICANN-accredited registrar. The Working Group recognizes that there may be instances where the Registry Operator MAY waive this fee.**

* Note: this could include all of the domain names a registrar has within a gTLD or all of the gTLD domain names a registrar has under management.

** A non-exhaustive list of examples where a Registry Operator may choose to waive the mandatory fee include cases where a registrar is involuntarily terminated by ICANN org due to a breach, ICANN terminates a registrar due to unresponsive to accreditation renewal notices, a registrar chooses to voluntarily cease operations with a specific TLD, etc.

Concept 4: If the full portfolio transfer involves multiple registries, the affected registries must ensure the collective fee does not exceed the recommended ceiling, and the fee should be apportioned based on the number of domain names. By way of example, if a registrar has 60,000 domains under management under two TLDs, e.g., 40,000 names under .ABC, and 20,000 names under .DEF, the combined fee cannot exceed [$50,000] USD (per concept 3). Since two thirds of the names under management are registered to .ABC, .ABC registry may bill the Gaining Registrar for up to 66.66% of the total fee [of $50,000], e.g., up to $33,333.33, and .DEF may bill the Gaining Registrar for up to the remaining 33.33% of the total fee [of $50,000], e.g., up to $16,666.67. [If .DEF registry chooses to waive its portion of the fee for the Gaining Registrar (per Preliminary Agreement #1), .ABC registry may still only bill the Gaining Registrar up to 66.67% of the total fee of [$50,000], and not adjust it to a higher percentage in light of the other registry’s waiver.]

i2) Preliminary Agreement #1

In the event a change of sponsorship is permitted by the Registry operator, Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registrants at least [30 days] before the change of sponsorship will occur and provide opt out instructions where applicable. [This notification must provide the date of the change of sponsorship, the name of the Gaining Registrar, and the Gaining Registrar’s (or their Reseller’s) terms of service.]

  • Should we specify a link where those terms of service can be found instead of listing the full terms of service?
  • Also comment from Steinar: “Adding to the list the Registrant option to transfer to another Registrar other than the "Gaining Registrar"” – and question, should we include “where applicable”?
  • Think we don’t need the last “where applicable” before the brackets.
  • There are two possibilities as opting out – the path of letting the registrant know, giving the registrant the option to make that decision on their own. Need to be careful not to call it “opting out”.  But both concepts need to be brought out.
  • Clarify under what circumstances would there not be an option for the registrant?  What if there is timing that it has to happen sooner rather than later.
  • When dealing with change of sponsorship we have some notion of when something is supposed to happen, but only if everything goes right.  What are we going to do if the date changes?  Do we send another notification?
  • In the original notice do you set a date range?
  • In the chat we tried to incorporate some of the suggestions: ““In the event a change of sponsorship is permitted by the Registry operator, Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registrants at least 30 days before the change of sponsorship will occur. This notification must provide (i) opt out instructions, (ii) the approximate date of the change of sponsorship, (iii) the name of the Gaining Registrar, and (iv) a link to the Gaining Registrar’s (or their Reseller’s) terms of service.” Also, change to “expected date”.
  • If it slips at least the registrant knows what that last date should be.
  • It is not only going to be the technical issues, you also need to plan way ahead.  It takes a lot of planning to make this happen.
  • The notification can advise that the transfer will occur "no earlier than X". The registrant will be able to transfer to an alternative registrar, if available, prior to that date.
  • Question: If there are multiple TLDs being moved, would we need multiple emails or one?  Answer: Maybe both, depending on the registries involved.
  • Re: 30 days – transfers don’t happen immediately, so not sure that 30 days is practical.  Also, how does that work with a 30-day lock? Sponsorship change also is different.  Not really a transfer.
  • Would it be sufficient to indicate that the requirement is notification, without saying if it’s singular (aggregate) or multiple; and on the issue of timing say, “must be notified no less than 30 days in advance and no more than 60 days in advance; also that this does not supersede any other required notifications.
  • Should keep the details to a minimum – don’t have to specify number of notifications.

i2) Preliminary Agreement #1

Rationale:

Advance notice would give affected registrants the ability to transfer their name elsewhere if they so desire or opt out of the transfer if that option is available. In some instances, such as a registrar consolidation where a registrar will cease to exist upon the transfer, the option to opt out may not be available. [Clarifying when the transfer will take place, to which registrar it will transfer, and what their terms of service are enables registrants to familiarize themselves with the new registrar and their terms before the change of sponsorship takes place.]

i2) Preliminary Agreement #4

The losing registrar’s existing Registration Agreement with customers must permit the transfer of domain names in the event of the scenarios described in the Transfer Policy with respect to a change of sponsorship. [Additionally, the losing registrar’s Registration Agreement must inform registrants that in the event of a change of sponsorship, the affected registrants will be deemed to have accepted the new registrar’s terms, unless the registrant transfers their domain name(s) to a different registrar prior to the change of sponsorship. Prior to initiating the transfer, the losing registrar and gaining registrar must ensure that they, or their Resellers (where applicable), have confirmed the affected registrants have agreed to the new terms.]

  • Not sure how the losing and gaining registrar can confirm that the registrant has agreed to the new terms.
  • Maybe we had to clean that up. If you're sending a notice to the registrants and that notice includes something similar to this, then you're putting that in the registrants’ hands from a registrar standpoint. And the text clearly states they're either moving it to somewhere where they want to or they're accepting the registrar’s terms of service by continuing along this path.
  •  The highlighted yellow text, where it says that the registration agreement must inform registrants that the new agreement comes into effect, that seems to contradict to that final sentence where it says that the registrars have to confirm that they've agreed to the new terms. If they've been deemed to have accepted it, then there's no confirmation necessary. So I wonder if we should remove that final sentence?
  • Maybe the last sentence isn't needed.  We can do some updating.
  • We're ready to change these from loose agreements here to preliminary recommendations for the group to start honing in on language and syntax.


Review of homework:

The 5 questions pertaining to (i1) Concepts are provided below:

  1. Regarding Concept 3, is $50,000 the final number to be used for the proposed price ceiling? 

→ Concept 1:  The Working Group recognizes that a fee may be involved in a full portfolio transfer but believes flexibility is necessary, and the number should not be explicitly prescribed in the Transfer Policy.

→ Concept 2: The Working Group also recognizes, however, that a price ceiling is helpful to include in the policy language to promote transparency in pricing.

→ Concept 3: In light of Concept 2, the Working Group believes the total fee for a full portfolio transfer must not exceed [$50,000 or $1.00 per domain name transferred].

Discussion:

  • This is in reference to the concepts we put together about the pricing. That's currently in the policy versus what it should be going forward.  There were 5 questions that were posed to the Working Group. We had put those into the working document, but didn't receive any feedback on those unfortunately. So now is the time for the group to talk through some of these questions.
  • We’ve been talking in the abstract and in Concept 3 below. We've bracketed the actual amount since the group hasn't really agreed on an amount. And so I think you know the options in terms of the amount on the screen. The $50,000 either stays a status quo with some new parameters around it that the group has discussed, for example, the ceiling on the price would be divided amongst all the affected registry operators rather than every affected registry operator having the ability to charge that amount of money.  Alternatively, the group could change that number for something that's widely accepted. The group could agree to you to remove the fee entirely and use something like cost recovery/reasonable, but of course but we've talked about some of the drawbacks of doing that. Again, the group could consider doing a tiered structure, but, so far I don't think anything that staff and leadership had suggested have been widely accepted by the group. As we noted, we're kind of running out of time to discuss this.
  • There's strong support for getting rid of the exact number in in the policy. It sounded like the group was very supportive of removing that from the current policy.  And then we can move on to talking about do we replace it or not?
  • So if we, if we take it out, what would the language say?
  • A reasonable fee should be charged, whatever it is. Because if we don't have support for any other ideas, then maybe the language gets a lot simpler, and it does just become a reasonable fee can be charged..
  • We don’t know if this is reasonable or not.  How do you determine that and can it be enforced?
  • Without agreement the $50K remains.
  • Could remove it and replace with “reasonable” or comes up with the perfect algorithm.
  • What happens if a reasonable fee is higher than the ceiling?
  • This fee hasn’t been charged very much; adding in “reasonable” seems to cause uncertainty.  It hasn’t caused problems so we should leave it as is.
  • With the policy changes we’ve agreed so far this may be used more often.
  • If a fee is charged it should be collectively set across parties – should not be mandatory and should be a reasonable amount.  Having a predictable price has been helpful.
  • We are only talking about when you hit 50K names per TLD.  We aren’t talking about a BTAPPA situation.  It hasn’t kicked in that often.
  • We are either sticking with the current language -or- removing numbers and putting them some place else -or- other?
  • Have not found that middle ground after several weeks.  People were talking about removing the fee from the policy but haven’t agreed on what to replace it with.  No one is getting to that middle term.
  • From a RO perspective a BTAPPA is very different from a full portfolio transfer.


2. In the current policy, there is no charge to transfer less than 50,000 domains, but transferring 50,000 or more comes with a flat fee of $50,000. Is this concept of having a minimum/“ledge” of domain names still applicable?

Discussion:

  • Doesn’t seem like there’s logic behind this – heard that maybe these aren’t the right numbers and that maybe they should be removed or replaced.
  • Doesn’t this invite gaming? You could do 49K.
  • You can’t chunk this because we know how many names the registry has – this fee would only apply when transferring a full portfolio/all names under management.
  • Could you do a partial and then full transfer? Maybe but that would be known fairly quickly.
  • There is an ambiguity – old policy would seem to suggest whether or not there is a fee it depends on the outgoing names from a registrar (50K or more).
  • But it is per registry operator.
  • The apportioning takes work, but we could figure that out.  The apportionment will need an administration mechanism… likely via ICANN Org.
  • It sounds like we are talking about staying within the framework of the current policy and making smaller adjustments to that policy.
  • Whatever language we have with a fee, make sure it is “MAY”.
  • Yes, that is what the current preliminary agreements say. (May) Showing the currently policy for ease of reference.
  • Need a project manager to represent the registrant.
  • Need to think about how ICANN could be involved.
  • How can leadership and staff help the group move forward?
  • Helpful to give options.