From caitlin.tubergen at icann.org Tue Dec 2 21:52:17 2014 From: caitlin.tubergen at icann.org (Caitlin Tubergen) Date: Tue, 2 Dec 2014 21:52:17 +0000 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 Message-ID: Hi All, Please save the date for the final IRTP-C IRT call before the draft Change of Registrant Policy goes out for public comment. The draft policy is attached; a briefing document, describing two outstanding issues, is also attached. If you would like to distribute the documents to your colleagues, or other interested parties, please do so before the the call on Thursday, 11 December 2014. Comments on the policy or the briefing document should be delivered to me prior to the call on Thursday, 11 December. Details for 11 December Call The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 11 December 2014 at 17:00 UTC. 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. Link to Adobe Connect (with audio enabled): https://icann.adobeconnect.com/irtppartc/ *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. If you are Unable to log into Adobe Connect and can only join via phone: List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num=1-719-457-6209 Participant Passcode: 6458688446 Please let me know if you have any questions. Kind regards, Caitlin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft Change of Registrant Policy_13Nov[2].docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 114104 bytes Desc: Draft Change of Registrant Policy_13Nov[2].docx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Updated Change of Registrant Policy Issues Briefing Document 2Dec.docx Type: application/x-msword Size: 100908 bytes Desc: Updated Change of Registrant Policy Issues Briefing Document 2Dec.docx URL: From mike at haven2.com Tue Dec 2 22:16:44 2014 From: mike at haven2.com (Mike O'Connor) Date: Tue, 2 Dec 2014 16:16:44 -0600 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 In-Reply-To: References: Message-ID: <6D6F80C0-C94A-4ED1-A7D3-3C6397F79E82@haven2.com> bah! please ignore all those meeting update messages from me. i had no idea my server had such powers. mike On Dec 2, 2014, at 3:52 PM, Caitlin Tubergen wrote: > Hi All, > > Please save the date for the final IRTP-C IRT call before the draft Change of Registrant Policy goes out for public comment. > > The draft policy is attached; a briefing document, describing two outstanding issues, is also attached. If you would like to distribute the documents to your colleagues, or other interested parties, please do so before the the call on Thursday, 11 December 2014. Comments on the policy or the briefing document should be delivered to me prior to the call on Thursday, 11 December. > > Details for 11 December Call > The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 11 December 2014 at 17:00 UTC. > 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. > > Link to Adobe Connect (with audio enabled): https://icann.adobeconnect.com/irtppartc/ > *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). > After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. > If you are Unable to log into Adobe Connect and can only join via phone: > List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num=1-719-457-6209 > Participant Passcode: 6458688446 > > Please let me know if you have any questions. > > Kind regards, > > Caitlin > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) From terri.agnew at icann.org Tue Dec 9 22:13:31 2014 From: terri.agnew at icann.org (Terri Agnew) Date: Tue, 9 Dec 2014 22:13:31 +0000 Subject: [gnso-impl-irtpc-rt] PLEASE RSVP Monthly GNSO WG Newcomer Open House Session In-Reply-To: <6d7533cd741540c8a710eb10b02c2387@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <6fe6e301344e4fd1b1546f9cbeeba37b@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <6d7533cd741540c8a710eb10b02c2387@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: Reminder: Monthly GNSO WG Newcomer Open House Session These ongoing monthly sessions are for new GNSO WG participants to come together and discuss any questions they may have about GNSO Working Groups, procedures and/or processes. We know there is a lot of information to digest when you join a GNSO Working Group and these monthly meetings are an opportunity for newcomers and more experienced participants to meet in an informal setting without the pressure of "real work" that needs be done. The agenda is flexible. The presenters will be ready with a standard set of materials if people would like to discuss them. Feel free to submit questions, either in advance or at the beginning of the meeting, if there is a topic that you would like to explore in more depth . Providing useful answers to a wide range of questions is part of the reason why these meetings are Thursday 11 December at 12.00 UTC To convert to your local time zone, please see http://www.timeanddate.com/worldclock/converter.html If you are interested to join the next meeting on 11 December or any of the future meetings, please let the GNSO Secretariat know ( gnso-secs at icann.org) and we will send you the call details. If there are any specific questions you already have, or any overviews or introductions you think would be helpful (e.g. GNSO Policy Development Process or GNSO Working Group guidelines), please let us know in advance and we will prepare materials accordingly. Feel free to share this invitation with others that you think may be interested. We look forward to welcoming you at the next meeting! Terri Agnew GNSO Secretariat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5417 bytes Desc: not available URL: From mike at haven2.com Thu Dec 11 13:16:14 2014 From: mike at haven2.com (Mike O'Connor) Date: Thu, 11 Dec 2014 07:16:14 -0600 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 In-Reply-To: References: Message-ID: <3717B054-6FC7-4F34-B83E-3B4714051762@haven2.com> dear all, sorry to respond to this note within hours of the meeting. but i wanted to let you know that i?ll be strenuously opposing Section 3.4 as it represents a change in the intent and policy of IRTP-C. at a minimum, if the IRT insists on the addition of this language, i will raise the ?change of policy which needs to go through Policy/Implementation review? flag. i haven?t been following the Policy/Implementation WG so i don?t know where they are at, but this will make a nifty test case for them because this is a really good example of core policy being changed during implementation. mike On Dec 2, 2014, at 3:52 PM, Caitlin Tubergen wrote: > Hi All, > > Please save the date for the final IRTP-C IRT call before the draft Change of Registrant Policy goes out for public comment. > > The draft policy is attached; a briefing document, describing two outstanding issues, is also attached. If you would like to distribute the documents to your colleagues, or other interested parties, please do so before the the call on Thursday, 11 December 2014. Comments on the policy or the briefing document should be delivered to me prior to the call on Thursday, 11 December. > > Details for 11 December Call > The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 11 December 2014 at 17:00 UTC. > 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. > > Link to Adobe Connect (with audio enabled): https://icann.adobeconnect.com/irtppartc/ > *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). > After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. > If you are Unable to log into Adobe Connect and can only join via phone: > List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num=1-719-457-6209 > Participant Passcode: 6458688446 > > Please let me know if you have any questions. > > Kind regards, > > Caitlin > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) From mike at haven2.com Thu Dec 11 14:10:41 2014 From: mike at haven2.com (Mike O'Connor) Date: Thu, 11 Dec 2014 08:10:41 -0600 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 In-Reply-To: References: <3717B054-6FC7-4F34-B83E-3B4714051762@haven2.com> <1655190648.1481619.1418305632218.JavaMail.zimbra@firstfind.nl> Message-ID: <7C6562B6-6D6E-4612-A37E-1ED051B30F8D@haven2.com> hi all (but mostly to Theo). here?s a link to the final report, where we documented a series of use-cases for transfers: http://gnso.icann.org/en/issues/irtp-c-final-report-09oct12-en.pdf head on down to page 72 - 77 (nearly at the end) and you?ll see a series of graphics that attempt to lay out how various things would work ? maybe we could walk through some of those on the call m On Dec 11, 2014, at 8:04 AM, James M. Bladel wrote: > Mikey & Theo: > > Totally agree. This was discussed on the last call (or at least, the last call I attended). It is a giant loophole that undermines the entire intent and we must find a way to close it. > > Thanks? > > J. > > > From: Theo Geurts > Date: Thursday, December 11, 2014 at 6:47 > To: Mike O'Connor > Cc: Caitlin Tubergen , Barbara Knight , Leticia Castillo , James Bladel , Marika Konings , Gisella Gruber , Arthur Zonnenberg , Phil Corwin , Lars Hoffmann , "gnso-impl-irtpc-rt at icann.org" , Steve Chan , Terri Agnew , "Sedo :: Simonetta Batteiger" , Nathalie Peregrine , Rob Golding , Michele Neylon - Blacknight , Mike Zupke , Bob Mountain > Subject: Re: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 > > Thanks Mike, > > Being the one that raised this issue a few times, i decided to write a lil FAQ for our resellers, incase 3.2 would apply. I give up after an hour or so, i could not come up with a scenario where 3.4 did NOT apply. So for me to carry out this PDP in it's current language as a registrar, is pretty easy, as i would have to do nothing at all. I can't speak for other registrars but i would assume more of us would be in the same boat. > > So yes, this needs to be addressed one way or another. > > Talk to you folks on the call. > > Best regards, > > Theo Geurts > Compliance Officer > > Realtime Register B.V. > > Ceintuurbaan 32A > 8024 AA - ZWOLLE - The Netherlands > > T: +31.384530759 > F: +31.384524734 > U: www.realtimeregister.com > E: support at realtimeregister.com > > > > > > Van: "Mike O'Connor" > Aan: "Caitlin Tubergen" > Cc: "Theo Geurts" , "Barbara Knight" , "Leticia Castillo" , "James Bladel" , "Marika Konings" , "Gisella Gruber" , "Arthur Zonnenberg" , "Phil Corwin" , "Lars Hoffmann" , gnso-impl-irtpc-rt at icann.org, "Steve Chan" , "Terri Agnew" , "Sedo :: Simonetta Batteiger" , "Nathalie Peregrine" , "Rob Golding" , "Michele Neylon - Blacknight" , "Mike Zupke" , "Bob Mountain" > Verzonden: Donderdag 11 december 2014 14:16:14 > Onderwerp: Re: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 > > dear all, > > sorry to respond to this note within hours of the meeting. > > but i wanted to let you know that i?ll be strenuously opposing Section 3.4 as it represents a change in the intent and policy of IRTP-C. at a minimum, if the IRT insists on the addition of this language, i will raise the ?change of policy which needs to go through Policy/Implementation review? flag. i haven?t been following the Policy/Implementation WG so i don?t know where they are at, but this will make a nifty test case for them because this is a really good example of core policy being changed during implementation. > > mike > > > On Dec 2, 2014, at 3:52 PM, Caitlin Tubergen wrote: > > > Hi All, > > > > Please save the date for the final IRTP-C IRT call before the draft Change of Registrant Policy goes out for public comment. > > > > The draft policy is attached; a briefing document, describing two outstanding issues, is also attached. If you would like to distribute the documents to your colleagues, or other interested parties, please do so before the the call on Thursday, 11 December 2014. Comments on the policy or the briefing document should be delivered to me prior to the call on Thursday, 11 December. > > > > Details for 11 December Call > > The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 11 December 2014 at 17:00 UTC. > > 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. > > > > Link to Adobe Connect (with audio enabled): https://icann.adobeconnect.com/irtppartc/ > > *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). > > After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. > > If you are Unable to log into Adobe Connect and can only join via phone: > > List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num=1-719-457-6209 > > Participant Passcode: 6458688446 > > > > Please let me know if you have any questions. > > > > Kind regards, > > > > Caitlin > > > > > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbladel at godaddy.com Thu Dec 11 14:04:23 2014 From: jbladel at godaddy.com (James M. Bladel) Date: Thu, 11 Dec 2014 14:04:23 +0000 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 In-Reply-To: <1655190648.1481619.1418305632218.JavaMail.zimbra@firstfind.nl> References: <3717B054-6FC7-4F34-B83E-3B4714051762@haven2.com> <1655190648.1481619.1418305632218.JavaMail.zimbra@firstfind.nl> Message-ID: Mikey & Theo: Totally agree. This was discussed on the last call (or at least, the last call I attended). It is a giant loophole that undermines the entire intent and we must find a way to close it. Thanks? J. From: Theo Geurts > Date: Thursday, December 11, 2014 at 6:47 To: Mike O'Connor > Cc: Caitlin Tubergen >, Barbara Knight >, Leticia Castillo >, James Bladel >, Marika Konings >, Gisella Gruber >, Arthur Zonnenberg >, Phil Corwin >, Lars Hoffmann >, "gnso-impl-irtpc-rt at icann.org" >, Steve Chan >, Terri Agnew >, "Sedo :: Simonetta Batteiger" >, Nathalie Peregrine >, Rob Golding >, Michele Neylon - Blacknight >, Mike Zupke >, Bob Mountain > Subject: Re: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 Thanks Mike, Being the one that raised this issue a few times, i decided to write a lil FAQ for our resellers, incase 3.2 would apply. I give up after an hour or so, i could not come up with a scenario where 3.4 did NOT apply. So for me to carry out this PDP in it's current language as a registrar, is pretty easy, as i would have to do nothing at all. I can't speak for other registrars but i would assume more of us would be in the same boat. So yes, this needs to be addressed one way or another. Talk to you folks on the call. Best regards, Theo Geurts Compliance Officer Realtime Register B.V. Ceintuurbaan 32A 8024 AA - ZWOLLE - The Netherlands T: +31.384530759 F: +31.384524734 U: www.realtimeregister.com E: support at realtimeregister.com ________________________________ Van: "Mike O'Connor" > Aan: "Caitlin Tubergen" > Cc: "Theo Geurts" >, "Barbara Knight" >, "Leticia Castillo" >, "James Bladel" >, "Marika Konings" >, "Gisella Gruber" >, "Arthur Zonnenberg" >, "Phil Corwin" >, "Lars Hoffmann" >, gnso-impl-irtpc-rt at icann.org, "Steve Chan" >, "Terri Agnew" >, "Sedo :: Simonetta Batteiger" >, "Nathalie Peregrine" >, "Rob Golding" >, "Michele Neylon - Blacknight" >, "Mike Zupke" >, "Bob Mountain" > Verzonden: Donderdag 11 december 2014 14:16:14 Onderwerp: Re: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 dear all, sorry to respond to this note within hours of the meeting. but i wanted to let you know that i?ll be strenuously opposing Section 3.4 as it represents a change in the intent and policy of IRTP-C. at a minimum, if the IRT insists on the addition of this language, i will raise the ?change of policy which needs to go through Policy/Implementation review? flag. i haven?t been following the Policy/Implementation WG so i don?t know where they are at, but this will make a nifty test case for them because this is a really good example of core policy being changed during implementation. mike On Dec 2, 2014, at 3:52 PM, Caitlin Tubergen > wrote: > Hi All, > > Please save the date for the final IRTP-C IRT call before the draft Change of Registrant Policy goes out for public comment. > > The draft policy is attached; a briefing document, describing two outstanding issues, is also attached. If you would like to distribute the documents to your colleagues, or other interested parties, please do so before the the call on Thursday, 11 December 2014. Comments on the policy or the briefing document should be delivered to me prior to the call on Thursday, 11 December. > > Details for 11 December Call > The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 11 December 2014 at 17:00 UTC. > 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. > > Link to Adobe Connect (with audio enabled): https://icann.adobeconnect.com/irtppartc/ > *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). > After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. > If you are Unable to log into Adobe Connect and can only join via phone: > List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num=1-719-457-6209 > Participant Passcode: 6458688446 > > Please let me know if you have any questions. > > Kind regards, > > Caitlin > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at haven2.com Thu Dec 11 16:49:35 2014 From: mike at haven2.com (Mike O'Connor) Date: Thu, 11 Dec 2014 10:49:35 -0600 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 In-Reply-To: References: <3717B054-6FC7-4F34-B83E-3B4714051762@haven2.com> <1655190648.1481619.1418305632218.JavaMail.zimbra@firstfind.nl> Message-ID: <1D4C2179-78F8-451F-8C66-C3D1186F5557@haven2.com> i?ve been staring at 3.4 for a while? in [3.1 e)] we refer to Section 3.4 as the section where Prior Registrants can opt out of the 60 day lock in [3.4] we?re talking about those cases where credentials don?t need to be exchanged are we looking at a drafting error? the intent of the opt-out language in [3.1. e)] is to provide a registrant who is in a hurry to transfer their name a way to avoid the 60-day lockout. the current [3.4] language is talking about removing the exchange of credentials [3.2] for those cases where the registrant is actually changed. those seem like really different things ? so it seems like we can look at either; - change 3.4 back to opting out of the 60-day lockout (which seems like something we need to do in a section somewhere) or - use [3.4] to specify those circumstances where there doesn?t need to be an exchange of credentials (which would be those cases where the update of registration data does NOT cause a change of registrant) just a few notes, to help me remember what i?ve been thinking about m On Dec 11, 2014, at 8:04 AM, James M. Bladel wrote: > Mikey & Theo: > > Totally agree. This was discussed on the last call (or at least, the last call I attended). It is a giant loophole that undermines the entire intent and we must find a way to close it. > > Thanks? > > J. > > > From: Theo Geurts > Date: Thursday, December 11, 2014 at 6:47 > To: Mike O'Connor > Cc: Caitlin Tubergen , Barbara Knight , Leticia Castillo , James Bladel , Marika Konings , Gisella Gruber , Arthur Zonnenberg , Phil Corwin , Lars Hoffmann , "gnso-impl-irtpc-rt at icann.org" , Steve Chan , Terri Agnew , "Sedo :: Simonetta Batteiger" , Nathalie Peregrine , Rob Golding , Michele Neylon - Blacknight , Mike Zupke , Bob Mountain > Subject: Re: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 > > Thanks Mike, > > Being the one that raised this issue a few times, i decided to write a lil FAQ for our resellers, incase 3.2 would apply. I give up after an hour or so, i could not come up with a scenario where 3.4 did NOT apply. So for me to carry out this PDP in it's current language as a registrar, is pretty easy, as i would have to do nothing at all. I can't speak for other registrars but i would assume more of us would be in the same boat. > > So yes, this needs to be addressed one way or another. > > Talk to you folks on the call. > > Best regards, > > Theo Geurts > Compliance Officer > > Realtime Register B.V. > > Ceintuurbaan 32A > 8024 AA - ZWOLLE - The Netherlands > > T: +31.384530759 > F: +31.384524734 > U: www.realtimeregister.com > E: support at realtimeregister.com > > > > > > Van: "Mike O'Connor" > Aan: "Caitlin Tubergen" > Cc: "Theo Geurts" , "Barbara Knight" , "Leticia Castillo" , "James Bladel" , "Marika Konings" , "Gisella Gruber" , "Arthur Zonnenberg" , "Phil Corwin" , "Lars Hoffmann" , gnso-impl-irtpc-rt at icann.org, "Steve Chan" , "Terri Agnew" , "Sedo :: Simonetta Batteiger" , "Nathalie Peregrine" , "Rob Golding" , "Michele Neylon - Blacknight" , "Mike Zupke" , "Bob Mountain" > Verzonden: Donderdag 11 december 2014 14:16:14 > Onderwerp: Re: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 > > dear all, > > sorry to respond to this note within hours of the meeting. > > but i wanted to let you know that i?ll be strenuously opposing Section 3.4 as it represents a change in the intent and policy of IRTP-C. at a minimum, if the IRT insists on the addition of this language, i will raise the ?change of policy which needs to go through Policy/Implementation review? flag. i haven?t been following the Policy/Implementation WG so i don?t know where they are at, but this will make a nifty test case for them because this is a really good example of core policy being changed during implementation. > > mike > > > On Dec 2, 2014, at 3:52 PM, Caitlin Tubergen wrote: > > > Hi All, > > > > Please save the date for the final IRTP-C IRT call before the draft Change of Registrant Policy goes out for public comment. > > > > The draft policy is attached; a briefing document, describing two outstanding issues, is also attached. If you would like to distribute the documents to your colleagues, or other interested parties, please do so before the the call on Thursday, 11 December 2014. Comments on the policy or the briefing document should be delivered to me prior to the call on Thursday, 11 December. > > > > Details for 11 December Call > > The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 11 December 2014 at 17:00 UTC. > > 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. > > > > Link to Adobe Connect (with audio enabled): https://icann.adobeconnect.com/irtppartc/ > > *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). > > After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. > > If you are Unable to log into Adobe Connect and can only join via phone: > > List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num=1-719-457-6209 > > Participant Passcode: 6458688446 > > > > Please let me know if you have any questions. > > > > Kind regards, > > > > Caitlin > > > > > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.golding at astutium.com Thu Dec 11 17:07:10 2014 From: rob.golding at astutium.com (Rob Golding) Date: Thu, 11 Dec 2014 17:07:10 -0000 Subject: [gnso-impl-irtpc-rt] Save the Date: IRTP-C Implementation Review Team Call 11 Dec 2014 In-Reply-To: <1D4C2179-78F8-451F-8C66-C3D1186F5557@haven2.com> References: <3717B054-6FC7-4F34-B83E-3B4714051762@haven2.com> <1655190648.1481619.1418305632218.JavaMail.zimbra@firstfind.nl> <1D4C2179-78F8-451F-8C66-C3D1186F5557@haven2.com> Message-ID: <5c2101d01564$e6f5b680$b4e12380$@astutium.com> > i've been staring at 3.4 for a while. I'm getting confused about it now as well, and may not make the call (am hoping to adobe connect through) Rob From caitlin.tubergen at icann.org Fri Dec 12 01:00:11 2014 From: caitlin.tubergen at icann.org (Caitlin Tubergen) Date: Fri, 12 Dec 2014 01:00:11 +0000 Subject: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) Message-ID: Hi, All, Thank you to everyone who attended the call; it was a very robust discussion. For those who were unable to attend, I have attached instructions on how to listen to the recording. At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. A couple of suggestions mentioned on the call include: 1. FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn?t contact the registrar within a certain number of days, the email change would go through.) 2. Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a ?push? between accounts Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. Kind regards, Caitlin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Subject: Replay confirmation: 899424856 Date: Thu, 11 Dec 2014 12:03:45 -0600 Size: 35335 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5050 bytes Desc: not available URL: From caitlin.tubergen at icann.org Fri Dec 12 01:22:15 2014 From: caitlin.tubergen at icann.org (Caitlin Tubergen) Date: Fri, 12 Dec 2014 01:22:15 +0000 Subject: [gnso-impl-irtpc-rt] Re: Outstanding Issue from today's IRT Call (email/account holder) In-Reply-To: References: Message-ID: Please find the draft COR policy attached and accept my apologies for a double email. Kind regards, Caitlin From: Caitlin Tubergen Date: Thursday, December 11, 2014 at 5:00 PM To: "gnso-impl-irtpc-rt at icann.org" Subject: Outstanding Issue from today's IRT Call (email/account holder) Hi, All, Thank you to everyone who attended the call; it was a very robust discussion. For those who were unable to attend, I have attached instructions on how to listen to the recording. At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. A couple of suggestions mentioned on the call include: 1. FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn?t contact the registrar within a certain number of days, the email change would go through.) 2. Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a ?push? between accounts Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. Kind regards, Caitlin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft Change of Registrant Policy_11Dec.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 162588 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5050 bytes Desc: not available URL: From mike at haven2.com Fri Dec 12 15:26:03 2014 From: mike at haven2.com (Mike O'Connor) Date: Fri, 12 Dec 2014 09:26:03 -0600 Subject: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) In-Reply-To: References: Message-ID: <2CE53F05-C1CB-408F-AA05-ABB1FBAC2D5A@haven2.com> hi all, here?s a first-try at the revision: 3.4 The 60-day transfer lock will be required if an Account Holder updates their email address, thus effectively causing a Change of Registrant and simultaneously rendering impossible the exchange of the Change of Registrant Credential as described in section 3.2. If the Account Holder wishes to opt out of the lock, they can validate the change of address through other verifiable means. On Dec 11, 2014, at 7:22 PM, Caitlin Tubergen wrote: > Please find the draft COR policy attached and accept my apologies for a double email. > > Kind regards, > > Caitlin > > From: Caitlin Tubergen > Date: Thursday, December 11, 2014 at 5:00 PM > To: "gnso-impl-irtpc-rt at icann.org" > Subject: Outstanding Issue from today's IRT Call (email/account holder) > > Hi, All, > > Thank you to everyone who attended the call; it was a very robust discussion. > > For those who were unable to attend, I have attached instructions on how to listen to the recording. > > At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. > > Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. > > ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. > > A couple of suggestions mentioned on the call include: > ? FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn?t contact the registrar within a certain number of days, the email change would go through.) > ? Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a ?push? between accounts > Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. > > Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. > > Kind regards, > > Caitlin > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3630 bytes Desc: not available URL: From mike at haven2.com Fri Dec 12 15:33:02 2014 From: mike at haven2.com (Mike O'Connor) Date: Fri, 12 Dec 2014 09:33:02 -0600 Subject: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) In-Reply-To: <2CE53F05-C1CB-408F-AA05-ABB1FBAC2D5A@haven2.com> References: <2CE53F05-C1CB-408F-AA05-ABB1FBAC2D5A@haven2.com> Message-ID: <403F67B3-2863-4441-973F-F75478A95891@haven2.com> oops - i forgot to attach the revised draft too. On Dec 12, 2014, at 9:26 AM, Mike O'Connor wrote: > hi all, > > here?s a first-try at the revision: > > 3.4 The 60-day transfer lock will be required if an Account Holder updates their email address, thus effectively causing a Change of Registrant and simultaneously rendering impossible the exchange of the Change of Registrant Credential as described in section 3.2. If the Account Holder wishes to opt out of the lock, they can validate the change of address through other verifiable means. > > On Dec 11, 2014, at 7:22 PM, Caitlin Tubergen wrote: > >> Please find the draft COR policy attached and accept my apologies for a double email. >> >> Kind regards, >> >> Caitlin >> >> From: Caitlin Tubergen >> Date: Thursday, December 11, 2014 at 5:00 PM >> To: "gnso-impl-irtpc-rt at icann.org" >> Subject: Outstanding Issue from today's IRT Call (email/account holder) >> >> Hi, All, >> >> Thank you to everyone who attended the call; it was a very robust discussion. >> >> For those who were unable to attend, I have attached instructions on how to listen to the recording. >> >> At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. >> >> Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. >> >> ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. >> >> A couple of suggestions mentioned on the call include: >> ? FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn?t contact the registrar within a certain number of days, the email change would go through.) >> ? Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a ?push? between accounts >> Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. >> >> Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. >> >> Kind regards, >> >> Caitlin >> > > > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft Change of Registrant Policy_11Dec-MO1.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 115021 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3630 bytes Desc: not available URL: From mike at haven2.com Sat Dec 20 13:41:35 2014 From: mike at haven2.com (Mike O'Connor) Date: Sat, 20 Dec 2014 07:41:35 -0600 Subject: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) In-Reply-To: <403F67B3-2863-4441-973F-F75478A95891@haven2.com> References: <2CE53F05-C1CB-408F-AA05-ABB1FBAC2D5A@haven2.com> <403F67B3-2863-4441-973F-F75478A95891@haven2.com> Message-ID: <7B7538E2-F2E5-4C1D-A0EC-9FFC6C309D00@haven2.com> i finally circled back to this and realized that i wrote language that is almost as flawed as the original. basically, this is a use case and i?m not sure actual policy language is required ? since we didn?t specify how the exchange of credentials was accomplished. since this customer is doing both sides of the transaction within the same registrar, it seems to me that the ?independently verifiable? angle kicks in. here is what i propose 3.4 In the case where an Account Holder wishes to update an email address they can no longer access and thus cause a Change of Registrant, the exchange of the Change of Registrant Credential as described in section 3.2 must be transacted and validated through other verifiable means. change of registrant does NOT include change of registrar (that?s the whole underlying point of splitting these processes apart) ? so their registrar can develop whatever processes that are needed to facilitate the exchange of credentials. clearly email as the medium of exchange won?t work in this use case, something else will be needed instead. but registrars already have processes that they use to verify people?s identity when email isn?t available (Simonetta rattled a few off on the call but i?ve forgotten what they were). isn?t that all that?s required? On Dec 12, 2014, at 9:33 AM, Mike O'Connor wrote: > oops - i forgot to attach the revised draft too. > > > > On Dec 12, 2014, at 9:26 AM, Mike O'Connor wrote: > >> hi all, >> >> here?s a first-try at the revision: >> >> 3.4 The 60-day transfer lock will be required if an Account Holder updates their email address, thus effectively causing a Change of Registrant and simultaneously rendering impossible the exchange of the Change of Registrant Credential as described in section 3.2. If the Account Holder wishes to opt out of the lock, they can validate the change of address through other verifiable means. >> >> On Dec 11, 2014, at 7:22 PM, Caitlin Tubergen wrote: >> >>> Please find the draft COR policy attached and accept my apologies for a double email. >>> >>> Kind regards, >>> >>> Caitlin >>> >>> From: Caitlin Tubergen >>> Date: Thursday, December 11, 2014 at 5:00 PM >>> To: "gnso-impl-irtpc-rt at icann.org" >>> Subject: Outstanding Issue from today's IRT Call (email/account holder) >>> >>> Hi, All, >>> >>> Thank you to everyone who attended the call; it was a very robust discussion. >>> >>> For those who were unable to attend, I have attached instructions on how to listen to the recording. >>> >>> At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. >>> >>> Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. >>> >>> ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. >>> >>> A couple of suggestions mentioned on the call include: >>> ? FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn?t contact the registrar within a certain number of days, the email change would go through.) >>> ? Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a ?push? between accounts >>> Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. >>> >>> Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. >>> >>> Kind regards, >>> >>> Caitlin >>> >> >> >> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) >> > > > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3630 bytes Desc: not available URL: From mike at haven2.com Sat Dec 20 13:54:44 2014 From: mike at haven2.com (Mike O'Connor) Date: Sat, 20 Dec 2014 07:54:44 -0600 Subject: Fwd: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) References: <7B7538E2-F2E5-4C1D-A0EC-9FFC6C309D00@haven2.com> Message-ID: i?m having a sinking feeling that i?m not subscribed to the list, so this is just a repeat of the note i sent a minute ago. pls ignore? m Begin forwarded message: > From: Mike O'Connor > Subject: Re: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) > Date: December 20, 2014 at 7:41:35 AM CST > To: Mike O'Connor > Cc: "gnso-impl-irtpc-rt at icann.org" , Caitlin Tubergen > > i finally circled back to this and realized that i wrote language that is almost as flawed as the original. > > basically, this is a use case and i?m not sure actual policy language is required ? since we didn?t specify how the exchange of credentials was accomplished. since this customer is doing both sides of the transaction within the same registrar, it seems to me that the ?independently verifiable? angle kicks in. here is what i propose > > 3.4 In the case where an Account Holder wishes to update an email address they can no longer access and thus cause a Change of Registrant, the exchange of the Change of Registrant Credential as described in section 3.2 must be transacted and validated through other verifiable means. > > change of registrant does NOT include change of registrar (that?s the whole underlying point of splitting these processes apart) ? so their registrar can develop whatever processes that are needed to facilitate the exchange of credentials. clearly email as the medium of exchange won?t work in this use case, something else will be needed instead. but registrars already have processes that they use to verify people?s identity when email isn?t available (Simonetta rattled a few off on the call but i?ve forgotten what they were). isn?t that all that?s required? > > On Dec 12, 2014, at 9:33 AM, Mike O'Connor wrote: > >> oops - i forgot to attach the revised draft too. >> >> >> >> On Dec 12, 2014, at 9:26 AM, Mike O'Connor wrote: >> >>> hi all, >>> >>> here?s a first-try at the revision: >>> >>> 3.4 The 60-day transfer lock will be required if an Account Holder updates their email address, thus effectively causing a Change of Registrant and simultaneously rendering impossible the exchange of the Change of Registrant Credential as described in section 3.2. If the Account Holder wishes to opt out of the lock, they can validate the change of address through other verifiable means. >>> >>> On Dec 11, 2014, at 7:22 PM, Caitlin Tubergen wrote: >>> >>>> Please find the draft COR policy attached and accept my apologies for a double email. >>>> >>>> Kind regards, >>>> >>>> Caitlin >>>> >>>> From: Caitlin Tubergen >>>> Date: Thursday, December 11, 2014 at 5:00 PM >>>> To: "gnso-impl-irtpc-rt at icann.org" >>>> Subject: Outstanding Issue from today's IRT Call (email/account holder) >>>> >>>> Hi, All, >>>> >>>> Thank you to everyone who attended the call; it was a very robust discussion. >>>> >>>> For those who were unable to attend, I have attached instructions on how to listen to the recording. >>>> >>>> At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. >>>> >>>> Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. >>>> >>>> ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. >>>> >>>> A couple of suggestions mentioned on the call include: >>>> ? FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn?t contact the registrar within a certain number of days, the email change would go through.) >>>> ? Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a ?push? between accounts >>>> Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. >>>> >>>> Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. >>>> >>>> Kind regards, >>>> >>>> Caitlin >>>> >>> >>> >>> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) >>> >> >> >> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) >> > > > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.com Sat Dec 20 14:43:21 2014 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Sat, 20 Dec 2014 14:43:21 +0000 Subject: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) In-Reply-To: References: <7B7538E2-F2E5-4C1D-A0EC-9FFC6C309D00@haven2.com> Message-ID: Both emails came through .. -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press/ http://www.technology.ie/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: owner-gnso-impl-irtpc-rt at icann.org [mailto:owner-gnso-impl-irtpc-rt at icann.org] On Behalf Of Mike O'Connor Sent: Saturday, December 20, 2014 8:55 AM To: gnso-impl-irtpc-rt at icann.org Subject: Fwd: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) i'm having a sinking feeling that i'm not subscribed to the list, so this is just a repeat of the note i sent a minute ago. pls ignore... m Begin forwarded message: From: Mike O'Connor > Subject: Re: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder) Date: December 20, 2014 at 7:41:35 AM CST To: Mike O'Connor > Cc: "gnso-impl-irtpc-rt at icann.org" >, Caitlin Tubergen > i finally circled back to this and realized that i wrote language that is almost as flawed as the original. basically, this is a use case and i'm not sure actual policy language is required - since we didn't specify how the exchange of credentials was accomplished. since this customer is doing both sides of the transaction within the same registrar, it seems to me that the "independently verifiable" angle kicks in. here is what i propose 3.4 In the case where an Account Holder wishes to update an email address they can no longer access and thus cause a Change of Registrant, the exchange of the Change of Registrant Credential as described in section 3.2 must be transacted and validated through other verifiable means. change of registrant does NOT include change of registrar (that's the whole underlying point of splitting these processes apart) - so their registrar can develop whatever processes that are needed to facilitate the exchange of credentials. clearly email as the medium of exchange won't work in this use case, something else will be needed instead. but registrars already have processes that they use to verify people's identity when email isn't available (Simonetta rattled a few off on the call but i've forgotten what they were). isn't that all that's required? On Dec 12, 2014, at 9:33 AM, Mike O'Connor > wrote: oops - i forgot to attach the revised draft too. On Dec 12, 2014, at 9:26 AM, Mike O'Connor > wrote: hi all, here's a first-try at the revision: 3.4 The 60-day transfer lock will be required if an Account Holder updates their email address, thus effectively causing a Change of Registrant and simultaneously rendering impossible the exchange of the Change of Registrant Credential as described in section 3.2. If the Account Holder wishes to opt out of the lock, they can validate the change of address through other verifiable means. On Dec 11, 2014, at 7:22 PM, Caitlin Tubergen > wrote: Please find the draft COR policy attached and accept my apologies for a double email. Kind regards, Caitlin From: Caitlin Tubergen > Date: Thursday, December 11, 2014 at 5:00 PM To: "gnso-impl-irtpc-rt at icann.org" > Subject: Outstanding Issue from today's IRT Call (email/account holder) Hi, All, Thank you to everyone who attended the call; it was a very robust discussion. For those who were unable to attend, I have attached instructions on how to listen to the recording. At the start of the call, I presented a scenario whereby a Prior Registrant would be unable to ACK/affirm a Change of Registrant request (COR) request because their email account no longer exists. (Perhaps they left their company, university, etc.) Similarly, if someone were to move and suddenly have a new address, telephone, email address, ISP provider, it would be impossible to ACK a COR via email, postal mail, phone, etc. While this is narrow use case, ICANN staff and the IRT are trying to ensure that we are not creating an unworkable scenario where a Prior Registrant cannot update his or her email address. Section 3.4 of the draft COR Policy would allow a registrant to log into their account and update their information via their verified account. This gets around the non-existent email address issue, but some have expressed concerns about the risk of hijacking since resellers, hosting providers, et. al., may be an account holder. ICANN staff is currently seeking solutions to the problem mentioned above. Specifically, we are looking for alternative authentication methods besides the exchange of pin. A couple of suggestions mentioned on the call include: * FOAs for change of registrant. (The Prior Registrant would receive an informative FOA at its email address (listed in Whois) and if it doesn't contact the registrar within a certain number of days, the email change would go through.) * Alternative authentication depending on the type of registrant change, i.e., a different authentication method could be used if the name is staying in the same account rather than a "push" between accounts Please feel free to elaborate on the above or provide new suggestions entirely. We discussed the difficulty with the resolution of this particular problem and how this may need to back to the GNSO for more guidance if it cannot be resolved within the IRT, particularly since the IRT is not a representative body of the ICANN community. Please provide any suggestions to me by COB Thursday, 18 December. Thank you in advance for your feedback. Kind regards, Caitlin PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From caitlin.tubergen at icann.org Mon Dec 22 21:48:16 2014 From: caitlin.tubergen at icann.org (Caitlin Tubergen) Date: Mon, 22 Dec 2014 21:48:16 +0000 Subject: [gnso-impl-irtpc-rt] Save the Date - Next IRTP-C IRT Call Thurs 8 Jan 2015 at 1700 UTC Message-ID: Hi All, Thank to those who responded to the request for alternatives to exchanging pins via email. During our next call, I would like to take some time to discuss the alternatives that IRT members suggested to get around the problem presented during our last call. I plan to go through all of the suggestions in a short presentation and then let the IRT discuss how it proposes to move forward. If you have any other suggestions in the meantime, please feel free to email me. Details for our next call appear below: Details for 8 January 2015 Call The next Inter-Registrar Transfer Policy (IRTP) Part C Implementation Review Team teleconference is scheduled for Thursday 8 January 2014 at 17:00 UTC. 09:00 PST, 12:00 EST, 17:00 London, 17:00 CET, 03:00 (+1 day) Sydney. Link to Adobe Connect (with audio enabled):https://icann.adobeconnect.com/irtppartc/ *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. If you are Unable to log into Adobe Connect and can only join via phone: List of International Dial In Numbers:https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6458688446&num =1-719-457-6209 Participant Passcode: 6458688446 I hope everyone has a wonderful holiday season. Kind regards, and happy holidays, Caitlin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5050 bytes Desc: not available URL: