ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

[gnso-irtp-b-jun09] FW: Adobe Acrobat Connect Pro - Chat Transcript from IRTP Part B

  • To: "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: [gnso-irtp-b-jun09] FW: Adobe Acrobat Connect Pro - Chat Transcript from IRTP Part B
  • From: Marika Konings <marika.konings@xxxxxxxxx>
  • Date: Tue, 31 Aug 2010 08:01:51 -0700

Dear All,

Please find below the chat transcript of today’s meeting.

With best regards,

Marika

==============================

  Marika Konings:IRTP Part B WG Meeting - 31 August 2010
  Berry Cobb:Hi Marika & Michele.  We're you two aware of "IRTP Beta Audit" 
being conducted by Compliance?  Pam Little briefed the Japan Ry/Rr group and 
made mention of it there.
  Michele Neylon:um sort of
  Michele Neylon:David had mentioned it a while back I think
  Michele Neylon:and I thnk that it was mnetioned in Brussles
  Berry Cobb:k, thought that may have been what he was talking about.
  Berry Cobb:I think they may have numbers now.  we should contact them to see 
what they came up with.
  Marika Konings:Yes, I am
  Marika Konings:I can check with Pam to see where things are
  Michele Neylon:just dialling in
  mikey:me too
  mikey:stupid music today
  Chris Chaplow:wow ful house already
  Paul Diaz:Do we have to do the "SOI update" like we did on VI yesterday?
  Michele Neylon:*sigh*
  Michele Neylon:I'll ask
  Marika Konings:It is actually a DOI (Disclosure of Interest) request that is 
required at the start of the meeting
  Marika Konings:Disclosure of Interest:  Relevant to a specific issue at a 
specific time.  A written statement made by a Relevant Party of direct and 
indirect interests that may be commercial (e.g. monetary payment) or 
non-commercial (e.g. non-tangible benefit such as publicity, political or 
academic visibility) and may affect, or be perceived to affect, the Relevant 
Party's judgment on a specific issue.
  michael collins:sorry I'm late
  Michele Neylon:hi
  Bob Mountain:No echo here.
  Simonetta Batteiger:no echo here either
  Michele Neylon:mikey is up next
  Marika Konings:From the Issues Report in relation to issue B: The WG notes 
that the IRTP is widely used to effect a change of "control" over a given 
registration, as opposed to simply moving the registration to a new sponsoring 
registrar with all contacts unchanged. While the IRTP lists both the registrant 
and the admin contact as authorized "transfer contacts" to change registrars, 
the change of control function is not defined. Therefore, the WG recommends 
that only the registrant can effect a change of control, while both the 
registrant and admin contact remain eligible to authorize a transfer that does 
not modify any contact information. This could be achieved by either (a) 
restricting the admin contact's ability to modify any contact information 
associated with the domain name, or (b) ensuring that any transfer reversal or 
change of control features are explicitly limited for use by the registrant 
only. The WG seeks input from the community on this proposed recommendation.
  Bob Mountain:Agreed
  Barbara Steele-RySG:I didn't mean to confuse everyone.  I may have 
misunderstood.
  Michele Neylon:Barbara - you've broken us :)
  James Bladel::)
  Simonetta Batteiger:what is the intent of the public display? why would you 
want the thick information public?
  Paul Diaz:Registrant email is not a required field for the public WHOIS; 
thick models "could be less secure" in so far that a hacker can seen and then 
gain control over that email
  James Bladel:I think this is a solid endorsement of Privacy/Proxy services by 
the RySG.  :)
  Paul Diaz::-)
  Marika Konings:From the Initial Report: The WG is considering a 
recommendation to request an Issues Report on the requirement of ‘thick’ Whois 
for all gTLDs. The benefit would be that in a thick registry one could develop 
a secure method for a gaining registrar to gain access to the registrant 
contact information. Currently there is no means for the secure exchange of 
registrant details in a thin registry. In this scenario, disputes between the 
registrant and admin contact could be avoided, as the registrant would become 
the ultimate approver of a transfer. The WG is interested to receive input from 
the community on why it should or why it should not consider this 
recommendation for a PDP to require ‘thick’ Whois for all gTLDs.
  Barbara Steele-RySG:I don't know that I would go that far.
  Paul Diaz:correct, Michael Collins
  James Bladel::)
  Berry Cobb:If user accounts were setup with usernames and not email 
addresses, this becomes a non-issue right?
  Michele Neylon:Berry - not really :)
  Berry Cobb:bummer
  Michele Neylon:Berry - we've seen them get hacked
  Paul Diaz:Perhaps, Berry, but the IPC will go crazy if this WG recommends 
moving away from publishing email addresses
  Paul Diaz:so will Law Enforcement
  Simonetta Batteiger:could we then not recommend that the registrant email in 
a thick WhoIs should not be displayed?
  Berry Cobb:i support the publishing of the email addy, b/c that is the most 
important contact method.  If usernames were only used to access Rr acct, then 
the publishing of an email address would not be a primary threat in gaining 
access to one's acct.
  Matt Serlin:agreed...i think publication of the registrant e-mail is fine
  Matt Serlin:and i don't think e-mail security should be something that we 
consider as part of this
  Simonetta Batteiger:the privacy protected email system allows for contacting 
the registrant without publishing a real email address
  Berry Cobb:Exactly.  what is root cause to the hijacks.
  Berry Cobb:If the RCA shows that an email addy is used and identified as 
vunerability, then how can it be outside of scope to recommend a possible fix 
for root cause?
  James Bladel:And the SSAC i htink
  Matt Serlin:yes in SSAC 40
  Matt Serlin:there were some recommendations in there for security

------ End of Forwarded Message


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

Privacy Policy | Terms of Service | Cookies Policy