Page History

PROPOSED AGENDA

1. Welcome and ChairupdatesChair updates
2. Discussion of additional Security Measures

           aa. Improper CORs

           bb. COR + Registrar transfers

           cc. Poll questions

       3.AOB

BACKGROUND DOCUMENTS

Notes/ Action Items

ACTION ITEMS/HOMEWORK: None captured.

Notes:

1. Welcome and Chair updates

• We have this meeting and next week and then take a break – hope is to have CoR wrapped up by ICANN79.  Great discussions last couple of weeks; hope we can narrow things done.
• Request for updates: None provided.

2. Discussion of additional Security Measures – See attached slides

a. Improper CORs

Option 1 Discussion:

• Status quo – what is required today.  The minimal step today; do you keep this, modify it?
• Within one day of completion is different from before one day.  Issue of how to stop is still up for discussion.
• Also should provide reseller data.  This happens all the time – change of contact info is not necessarily CoR.
• One suggestion though is to be specific by saying to "provide REGISTRAR contact information for questions".
• Two points: 1) Notification in first bullet should be to previous registrant and new; 2) don’t think this is responsive to an improper CoR but to any CoR.
• This is just a change of registrant – change of registrar was in our Group 1a discussions/requirements.
• We don’t know what it is – why there is a modification of data. Then you have a process where something isn’t right – there is a next step.  Until that time you don’t know if it’s improper or not.
• Something for the group to consider here: Note that there is connective tissue back to the whois accuracy specification. Wonder, as part of this of these first 3 steps, or maybe a new number 4, where the whois accuracy specification may be invoked. So I'd ask that the group consider that because it's conceivable that some of these changes to contact information will trigger that part of the specification. But I don't think we dove into the details enough about what happens when the tag is requested, and it is understood that the primary communication methods have been changed. And so the group still may want to consider that.
•  Group 1a was focused just on that registrar transfer. And then a change of registrar is initiated. To your point on Barry, on the whois accuracy specification in the RAA, and that's something that we're contractually obligated as registrars to do. So that has to occur no matter what this policy says. So II think that that's a good call out there. The other thing I was thinking about as you're describing it was the annual whois reminder.  When we send out that reminder it'll probably trigger a lot of these notifications here.
• From the registrar's perspective the less friction with these things and less notifications and emails the better, and to a large degree same for the registrant. At what point in the process would a registrar do the whois accuracy verification with a change of registrant? Would it be prior to the
• registration with the new registration data? If so, that would seem to require an affirmative action of the new registrant. And if that is an email that's going out requesting an affirmative action of the new registrant, which is obviously kind of friction, and one that's unavoidable because of the whois accuracy verification requirements, then it wouldn't seem to be too much of a stretch to also require the losing registrar to make that affirmative action by, you know, either approving right away or taking some action to stop the transfer because they didn't approve it.
• So there's whois accuracy policy. There's who is data reminder policy. Those both touch registration data. They could be triggered by a transfer of ownership or contact update. But although those processes overlap, we do need to be careful to keep them separate mentally. So, for example, there could be a domain where the contact info is updated. So it triggers, whatever CoR process we're going to have.  But it would be updated to a data set that has already been verified because that same person’s data set is owned by a different domain. So that's a situation where we have a CoR process, but not a whois accuracy policy process being triggered. So, they overlap. But they are different, and we should keep them mentally separate.

Option 2 Discussion:

• This isn’t current policy; it adds a requirement.
• Most away from the wording “must investigate and respond” – make sure there is an outcome (DNS abuse negotiations).
• From experience there is barely anything to investigate.
• So for situations where send a reply with no further action is appropriate, what can we require in the policy?
• "Must investigate and take appropriate action as applicable" ?
• Unless it is a very valuable domain name (million $+) there is no recourse.  The piece missing is for the registrant to do something independently.
• The above point is always going to be problematic.
• The TDRP discussion – we talked about having a registrant option, maybe that includes CoR.
• If you want a frictionless CoR you need to empower the registrant.
• From the data, there are very few improper CoRs.  Don’t think it’s possible to put all these red lights in policy – will likely need to be handled by the registrars.
• Caution that we’ve already talked about registrants in change of registrars – disputes in change of registrant is more complex and don’t know that a registrant-initiated dispute would be the right mechanism.  Maybe a short – 30 day? – lock with an opt out?
• There is more than one way to give a registrant agency; what if we went with the bare minimum – then protection from ICANN is minimal so registrants purchase other protection beyond the scope of the transfer policy. So the policy says we can’t protect registrants.
• What we’ve heard is the current policy isn’t working.  We are responding to what people are asking for, not necessarily a minimal policy.
• We have several options and they get more specific.
• It’s not that (domain theft) occurs often, but that when it occurs it is destructive.
• What I am hearing is option 1 makes sense and maybe that there is something the registrar should do (option 2) “as appropriate.

Option 3 Discussion:

• This stating registrars have to offer an appeals process; option 4 would provide more details.
• Question: Why isn’t the fallback just to confirm that the registrant of record made the change and the new registrant? Answer: It can get more complicated than just going back to the prior registrant.
• Sometimes these can be very complex.
• Would like to know from registrars that have them why they have an appeals process and how it works – or registries. 
• Very small registrars can’t/won’t do this.  The more policy you put in the harder it is – have to think about balance.
• Should be left to registrars – not sure we need a policy; but not opposed to a requirement to offer the option as long as it’s required of all registrars.
• Can’t see a lawyer advising a registrar to have an appeals process – but registrars are already doing this; you are regulating for the worst actors.
• What  you are trying to do with the requirement for an appeals process is having the registrar to take the role of the court.   This currently is an informal process.  Don’t want to have the liability (if it’s a requirement) if we get it wrong.
• There shouldn’t be a policy to have a process that doesn’t say what that process is.

b. COR + Registrar transfers [Deferred for lack of time].

c. Poll questions

There will be two sets of poll questions, first following the 2.a. discussion, then following the 2.b. discussion. They will look like this:

(2.a.)

Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when an improper COR occurs? Select your first, second, and third choices (if applicable)

Option 1: Registrars must provide contact information for questions (current policy) – 50%

Option 2: Registrars must investigate/respond to reports of improper CORs - 83%

Option 3: Registrars must provide a dispute/appeal process to correct improper CORs - 83%

Option 4: Registrars must provide an appeal process with specific criteria to correct improper CORs - 67%

Option 5: Other - 58%

Option 6: None of the above 17%

If you selected "Other", please explain: ____________________

Poll Questions and Wrap-Up Discussion:

• Option 4 would be the most prescriptive.
• Sounds like people were comfortable with option 1 and maybe option 2 with wording changes.
• Option 1: strike through on the lock – not strike through.  One of the options to come is retaining that lock.
• Are the options cumulative?

(2.b.)

[Deferred for lack of time]. Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when a TAC request follows a completed COR? Select your first, second, and third choices (if applicable)

Option 1: No special requirements are necessary.

Option 2: There should be a waiting period before issuing the TAC, allowing time for objections.

Option 3: Before issuing the TAC, changes to RNH/Account Holder information must be verified.*

Option 4: Following a COR, impose a 30-day transfer lock, but allow Registrars to lift it, if agreed.

Option 5: Registrars must offer registrants an opt-in option for added protection.

Option 6: Other

Option 7: None of the above

If you selected "Other", please explain

________________

3. AOB