From rafik.dammak at gmail.com Mon Dec 3 14:46:23 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Mon, 3 Dec 2018 21:46:23 +0900 Subject: [NCSG-PC] [update] public comment reviews (submission by 27th Nov) In-Reply-To: References: Message-ID: Hi all, the deadline for submitting SSAC comment is today: https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit please weigh in and review. the comment is short and reiterating one position that was not taken into consideration about term limit. with regard to the length of comment, you can find the response of the penholder below. Best, Rafik Le mer. 28 nov. 2018 ? 08:19, Rafik Dammak a ?crit : > Hi all, > > thanks for the comments. > the current situation: > CCT and Auctions proceed public comments were extended. however I will > submit the CCT comment anyway as it is ready (and there was no objection) > and I will finalize the auctions proceeds within 24-48hours, we need to > move on and close this. There are several suggestions on the pending areas > and will put suggested language there based on the input to date. > > we also have SSAC comment to be submitted by 3rd December and waiting for > NCSG PC review: > https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit > . I already checked with Tomslin about the report and got his response : > "In my assessment of the draft report, the recommendations had a direct > correlation to the report items. I also noticed they clarified our concern > on methodology. Additional recommendations either addressed our concerns on > transparency and accountability or tried to improve how SSAC identified > skills for recruitment. So, I didn't find them contentious." > > we don't have anything else in the pipeline yet for other public comments. > I will share asap I got drafts to be reviewed. There are drafting teams for > new gTLD subsequent procedures supplemental report, for EPDP initial report > (that is with NCSG rep to EPDP team) and volunteers for redcross comment. > > Best, > > Rafik > > Le mar. 27 nov. 2018 ? 18:47, Tatiana Tropina > a ?crit : > >> All, >> sorry for being late. Work, swamped. Agree that CCT draft can be >> submitted. For the AP draft, we really have some issues of disagreement, I >> added my opinion where possible. I think most of the time what Rafik >> suggests is the middle ground. >> Cheers, >> Tanya >> >> On Tue, 27 Nov 2018 at 10:33, Rafik Dammak >> wrote: >> >>> Hi all, >>> >>> the current situation: >>> - CCT draft is in good shape and all comments resolved. it is ready for >>> submission unless there is strong objection. >>> - Auctions proceeds draft still has some outstanding issues to be >>> resolved. >>> still waiting for more input and review. >>> >>> Best, >>> >>> Rafik >>> >>> Le lun. 26 nov. 2018 ? 23:09, Rafik Dammak a >>> ?crit : >>> >>>> Hi all, >>>> >>>> another reminder about reviewing and finalizing the comments. >>>> I will follow-up tomorrow my time to respond to comments and edits. >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> Le dim. 25 nov. 2018 ? 09:18, Rafik Dammak a >>>> ?crit : >>>> >>>>> Hi all, >>>>> >>>>> this is a reminder for reviewing the comments. >>>>> I cleaned-up the documents accepting most of the edits. I also added >>>>> some comments/questions there for clarification. >>>>> I agree they are in good shape. so please review asap. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> Le jeu. 22 nov. 2018 ? 08:02, Rafik Dammak a >>>>> ?crit : >>>>> >>>>>> hi all, >>>>>> >>>>>> we have 2 draft comments to review for submission on 27th November: >>>>>> >>>>>> - The initial report on Auctions Proceeds: >>>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit >>>>>> - CCT RT final report: >>>>>> https://docs.google.com/document/d/1iRMb8X9mN-8cInJuVyHargHIPM9E1Ibq5LRsYcKUuJg/edit >>>>>> >>>>>> please review, add your comments and edits. >>>>>> >>>>>> Best, >>>>>> >>>>>> Rafik >>>>>> >>>>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From farell at benin2point0.org Mon Dec 3 15:23:59 2018 From: farell at benin2point0.org (Farell FOLLY) Date: Mon, 3 Dec 2018 14:23:59 +0100 Subject: [NCSG-PC] [update] public comment reviews (submission by 27th Nov) In-Reply-To: References: Message-ID: <51944C85-467E-4494-9DD8-FA3FD39614AC@benin2point0.org> I reviewed it and had no concern. Thanks. @__f_f__ Best Regards ____________________________________ (Ekue) Farell FOLLY NCUC Rep. to the NCSG Policy Committee linkedin.com/in/farellf > On 3 Dec 2018, at 13:46, Rafik Dammak wrote: > > Hi all, > > the deadline for submitting SSAC comment is today: https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit > please weigh in and review. the comment is short and reiterating one position that was not taken into consideration about term limit. with regard to the length of comment, you can find the response of the penholder below. > > Best, > > Rafik > > Le mer. 28 nov. 2018 ? 08:19, Rafik Dammak > a ?crit : > Hi all, > > thanks for the comments. > the current situation: > CCT and Auctions proceed public comments were extended. however I will submit the CCT comment anyway as it is ready (and there was no objection) and I will finalize the auctions proceeds within 24-48hours, we need to move on and close this. There are several suggestions on the pending areas and will put suggested language there based on the input to date. > > we also have SSAC comment to be submitted by 3rd December and waiting for NCSG PC review: https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit . I already checked with Tomslin about the report and got his response : > "In my assessment of the draft report, the recommendations had a direct correlation to the report items. I also noticed they clarified our concern on methodology. Additional recommendations either addressed our concerns on transparency and accountability or tried to improve how SSAC identified skills for recruitment. So, I didn't find them contentious." > > we don't have anything else in the pipeline yet for other public comments. I will share asap I got drafts to be reviewed. There are drafting teams for new gTLD subsequent procedures supplemental report, for EPDP initial report (that is with NCSG rep to EPDP team) and volunteers for redcross comment. > > Best, > > Rafik > > Le mar. 27 nov. 2018 ? 18:47, Tatiana Tropina > a ?crit : > All, > sorry for being late. Work, swamped. Agree that CCT draft can be submitted. For the AP draft, we really have some issues of disagreement, I added my opinion where possible. I think most of the time what Rafik suggests is the middle ground. > Cheers, > Tanya > > On Tue, 27 Nov 2018 at 10:33, Rafik Dammak > wrote: > Hi all, > > the current situation: > - CCT draft is in good shape and all comments resolved. it is ready for submission unless there is strong objection. > - Auctions proceeds draft still has some outstanding issues to be resolved. > still waiting for more input and review. > > Best, > > Rafik > > Le lun. 26 nov. 2018 ? 23:09, Rafik Dammak > a ?crit : > Hi all, > > another reminder about reviewing and finalizing the comments. > I will follow-up tomorrow my time to respond to comments and edits. > > Best, > > Rafik > > Le dim. 25 nov. 2018 ? 09:18, Rafik Dammak > a ?crit : > Hi all, > > this is a reminder for reviewing the comments. > I cleaned-up the documents accepting most of the edits. I also added some comments/questions there for clarification. > I agree they are in good shape. so please review asap. > > Best, > > Rafik > Le jeu. 22 nov. 2018 ? 08:02, Rafik Dammak > a ?crit : > hi all, > > we have 2 draft comments to review for submission on 27th November: > > - The initial report on Auctions Proceeds: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit > - CCT RT final report: https://docs.google.com/document/d/1iRMb8X9mN-8cInJuVyHargHIPM9E1Ibq5LRsYcKUuJg/edit > > please review, add your comments and edits. > > Best, > > Rafik > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsilvavalent at gmail.com Mon Dec 3 16:27:59 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Mon, 3 Dec 2018 11:27:59 -0300 Subject: [NCSG-PC] [update] public comment reviews (submission by 27th Nov) In-Reply-To: <51944C85-467E-4494-9DD8-FA3FD39614AC@benin2point0.org> References: <51944C85-467E-4494-9DD8-FA3FD39614AC@benin2point0.org> Message-ID: <2C7A072B-E4F5-4BC5-8F13-D21EDEFDCEB1@gmail.com> Same here, I think I express it also in another email chain for this comment. Best, Mart?n > On 3 Dec 2018, at 10:23, Farell FOLLY wrote: > > I reviewed it and had no concern. > > Thanks. > > > @__f_f__ > > Best Regards > ____________________________________ > > (Ekue) Farell FOLLY > NCUC Rep. to the NCSG Policy Committee > linkedin.com/in/farellf > > > > > > >> On 3 Dec 2018, at 13:46, Rafik Dammak > wrote: >> >> Hi all, >> >> the deadline for submitting SSAC comment is today: https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit >> please weigh in and review. the comment is short and reiterating one position that was not taken into consideration about term limit. with regard to the length of comment, you can find the response of the penholder below. >> >> Best, >> >> Rafik >> >> Le mer. 28 nov. 2018 ? 08:19, Rafik Dammak > a ?crit : >> Hi all, >> >> thanks for the comments. >> the current situation: >> CCT and Auctions proceed public comments were extended. however I will submit the CCT comment anyway as it is ready (and there was no objection) and I will finalize the auctions proceeds within 24-48hours, we need to move on and close this. There are several suggestions on the pending areas and will put suggested language there based on the input to date. >> >> we also have SSAC comment to be submitted by 3rd December and waiting for NCSG PC review: https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit . I already checked with Tomslin about the report and got his response : >> "In my assessment of the draft report, the recommendations had a direct correlation to the report items. I also noticed they clarified our concern on methodology. Additional recommendations either addressed our concerns on transparency and accountability or tried to improve how SSAC identified skills for recruitment. So, I didn't find them contentious." >> >> we don't have anything else in the pipeline yet for other public comments. I will share asap I got drafts to be reviewed. There are drafting teams for new gTLD subsequent procedures supplemental report, for EPDP initial report (that is with NCSG rep to EPDP team) and volunteers for redcross comment. >> >> Best, >> >> Rafik >> >> Le mar. 27 nov. 2018 ? 18:47, Tatiana Tropina > a ?crit : >> All, >> sorry for being late. Work, swamped. Agree that CCT draft can be submitted. For the AP draft, we really have some issues of disagreement, I added my opinion where possible. I think most of the time what Rafik suggests is the middle ground. >> Cheers, >> Tanya >> >> On Tue, 27 Nov 2018 at 10:33, Rafik Dammak > wrote: >> Hi all, >> >> the current situation: >> - CCT draft is in good shape and all comments resolved. it is ready for submission unless there is strong objection. >> - Auctions proceeds draft still has some outstanding issues to be resolved. >> still waiting for more input and review. >> >> Best, >> >> Rafik >> >> Le lun. 26 nov. 2018 ? 23:09, Rafik Dammak > a ?crit : >> Hi all, >> >> another reminder about reviewing and finalizing the comments. >> I will follow-up tomorrow my time to respond to comments and edits. >> >> Best, >> >> Rafik >> >> Le dim. 25 nov. 2018 ? 09:18, Rafik Dammak > a ?crit : >> Hi all, >> >> this is a reminder for reviewing the comments. >> I cleaned-up the documents accepting most of the edits. I also added some comments/questions there for clarification. >> I agree they are in good shape. so please review asap. >> >> Best, >> >> Rafik >> Le jeu. 22 nov. 2018 ? 08:02, Rafik Dammak > a ?crit : >> hi all, >> >> we have 2 draft comments to review for submission on 27th November: >> >> - The initial report on Auctions Proceeds: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit >> - CCT RT final report: https://docs.google.com/document/d/1iRMb8X9mN-8cInJuVyHargHIPM9E1Ibq5LRsYcKUuJg/edit >> >> please review, add your comments and edits. >> >> Best, >> >> Rafik >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From tatiana.tropina at gmail.com Mon Dec 3 16:31:53 2018 From: tatiana.tropina at gmail.com (Tatiana Tropina) Date: Mon, 3 Dec 2018 14:31:53 +0000 Subject: [NCSG-PC] [update] public comment reviews (submission by 27th Nov) In-Reply-To: <2C7A072B-E4F5-4BC5-8F13-D21EDEFDCEB1@gmail.com> References: <51944C85-467E-4494-9DD8-FA3FD39614AC@benin2point0.org> <2C7A072B-E4F5-4BC5-8F13-D21EDEFDCEB1@gmail.com> Message-ID: I am fine with the comment Cheers Tanya On Mon 3. Dec 2018 at 14:28, Martin Pablo Silva Valent < mpsilvavalent at gmail.com> wrote: > Same here, I think I express it also in another email chain for this > comment. > > Best, > Mart?n > > > On 3 Dec 2018, at 10:23, Farell FOLLY wrote: > > I reviewed it and had no concern. > > Thanks. > > > @__f_f__ > > Best Regards > ____________________________________ > > (Ekue) Farell FOLLY > NCUC Rep. to the NCSG Policy Committee > linkedin.com/in/farellf > > > > > > > On 3 Dec 2018, at 13:46, Rafik Dammak wrote: > > Hi all, > > the deadline for submitting SSAC comment is today: > https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit > please weigh in and review. the comment is short and reiterating one > position that was not taken into consideration about term limit. with > regard to the length of comment, you can find the response of the penholder > below. > > Best, > > Rafik > > Le mer. 28 nov. 2018 ? 08:19, Rafik Dammak a > ?crit : > >> Hi all, >> >> thanks for the comments. >> the current situation: >> CCT and Auctions proceed public comments were extended. however I will >> submit the CCT comment anyway as it is ready (and there was no objection) >> and I will finalize the auctions proceeds within 24-48hours, we need to >> move on and close this. There are several suggestions on the pending areas >> and will put suggested language there based on the input to date. >> >> we also have SSAC comment to be submitted by 3rd December and waiting for >> NCSG PC review: >> https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit >> . I already checked with Tomslin about the report and got his response : >> "In my assessment of the draft report, the recommendations had a direct >> correlation to the report items. I also noticed they clarified our concern >> on methodology. Additional recommendations either addressed our concerns on >> transparency and accountability or tried to improve how SSAC identified >> skills for recruitment. So, I didn't find them contentious." >> >> we don't have anything else in the pipeline yet for other public >> comments. I will share asap I got drafts to be reviewed. There are drafting >> teams for new gTLD subsequent procedures supplemental report, for EPDP >> initial report (that is with NCSG rep to EPDP team) and volunteers for >> redcross comment. >> >> Best, >> >> Rafik >> >> Le mar. 27 nov. 2018 ? 18:47, Tatiana Tropina >> a ?crit : >> >>> All, >>> sorry for being late. Work, swamped. Agree that CCT draft can be >>> submitted. For the AP draft, we really have some issues of disagreement, I >>> added my opinion where possible. I think most of the time what Rafik >>> suggests is the middle ground. >>> Cheers, >>> Tanya >>> >>> On Tue, 27 Nov 2018 at 10:33, Rafik Dammak >>> wrote: >>> >>>> Hi all, >>>> >>>> the current situation: >>>> - CCT draft is in good shape and all comments resolved. it is ready for >>>> submission unless there is strong objection. >>>> - Auctions proceeds draft still has some outstanding issues to be >>>> resolved. >>>> still waiting for more input and review. >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> Le lun. 26 nov. 2018 ? 23:09, Rafik Dammak a >>>> ?crit : >>>> >>>>> Hi all, >>>>> >>>>> another reminder about reviewing and finalizing the comments. >>>>> I will follow-up tomorrow my time to respond to comments and edits. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> >>>>> Le dim. 25 nov. 2018 ? 09:18, Rafik Dammak a >>>>> ?crit : >>>>> >>>>>> Hi all, >>>>>> >>>>>> this is a reminder for reviewing the comments. >>>>>> I cleaned-up the documents accepting most of the edits. I also added >>>>>> some comments/questions there for clarification. >>>>>> I agree they are in good shape. so please review asap. >>>>>> >>>>>> Best, >>>>>> >>>>>> Rafik >>>>>> Le jeu. 22 nov. 2018 ? 08:02, Rafik Dammak >>>>>> a ?crit : >>>>>> >>>>>>> hi all, >>>>>>> >>>>>>> we have 2 draft comments to review for submission on 27th November: >>>>>>> >>>>>>> - The initial report on Auctions Proceeds: >>>>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit >>>>>>> - CCT RT final report: >>>>>>> https://docs.google.com/document/d/1iRMb8X9mN-8cInJuVyHargHIPM9E1Ibq5LRsYcKUuJg/edit >>>>>>> >>>>>>> please review, add your comments and edits. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Rafik >>>>>>> >>>>>> _______________________________________________ >>>> NCSG-PC mailing list >>>> NCSG-PC at lists.ncsg.is >>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>> >>> _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arsenebaguma at gmail.com Mon Dec 3 17:59:32 2018 From: arsenebaguma at gmail.com (=?UTF-8?Q?Ars=C3=A8ne_Tungali?=) Date: Mon, 3 Dec 2018 17:59:32 +0200 Subject: [NCSG-PC] [update] public comment reviews (submission by 27th Nov) In-Reply-To: References: <51944C85-467E-4494-9DD8-FA3FD39614AC@benin2point0.org> <2C7A072B-E4F5-4BC5-8F13-D21EDEFDCEB1@gmail.com> Message-ID: I am okay with this draft. Thanks to the pen holders 2018-12-03 16:31 UTC+02:00, Tatiana Tropina : > I am fine with the comment > Cheers > Tanya > > On Mon 3. Dec 2018 at 14:28, Martin Pablo Silva Valent < > mpsilvavalent at gmail.com> wrote: > >> Same here, I think I express it also in another email chain for this >> comment. >> >> Best, >> Mart?n >> >> >> On 3 Dec 2018, at 10:23, Farell FOLLY wrote: >> >> I reviewed it and had no concern. >> >> Thanks. >> >> >> @__f_f__ >> >> Best Regards >> ____________________________________ >> >> (Ekue) Farell FOLLY >> NCUC Rep. to the NCSG Policy Committee >> linkedin.com/in/farellf >> >> >> >> >> >> >> On 3 Dec 2018, at 13:46, Rafik Dammak wrote: >> >> Hi all, >> >> the deadline for submitting SSAC comment is today: >> https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit >> please weigh in and review. the comment is short and reiterating one >> position that was not taken into consideration about term limit. with >> regard to the length of comment, you can find the response of the >> penholder >> below. >> >> Best, >> >> Rafik >> >> Le mer. 28 nov. 2018 ? 08:19, Rafik Dammak a >> ?crit : >> >>> Hi all, >>> >>> thanks for the comments. >>> the current situation: >>> CCT and Auctions proceed public comments were extended. however I will >>> submit the CCT comment anyway as it is ready (and there was no >>> objection) >>> and I will finalize the auctions proceeds within 24-48hours, we need to >>> move on and close this. There are several suggestions on the pending >>> areas >>> and will put suggested language there based on the input to date. >>> >>> we also have SSAC comment to be submitted by 3rd December and waiting >>> for >>> NCSG PC review: >>> https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit >>> . I already checked with Tomslin about the report and got his response : >>> "In my assessment of the draft report, the recommendations had a direct >>> correlation to the report items. I also noticed they clarified our >>> concern >>> on methodology. Additional recommendations either addressed our concerns >>> on >>> transparency and accountability or tried to improve how SSAC identified >>> skills for recruitment. So, I didn't find them contentious." >>> >>> we don't have anything else in the pipeline yet for other public >>> comments. I will share asap I got drafts to be reviewed. There are >>> drafting >>> teams for new gTLD subsequent procedures supplemental report, for EPDP >>> initial report (that is with NCSG rep to EPDP team) and volunteers for >>> redcross comment. >>> >>> Best, >>> >>> Rafik >>> >>> Le mar. 27 nov. 2018 ? 18:47, Tatiana Tropina >>> >>> a ?crit : >>> >>>> All, >>>> sorry for being late. Work, swamped. Agree that CCT draft can be >>>> submitted. For the AP draft, we really have some issues of disagreement, >>>> I >>>> added my opinion where possible. I think most of the time what Rafik >>>> suggests is the middle ground. >>>> Cheers, >>>> Tanya >>>> >>>> On Tue, 27 Nov 2018 at 10:33, Rafik Dammak >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> the current situation: >>>>> - CCT draft is in good shape and all comments resolved. it is ready >>>>> for >>>>> submission unless there is strong objection. >>>>> - Auctions proceeds draft still has some outstanding issues to be >>>>> resolved. >>>>> still waiting for more input and review. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> >>>>> Le lun. 26 nov. 2018 ? 23:09, Rafik Dammak a >>>>> ?crit : >>>>> >>>>>> Hi all, >>>>>> >>>>>> another reminder about reviewing and finalizing the comments. >>>>>> I will follow-up tomorrow my time to respond to comments and edits. >>>>>> >>>>>> Best, >>>>>> >>>>>> Rafik >>>>>> >>>>>> Le dim. 25 nov. 2018 ? 09:18, Rafik Dammak a >>>>>> ?crit : >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this is a reminder for reviewing the comments. >>>>>>> I cleaned-up the documents accepting most of the edits. I also >>>>>>> added >>>>>>> some comments/questions there for clarification. >>>>>>> I agree they are in good shape. so please review asap. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Rafik >>>>>>> Le jeu. 22 nov. 2018 ? 08:02, Rafik Dammak >>>>>>> a ?crit : >>>>>>> >>>>>>>> hi all, >>>>>>>> >>>>>>>> we have 2 draft comments to review for submission on 27th November: >>>>>>>> >>>>>>>> - The initial report on Auctions Proceeds: >>>>>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit >>>>>>>> - CCT RT final report: >>>>>>>> https://docs.google.com/document/d/1iRMb8X9mN-8cInJuVyHargHIPM9E1Ibq5LRsYcKUuJg/edit >>>>>>>> >>>>>>>> please review, add your comments and edits. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Rafik >>>>>>>> >>>>>>> _______________________________________________ >>>>> NCSG-PC mailing list >>>>> NCSG-PC at lists.ncsg.is >>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>>> >>>> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > -- ------------------------ **Ars?ne Tungali* * Co-Founder & Executive Director, *Rudi international *, CEO,* Smart Services Sarl *, Tel: +243 993810967 GPG: 523644A0 *Goma, Democratic Republic of Congo* 2015 Mandela Washington Felllow (YALI) - ISOC Ambassador (IGF Brazil & Mexico ) - AFRISIG 2016 - Blogger - ICANN's GNSO Council Member. AFRINIC Fellow ( Mauritius )* From rafik.dammak at gmail.com Tue Dec 4 02:51:35 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Tue, 4 Dec 2018 09:51:35 +0900 Subject: [NCSG-PC] [update] public comment reviews (submission by 27th Nov) In-Reply-To: References: Message-ID: thanks all, seeing no objection I submitted the comment. Best, Rafik Le lun. 3 d?c. 2018 ? 21:46, Rafik Dammak a ?crit : > Hi all, > > the deadline for submitting SSAC comment is today: > https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit > please weigh in and review. the comment is short and reiterating one > position that was not taken into consideration about term limit. with > regard to the length of comment, you can find the response of the penholder > below. > > Best, > > Rafik > > Le mer. 28 nov. 2018 ? 08:19, Rafik Dammak a > ?crit : > >> Hi all, >> >> thanks for the comments. >> the current situation: >> CCT and Auctions proceed public comments were extended. however I will >> submit the CCT comment anyway as it is ready (and there was no objection) >> and I will finalize the auctions proceeds within 24-48hours, we need to >> move on and close this. There are several suggestions on the pending areas >> and will put suggested language there based on the input to date. >> >> we also have SSAC comment to be submitted by 3rd December and waiting for >> NCSG PC review: >> https://docs.google.com/document/d/1fSi1SLEqk0QcWHmq-R1MBRWZJZ4MpsX2thXfI4sUjXA/edit >> . I already checked with Tomslin about the report and got his response : >> "In my assessment of the draft report, the recommendations had a direct >> correlation to the report items. I also noticed they clarified our concern >> on methodology. Additional recommendations either addressed our concerns on >> transparency and accountability or tried to improve how SSAC identified >> skills for recruitment. So, I didn't find them contentious." >> >> we don't have anything else in the pipeline yet for other public >> comments. I will share asap I got drafts to be reviewed. There are drafting >> teams for new gTLD subsequent procedures supplemental report, for EPDP >> initial report (that is with NCSG rep to EPDP team) and volunteers for >> redcross comment. >> >> Best, >> >> Rafik >> >> Le mar. 27 nov. 2018 ? 18:47, Tatiana Tropina >> a ?crit : >> >>> All, >>> sorry for being late. Work, swamped. Agree that CCT draft can be >>> submitted. For the AP draft, we really have some issues of disagreement, I >>> added my opinion where possible. I think most of the time what Rafik >>> suggests is the middle ground. >>> Cheers, >>> Tanya >>> >>> On Tue, 27 Nov 2018 at 10:33, Rafik Dammak >>> wrote: >>> >>>> Hi all, >>>> >>>> the current situation: >>>> - CCT draft is in good shape and all comments resolved. it is ready for >>>> submission unless there is strong objection. >>>> - Auctions proceeds draft still has some outstanding issues to be >>>> resolved. >>>> still waiting for more input and review. >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> Le lun. 26 nov. 2018 ? 23:09, Rafik Dammak a >>>> ?crit : >>>> >>>>> Hi all, >>>>> >>>>> another reminder about reviewing and finalizing the comments. >>>>> I will follow-up tomorrow my time to respond to comments and edits. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> >>>>> Le dim. 25 nov. 2018 ? 09:18, Rafik Dammak a >>>>> ?crit : >>>>> >>>>>> Hi all, >>>>>> >>>>>> this is a reminder for reviewing the comments. >>>>>> I cleaned-up the documents accepting most of the edits. I also added >>>>>> some comments/questions there for clarification. >>>>>> I agree they are in good shape. so please review asap. >>>>>> >>>>>> Best, >>>>>> >>>>>> Rafik >>>>>> Le jeu. 22 nov. 2018 ? 08:02, Rafik Dammak >>>>>> a ?crit : >>>>>> >>>>>>> hi all, >>>>>>> >>>>>>> we have 2 draft comments to review for submission on 27th November: >>>>>>> >>>>>>> - The initial report on Auctions Proceeds: >>>>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit >>>>>>> - CCT RT final report: >>>>>>> https://docs.google.com/document/d/1iRMb8X9mN-8cInJuVyHargHIPM9E1Ibq5LRsYcKUuJg/edit >>>>>>> >>>>>>> please review, add your comments and edits. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Rafik >>>>>>> >>>>>> _______________________________________________ >>>> NCSG-PC mailing list >>>> NCSG-PC at lists.ncsg.is >>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at ipjustice.org Thu Dec 6 02:33:34 2018 From: robin at ipjustice.org (Robin Gross) Date: Wed, 5 Dec 2018 16:33:34 -0800 Subject: [NCSG-PC] Fwd: [Gnso-newgtld-wg-wt5] Work Track 5 Supplemental Initial Report - Published for Public Comment References: Message-ID: <08DF24C6-7199-44A3-97C5-C35C2DCE9389@ipjustice.org> Here it is, the Initial Report for WT5. Public comments are now open until 22 January 2019. Best, Robin > Begin forwarded message: > > From: Steve Chan > Subject: [Gnso-newgtld-wg-wt5] Work Track 5 Supplemental Initial Report - Published for Public Comment > Date: December 5, 2018 at 4:23:27 PM PST > To: "gnso-newgtld-wg-wt5 at icann.org" > > Dear Work Track 5 Members, > > Please note that the Work Track 5 Supplemental Initial Report was just published for public comment here: https://www.icann.org/public-comments/geo-names-wt5-initial-2018-12-05-en > > Congratulations to all of you for reaching this milestone in the policy development process! > > Best, > Steve > > > > > Steven Chan > > Policy Director, GNSO Support > > ICANN > 12025 Waterfront Drive, Suite 300 > Los Angeles, CA 90094-2536 > > Mobile: +1.310.339.4410 > Office Telephone: +1.310.301.5800 > Office Fax: +1.310.823.8649 > > Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages . > > Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO > Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ > http://gnso.icann.org/en/ > > _______________________________________________ > Gnso-newgtld-wg-wt5 mailing list > Gnso-newgtld-wg-wt5 at icann.org > https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Thu Dec 6 05:37:35 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Thu, 6 Dec 2018 12:37:35 +0900 Subject: [NCSG-PC] Fwd: [Gnso-newgtld-wg-wt5] Work Track 5 Supplemental Initial Report - Published for Public Comment In-Reply-To: <08DF24C6-7199-44A3-97C5-C35C2DCE9389@ipjustice.org> References: <08DF24C6-7199-44A3-97C5-C35C2DCE9389@ipjustice.org> Message-ID: thanks Robin for sharing this, I shared the call in NCSG list to get volunteers for drafting NCSG response. Rafik Le jeu. 6 d?c. 2018 ? 09:33, Robin Gross a ?crit : > Here it is, the Initial Report for WT5. Public comments are now open > until 22 January 2019. > > Best, > Robin > > Begin forwarded message: > > *From: *Steve Chan > *Subject: **[Gnso-newgtld-wg-wt5] Work Track 5 Supplemental Initial > Report - Published for Public Comment* > *Date: *December 5, 2018 at 4:23:27 PM PST > *To: *"gnso-newgtld-wg-wt5 at icann.org" > > Dear Work Track 5 Members, > > Please note that the Work Track 5 Supplemental Initial Report was just > published for public comment here: > https://www.icann.org/public-comments/geo-names-wt5-initial-2018-12-05-en > > Congratulations to all of you for reaching this milestone in the policy > development process! > > Best, > Steve > > > > > *Steven Chan* > Policy Director, GNSO Support > > *ICANN* > 12025 Waterfront Drive, Suite 300 > Los Angeles, CA 90094-2536 > Mobile: +1.310.339.4410 > Office Telephone: +1.310.301.5800 > Office Fax: +1.310.823.8649 > > Find out more about the GNSO by taking our interactive courses > and visiting the GNSO Newcomer pages > > . > > Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO > Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ > http://gnso.icann.org/en/ > > _______________________________________________ > Gnso-newgtld-wg-wt5 mailing list > Gnso-newgtld-wg-wt5 at icann.org > https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt5 > > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Sun Dec 9 06:49:36 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Sun, 9 Dec 2018 13:49:36 +0900 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) Message-ID: Hi all, with some delay, I could finally go through the draft and makes edits based on comments: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. I left the document on suggestion-mode to highlight the changes. I closed some comments that didn't lead to any change (you can still check them). the deadline for submission is the 11th December. please review the comment. Best, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Sun Dec 9 06:53:51 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Sun, 9 Dec 2018 13:53:51 +0900 Subject: [NCSG-PC] SCBO call for candidates Message-ID: Hi all, as it was agreed, we extended the call for candidates for SCBO. we didn't receive any additional application. We have only one application received during the first call. I have no objection to appointing the only applicant, in addition to Stephanie who moved her membership in SCBO as a GNSO councillor to SME. please share your thoughts here. the SCBO will start working on ICANN budget and operating plan in 18th Dec. Best, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Mon Dec 10 03:27:59 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Mon, 10 Dec 2018 01:27:59 +0000 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: Message-ID: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Thanks, Rafik. I have been further reflecting on this comment and believe we need to revise Recommendation #1 to take a stronger position. I do not support either Mechanism A or B, and would prefer to see us support solely Mechanism C. This is because an independent ICANN Foundation with its own, independent Board of Directors would be more accountable than anything Mechanisms A (utterly unaccountable) or B (weak accountability structure) can offer. I have also deleted an edit that said ICANN org should be able to access auction proceeds if it goes through a community consultation process. I do not support this at all, and think it contradicts the rest of our comment where we speak to how funds were supposed to be sequested for charitable purposes. Best wishes, Ayden ??????? Original Message ??????? On Saturday, 8 December 2018 23:49, Rafik Dammak wrote: > Hi all, > > with some delay, I could finally go through the draft and makes edits based on comments: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. I left the document on suggestion-mode to highlight the changes. I closed some comments that didn't lead to any change (you can still check them). > the deadline for submission is the 11th December. please review the comment. > > Best, > > Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsilvavalent at gmail.com Mon Dec 10 12:37:52 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Mon, 10 Dec 2018 07:37:52 -0300 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: I have to agree with Ayden, the more shielded those funds are, the better, is too much money and really needs to be used 1) only in a financialy sustainable way, 2) in charitable projects. The 1) one is more easily accountable, but the latter really needs as independent and accountable process as it can get. Best, Mart?n On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline Thanks, Rafik. I have been further reflecting on this comment and believe > we need to revise Recommendation #1 to take a stronger position. I do not > support either Mechanism A or B, and would prefer to see us support solely > Mechanism C. This is because an independent ICANN Foundation with its own, > independent Board of Directors would be more accountable than anything > Mechanisms A (utterly unaccountable) or B (weak accountability structure) > can offer. > > I have also deleted an edit that said ICANN org should be able to access > auction proceeds if it goes through a community consultation process. I do > not support this at all, and think it contradicts the rest of our comment > where we speak to how funds were supposed to be sequested for charitable > purposes. > > Best wishes, Ayden > > ??????? Original Message ??????? > On Saturday, 8 December 2018 23:49, Rafik Dammak > wrote: > > Hi all, > > with some delay, I could finally go through the draft and makes edits > based on comments: > https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. > I left the document on suggestion-mode to highlight the changes. I closed > some comments that didn't lead to any change (you can still check them). > the deadline for submission is the 11th December. please review the > comment. > > Best, > > Rafik > > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From PolicyCalendar at icann.org Mon Dec 10 15:22:43 2018 From: PolicyCalendar at icann.org (ICANN Policy Calendar) Date: Mon, 10 Dec 2018 13:22:43 +0000 Subject: [NCSG-PC] Monthly NCSG Policy Call on Monday 18 December 2018 at 12:00 UTC Message-ID: <39b4074c889e4849a9b60a519dbac50e@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Dear All, Please find participation details for the Monthly NCSG Policy Call on Monday 18 December 2018 at 12:00 UTC Adobe Connect: https://participate.icann.org/ncsg Time Zones: https://tinyurl.com/y8efhvas Dial out request: please send an email to Maryam.bakoshi at icann.org offline. Audio dial-in details below: [https://cobranding-pgi.s3.amazonaws.com/1/Logo1.png] You're invited. You've been invited to a GlobalMeet? audio meeting. Have the meeting call you. Click the Connect Me link below. No need to dial-in. Connect Me [go.conferencinghub.com] Not at your computer? You can join by dialing one of the access numbers below. Mobile: tel://16054755604,*,,9922790467# Phone Only Controls : https://go.conferencinghub.com/2xdh7 Access Number: 1-605-475-5604 Guest Passcode: 992 279 0467 Additional Access: USA: 1-605-475-5604 USA: 1-719-457-6209 Canada, Calgary: +1 403 407 5793 Canada, Montreal: +1 514 669 5928 Canada, Toronto: +1 647 426 9172 Canada, Vancouver: +1 604 222 7836 Argentina, Buenos Aires: +54 (0) 11 5172 6003 Argentina (toll free): 0800 800 1223 Australia, Sydney: +61 (0) 2 8017 6064 Australia, Melbourne: +61 (0) 3 8687 0553 Australia, Brisbane: +61 (0) 7 3015 0535 Australia (toll free): 1 800 804 786 Austria (toll free): 0800 070 981 Bahrain, Manama: +973 1619 8739 Bahrain (toll free): 800 04212 Belarus (toll free): 8 820 0011 0341 Belgium, Brussels: +32 (0) 2 400 6928 Belgium (toll free): 0800 39279 Bosnia and Herzegovina: +387 7031 1442 Brazil, Sao Paulo: +55 11 4935 7169 Brazil, Rio de Janeiro: +55 21 4560 0072 Brazil (toll free): 0800 887 0233 Bulgaria, Sofia: +359 (0) 2 491 6045 Bulgaria (toll free): 00800 111 4950 Cambodia, Phnom Penh: +855 23 965 723 Canada (toll free): 1 855 950 3717 Chile, Santiago: +56 (0) 2 2666 0696 Chile (toll free): 171 800 835 783 China (national): +400 613 8103 China, Beijing: +86 10 5667 0003 China, Shanghai: +86 21 2039 7081 Colombia, Bogota: +57 1 508 8137 Colombia (toll free): 01 800 755 0102 Costa Rica (toll free): 800 542 5328 Croatia (toll free): 0800 805 940 Cyprus (toll free): 800 97424 Czech Republic, Prague: +420 225 986 554 Czech Republic (toll free): 800 701 532 Denmark, Copenhagen: +45 32 72 78 10 Denmark (toll free): 80 70 35 86 Egypt (toll free): 0800 000 0593 Estonia, Tallinn: +372 622 6551 Estonia (toll free): 800 011 1589 Fiji (toll free): 00800 3322 Finland, Helsinki: +358 (0) 9 2310 1677 Finland (toll free): 0800 772 236 France, Paris: +33 (0) 1 70 37 16 56 France (toll free): 0800 946 531 France (national): 0811 655 100 France (national): 0821 231 671 Georgia, Tbilisi: +995 32 2 050 778 Germany, Frankfurt: +49 (0) 69 2222 10612 Germany, Munich: +49 (0) 89 2030 31207 Germany (national): 01801 003 899 Germany (toll free): 0800 588 9170 Greece, Athens: +30 211 181 3824 Greece (toll free): 00800 128 913 Hong Kong: +852 3018 9111 Hong Kong (toll free): 800 901 787 Hungary, Budapest: +36 1408 8953 Hungary (toll free): 068 001 9673 Iceland (toll free): 800 9847 India, Delhi: +91 11 6310 0268 India, Mumbai: +91 22 6310 0298 India, Chennai: +91 44 6310 0234 India, Bangalore: +91 80 6760 8755 India (toll free): 1800 3010 1582 Indonesia, Jakarta: +62 21 2188 9084 Indonesia (toll free): 007 803 321 8927 Ireland, Dublin: +353 (0) 1 526 9421 Ireland (national): 0818 270 271 Ireland (toll free): 1800 937 649 Ireland (national): 1890 907 630 Israel, Tel Aviv: +972 (0)3 721 7943 Israel (toll free): 1809 213 168 Italy, Milan: +39 02 3600 8006 Italy, Rome: +39 06 8750 0676 Italy (toll free): 800 146 094 Japan, Tokyo: +81 3 4560 1270 Japan, Osaka: +81 6 4560 2410 Japan (toll free): 0120 305 211 Japan (mobile): 0120 632 611 Japan (national): 0570 085 744 Jordan (toll free): 0800 22172 Kazakhstan (toll free): 8800 333 7554 Kenya, Nairobi: +254 (0)207 643 581 South Korea, Seoul: +82 (0) 2 6007 0079 South Korea (toll free): 00798 6136 1454 Kuwait (national): +965 2206 3002 Latvia, Riga: +371 6601 3627 Latvia (toll free): 8000 4418 Lithuania, Vilnius: +370 5205 5468 Lithuania (toll free): 8800 31449 Luxembourg: +352 2088 1749 Luxembourg (toll free): 800 28433 Macau (national): +853 6262 1676 Malaysia, Kuala Lumpur: +60 (0) 3 7724 8010 Malaysia (toll free): 1 800 816 152 Mexico, Guadalajara: +52 33 4162 4504 Mexico, Mexico City: +52 55 8421 0326 Mexico, Monterrey: +52 81 4162 5648 Mexico (toll free): 01 800 733 4102 Morocco, Casablanca: +212 (0) 520 48 0022 Morocco (toll free): 0800 091 296 Netherlands, Amsterdam: +31 (0) 20 716 8345 Netherlands (toll free): 0800 020 2597 New Zealand, Christchurch: +64 (0) 3 974 2596 New Zealand, Wellington: +64 (0) 4 909 4674 New Zealand, Auckland: +64 (0) 9 929 1825 New Zealand (toll free): 0800 452 947 Nigeria, Lagos: +234 1 277 3944 Norway, Oslo: +47 21 00 48 15 Norway (toll free): 800 56081 Oman (toll free): 800 77265 Pakistan, Islamabad: +92 5181 08863 Panama, Panama City: +507 8 335 913 Panama (toll free): 00800 223 1390 Peru, Lima: +51 (0) 1 700 9571 Philippines, Manila: +63 (0)2 395 3426 Philippines (toll free): 1 800 111 013 99 Poland, Warsaw: +48 22 295 3570 Poland (toll free): 00 800 121 4356 Portugal, Lisbon: +351 21 316 4093 Portugal (toll free): 800 784 442 Qatar (freephone): 00 800 100 491 Romania, Bucharest: +40 (0) 21 529 3992 Romania (toll free): 0800 801 035 Russia, Moscow: +7 495 646 9181 Russia (toll free): 8 800 500 9241 Saudi Arabia (toll free): 800 844 6641 Saudi Arabia (toll free): 800 850 0219 Serbia (toll free): 0800 190 712 Singapore: +65 6654 9112 Singapore (toll free): 800 616 3192 Slovakia, Bratislava: +421 (0)2 3321 5498 Slovakia (toll free): 0800 002 002 Slovenia, Ljubljana: +386 1600 8695 Slovenia (toll free): 0800 81193 South Africa, Johannesburg: +27 (0)11 589 8321 South Africa (toll free): 0800 999 434 Spain, Madrid: +34 91 114 6653 Spain, Barcelona: +34 93 800 1946 Spain (toll free): 900 828 035 Sri Lanka, Sri Lanka: +94 720 910 333 Sweden, Stockholm: +46 (0) 8 5065 3956 Sweden (toll free): 0200 125 588 Switzerland, Geneva: +41 (0) 22 595 4795 Switzerland, Zurich: +41 (0) 44 580 7207 Switzerland (toll free): 0800 740 360 Taiwan, Taipei: +886 (0) 2 2650 7329 Taiwan (toll free): 0800 666 596 Thailand, Bangkok: +66 (0) 2104 0761 Thailand (toll free): 001 800 6136 1473 Tunisia, Tunis: +216 31 378 101 Turkey, Istanbul: +90 212 375 50 49 Turkey (toll free): 00800 4488 26642 Ukraine (toll free): 0800 500 896 UAE (toll free): 8000 3570 2662 UK (03): +44 (0)330 336 6002 UK (toll free): 0800 358 6385 UK (national): 0844 473 5010 UK (national): 0845 545 0015 USA /Canada (toll free): 1-866-398-2885 Uruguay (toll free): 0004 019 0152 Venezuela, Caracas: +58 212 720 2164 Venezuela (toll free): 0 800 162 7451 Vietnam, Hanoi: +84 24 4458 3312 Vietnam, Ho Chi Minh: +84 28 4458 1322 Vietnam (toll free): 1800 9226 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 11246 bytes Desc: not available URL: From PolicyCalendar at icann.org Mon Dec 10 15:24:21 2018 From: PolicyCalendar at icann.org (ICANN Policy Calendar) Date: Mon, 10 Dec 2018 13:24:21 +0000 Subject: [NCSG-PC] Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Message-ID: <5444abf1841c458b8af4fcd8a684ad1a@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Dear All, Please find participation details for the Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Adobe Connect: https://participate.icann.org/ncsg Time Zones: https://tinyurl.com/y8efhvas Dial out request: please send an email to Maryam.bakoshi at icann.org offline. Audio dial-in details below: [https://cobranding-pgi.s3.amazonaws.com/1/Logo1.png] You're invited. You've been invited to a GlobalMeet? audio meeting. Have the meeting call you. Click the Connect Me link below. No need to dial-in. Connect Me [go.conferencinghub.com] Not at your computer? You can join by dialing one of the access numbers below. Mobile: tel://16054755604,*,,9922790467# Phone Only Controls : https://go.conferencinghub.com/2xdh7 Access Number: 1-605-475-5604 Guest Passcode: 992 279 0467 Additional Access: USA: 1-605-475-5604 USA: 1-719-457-6209 Canada, Calgary: +1 403 407 5793 Canada, Montreal: +1 514 669 5928 Canada, Toronto: +1 647 426 9172 Canada, Vancouver: +1 604 222 7836 Argentina, Buenos Aires: +54 (0) 11 5172 6003 Argentina (toll free): 0800 800 1223 Australia, Sydney: +61 (0) 2 8017 6064 Australia, Melbourne: +61 (0) 3 8687 0553 Australia, Brisbane: +61 (0) 7 3015 0535 Australia (toll free): 1 800 804 786 Austria (toll free): 0800 070 981 Bahrain, Manama: +973 1619 8739 Bahrain (toll free): 800 04212 Belarus (toll free): 8 820 0011 0341 Belgium, Brussels: +32 (0) 2 400 6928 Belgium (toll free): 0800 39279 Bosnia and Herzegovina: +387 7031 1442 Brazil, Sao Paulo: +55 11 4935 7169 Brazil, Rio de Janeiro: +55 21 4560 0072 Brazil (toll free): 0800 887 0233 Bulgaria, Sofia: +359 (0) 2 491 6045 Bulgaria (toll free): 00800 111 4950 Cambodia, Phnom Penh: +855 23 965 723 Canada (toll free): 1 855 950 3717 Chile, Santiago: +56 (0) 2 2666 0696 Chile (toll free): 171 800 835 783 China (national): +400 613 8103 China, Beijing: +86 10 5667 0003 China, Shanghai: +86 21 2039 7081 Colombia, Bogota: +57 1 508 8137 Colombia (toll free): 01 800 755 0102 Costa Rica (toll free): 800 542 5328 Croatia (toll free): 0800 805 940 Cyprus (toll free): 800 97424 Czech Republic, Prague: +420 225 986 554 Czech Republic (toll free): 800 701 532 Denmark, Copenhagen: +45 32 72 78 10 Denmark (toll free): 80 70 35 86 Egypt (toll free): 0800 000 0593 Estonia, Tallinn: +372 622 6551 Estonia (toll free): 800 011 1589 Fiji (toll free): 00800 3322 Finland, Helsinki: +358 (0) 9 2310 1677 Finland (toll free): 0800 772 236 France, Paris: +33 (0) 1 70 37 16 56 France (toll free): 0800 946 531 France (national): 0811 655 100 France (national): 0821 231 671 Georgia, Tbilisi: +995 32 2 050 778 Germany, Frankfurt: +49 (0) 69 2222 10612 Germany, Munich: +49 (0) 89 2030 31207 Germany (national): 01801 003 899 Germany (toll free): 0800 588 9170 Greece, Athens: +30 211 181 3824 Greece (toll free): 00800 128 913 Hong Kong: +852 3018 9111 Hong Kong (toll free): 800 901 787 Hungary, Budapest: +36 1408 8953 Hungary (toll free): 068 001 9673 Iceland (toll free): 800 9847 India, Delhi: +91 11 6310 0268 India, Mumbai: +91 22 6310 0298 India, Chennai: +91 44 6310 0234 India, Bangalore: +91 80 6760 8755 India (toll free): 1800 3010 1582 Indonesia, Jakarta: +62 21 2188 9084 Indonesia (toll free): 007 803 321 8927 Ireland, Dublin: +353 (0) 1 526 9421 Ireland (national): 0818 270 271 Ireland (toll free): 1800 937 649 Ireland (national): 1890 907 630 Israel, Tel Aviv: +972 (0)3 721 7943 Israel (toll free): 1809 213 168 Italy, Milan: +39 02 3600 8006 Italy, Rome: +39 06 8750 0676 Italy (toll free): 800 146 094 Japan, Tokyo: +81 3 4560 1270 Japan, Osaka: +81 6 4560 2410 Japan (toll free): 0120 305 211 Japan (mobile): 0120 632 611 Japan (national): 0570 085 744 Jordan (toll free): 0800 22172 Kazakhstan (toll free): 8800 333 7554 Kenya, Nairobi: +254 (0)207 643 581 South Korea, Seoul: +82 (0) 2 6007 0079 South Korea (toll free): 00798 6136 1454 Kuwait (national): +965 2206 3002 Latvia, Riga: +371 6601 3627 Latvia (toll free): 8000 4418 Lithuania, Vilnius: +370 5205 5468 Lithuania (toll free): 8800 31449 Luxembourg: +352 2088 1749 Luxembourg (toll free): 800 28433 Macau (national): +853 6262 1676 Malaysia, Kuala Lumpur: +60 (0) 3 7724 8010 Malaysia (toll free): 1 800 816 152 Mexico, Guadalajara: +52 33 4162 4504 Mexico, Mexico City: +52 55 8421 0326 Mexico, Monterrey: +52 81 4162 5648 Mexico (toll free): 01 800 733 4102 Morocco, Casablanca: +212 (0) 520 48 0022 Morocco (toll free): 0800 091 296 Netherlands, Amsterdam: +31 (0) 20 716 8345 Netherlands (toll free): 0800 020 2597 New Zealand, Christchurch: +64 (0) 3 974 2596 New Zealand, Wellington: +64 (0) 4 909 4674 New Zealand, Auckland: +64 (0) 9 929 1825 New Zealand (toll free): 0800 452 947 Nigeria, Lagos: +234 1 277 3944 Norway, Oslo: +47 21 00 48 15 Norway (toll free): 800 56081 Oman (toll free): 800 77265 Pakistan, Islamabad: +92 5181 08863 Panama, Panama City: +507 8 335 913 Panama (toll free): 00800 223 1390 Peru, Lima: +51 (0) 1 700 9571 Philippines, Manila: +63 (0)2 395 3426 Philippines (toll free): 1 800 111 013 99 Poland, Warsaw: +48 22 295 3570 Poland (toll free): 00 800 121 4356 Portugal, Lisbon: +351 21 316 4093 Portugal (toll free): 800 784 442 Qatar (freephone): 00 800 100 491 Romania, Bucharest: +40 (0) 21 529 3992 Romania (toll free): 0800 801 035 Russia, Moscow: +7 495 646 9181 Russia (toll free): 8 800 500 9241 Saudi Arabia (toll free): 800 844 6641 Saudi Arabia (toll free): 800 850 0219 Serbia (toll free): 0800 190 712 Singapore: +65 6654 9112 Singapore (toll free): 800 616 3192 Slovakia, Bratislava: +421 (0)2 3321 5498 Slovakia (toll free): 0800 002 002 Slovenia, Ljubljana: +386 1600 8695 Slovenia (toll free): 0800 81193 South Africa, Johannesburg: +27 (0)11 589 8321 South Africa (toll free): 0800 999 434 Spain, Madrid: +34 91 114 6653 Spain, Barcelona: +34 93 800 1946 Spain (toll free): 900 828 035 Sri Lanka, Sri Lanka: +94 720 910 333 Sweden, Stockholm: +46 (0) 8 5065 3956 Sweden (toll free): 0200 125 588 Switzerland, Geneva: +41 (0) 22 595 4795 Switzerland, Zurich: +41 (0) 44 580 7207 Switzerland (toll free): 0800 740 360 Taiwan, Taipei: +886 (0) 2 2650 7329 Taiwan (toll free): 0800 666 596 Thailand, Bangkok: +66 (0) 2104 0761 Thailand (toll free): 001 800 6136 1473 Tunisia, Tunis: +216 31 378 101 Turkey, Istanbul: +90 212 375 50 49 Turkey (toll free): 00800 4488 26642 Ukraine (toll free): 0800 500 896 UAE (toll free): 8000 3570 2662 UK (03): +44 (0)330 336 6002 UK (toll free): 0800 358 6385 UK (national): 0844 473 5010 UK (national): 0845 545 0015 USA /Canada (toll free): 1-866-398-2885 Uruguay (toll free): 0004 019 0152 Venezuela, Caracas: +58 212 720 2164 Venezuela (toll free): 0 800 162 7451 Vietnam, Hanoi: +84 24 4458 3312 Vietnam, Ho Chi Minh: +84 28 4458 1322 Vietnam (toll free): 1800 9226 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 11246 bytes Desc: not available URL: From maryam.bakoshi at icann.org Mon Dec 10 15:24:43 2018 From: maryam.bakoshi at icann.org (Maryam Bakoshi) Date: Mon, 10 Dec 2018 13:24:43 +0000 Subject: [NCSG-PC] Meeting Invite: Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Message-ID: <4A18A593-691C-4868-89AB-B174915E0783@icann.org> Dear All, Please find participation details for the Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Adobe Connect: https://participate.icann.org/ncsg Time Zones: https://tinyurl.com/y8efhvas Dial out request: please send an email to Maryam.bakoshi at icann.org offline. Audio dial-in details below: [https://cobranding-pgi.s3.amazonaws.com/1/Logo1.png] You're invited. You've been invited to a GlobalMeet? audio meeting. Have the meeting call you. Click the Connect Me link below. No need to dial-in. Connect Me [go.conferencinghub.com] Not at your computer? You can join by dialing one of the access numbers below. Mobile: tel://16054755604,*,,9922790467# Phone Only Controls : https://go.conferencinghub.com/2xdh7 Access Number: 1-605-475-5604 Guest Passcode: 992 279 0467 Additional Access: USA: 1-605-475-5604 USA: 1-719-457-6209 Canada, Calgary: +1 403 407 5793 Canada, Montreal: +1 514 669 5928 Canada, Toronto: +1 647 426 9172 Canada, Vancouver: +1 604 222 7836 Argentina, Buenos Aires: +54 (0) 11 5172 6003 Argentina (toll free): 0800 800 1223 Australia, Sydney: +61 (0) 2 8017 6064 Australia, Melbourne: +61 (0) 3 8687 0553 Australia, Brisbane: +61 (0) 7 3015 0535 Australia (toll free): 1 800 804 786 Austria (toll free): 0800 070 981 Bahrain, Manama: +973 1619 8739 Bahrain (toll free): 800 04212 Belarus (toll free): 8 820 0011 0341 Belgium, Brussels: +32 (0) 2 400 6928 Belgium (toll free): 0800 39279 Bosnia and Herzegovina: +387 7031 1442 Brazil, Sao Paulo: +55 11 4935 7169 Brazil, Rio de Janeiro: +55 21 4560 0072 Brazil (toll free): 0800 887 0233 Bulgaria, Sofia: +359 (0) 2 491 6045 Bulgaria (toll free): 00800 111 4950 Cambodia, Phnom Penh: +855 23 965 723 Canada (toll free): 1 855 950 3717 Chile, Santiago: +56 (0) 2 2666 0696 Chile (toll free): 171 800 835 783 China (national): +400 613 8103 China, Beijing: +86 10 5667 0003 China, Shanghai: +86 21 2039 7081 Colombia, Bogota: +57 1 508 8137 Colombia (toll free): 01 800 755 0102 Costa Rica (toll free): 800 542 5328 Croatia (toll free): 0800 805 940 Cyprus (toll free): 800 97424 Czech Republic, Prague: +420 225 986 554 Czech Republic (toll free): 800 701 532 Denmark, Copenhagen: +45 32 72 78 10 Denmark (toll free): 80 70 35 86 Egypt (toll free): 0800 000 0593 Estonia, Tallinn: +372 622 6551 Estonia (toll free): 800 011 1589 Fiji (toll free): 00800 3322 Finland, Helsinki: +358 (0) 9 2310 1677 Finland (toll free): 0800 772 236 France, Paris: +33 (0) 1 70 37 16 56 France (toll free): 0800 946 531 France (national): 0811 655 100 France (national): 0821 231 671 Georgia, Tbilisi: +995 32 2 050 778 Germany, Frankfurt: +49 (0) 69 2222 10612 Germany, Munich: +49 (0) 89 2030 31207 Germany (national): 01801 003 899 Germany (toll free): 0800 588 9170 Greece, Athens: +30 211 181 3824 Greece (toll free): 00800 128 913 Hong Kong: +852 3018 9111 Hong Kong (toll free): 800 901 787 Hungary, Budapest: +36 1408 8953 Hungary (toll free): 068 001 9673 Iceland (toll free): 800 9847 India, Delhi: +91 11 6310 0268 India, Mumbai: +91 22 6310 0298 India, Chennai: +91 44 6310 0234 India, Bangalore: +91 80 6760 8755 India (toll free): 1800 3010 1582 Indonesia, Jakarta: +62 21 2188 9084 Indonesia (toll free): 007 803 321 8927 Ireland, Dublin: +353 (0) 1 526 9421 Ireland (national): 0818 270 271 Ireland (toll free): 1800 937 649 Ireland (national): 1890 907 630 Israel, Tel Aviv: +972 (0)3 721 7943 Israel (toll free): 1809 213 168 Italy, Milan: +39 02 3600 8006 Italy, Rome: +39 06 8750 0676 Italy (toll free): 800 146 094 Japan, Tokyo: +81 3 4560 1270 Japan, Osaka: +81 6 4560 2410 Japan (toll free): 0120 305 211 Japan (mobile): 0120 632 611 Japan (national): 0570 085 744 Jordan (toll free): 0800 22172 Kazakhstan (toll free): 8800 333 7554 Kenya, Nairobi: +254 (0)207 643 581 South Korea, Seoul: +82 (0) 2 6007 0079 South Korea (toll free): 00798 6136 1454 Kuwait (national): +965 2206 3002 Latvia, Riga: +371 6601 3627 Latvia (toll free): 8000 4418 Lithuania, Vilnius: +370 5205 5468 Lithuania (toll free): 8800 31449 Luxembourg: +352 2088 1749 Luxembourg (toll free): 800 28433 Macau (national): +853 6262 1676 Malaysia, Kuala Lumpur: +60 (0) 3 7724 8010 Malaysia (toll free): 1 800 816 152 Mexico, Guadalajara: +52 33 4162 4504 Mexico, Mexico City: +52 55 8421 0326 Mexico, Monterrey: +52 81 4162 5648 Mexico (toll free): 01 800 733 4102 Morocco, Casablanca: +212 (0) 520 48 0022 Morocco (toll free): 0800 091 296 Netherlands, Amsterdam: +31 (0) 20 716 8345 Netherlands (toll free): 0800 020 2597 New Zealand, Christchurch: +64 (0) 3 974 2596 New Zealand, Wellington: +64 (0) 4 909 4674 New Zealand, Auckland: +64 (0) 9 929 1825 New Zealand (toll free): 0800 452 947 Nigeria, Lagos: +234 1 277 3944 Norway, Oslo: +47 21 00 48 15 Norway (toll free): 800 56081 Oman (toll free): 800 77265 Pakistan, Islamabad: +92 5181 08863 Panama, Panama City: +507 8 335 913 Panama (toll free): 00800 223 1390 Peru, Lima: +51 (0) 1 700 9571 Philippines, Manila: +63 (0)2 395 3426 Philippines (toll free): 1 800 111 013 99 Poland, Warsaw: +48 22 295 3570 Poland (toll free): 00 800 121 4356 Portugal, Lisbon: +351 21 316 4093 Portugal (toll free): 800 784 442 Qatar (freephone): 00 800 100 491 Romania, Bucharest: +40 (0) 21 529 3992 Romania (toll free): 0800 801 035 Russia, Moscow: +7 495 646 9181 Russia (toll free): 8 800 500 9241 Saudi Arabia (toll free): 800 844 6641 Saudi Arabia (toll free): 800 850 0219 Serbia (toll free): 0800 190 712 Singapore: +65 6654 9112 Singapore (toll free): 800 616 3192 Slovakia, Bratislava: +421 (0)2 3321 5498 Slovakia (toll free): 0800 002 002 Slovenia, Ljubljana: +386 1600 8695 Slovenia (toll free): 0800 81193 South Africa, Johannesburg: +27 (0)11 589 8321 South Africa (toll free): 0800 999 434 Spain, Madrid: +34 91 114 6653 Spain, Barcelona: +34 93 800 1946 Spain (toll free): 900 828 035 Sri Lanka, Sri Lanka: +94 720 910 333 Sweden, Stockholm: +46 (0) 8 5065 3956 Sweden (toll free): 0200 125 588 Switzerland, Geneva: +41 (0) 22 595 4795 Switzerland, Zurich: +41 (0) 44 580 7207 Switzerland (toll free): 0800 740 360 Taiwan, Taipei: +886 (0) 2 2650 7329 Taiwan (toll free): 0800 666 596 Thailand, Bangkok: +66 (0) 2104 0761 Thailand (toll free): 001 800 6136 1473 Tunisia, Tunis: +216 31 378 101 Turkey, Istanbul: +90 212 375 50 49 Turkey (toll free): 00800 4488 26642 Ukraine (toll free): 0800 500 896 UAE (toll free): 8000 3570 2662 UK (03): +44 (0)330 336 6002 UK (toll free): 0800 358 6385 UK (national): 0844 473 5010 UK (national): 0845 545 0015 USA /Canada (toll free): 1-866-398-2885 Uruguay (toll free): 0004 019 0152 Venezuela, Caracas: +58 212 720 2164 Venezuela (toll free): 0 800 162 7451 Vietnam, Hanoi: +84 24 4458 3312 Vietnam, Ho Chi Minh: +84 28 4458 1322 Vietnam (toll free): 1800 9226 -- Many thanks, Maryam Bakoshi | SO/AC Collaboration Services Sr. Coordinator ICANN | Internet Corporation got Assigned Names and Numbers S: Maryam.bakoshi.icann | T: +44 7846 471777 -------------- next part -------------- An HTML attachment was scrubbed... URL: From PolicyCalendar at icann.org Mon Dec 10 22:36:42 2018 From: PolicyCalendar at icann.org (ICANN Policy Calendar) Date: Mon, 10 Dec 2018 20:36:42 +0000 Subject: [NCSG-PC] Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Message-ID: Dear All, Please find participation details for the Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Adobe Connect: https://participate.icann.org/ncsg Time Zones: https://tinyurl.com/y8efhvas Dial out request: please send an email to Maryam.bakoshi at icann.org offline. Audio dial-in details below: [https://cobranding-pgi.s3.amazonaws.com/1/Logo1.png] You're invited. You've been invited to a GlobalMeet? audio meeting. Have the meeting call you. Click the Connect Me link below. No need to dial-in. Connect Me [go.conferencinghub.com] Not at your computer? You can join by dialing one of the access numbers below. Mobile: tel://16054755604,*,,9922790467# Phone Only Controls : https://go.conferencinghub.com/2xdh7 Access Number: 1-605-475-5604 Guest Passcode: 992 279 0467 Additional Access: USA: 1-605-475-5604 USA: 1-719-457-6209 Canada, Calgary: +1 403 407 5793 Canada, Montreal: +1 514 669 5928 Canada, Toronto: +1 647 426 9172 Canada, Vancouver: +1 604 222 7836 Argentina, Buenos Aires: +54 (0) 11 5172 6003 Argentina (toll free): 0800 800 1223 Australia, Sydney: +61 (0) 2 8017 6064 Australia, Melbourne: +61 (0) 3 8687 0553 Australia, Brisbane: +61 (0) 7 3015 0535 Australia (toll free): 1 800 804 786 Austria (toll free): 0800 070 981 Bahrain, Manama: +973 1619 8739 Bahrain (toll free): 800 04212 Belarus (toll free): 8 820 0011 0341 Belgium, Brussels: +32 (0) 2 400 6928 Belgium (toll free): 0800 39279 Bosnia and Herzegovina: +387 7031 1442 Brazil, Sao Paulo: +55 11 4935 7169 Brazil, Rio de Janeiro: +55 21 4560 0072 Brazil (toll free): 0800 887 0233 Bulgaria, Sofia: +359 (0) 2 491 6045 Bulgaria (toll free): 00800 111 4950 Cambodia, Phnom Penh: +855 23 965 723 Canada (toll free): 1 855 950 3717 Chile, Santiago: +56 (0) 2 2666 0696 Chile (toll free): 171 800 835 783 China (national): +400 613 8103 China, Beijing: +86 10 5667 0003 China, Shanghai: +86 21 2039 7081 Colombia, Bogota: +57 1 508 8137 Colombia (toll free): 01 800 755 0102 Costa Rica (toll free): 800 542 5328 Croatia (toll free): 0800 805 940 Cyprus (toll free): 800 97424 Czech Republic, Prague: +420 225 986 554 Czech Republic (toll free): 800 701 532 Denmark, Copenhagen: +45 32 72 78 10 Denmark (toll free): 80 70 35 86 Egypt (toll free): 0800 000 0593 Estonia, Tallinn: +372 622 6551 Estonia (toll free): 800 011 1589 Fiji (toll free): 00800 3322 Finland, Helsinki: +358 (0) 9 2310 1677 Finland (toll free): 0800 772 236 France, Paris: +33 (0) 1 70 37 16 56 France (toll free): 0800 946 531 France (national): 0811 655 100 France (national): 0821 231 671 Georgia, Tbilisi: +995 32 2 050 778 Germany, Frankfurt: +49 (0) 69 2222 10612 Germany, Munich: +49 (0) 89 2030 31207 Germany (national): 01801 003 899 Germany (toll free): 0800 588 9170 Greece, Athens: +30 211 181 3824 Greece (toll free): 00800 128 913 Hong Kong: +852 3018 9111 Hong Kong (toll free): 800 901 787 Hungary, Budapest: +36 1408 8953 Hungary (toll free): 068 001 9673 Iceland (toll free): 800 9847 India, Delhi: +91 11 6310 0268 India, Mumbai: +91 22 6310 0298 India, Chennai: +91 44 6310 0234 India, Bangalore: +91 80 6760 8755 India (toll free): 1800 3010 1582 Indonesia, Jakarta: +62 21 2188 9084 Indonesia (toll free): 007 803 321 8927 Ireland, Dublin: +353 (0) 1 526 9421 Ireland (national): 0818 270 271 Ireland (toll free): 1800 937 649 Ireland (national): 1890 907 630 Israel, Tel Aviv: +972 (0)3 721 7943 Israel (toll free): 1809 213 168 Italy, Milan: +39 02 3600 8006 Italy, Rome: +39 06 8750 0676 Italy (toll free): 800 146 094 Japan, Tokyo: +81 3 4560 1270 Japan, Osaka: +81 6 4560 2410 Japan (toll free): 0120 305 211 Japan (mobile): 0120 632 611 Japan (national): 0570 085 744 Jordan (toll free): 0800 22172 Kazakhstan (toll free): 8800 333 7554 Kenya, Nairobi: +254 (0)207 643 581 South Korea, Seoul: +82 (0) 2 6007 0079 South Korea (toll free): 00798 6136 1454 Kuwait (national): +965 2206 3002 Latvia, Riga: +371 6601 3627 Latvia (toll free): 8000 4418 Lithuania, Vilnius: +370 5205 5468 Lithuania (toll free): 8800 31449 Luxembourg: +352 2088 1749 Luxembourg (toll free): 800 28433 Macau (national): +853 6262 1676 Malaysia, Kuala Lumpur: +60 (0) 3 7724 8010 Malaysia (toll free): 1 800 816 152 Mexico, Guadalajara: +52 33 4162 4504 Mexico, Mexico City: +52 55 8421 0326 Mexico, Monterrey: +52 81 4162 5648 Mexico (toll free): 01 800 733 4102 Morocco, Casablanca: +212 (0) 520 48 0022 Morocco (toll free): 0800 091 296 Netherlands, Amsterdam: +31 (0) 20 716 8345 Netherlands (toll free): 0800 020 2597 New Zealand, Christchurch: +64 (0) 3 974 2596 New Zealand, Wellington: +64 (0) 4 909 4674 New Zealand, Auckland: +64 (0) 9 929 1825 New Zealand (toll free): 0800 452 947 Nigeria, Lagos: +234 1 277 3944 Norway, Oslo: +47 21 00 48 15 Norway (toll free): 800 56081 Oman (toll free): 800 77265 Pakistan, Islamabad: +92 5181 08863 Panama, Panama City: +507 8 335 913 Panama (toll free): 00800 223 1390 Peru, Lima: +51 (0) 1 700 9571 Philippines, Manila: +63 (0)2 395 3426 Philippines (toll free): 1 800 111 013 99 Poland, Warsaw: +48 22 295 3570 Poland (toll free): 00 800 121 4356 Portugal, Lisbon: +351 21 316 4093 Portugal (toll free): 800 784 442 Qatar (freephone): 00 800 100 491 Romania, Bucharest: +40 (0) 21 529 3992 Romania (toll free): 0800 801 035 Russia, Moscow: +7 495 646 9181 Russia (toll free): 8 800 500 9241 Saudi Arabia (toll free): 800 844 6641 Saudi Arabia (toll free): 800 850 0219 Serbia (toll free): 0800 190 712 Singapore: +65 6654 9112 Singapore (toll free): 800 616 3192 Slovakia, Bratislava: +421 (0)2 3321 5498 Slovakia (toll free): 0800 002 002 Slovenia, Ljubljana: +386 1600 8695 Slovenia (toll free): 0800 81193 South Africa, Johannesburg: +27 (0)11 589 8321 South Africa (toll free): 0800 999 434 Spain, Madrid: +34 91 114 6653 Spain, Barcelona: +34 93 800 1946 Spain (toll free): 900 828 035 Sri Lanka, Sri Lanka: +94 720 910 333 Sweden, Stockholm: +46 (0) 8 5065 3956 Sweden (toll free): 0200 125 588 Switzerland, Geneva: +41 (0) 22 595 4795 Switzerland, Zurich: +41 (0) 44 580 7207 Switzerland (toll free): 0800 740 360 Taiwan, Taipei: +886 (0) 2 2650 7329 Taiwan (toll free): 0800 666 596 Thailand, Bangkok: +66 (0) 2104 0761 Thailand (toll free): 001 800 6136 1473 Tunisia, Tunis: +216 31 378 101 Turkey, Istanbul: +90 212 375 50 49 Turkey (toll free): 00800 4488 26642 Ukraine (toll free): 0800 500 896 UAE (toll free): 8000 3570 2662 UK (03): +44 (0)330 336 6002 UK (toll free): 0800 358 6385 UK (national): 0844 473 5010 UK (national): 0845 545 0015 USA /Canada (toll free): 1-866-398-2885 Uruguay (toll free): 0004 019 0152 Venezuela, Caracas: +58 212 720 2164 Venezuela (toll free): 0 800 162 7451 Vietnam, Hanoi: +84 24 4458 3312 Vietnam, Ho Chi Minh: +84 28 4458 1322 Vietnam (toll free): 1800 9226 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 11472 bytes Desc: not available URL: From mpsilvavalent at gmail.com Mon Dec 10 23:27:31 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Mon, 10 Dec 2018 18:27:31 -0300 Subject: [NCSG-PC] Meeting Invite: Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC In-Reply-To: <4A18A593-691C-4868-89AB-B174915E0783@icann.org> References: <4A18A593-691C-4868-89AB-B174915E0783@icann.org> Message-ID: <374A4C43-CC1A-4C2F-92D6-1CE3C5EA40A7@gmail.com> I won?t be able to make it, please send my regards. I will listen the audio and post any comments on the list. Ia m open for any comments as well via email. Best, Mart?n Silva > On 10 Dec 2018, at 10:24, Maryam Bakoshi wrote: > > Dear All, > > Please find participation details for the Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC > > Adobe Connect: https://participate.icann.org/ncsg > > Time Zones: https://tinyurl.com/y8efhvas > > Dial out request: please send an email to Maryam.bakoshi at icann.org offline. > > Audio dial-in details below: > > You're invited. > You've been invited to a GlobalMeet? audio meeting. > > Have the meeting call you. > Click the Connect Me link below. No need to dial-in. > > > Connect Me [go.conferencinghub.com] > Not at your computer? > You can join by dialing one of the access numbers below. > > Mobile: > tel://16054755604,*,,9922790467# > Phone Only Controls : > https://go.conferencinghub.com/2xdh7 > Access Number: > 1-605-475-5604 > Guest Passcode: > 992 279 0467 > Additional Access: > USA: > 1-605-475-5604 > USA: > 1-719-457-6209 > Canada, Calgary: > +1 403 407 5793 > Canada, Montreal: > +1 514 669 5928 > Canada, Toronto: > +1 647 426 9172 > Canada, Vancouver: > +1 604 222 7836 > Argentina, Buenos Aires: > +54 (0) 11 5172 6003 > Argentina (toll free): > 0800 800 1223 > Australia, Sydney: > +61 (0) 2 8017 6064 > Australia, Melbourne: > +61 (0) 3 8687 0553 > Australia, Brisbane: > +61 (0) 7 3015 0535 > Australia (toll free): > 1 800 804 786 > Austria (toll free): > 0800 070 981 > Bahrain, Manama: > +973 1619 8739 > Bahrain (toll free): > 800 04212 > Belarus (toll free): > 8 820 0011 0341 > Belgium, Brussels: > +32 (0) 2 400 6928 > Belgium (toll free): > 0800 39279 > Bosnia and Herzegovina: > +387 7031 1442 > Brazil, Sao Paulo: > +55 11 4935 7169 > Brazil, Rio de Janeiro: > +55 21 4560 0072 > Brazil (toll free): > 0800 887 0233 > Bulgaria, Sofia: > +359 (0) 2 491 6045 > Bulgaria (toll free): > 00800 111 4950 > Cambodia, Phnom Penh: > +855 23 965 723 > Canada (toll free): > 1 855 950 3717 > Chile, Santiago: > +56 (0) 2 2666 0696 > Chile (toll free): > 171 800 835 783 > China (national): > +400 613 8103 > China, Beijing: > +86 10 5667 0003 > China, Shanghai: > +86 21 2039 7081 > Colombia, Bogota: > +57 1 508 8137 > Colombia (toll free): > 01 800 755 0102 > Costa Rica (toll free): > 800 542 5328 > Croatia (toll free): > 0800 805 940 > Cyprus (toll free): > 800 97424 > Czech Republic, Prague: > +420 225 986 554 > Czech Republic (toll free): > 800 701 532 > Denmark, Copenhagen: > +45 32 72 78 10 > Denmark (toll free): > 80 70 35 86 > Egypt (toll free): > 0800 000 0593 > Estonia, Tallinn: > +372 622 6551 > Estonia (toll free): > 800 011 1589 > Fiji (toll free): > 00800 3322 > Finland, Helsinki: > +358 (0) 9 2310 1677 > Finland (toll free): > 0800 772 236 > France, Paris: > +33 (0) 1 70 37 16 56 > France (toll free): > 0800 946 531 > France (national): > 0811 655 100 > France (national): > 0821 231 671 > Georgia, Tbilisi: > +995 32 2 050 778 > Germany, Frankfurt: > +49 (0) 69 2222 10612 > Germany, Munich: > +49 (0) 89 2030 31207 > Germany (national): > 01801 003 899 > Germany (toll free): > 0800 588 9170 > Greece, Athens: > +30 211 181 3824 > Greece (toll free): > 00800 128 913 > Hong Kong: > +852 3018 9111 > Hong Kong (toll free): > 800 901 787 > Hungary, Budapest: > +36 1408 8953 > Hungary (toll free): > 068 001 9673 > Iceland (toll free): > 800 9847 > India, Delhi: > +91 11 6310 0268 > India, Mumbai: > +91 22 6310 0298 > India, Chennai: > +91 44 6310 0234 > India, Bangalore: > +91 80 6760 8755 > India (toll free): > 1800 3010 1582 > Indonesia, Jakarta: > +62 21 2188 9084 > Indonesia (toll free): > 007 803 321 8927 > Ireland, Dublin: > +353 (0) 1 526 9421 > Ireland (national): > 0818 270 271 > Ireland (toll free): > 1800 937 649 > Ireland (national): > 1890 907 630 > Israel, Tel Aviv: > +972 (0)3 721 7943 > Israel (toll free): > 1809 213 168 > Italy, Milan: > +39 02 3600 8006 > Italy, Rome: > +39 06 8750 0676 > Italy (toll free): > 800 146 094 > Japan, Tokyo: > +81 3 4560 1270 > Japan, Osaka: > +81 6 4560 2410 > Japan (toll free): > 0120 305 211 > Japan (mobile): > 0120 632 611 > Japan (national): > 0570 085 744 > Jordan (toll free): > 0800 22172 > Kazakhstan (toll free): > 8800 333 7554 > Kenya, Nairobi: > +254 (0)207 643 581 > South Korea, Seoul: > +82 (0) 2 6007 0079 > South Korea (toll free): > 00798 6136 1454 > Kuwait (national): > +965 2206 3002 > Latvia, Riga: > +371 6601 3627 > Latvia (toll free): > 8000 4418 > Lithuania, Vilnius: > +370 5205 5468 > Lithuania (toll free): > 8800 31449 > Luxembourg: > +352 2088 1749 > Luxembourg (toll free): > 800 28433 > Macau (national): > +853 6262 1676 > Malaysia, Kuala Lumpur: > +60 (0) 3 7724 8010 > Malaysia (toll free): > 1 800 816 152 > Mexico, Guadalajara: > +52 33 4162 4504 > Mexico, Mexico City: > +52 55 8421 0326 > Mexico, Monterrey: > +52 81 4162 5648 > Mexico (toll free): > 01 800 733 4102 > Morocco, Casablanca: > +212 (0) 520 48 0022 > Morocco (toll free): > 0800 091 296 > Netherlands, Amsterdam: > +31 (0) 20 716 8345 > Netherlands (toll free): > 0800 020 2597 > New Zealand, Christchurch: > +64 (0) 3 974 2596 > New Zealand, Wellington: > +64 (0) 4 909 4674 > New Zealand, Auckland: > +64 (0) 9 929 1825 > New Zealand (toll free): > 0800 452 947 > Nigeria, Lagos: > +234 1 277 3944 > Norway, Oslo: > +47 21 00 48 15 > Norway (toll free): > 800 56081 > Oman (toll free): > 800 77265 > Pakistan, Islamabad: > +92 5181 08863 > Panama, Panama City: > +507 8 335 913 > Panama (toll free): > 00800 223 1390 > Peru, Lima: > +51 (0) 1 700 9571 > Philippines, Manila: > +63 (0)2 395 3426 > Philippines (toll free): > 1 800 111 013 99 > Poland, Warsaw: > +48 22 295 3570 > Poland (toll free): > 00 800 121 4356 > Portugal, Lisbon: > +351 21 316 4093 > Portugal (toll free): > 800 784 442 > Qatar (freephone): > 00 800 100 491 > Romania, Bucharest: > +40 (0) 21 529 3992 > Romania (toll free): > 0800 801 035 > Russia, Moscow: > +7 495 646 9181 > Russia (toll free): > 8 800 500 9241 > Saudi Arabia (toll free): > 800 844 6641 > Saudi Arabia (toll free): > 800 850 0219 > Serbia (toll free): > 0800 190 712 > Singapore: > +65 6654 9112 > Singapore (toll free): > 800 616 3192 > Slovakia, Bratislava: > +421 (0)2 3321 5498 > Slovakia (toll free): > 0800 002 002 > Slovenia, Ljubljana: > +386 1600 8695 > Slovenia (toll free): > 0800 81193 > South Africa, Johannesburg: > +27 (0)11 589 8321 > South Africa (toll free): > 0800 999 434 > Spain, Madrid: > +34 91 114 6653 > Spain, Barcelona: > +34 93 800 1946 > Spain (toll free): > 900 828 035 > Sri Lanka, Sri Lanka: > +94 720 910 333 > Sweden, Stockholm: > +46 (0) 8 5065 3956 > Sweden (toll free): > 0200 125 588 > Switzerland, Geneva: > +41 (0) 22 595 4795 > Switzerland, Zurich: > +41 (0) 44 580 7207 > Switzerland (toll free): > 0800 740 360 > Taiwan, Taipei: > +886 (0) 2 2650 7329 > Taiwan (toll free): > 0800 666 596 > Thailand, Bangkok: > +66 (0) 2104 0761 > Thailand (toll free): > 001 800 6136 1473 > Tunisia, Tunis: > +216 31 378 101 > Turkey, Istanbul: > +90 212 375 50 49 > Turkey (toll free): > 00800 4488 26642 > Ukraine (toll free): > 0800 500 896 > UAE (toll free): > 8000 3570 2662 > UK (03): > +44 (0)330 336 6002 > UK (toll free): > 0800 358 6385 > UK (national): > 0844 473 5010 > UK (national): > 0845 545 0015 > USA /Canada (toll free): > 1-866-398-2885 > Uruguay (toll free): > 0004 019 0152 > Venezuela, Caracas: > +58 212 720 2164 > Venezuela (toll free): > 0 800 162 7451 > Vietnam, Hanoi: > +84 24 4458 3312 > Vietnam, Ho Chi Minh: > +84 28 4458 1322 > Vietnam (toll free): > 1800 9226 > > > > > > > > -- > Many thanks, > > Maryam Bakoshi | SO/AC Collaboration Services Sr. Coordinator > ICANN | Internet Corporation got Assigned Names and Numbers > S: Maryam.bakoshi.icann | T: +44 7846 471777 > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Tue Dec 11 08:33:12 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Tue, 11 Dec 2018 15:33:12 +0900 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: Hi, no problem with removing the part about access to funds. however, regarding the options, those who commented in the doc or in the NCSG list supported option B so I don't see how we can solely support option C only. Best, Rafik Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent < mpsilvavalent at gmail.com> a ?crit : > I have to agree with Ayden, the more shielded those funds are, the better, > is too much money and really needs to be used 1) only in a financialy > sustainable way, 2) in charitable projects. The 1) one is more easily > accountable, but the latter really needs as independent and accountable > process as it can get. > > > Best, > Mart?n > > > On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline >> Thanks, Rafik. I have been further reflecting on this comment and believe >> we need to revise Recommendation #1 to take a stronger position. I do not >> support either Mechanism A or B, and would prefer to see us support solely >> Mechanism C. This is because an independent ICANN Foundation with its own, >> independent Board of Directors would be more accountable than anything >> Mechanisms A (utterly unaccountable) or B (weak accountability structure) >> can offer. >> >> I have also deleted an edit that said ICANN org should be able to access >> auction proceeds if it goes through a community consultation process. I do >> not support this at all, and think it contradicts the rest of our comment >> where we speak to how funds were supposed to be sequested for charitable >> purposes. >> >> Best wishes, Ayden >> >> ??????? Original Message ??????? >> On Saturday, 8 December 2018 23:49, Rafik Dammak >> wrote: >> >> Hi all, >> >> with some delay, I could finally go through the draft and makes edits >> based on comments: >> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. >> I left the document on suggestion-mode to highlight the changes. I closed >> some comments that didn't lead to any change (you can still check them). >> the deadline for submission is the 11th December. please review the >> comment. >> >> Best, >> >> Rafik >> >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Tue Dec 11 11:41:23 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Tue, 11 Dec 2018 09:41:23 +0000 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: I have yet to hear a strong reason for supporting Mechanism B - what is the rationale for it? There has not been a lot of engagement on the list on this topic either, so I do not agree that there is a consensus that we should be supporting that dispersement mechanism. Ayden ??????? Original Message ??????? On Tuesday, 11 December 2018 01:33, Rafik Dammak wrote: > Hi, > > no problem with removing the part about access to funds. > however, regarding the options, those who commented in the doc or in the NCSG list supported option B so I don't see how we can solely support option C only. > > Best, > > Rafik > > Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent a ?crit : > >> I have to agree with Ayden, the more shielded those funds are, the better, is too much money and really needs to be used 1) only in a financialy sustainable way, 2) in charitable projects. The 1) one is more easily accountable, but the latter really needs as independent and accountable process as it can get. >> >> Best, >> Mart?n >> >> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline > >>> Thanks, Rafik. I have been further reflecting on this comment and believe we need to revise Recommendation #1 to take a stronger position. I do not support either Mechanism A or B, and would prefer to see us support solely Mechanism C. This is because an independent ICANN Foundation with its own, independent Board of Directors would be more accountable than anything Mechanisms A (utterly unaccountable) or B (weak accountability structure) can offer. >>> >>> I have also deleted an edit that said ICANN org should be able to access auction proceeds if it goes through a community consultation process. I do not support this at all, and think it contradicts the rest of our comment where we speak to how funds were supposed to be sequested for charitable purposes. >>> >>> Best wishes, Ayden >>> >>> ??????? Original Message ??????? >>> On Saturday, 8 December 2018 23:49, Rafik Dammak wrote: >>> >>>> Hi all, >>>> >>>> with some delay, I could finally go through the draft and makes edits based on comments: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. I left the document on suggestion-mode to highlight the changes. I closed some comments that didn't lead to any change (you can still check them). >>>> the deadline for submission is the 11th December. please review the comment. >>>> >>>> Best, >>>> >>>> Rafik >>> >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at davecake.net Tue Dec 11 12:59:49 2018 From: dave at davecake.net (David Cake) Date: Tue, 11 Dec 2018 21:59:49 +1100 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: I generally agree with Ayden and Martin - It will be better to have the funds administered in such a way that ICANN does dip into them for its own purposes. David > On 11 Dec 2018, at 8:41 pm, Ayden F?rdeline wrote: > > I have yet to hear a strong reason for supporting Mechanism B - what is the rationale for it? There has not been a lot of engagement on the list on this topic either, so I do not agree that there is a consensus that we should be supporting that dispersement mechanism. > > Ayden > > > ??????? Original Message ??????? > On Tuesday, 11 December 2018 01:33, Rafik Dammak wrote: > >> Hi, >> >> no problem with removing the part about access to funds. >> however, regarding the options, those who commented in the doc or in the NCSG list supported option B so I don't see how we can solely support option C only. >> >> Best, >> >> Rafik >> >> >> Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent > a ?crit : >> I have to agree with Ayden, the more shielded those funds are, the better, is too much money and really needs to be used 1) only in a financialy sustainable way, 2) in charitable projects. The 1) one is more easily accountable, but the latter really needs as independent and accountable process as it can get. >> >> >> Best, >> Mart?n >> >> >> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline wrote: >> Thanks, Rafik. I have been further reflecting on this comment and believe we need to revise Recommendation #1 to take a stronger position. I do not support either Mechanism A or B, and would prefer to see us support solely Mechanism C. This is because an independent ICANN Foundation with its own, independent Board of Directors would be more accountable than anything Mechanisms A (utterly unaccountable) or B (weak accountability structure) can offer. >> >> I have also deleted an edit that said ICANN org should be able to access auction proceeds if it goes through a community consultation process. I do not support this at all, and think it contradicts the rest of our comment where we speak to how funds were supposed to be sequested for charitable purposes. >> >> Best wishes, Ayden >> >> ??????? Original Message ??????? >> On Saturday, 8 December 2018 23:49, Rafik Dammak > wrote: >> >>> Hi all, >>> >>> with some delay, I could finally go through the draft and makes edits based on comments: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit . I left the document on suggestion-mode to highlight the changes. I closed some comments that didn't lead to any change (you can still check them). >>> the deadline for submission is the 11th December. please review the comment. >>> >>> Best, >>> >>> Rafik >>> >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Tue Dec 11 15:51:59 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Tue, 11 Dec 2018 22:51:59 +0900 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: Hi, I don't think the point here is about we being convinced or not and so defending our own positions (if for example, I say I am supporting option B only?)). The few comments we got were supporting option B. I see some support here for option C on PC only. I am concerned about such change in the last minute and. Previous wording offer support for the 2 options as we don't have a clear consensus. if other PC members support option C, they can weigh in and so that clearly is in the record @Martin @David sorry to re-ask as your responses are not quite explicit, you are supporting option C? Best, Rafik Le mar. 11 d?c. 2018 ? 18:41, Ayden F?rdeline a ?crit : > I have yet to hear a strong reason for supporting Mechanism B - what is > the rationale for it? There has not been a lot of engagement on the list on > this topic either, so I do not agree that there is a consensus that we > should be supporting that dispersement mechanism. > > Ayden > > > ??????? Original Message ??????? > On Tuesday, 11 December 2018 01:33, Rafik Dammak > wrote: > > Hi, > > no problem with removing the part about access to funds. > however, regarding the options, those who commented in the doc or in the > NCSG list supported option B so I don't see how we can solely support > option C only. > > Best, > > Rafik > > > Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent < > mpsilvavalent at gmail.com> a ?crit : > >> I have to agree with Ayden, the more shielded those funds are, the >> better, is too much money and really needs to be used 1) only in a >> financialy sustainable way, 2) in charitable projects. The 1) one is more >> easily accountable, but the latter really needs as independent and >> accountable process as it can get. >> >> >> Best, >> Mart?n >> >> >> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline > >>> Thanks, Rafik. I have been further reflecting on this comment and >>> believe we need to revise Recommendation #1 to take a stronger position. I >>> do not support either Mechanism A or B, and would prefer to see us support >>> solely Mechanism C. This is because an independent ICANN Foundation with >>> its own, independent Board of Directors would be more accountable than >>> anything Mechanisms A (utterly unaccountable) or B (weak accountability >>> structure) can offer. >>> >>> I have also deleted an edit that said ICANN org should be able to access >>> auction proceeds if it goes through a community consultation process. I do >>> not support this at all, and think it contradicts the rest of our comment >>> where we speak to how funds were supposed to be sequested for charitable >>> purposes. >>> >>> Best wishes, Ayden >>> >>> ??????? Original Message ??????? >>> On Saturday, 8 December 2018 23:49, Rafik Dammak >>> wrote: >>> >>> Hi all, >>> >>> with some delay, I could finally go through the draft and makes edits >>> based on comments: >>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. >>> I left the document on suggestion-mode to highlight the changes. I closed >>> some comments that didn't lead to any change (you can still check them). >>> the deadline for submission is the 11th December. please review the >>> comment. >>> >>> Best, >>> >>> Rafik >>> >>> >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsilvavalent at gmail.com Tue Dec 11 15:57:05 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Tue, 11 Dec 2018 10:57:05 -0300 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: I do support mechanism c. Best, Mart?n On Tue, Dec 11, 2018, 10:52 Rafik Dammak Hi, > > I don't think the point here is about we being convinced or not and so > defending our own positions (if for example, I say I am supporting option B > only?)). The few comments we got were supporting option B. I see some > support here for option C on PC only. I am concerned about such change in > the last minute and. Previous wording offer support for the 2 options as we > don't have a clear consensus. > if other PC members support option C, they can weigh in and so that > clearly is in the record > @Martin @David sorry to re-ask as your responses are not quite explicit, > you are supporting option C? > > Best, > > Rafik > > Le mar. 11 d?c. 2018 ? 18:41, Ayden F?rdeline a > ?crit : > >> I have yet to hear a strong reason for supporting Mechanism B - what is >> the rationale for it? There has not been a lot of engagement on the list on >> this topic either, so I do not agree that there is a consensus that we >> should be supporting that dispersement mechanism. >> >> Ayden >> >> >> ??????? Original Message ??????? >> On Tuesday, 11 December 2018 01:33, Rafik Dammak >> wrote: >> >> Hi, >> >> no problem with removing the part about access to funds. >> however, regarding the options, those who commented in the doc or in the >> NCSG list supported option B so I don't see how we can solely support >> option C only. >> >> Best, >> >> Rafik >> >> >> Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent < >> mpsilvavalent at gmail.com> a ?crit : >> >>> I have to agree with Ayden, the more shielded those funds are, the >>> better, is too much money and really needs to be used 1) only in a >>> financialy sustainable way, 2) in charitable projects. The 1) one is more >>> easily accountable, but the latter really needs as independent and >>> accountable process as it can get. >>> >>> >>> Best, >>> Mart?n >>> >>> >>> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline >> >>>> Thanks, Rafik. I have been further reflecting on this comment and >>>> believe we need to revise Recommendation #1 to take a stronger position. I >>>> do not support either Mechanism A or B, and would prefer to see us support >>>> solely Mechanism C. This is because an independent ICANN Foundation with >>>> its own, independent Board of Directors would be more accountable than >>>> anything Mechanisms A (utterly unaccountable) or B (weak accountability >>>> structure) can offer. >>>> >>>> I have also deleted an edit that said ICANN org should be able to >>>> access auction proceeds if it goes through a community consultation >>>> process. I do not support this at all, and think it contradicts the rest of >>>> our comment where we speak to how funds were supposed to be sequested for >>>> charitable purposes. >>>> >>>> Best wishes, Ayden >>>> >>>> ??????? Original Message ??????? >>>> On Saturday, 8 December 2018 23:49, Rafik Dammak < >>>> rafik.dammak at gmail.com> wrote: >>>> >>>> Hi all, >>>> >>>> with some delay, I could finally go through the draft and makes edits >>>> based on comments: >>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. >>>> I left the document on suggestion-mode to highlight the changes. I closed >>>> some comments that didn't lead to any change (you can still check them). >>>> the deadline for submission is the 11th December. please review the >>>> comment. >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> >>>> _______________________________________________ >>>> NCSG-PC mailing list >>>> NCSG-PC at lists.ncsg.is >>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsilvavalent at gmail.com Tue Dec 11 16:03:22 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Tue, 11 Dec 2018 11:03:22 -0300 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: I would understand if we have to be more open since this is a last, big, minute change. Martin On Tue, Dec 11, 2018, 10:57 Martin Pablo Silva Valent < mpsilvavalent at gmail.com wrote: > I do support mechanism c. > > Best, > Mart?n > > > On Tue, Dec 11, 2018, 10:52 Rafik Dammak >> Hi, >> >> I don't think the point here is about we being convinced or not and so >> defending our own positions (if for example, I say I am supporting option B >> only?)). The few comments we got were supporting option B. I see some >> support here for option C on PC only. I am concerned about such change in >> the last minute and. Previous wording offer support for the 2 options as we >> don't have a clear consensus. >> if other PC members support option C, they can weigh in and so that >> clearly is in the record >> @Martin @David sorry to re-ask as your responses are not quite explicit, >> you are supporting option C? >> >> Best, >> >> Rafik >> >> Le mar. 11 d?c. 2018 ? 18:41, Ayden F?rdeline a >> ?crit : >> >>> I have yet to hear a strong reason for supporting Mechanism B - what is >>> the rationale for it? There has not been a lot of engagement on the list on >>> this topic either, so I do not agree that there is a consensus that we >>> should be supporting that dispersement mechanism. >>> >>> Ayden >>> >>> >>> ??????? Original Message ??????? >>> On Tuesday, 11 December 2018 01:33, Rafik Dammak >>> wrote: >>> >>> Hi, >>> >>> no problem with removing the part about access to funds. >>> however, regarding the options, those who commented in the doc or in the >>> NCSG list supported option B so I don't see how we can solely support >>> option C only. >>> >>> Best, >>> >>> Rafik >>> >>> >>> Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent < >>> mpsilvavalent at gmail.com> a ?crit : >>> >>>> I have to agree with Ayden, the more shielded those funds are, the >>>> better, is too much money and really needs to be used 1) only in a >>>> financialy sustainable way, 2) in charitable projects. The 1) one is more >>>> easily accountable, but the latter really needs as independent and >>>> accountable process as it can get. >>>> >>>> >>>> Best, >>>> Mart?n >>>> >>>> >>>> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline >>> >>>>> Thanks, Rafik. I have been further reflecting on this comment and >>>>> believe we need to revise Recommendation #1 to take a stronger position. I >>>>> do not support either Mechanism A or B, and would prefer to see us support >>>>> solely Mechanism C. This is because an independent ICANN Foundation with >>>>> its own, independent Board of Directors would be more accountable than >>>>> anything Mechanisms A (utterly unaccountable) or B (weak accountability >>>>> structure) can offer. >>>>> >>>>> I have also deleted an edit that said ICANN org should be able to >>>>> access auction proceeds if it goes through a community consultation >>>>> process. I do not support this at all, and think it contradicts the rest of >>>>> our comment where we speak to how funds were supposed to be sequested for >>>>> charitable purposes. >>>>> >>>>> Best wishes, Ayden >>>>> >>>>> ??????? Original Message ??????? >>>>> On Saturday, 8 December 2018 23:49, Rafik Dammak < >>>>> rafik.dammak at gmail.com> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> with some delay, I could finally go through the draft and makes edits >>>>> based on comments: >>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. >>>>> I left the document on suggestion-mode to highlight the changes. I closed >>>>> some comments that didn't lead to any change (you can still check them). >>>>> the deadline for submission is the 11th December. please review the >>>>> comment. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> >>>>> >>>>> _______________________________________________ >>>>> NCSG-PC mailing list >>>>> NCSG-PC at lists.ncsg.is >>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Tue Dec 11 18:14:01 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Wed, 12 Dec 2018 01:14:01 +0900 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: Hi, Edits were accepted. Deadline is few hours away. Best, Rafik On Tue, Dec 11, 2018, 23:03 Martin Pablo Silva Valent < mpsilvavalent at gmail.com wrote: > I would understand if we have to be more open since this is a last, big, > minute change. > > Martin > > On Tue, Dec 11, 2018, 10:57 Martin Pablo Silva Valent < > mpsilvavalent at gmail.com wrote: > >> I do support mechanism c. >> >> Best, >> Mart?n >> >> >> On Tue, Dec 11, 2018, 10:52 Rafik Dammak > >>> Hi, >>> >>> I don't think the point here is about we being convinced or not and so >>> defending our own positions (if for example, I say I am supporting option B >>> only?)). The few comments we got were supporting option B. I see some >>> support here for option C on PC only. I am concerned about such change in >>> the last minute and. Previous wording offer support for the 2 options as we >>> don't have a clear consensus. >>> if other PC members support option C, they can weigh in and so that >>> clearly is in the record >>> @Martin @David sorry to re-ask as your responses are not quite explicit, >>> you are supporting option C? >>> >>> Best, >>> >>> Rafik >>> >>> Le mar. 11 d?c. 2018 ? 18:41, Ayden F?rdeline a >>> ?crit : >>> >>>> I have yet to hear a strong reason for supporting Mechanism B - what is >>>> the rationale for it? There has not been a lot of engagement on the list on >>>> this topic either, so I do not agree that there is a consensus that we >>>> should be supporting that dispersement mechanism. >>>> >>>> Ayden >>>> >>>> >>>> ??????? Original Message ??????? >>>> On Tuesday, 11 December 2018 01:33, Rafik Dammak < >>>> rafik.dammak at gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> no problem with removing the part about access to funds. >>>> however, regarding the options, those who commented in the doc or in >>>> the NCSG list supported option B so I don't see how we can solely support >>>> option C only. >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> >>>> Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent < >>>> mpsilvavalent at gmail.com> a ?crit : >>>> >>>>> I have to agree with Ayden, the more shielded those funds are, the >>>>> better, is too much money and really needs to be used 1) only in a >>>>> financialy sustainable way, 2) in charitable projects. The 1) one is more >>>>> easily accountable, but the latter really needs as independent and >>>>> accountable process as it can get. >>>>> >>>>> >>>>> Best, >>>>> Mart?n >>>>> >>>>> >>>>> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline >>>> >>>>>> Thanks, Rafik. I have been further reflecting on this comment and >>>>>> believe we need to revise Recommendation #1 to take a stronger position. I >>>>>> do not support either Mechanism A or B, and would prefer to see us support >>>>>> solely Mechanism C. This is because an independent ICANN Foundation with >>>>>> its own, independent Board of Directors would be more accountable than >>>>>> anything Mechanisms A (utterly unaccountable) or B (weak accountability >>>>>> structure) can offer. >>>>>> >>>>>> I have also deleted an edit that said ICANN org should be able to >>>>>> access auction proceeds if it goes through a community consultation >>>>>> process. I do not support this at all, and think it contradicts the rest of >>>>>> our comment where we speak to how funds were supposed to be sequested for >>>>>> charitable purposes. >>>>>> >>>>>> Best wishes, Ayden >>>>>> >>>>>> ??????? Original Message ??????? >>>>>> On Saturday, 8 December 2018 23:49, Rafik Dammak < >>>>>> rafik.dammak at gmail.com> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> with some delay, I could finally go through the draft and makes edits >>>>>> based on comments: >>>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. >>>>>> I left the document on suggestion-mode to highlight the changes. I closed >>>>>> some comments that didn't lead to any change (you can still check them). >>>>>> the deadline for submission is the 11th December. please review the >>>>>> comment. >>>>>> >>>>>> Best, >>>>>> >>>>>> Rafik >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> NCSG-PC mailing list >>>>>> NCSG-PC at lists.ncsg.is >>>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>>>> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephanie at digitaldiscretion.ca Tue Dec 11 18:32:51 2018 From: stephanie at digitaldiscretion.ca (Stephanie Perrin) Date: Tue, 11 Dec 2018 11:32:51 -0500 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: <2D61803F-EA71-4BF7-83E0-9286D9B32807@digitaldiscretion.ca> I support this view on both issues Sent from my iPhone > On Dec 9, 2018, at 8:27 PM, Ayden F?rdeline wrote: > > Thanks, Rafik. I have been further reflecting on this comment and believe we need to revise Recommendation #1 to take a stronger position. I do not support either Mechanism A or B, and would prefer to see us support solely Mechanism C. This is because an independent ICANN Foundation with its own, independent Board of Directors would be more accountable than anything Mechanisms A (utterly unaccountable) or B (weak accountability structure) can offer. > > I have also deleted an edit that said ICANN org should be able to access auction proceeds if it goes through a community consultation process. I do not support this at all, and think it contradicts the rest of our comment where we speak to how funds were supposed to be sequested for charitable purposes. > > Best wishes, Ayden > > ??????? Original Message ??????? >> On Saturday, 8 December 2018 23:49, Rafik Dammak wrote: >> >> Hi all, >> >> with some delay, I could finally go through the draft and makes edits based on comments: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. I left the document on suggestion-mode to highlight the changes. I closed some comments that didn't lead to any change (you can still check them). >> the deadline for submission is the 11th December. please review the comment. >> >> Best, >> >> Rafik >> > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephanie at digitaldiscretion.ca Tue Dec 11 18:35:41 2018 From: stephanie at digitaldiscretion.ca (Stephanie Perrin) Date: Tue, 11 Dec 2018 11:35:41 -0500 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: <71AD0A8E-E2CA-4F60-88B6-C61AB549DD47@digitaldiscretion.ca> Me too Sent from my iPhone > On Dec 11, 2018, at 8:57 AM, Martin Pablo Silva Valent wrote: > > I do support mechanism c. > > Best, > Mart?n > > >> On Tue, Dec 11, 2018, 10:52 Rafik Dammak > Hi, >> >> I don't think the point here is about we being convinced or not and so defending our own positions (if for example, I say I am supporting option B only?)). The few comments we got were supporting option B. I see some support here for option C on PC only. I am concerned about such change in the last minute and. Previous wording offer support for the 2 options as we don't have a clear consensus. >> if other PC members support option C, they can weigh in and so that clearly is in the record >> @Martin @David sorry to re-ask as your responses are not quite explicit, you are supporting option C? >> >> Best, >> >> Rafik >> >>> Le mar. 11 d?c. 2018 ? 18:41, Ayden F?rdeline a ?crit : >>> I have yet to hear a strong reason for supporting Mechanism B - what is the rationale for it? There has not been a lot of engagement on the list on this topic either, so I do not agree that there is a consensus that we should be supporting that dispersement mechanism. >>> >>> Ayden >>> >>> >>> ??????? Original Message ??????? >>>> On Tuesday, 11 December 2018 01:33, Rafik Dammak wrote: >>>> >>>> Hi, >>>> >>>> no problem with removing the part about access to funds. >>>> however, regarding the options, those who commented in the doc or in the NCSG list supported option B so I don't see how we can solely support option C only. >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> >>>>> Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent a ?crit : >>>>> I have to agree with Ayden, the more shielded those funds are, the better, is too much money and really needs to be used 1) only in a financialy sustainable way, 2) in charitable projects. The 1) one is more easily accountable, but the latter really needs as independent and accountable process as it can get. >>>>> >>>>> >>>>> Best, >>>>> Mart?n >>>>> >>>>> >>>>>> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline >>>>> Thanks, Rafik. I have been further reflecting on this comment and believe we need to revise Recommendation #1 to take a stronger position. I do not support either Mechanism A or B, and would prefer to see us support solely Mechanism C. This is because an independent ICANN Foundation with its own, independent Board of Directors would be more accountable than anything Mechanisms A (utterly unaccountable) or B (weak accountability structure) can offer. >>>>>> >>>>>> I have also deleted an edit that said ICANN org should be able to access auction proceeds if it goes through a community consultation process. I do not support this at all, and think it contradicts the rest of our comment where we speak to how funds were supposed to be sequested for charitable purposes. >>>>>> >>>>>> Best wishes, Ayden >>>>>> >>>>>> ??????? Original Message ??????? >>>>>>> On Saturday, 8 December 2018 23:49, Rafik Dammak wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> with some delay, I could finally go through the draft and makes edits based on comments: https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. I left the document on suggestion-mode to highlight the changes. I closed some comments that didn't lead to any change (you can still check them). >>>>>>> the deadline for submission is the 11th December. please review the comment. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Rafik >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> NCSG-PC mailing list >>>>>> NCSG-PC at lists.ncsg.is >>>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Wed Dec 12 01:06:39 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Wed, 12 Dec 2018 08:06:39 +0900 Subject: [NCSG-PC] Auctions proceeds comment review (deadline 11th Dec) In-Reply-To: References: <-wHzDdmec7EVkC52q0TIgTIWJSqxMgtdQOXkF5xie8kpNbEvaMGanRxnXpWoGKuwqE3PZyLh7p4hEtExT08Z_xufwVUz_2wM9Xae3vf88fw=@ferdeline.com> Message-ID: Hi all, please find attached the final version. I resolved the edit to support option C. as there was no objection, but basically support for the option, I will submit the comment. Best, Rafik Le mer. 12 d?c. 2018 ? 01:14, Rafik Dammak a ?crit : > Hi, > > Edits were accepted. Deadline is few hours away. > > Best, > > Rafik > > On Tue, Dec 11, 2018, 23:03 Martin Pablo Silva Valent < > mpsilvavalent at gmail.com wrote: > >> I would understand if we have to be more open since this is a last, big, >> minute change. >> >> Martin >> >> On Tue, Dec 11, 2018, 10:57 Martin Pablo Silva Valent < >> mpsilvavalent at gmail.com wrote: >> >>> I do support mechanism c. >>> >>> Best, >>> Mart?n >>> >>> >>> On Tue, Dec 11, 2018, 10:52 Rafik Dammak >> >>>> Hi, >>>> >>>> I don't think the point here is about we being convinced or not and so >>>> defending our own positions (if for example, I say I am supporting option B >>>> only?)). The few comments we got were supporting option B. I see some >>>> support here for option C on PC only. I am concerned about such change in >>>> the last minute and. Previous wording offer support for the 2 options as we >>>> don't have a clear consensus. >>>> if other PC members support option C, they can weigh in and so that >>>> clearly is in the record >>>> @Martin @David sorry to re-ask as your responses are not quite >>>> explicit, you are supporting option C? >>>> >>>> Best, >>>> >>>> Rafik >>>> >>>> Le mar. 11 d?c. 2018 ? 18:41, Ayden F?rdeline a >>>> ?crit : >>>> >>>>> I have yet to hear a strong reason for supporting Mechanism B - what >>>>> is the rationale for it? There has not been a lot of engagement on the list >>>>> on this topic either, so I do not agree that there is a consensus that we >>>>> should be supporting that dispersement mechanism. >>>>> >>>>> Ayden >>>>> >>>>> >>>>> ??????? Original Message ??????? >>>>> On Tuesday, 11 December 2018 01:33, Rafik Dammak < >>>>> rafik.dammak at gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> no problem with removing the part about access to funds. >>>>> however, regarding the options, those who commented in the doc or in >>>>> the NCSG list supported option B so I don't see how we can solely support >>>>> option C only. >>>>> >>>>> Best, >>>>> >>>>> Rafik >>>>> >>>>> >>>>> Le lun. 10 d?c. 2018 ? 19:38, Martin Pablo Silva Valent < >>>>> mpsilvavalent at gmail.com> a ?crit : >>>>> >>>>>> I have to agree with Ayden, the more shielded those funds are, the >>>>>> better, is too much money and really needs to be used 1) only in a >>>>>> financialy sustainable way, 2) in charitable projects. The 1) one is more >>>>>> easily accountable, but the latter really needs as independent and >>>>>> accountable process as it can get. >>>>>> >>>>>> >>>>>> Best, >>>>>> Mart?n >>>>>> >>>>>> >>>>>> On Sun, Dec 9, 2018, 22:28 Ayden F?rdeline >>>>> wrote: >>>>>> >>>>>>> Thanks, Rafik. I have been further reflecting on this comment and >>>>>>> believe we need to revise Recommendation #1 to take a stronger position. I >>>>>>> do not support either Mechanism A or B, and would prefer to see us support >>>>>>> solely Mechanism C. This is because an independent ICANN Foundation with >>>>>>> its own, independent Board of Directors would be more accountable than >>>>>>> anything Mechanisms A (utterly unaccountable) or B (weak accountability >>>>>>> structure) can offer. >>>>>>> >>>>>>> I have also deleted an edit that said ICANN org should be able to >>>>>>> access auction proceeds if it goes through a community consultation >>>>>>> process. I do not support this at all, and think it contradicts the rest of >>>>>>> our comment where we speak to how funds were supposed to be sequested for >>>>>>> charitable purposes. >>>>>>> >>>>>>> Best wishes, Ayden >>>>>>> >>>>>>> ??????? Original Message ??????? >>>>>>> On Saturday, 8 December 2018 23:49, Rafik Dammak < >>>>>>> rafik.dammak at gmail.com> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> with some delay, I could finally go through the draft and makes >>>>>>> edits based on comments: >>>>>>> https://docs.google.com/document/d/1XL_KZuzd9TD8w74mndklzpHLV37MYrJdGPbW5Ucn0ao/edit. >>>>>>> I left the document on suggestion-mode to highlight the changes. I closed >>>>>>> some comments that didn't lead to any change (you can still check them). >>>>>>> the deadline for submission is the 11th December. please review the >>>>>>> comment. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Rafik >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> NCSG-PC mailing list >>>>>>> NCSG-PC at lists.ncsg.is >>>>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>>>>> >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Initial Report of the New gTLD Auction Proceeds Cross-Community Working Group - NCSG comment.pdf Type: application/pdf Size: 116060 bytes Desc: not available URL: From rafik.dammak at gmail.com Fri Dec 14 03:10:49 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Fri, 14 Dec 2018 10:10:49 +0900 Subject: [NCSG-PC] Draft Agenda for NCSG Monthly Policy Call 20th December In-Reply-To: References: Message-ID: Hi, I am sharing the draft agenda for our NCSG policy call next Monday and highlighting the topics we should focus on. EPDP will be covered substantively as we will be close to the public comment deadline. It will be also a good opportunity to give some updates from EPDP team representatives. We will also discuss the response to Board letter on EPDP and plan B to GNSO council. We also have the IGO-INGO topic again in the agenda. Council leadership will work on proposing a framework to move forward. I can tell you that GAC is being pushy (and ICANN board following this issue closely). This has an impact on council and future PDPs. There is expectation that everyone get familairized with the issue, at least the documents shared previously (also the webinar we had in October) PDP 3.0 implementation plan and SPS agenda will be discussed. Councillors are expected to prepare for the SPS. Please feel free to suggest or amend agenda items. I am not sure about other relevant topics. I. Introduction II. GNSO Council Call Preparation - Council agenda: https://gnso.icann.org/sites/default/files/file/field-file-attach/agenda-council-20dec18-en.pdf III. Policy Update - Policy topics: * EPDP discussion: initial report public comments and outstanding items * PDPs & Review Teams Update - Public comments status: https://www.icann.org/public-comments#open-public & list of volunteers https://community.icann.org/display/gnsononcomstake/Public+Comments+-+2018 IV. Misc - ICANN budget and operating plan for FY20 (to be published in 17th Dec) - Any other topic? Best Regards, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Fri Dec 14 03:17:53 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Fri, 14 Dec 2018 10:17:53 +0900 Subject: [NCSG-PC] (urgent) review of public comment for redcross Message-ID: Hi all, Ioana and Farzaneh just drafted this comment ( https://docs.google.com/document/d/1a7SpjIO6q2F5cjUotsljVG7GWjJNbxG9VIxiKk6fzFo/edit ) related to https://www.icann.org/public-comments/red-cross-names-consensus-policy-2018-11-21-en . The deadline is the 14th December, I will check with staff regarding the submission but in meantime please review the draft asap. We already made our position clear on this topic for the final report and with our statement made at GNSO council meeting. So we are not bringing new elements but sharing the same positions for this public comment initiated by the board for approving the recommendations. I expect the review to be straightforward and basically checking that this comment is consistent with previous ones. Best, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Fri Dec 14 03:30:06 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Fri, 14 Dec 2018 01:30:06 +0000 Subject: [NCSG-PC] (urgent) review of public comment for redcross In-Reply-To: References: Message-ID: Thanks Rafik (and Ioana and Farzaneh for drafting the comment); I have made some suggested edits to the document now. Best wishes, Ayden ??????? Original Message ??????? On Thursday, 13 December 2018 20:17, Rafik Dammak wrote: > Hi all, > > Ioana and Farzaneh just drafted this comment (https://docs.google.com/document/d/1a7SpjIO6q2F5cjUotsljVG7GWjJNbxG9VIxiKk6fzFo/edit ) related to https://www.icann.org/public-comments/red-cross-names-consensus-policy-2018-11-21-en. > > The deadline is the 14th December, I will check with staff regarding the submission but in meantime please review the draft asap. We already made our position clear on this topic for the final report and with our statement made at GNSO council meeting. So we are not bringing new elements but sharing the same positions for this public comment initiated by the board for approving the recommendations. > I expect the review to be straightforward and basically checking that this comment is consistent with previous ones. > > Best, > > Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Fri Dec 14 03:59:57 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Fri, 14 Dec 2018 10:59:57 +0900 Subject: [NCSG-PC] [Public Comment] review the NCSG comment on EPDP initial report In-Reply-To: References: Message-ID: Hi all, this is critical and urgent. The deadline for submission is quite strict. please review and comment the draft response to EPDP initial report. Best Regards, Rafik ---------- Forwarded message --------- Hi all, The representatives to EPDP team prepared a draft comment from NCSG on the initial report. You can find it here https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit . You can find the initial report here https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. The deadline for submission is the 21st December. The public comment is using google form, that explains why the draft may look long as it includes the questions and explanation. Our draft responses are in red. This public comment is an important milestone for EPDP and for NCSG to submit the comment. It is also important to encourage to have more input. Best Regards, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Fri Dec 14 05:00:46 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Fri, 14 Dec 2018 03:00:46 +0000 Subject: [NCSG-PC] [Public Comment] review the NCSG comment on EPDP initial report In-Reply-To: References: Message-ID: <-WrRnrS0KYweYgEP7xSVMaL8EUIkKeNFIhiny4ODwdiPvdCU97CatHKWvuR9yAwFc6bNSORp42NzgvM-qYd0SPwG3iNckdpZSz53eGJAOlw=@ferdeline.com> I support the submission of this comment. Ayden ??????? Original Message ??????? On Thursday, 13 December 2018 20:59, Rafik Dammak wrote: > Hi all, > > this is critical and urgent. The deadline for submission is quite strict. > please review and comment the draft response to EPDP initial report. > > Best Regards, > > Rafik > > ---------- Forwarded message --------- > > Hi all, > > The representatives to EPDP team prepared a draft comment from NCSG on the initial report. You can find it here https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit . You can find the initial report here https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. The deadline for submission is the 21st December. > > The public comment is using google form, that explains why the draft may look long as it includes the questions and explanation. Our draft responses are in red. > This public comment is an important milestone for EPDP and for NCSG to submit the comment. It is also important to encourage to have more input. > > Best Regards, > > Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From elsa.saade at gmail.com Fri Dec 14 06:46:48 2018 From: elsa.saade at gmail.com (Elsa S) Date: Thu, 13 Dec 2018 23:46:48 -0500 Subject: [NCSG-PC] [Public Comment] review the NCSG comment on EPDP initial report In-Reply-To: References: Message-ID: Hi Rafik, I've reviewed the comment. Added suggestions and a couple of comments. I think it generally looks good to go! E. -- On Thu, Dec 13, 2018 at 9:00 PM Rafik Dammak wrote: > Hi all, > > this is critical and urgent. The deadline for submission is quite strict. > please review and comment the draft response to EPDP initial report. > > Best Regards, > > Rafik > > ---------- Forwarded message --------- > > Hi all, > > The representatives to EPDP team prepared a draft comment from NCSG on the > initial report. You can find it here > https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit > . You can find the initial report here > https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. > The deadline for submission is the 21st December. > > The public comment is using google form, that explains why the draft may > look long as it includes the questions and explanation. Our draft responses > are in red. > This public comment is an important milestone for EPDP and for NCSG to > submit the comment. It is also important to encourage to have more input. > > Best Regards, > > Rafik > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -- -- Elsa Saade Consultant Gulf Centre for Human Rights Twitter: @Elsa_Saade -------------- next part -------------- An HTML attachment was scrubbed... URL: From arsenebaguma at gmail.com Fri Dec 14 08:59:03 2018 From: arsenebaguma at gmail.com (=?utf-8?Q?Ars=C3=A8ne_Tungali?=) Date: Fri, 14 Dec 2018 08:59:03 +0200 Subject: [NCSG-PC] Draft Agenda for NCSG Monthly Policy Call 20th December In-Reply-To: References: Message-ID: <07695E86-B57D-4B65-AC2A-4CB6C56DC5C2@gmail.com> ?We will also discuss the response to Board letter on EPDP and plan B to GNSO council. ? At some point i thought i missed a discussion on this important point as I would like to understand what?s out stake on this. I am happy it is on our agenda for Monday! Sent from my iPhone > On 14 Dec 2018, at 03:10, Rafik Dammak wrote: > > We will also discuss the response to Board letter on EPDP and plan B to GNSO council. From tatiana.tropina at gmail.com Fri Dec 14 11:04:09 2018 From: tatiana.tropina at gmail.com (Tatiana Tropina) Date: Fri, 14 Dec 2018 10:04:09 +0100 Subject: [NCSG-PC] Draft Agenda for NCSG Monthly Policy Call 20th December In-Reply-To: <07695E86-B57D-4B65-AC2A-4CB6C56DC5C2@gmail.com> References: <07695E86-B57D-4B65-AC2A-4CB6C56DC5C2@gmail.com> Message-ID: Dear all, I am very sorry that I won?t be able to attend the call, I will be at the airport and then on the plane during it. Apologies! Cheers, Tanya On Fri 14. Dec 2018 at 07:59, Ars?ne Tungali wrote: > ?We will also discuss the response to Board letter on EPDP and plan B to > GNSO council. ? > > At some point i thought i missed a discussion on this important point as I > would like to understand what?s out stake on this. I am happy it is on our > agenda for Monday! > > Sent from my iPhone > > > On 14 Dec 2018, at 03:10, Rafik Dammak wrote: > > > > We will also discuss the response to Board letter on EPDP and plan B to > GNSO council. > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tatiana.tropina at gmail.com Fri Dec 14 13:32:53 2018 From: tatiana.tropina at gmail.com (Tatiana Tropina) Date: Fri, 14 Dec 2018 12:32:53 +0100 Subject: [NCSG-PC] [Public Comment] review the NCSG comment on EPDP initial report In-Reply-To: References: Message-ID: I support the submission. Many thanks to those who worked on it. Cheers, Tanya On Fri 14. Dec 2018 at 05:47, Elsa S wrote: > Hi Rafik, > > I've reviewed the comment. Added suggestions and a couple of comments. I > think it generally looks good to go! > > E. > -- > > On Thu, Dec 13, 2018 at 9:00 PM Rafik Dammak > wrote: > >> Hi all, >> >> this is critical and urgent. The deadline for submission is quite strict. >> please review and comment the draft response to EPDP initial report. >> >> Best Regards, >> >> Rafik >> >> ---------- Forwarded message --------- >> >> Hi all, >> >> The representatives to EPDP team prepared a draft comment from NCSG on >> the initial report. You can find it here >> https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit >> . You can find the initial report here >> https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. >> The deadline for submission is the 21st December. >> >> The public comment is using google form, that explains why the draft may >> look long as it includes the questions and explanation. Our draft responses >> are in red. >> This public comment is an important milestone for EPDP and for NCSG to >> submit the comment. It is also important to encourage to have more input. >> >> Best Regards, >> >> Rafik >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > > > -- > -- > > Elsa Saade > Consultant > Gulf Centre for Human Rights > Twitter: @Elsa_Saade > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tatiana.tropina at gmail.com Fri Dec 14 13:35:25 2018 From: tatiana.tropina at gmail.com (Tatiana Tropina) Date: Fri, 14 Dec 2018 12:35:25 +0100 Subject: [NCSG-PC] (urgent) review of public comment for redcross In-Reply-To: References: Message-ID: All, As am at the airport on mobile only and can?t edit, I?ll just thank Ioana and Farz and give my support. Indeed, our position was already clear and the statement was made. Cheers, Tanya On Fri 14. Dec 2018 at 02:30, Ayden F?rdeline wrote: > Thanks Rafik (and Ioana and Farzaneh for drafting the comment); I have > made some suggested edits to the document now. > > Best wishes, Ayden > > > ??????? Original Message ??????? > On Thursday, 13 December 2018 20:17, Rafik Dammak > wrote: > > Hi all, > > Ioana and Farzaneh just drafted this comment ( > https://docs.google.com/document/d/1a7SpjIO6q2F5cjUotsljVG7GWjJNbxG9VIxiKk6fzFo/edit > ) related to > https://www.icann.org/public-comments/red-cross-names-consensus-policy-2018-11-21-en > . > > The deadline is the 14th December, I will check with staff regarding the > submission but in meantime please review the draft asap. We already made > our position clear on this topic for the final report and with our > statement made at GNSO council meeting. So we are not bringing new elements > but sharing the same positions for this public comment initiated by the > board for approving the recommendations. > I expect the review to be straightforward and basically checking that this > comment is consistent with previous ones. > > Best, > > Rafik > > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From PolicyCalendar at icann.org Fri Dec 14 15:17:15 2018 From: PolicyCalendar at icann.org (ICANN Policy Calendar) Date: Fri, 14 Dec 2018 13:17:15 +0000 Subject: [NCSG-PC] **REMINDER**Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Message-ID: Dear All, **REMINDER** Please find participation details for the Monthly NCSG Policy Call on Monday 17 December 2018 at 12:00 UTC Adobe Connect: https://participate.icann.org/ncsg Time Zones: https://tinyurl.com/y8efhvas Dial out request: please send an email to Maryam.bakoshi at icann.org offline. Audio dial-in details below: [https://cobranding-pgi.s3.amazonaws.com/1/Logo1.png] You're invited. You've been invited to a GlobalMeet? audio meeting. Have the meeting call you. Click the Connect Me link below. No need to dial-in. Connect Me [go.conferencinghub.com] Not at your computer? You can join by dialing one of the access numbers below. Mobile: tel://16054755604,*,,9922790467# Phone Only Controls : https://go.conferencinghub.com/2xdh7 Access Number: 1-605-475-5604 Guest Passcode: 992 279 0467 Additional Access: USA: 1-605-475-5604 USA: 1-719-457-6209 Canada, Calgary: +1 403 407 5793 Canada, Montreal: +1 514 669 5928 Canada, Toronto: +1 647 426 9172 Canada, Vancouver: +1 604 222 7836 Argentina, Buenos Aires: +54 (0) 11 5172 6003 Argentina (toll free): 0800 800 1223 Australia, Sydney: +61 (0) 2 8017 6064 Australia, Melbourne: +61 (0) 3 8687 0553 Australia, Brisbane: +61 (0) 7 3015 0535 Australia (toll free): 1 800 804 786 Austria (toll free): 0800 070 981 Bahrain, Manama: +973 1619 8739 Bahrain (toll free): 800 04212 Belarus (toll free): 8 820 0011 0341 Belgium, Brussels: +32 (0) 2 400 6928 Belgium (toll free): 0800 39279 Bosnia and Herzegovina: +387 7031 1442 Brazil, Sao Paulo: +55 11 4935 7169 Brazil, Rio de Janeiro: +55 21 4560 0072 Brazil (toll free): 0800 887 0233 Bulgaria, Sofia: +359 (0) 2 491 6045 Bulgaria (toll free): 00800 111 4950 Cambodia, Phnom Penh: +855 23 965 723 Canada (toll free): 1 855 950 3717 Chile, Santiago: +56 (0) 2 2666 0696 Chile (toll free): 171 800 835 783 China (national): +400 613 8103 China, Beijing: +86 10 5667 0003 China, Shanghai: +86 21 2039 7081 Colombia, Bogota: +57 1 508 8137 Colombia (toll free): 01 800 755 0102 Costa Rica (toll free): 800 542 5328 Croatia (toll free): 0800 805 940 Cyprus (toll free): 800 97424 Czech Republic, Prague: +420 225 986 554 Czech Republic (toll free): 800 701 532 Denmark, Copenhagen: +45 32 72 78 10 Denmark (toll free): 80 70 35 86 Egypt (toll free): 0800 000 0593 Estonia, Tallinn: +372 622 6551 Estonia (toll free): 800 011 1589 Fiji (toll free): 00800 3322 Finland, Helsinki: +358 (0) 9 2310 1677 Finland (toll free): 0800 772 236 France, Paris: +33 (0) 1 70 37 16 56 France (toll free): 0800 946 531 France (national): 0811 655 100 France (national): 0821 231 671 Georgia, Tbilisi: +995 32 2 050 778 Germany, Frankfurt: +49 (0) 69 2222 10612 Germany, Munich: +49 (0) 89 2030 31207 Germany (national): 01801 003 899 Germany (toll free): 0800 588 9170 Greece, Athens: +30 211 181 3824 Greece (toll free): 00800 128 913 Hong Kong: +852 3018 9111 Hong Kong (toll free): 800 901 787 Hungary, Budapest: +36 1408 8953 Hungary (toll free): 068 001 9673 Iceland (toll free): 800 9847 India, Delhi: +91 11 6310 0268 India, Mumbai: +91 22 6310 0298 India, Chennai: +91 44 6310 0234 India, Bangalore: +91 80 6760 8755 India (toll free): 1800 3010 1582 Indonesia, Jakarta: +62 21 2188 9084 Indonesia (toll free): 007 803 321 8927 Ireland, Dublin: +353 (0) 1 526 9421 Ireland (national): 0818 270 271 Ireland (toll free): 1800 937 649 Ireland (national): 1890 907 630 Israel, Tel Aviv: +972 (0)3 721 7943 Israel (toll free): 1809 213 168 Italy, Milan: +39 02 3600 8006 Italy, Rome: +39 06 8750 0676 Italy (toll free): 800 146 094 Japan, Tokyo: +81 3 4560 1270 Japan, Osaka: +81 6 4560 2410 Japan (toll free): 0120 305 211 Japan (mobile): 0120 632 611 Japan (national): 0570 085 744 Jordan (toll free): 0800 22172 Kazakhstan (toll free): 8800 333 7554 Kenya, Nairobi: +254 (0)207 643 581 South Korea, Seoul: +82 (0) 2 6007 0079 South Korea (toll free): 00798 6136 1454 Kuwait (national): +965 2206 3002 Latvia, Riga: +371 6601 3627 Latvia (toll free): 8000 4418 Lithuania, Vilnius: +370 5205 5468 Lithuania (toll free): 8800 31449 Luxembourg: +352 2088 1749 Luxembourg (toll free): 800 28433 Macau (national): +853 6262 1676 Malaysia, Kuala Lumpur: +60 (0) 3 7724 8010 Malaysia (toll free): 1 800 816 152 Mexico, Guadalajara: +52 33 4162 4504 Mexico, Mexico City: +52 55 8421 0326 Mexico, Monterrey: +52 81 4162 5648 Mexico (toll free): 01 800 733 4102 Morocco, Casablanca: +212 (0) 520 48 0022 Morocco (toll free): 0800 091 296 Netherlands, Amsterdam: +31 (0) 20 716 8345 Netherlands (toll free): 0800 020 2597 New Zealand, Christchurch: +64 (0) 3 974 2596 New Zealand, Wellington: +64 (0) 4 909 4674 New Zealand, Auckland: +64 (0) 9 929 1825 New Zealand (toll free): 0800 452 947 Nigeria, Lagos: +234 1 277 3944 Norway, Oslo: +47 21 00 48 15 Norway (toll free): 800 56081 Oman (toll free): 800 77265 Pakistan, Islamabad: +92 5181 08863 Panama, Panama City: +507 8 335 913 Panama (toll free): 00800 223 1390 Peru, Lima: +51 (0) 1 700 9571 Philippines, Manila: +63 (0)2 395 3426 Philippines (toll free): 1 800 111 013 99 Poland, Warsaw: +48 22 295 3570 Poland (toll free): 00 800 121 4356 Portugal, Lisbon: +351 21 316 4093 Portugal (toll free): 800 784 442 Qatar (freephone): 00 800 100 491 Romania, Bucharest: +40 (0) 21 529 3992 Romania (toll free): 0800 801 035 Russia, Moscow: +7 495 646 9181 Russia (toll free): 8 800 500 9241 Saudi Arabia (toll free): 800 844 6641 Saudi Arabia (toll free): 800 850 0219 Serbia (toll free): 0800 190 712 Singapore: +65 6654 9112 Singapore (toll free): 800 616 3192 Slovakia, Bratislava: +421 (0)2 3321 5498 Slovakia (toll free): 0800 002 002 Slovenia, Ljubljana: +386 1600 8695 Slovenia (toll free): 0800 81193 South Africa, Johannesburg: +27 (0)11 589 8321 South Africa (toll free): 0800 999 434 Spain, Madrid: +34 91 114 6653 Spain, Barcelona: +34 93 800 1946 Spain (toll free): 900 828 035 Sri Lanka, Sri Lanka: +94 720 910 333 Sweden, Stockholm: +46 (0) 8 5065 3956 Sweden (toll free): 0200 125 588 Switzerland, Geneva: +41 (0) 22 595 4795 Switzerland, Zurich: +41 (0) 44 580 7207 Switzerland (toll free): 0800 740 360 Taiwan, Taipei: +886 (0) 2 2650 7329 Taiwan (toll free): 0800 666 596 Thailand, Bangkok: +66 (0) 2104 0761 Thailand (toll free): 001 800 6136 1473 Tunisia, Tunis: +216 31 378 101 Turkey, Istanbul: +90 212 375 50 49 Turkey (toll free): 00800 4488 26642 Ukraine (toll free): 0800 500 896 UAE (toll free): 8000 3570 2662 UK (03): +44 (0)330 336 6002 UK (toll free): 0800 358 6385 UK (national): 0844 473 5010 UK (national): 0845 545 0015 USA /Canada (toll free): 1-866-398-2885 Uruguay (toll free): 0004 019 0152 Venezuela, Caracas: +58 212 720 2164 Venezuela (toll free): 0 800 162 7451 Vietnam, Hanoi: +84 24 4458 3312 Vietnam, Ho Chi Minh: +84 28 4458 1322 Vietnam (toll free): 1800 9226 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 12068 bytes Desc: not available URL: From mpsilvavalent at gmail.com Fri Dec 14 16:56:06 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Fri, 14 Dec 2018 11:56:06 -0300 Subject: [NCSG-PC] [Public Comment] review the NCSG comment on EPDP initial report In-Reply-To: References: Message-ID: Very good work, and thank you all that put something into it. I have no further comment on it and support the submission. Best, Martin On Fri, Dec 14, 2018, 08:33 Tatiana Tropina I support the submission. Many thanks to those who worked on it. > Cheers, > Tanya > > On Fri 14. Dec 2018 at 05:47, Elsa S wrote: > >> Hi Rafik, >> >> I've reviewed the comment. Added suggestions and a couple of comments. I >> think it generally looks good to go! >> >> E. >> -- >> >> On Thu, Dec 13, 2018 at 9:00 PM Rafik Dammak >> wrote: >> >>> Hi all, >>> >>> this is critical and urgent. The deadline for submission is quite >>> strict. >>> please review and comment the draft response to EPDP initial report. >>> >>> Best Regards, >>> >>> Rafik >>> >>> ---------- Forwarded message --------- >>> >>> Hi all, >>> >>> The representatives to EPDP team prepared a draft comment from NCSG on >>> the initial report. You can find it here >>> https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit >>> . You can find the initial report here >>> https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. >>> The deadline for submission is the 21st December. >>> >>> The public comment is using google form, that explains why the draft may >>> look long as it includes the questions and explanation. Our draft responses >>> are in red. >>> This public comment is an important milestone for EPDP and for NCSG to >>> submit the comment. It is also important to encourage to have more input. >>> >>> Best Regards, >>> >>> Rafik >>> >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >> >> >> -- >> -- >> >> Elsa Saade >> Consultant >> Gulf Centre for Human Rights >> Twitter: @Elsa_Saade >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsilvavalent at gmail.com Fri Dec 14 17:00:40 2018 From: mpsilvavalent at gmail.com (Martin Pablo Silva Valent) Date: Fri, 14 Dec 2018 12:00:40 -0300 Subject: [NCSG-PC] (urgent) review of public comment for redcross In-Reply-To: References: Message-ID: I agree with the content, and I see they already changed a few things on the writing side. I support this review. Best, Martin On Fri, Dec 14, 2018, 08:35 Tatiana Tropina All, > As am at the airport on mobile only and can?t edit, I?ll just thank Ioana > and Farz and give my support. Indeed, our position was already clear and > the statement was made. > Cheers, > Tanya > > On Fri 14. Dec 2018 at 02:30, Ayden F?rdeline wrote: > >> Thanks Rafik (and Ioana and Farzaneh for drafting the comment); I have >> made some suggested edits to the document now. >> >> Best wishes, Ayden >> >> >> ??????? Original Message ??????? >> On Thursday, 13 December 2018 20:17, Rafik Dammak >> wrote: >> >> Hi all, >> >> Ioana and Farzaneh just drafted this comment ( >> https://docs.google.com/document/d/1a7SpjIO6q2F5cjUotsljVG7GWjJNbxG9VIxiKk6fzFo/edit >> ) related to >> https://www.icann.org/public-comments/red-cross-names-consensus-policy-2018-11-21-en >> . >> >> The deadline is the 14th December, I will check with staff regarding the >> submission but in meantime please review the draft asap. We already made >> our position clear on this topic for the final report and with our >> statement made at GNSO council meeting. So we are not bringing new elements >> but sharing the same positions for this public comment initiated by the >> board for approving the recommendations. >> I expect the review to be straightforward and basically checking that >> this comment is consistent with previous ones. >> >> Best, >> >> Rafik >> >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephanie.perrin at mail.utoronto.ca Fri Dec 14 20:13:08 2018 From: stephanie.perrin at mail.utoronto.ca (Stephanie Perrin) Date: Fri, 14 Dec 2018 18:13:08 +0000 Subject: [NCSG-PC] Draft Agenda for NCSG Monthly Policy Call 20th December In-Reply-To: References: Message-ID: <6b40ddae-b6e6-1942-6ce8-801977debe94@mail.utoronto.ca> Better add this to the list. http://domainincite.com/23751-exclusive-gang-of-10-to-work-on-making-icann-the-whois-gatekeeper I am pretty annoyed about this. Why do we continue to support the myth that this organization operates as an MS policy development group? Farcical. SO On 2018-12-13 20:10, Rafik Dammak wrote: Hi, I am sharing the draft agenda for our NCSG policy call next Monday and highlighting the topics we should focus on. EPDP will be covered substantively as we will be close to the public comment deadline. It will be also a good opportunity to give some updates from EPDP team representatives. We will also discuss the response to Board letter on EPDP and plan B to GNSO council. We also have the IGO-INGO topic again in the agenda. Council leadership will work on proposing a framework to move forward. I can tell you that GAC is being pushy (and ICANN board following this issue closely). This has an impact on council and future PDPs. There is expectation that everyone get familairized with the issue, at least the documents shared previously (also the webinar we had in October) PDP 3.0 implementation plan and SPS agenda will be discussed. Councillors are expected to prepare for the SPS. Please feel free to suggest or amend agenda items. I am not sure about other relevant topics. I. Introduction II. GNSO Council Call Preparation * Council agenda:https://gnso.icann.org/sites/default/files/file/field-file-attach/agenda-council-20dec18-en.pdf III. Policy Update - Policy topics: * EPDP discussion: initial report public comments and outstanding items * PDPs & Review Teams Update - Public comments status: https://www.icann.org/public-comments#open-public & list of volunteers https://community.icann.org/display/gnsononcomstake/Public+Comments+-+2018 IV. Misc - ICANN budget and operating plan for FY20 (to be published in 17th Dec) - Any other topic? Best Regards, Rafik _______________________________________________ NCSG-PC mailing list NCSG-PC at lists.ncsg.is https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Sat Dec 15 00:58:15 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Sat, 15 Dec 2018 07:58:15 +0900 Subject: [NCSG-PC] (urgent) review of public comment for redcross In-Reply-To: References: Message-ID: hi all, I tidy up the document as the changes were minor editorial changes. Please find attached the final version. as I don't see any objection here and there was no change in our position along this PDP process, I will submit the comment. Thanks all. Best Regards, Rafik Le sam. 15 d?c. 2018 ? 00:01, Martin Pablo Silva Valent < mpsilvavalent at gmail.com> a ?crit : > I agree with the content, and I see they already changed a few things on > the writing side. I support this review. > > Best, > Martin > > On Fri, Dec 14, 2018, 08:35 Tatiana Tropina wrote: > >> All, >> As am at the airport on mobile only and can?t edit, I?ll just thank Ioana >> and Farz and give my support. Indeed, our position was already clear and >> the statement was made. >> Cheers, >> Tanya >> >> On Fri 14. Dec 2018 at 02:30, Ayden F?rdeline >> wrote: >> >>> Thanks Rafik (and Ioana and Farzaneh for drafting the comment); I have >>> made some suggested edits to the document now. >>> >>> Best wishes, Ayden >>> >>> >>> ??????? Original Message ??????? >>> On Thursday, 13 December 2018 20:17, Rafik Dammak < >>> rafik.dammak at gmail.com> wrote: >>> >>> Hi all, >>> >>> Ioana and Farzaneh just drafted this comment ( >>> https://docs.google.com/document/d/1a7SpjIO6q2F5cjUotsljVG7GWjJNbxG9VIxiKk6fzFo/edit >>> ) related to >>> https://www.icann.org/public-comments/red-cross-names-consensus-policy-2018-11-21-en >>> . >>> >>> The deadline is the 14th December, I will check with staff regarding the >>> submission but in meantime please review the draft asap. We already made >>> our position clear on this topic for the final report and with our >>> statement made at GNSO council meeting. So we are not bringing new elements >>> but sharing the same positions for this public comment initiated by the >>> board for approving the recommendations. >>> I expect the review to be straightforward and basically checking that >>> this comment is consistent with previous ones. >>> >>> Best, >>> >>> Rafik >>> >>> >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Proposed Consensus Policy Concerning the Names of the Red Cross International Movement and Red Cross National Societies - NCSG Comment.pdf Type: application/pdf Size: 123132 bytes Desc: not available URL: From kathy at kathykleiman.com Mon Dec 17 01:33:57 2018 From: kathy at kathykleiman.com (Kathy Kleiman) Date: Sun, 16 Dec 2018 18:33:57 -0500 Subject: [NCSG-PC] [Public Comment] review the NCSG comment on EPDP initial report In-Reply-To: <-WrRnrS0KYweYgEP7xSVMaL8EUIkKeNFIhiny4ODwdiPvdCU97CatHKWvuR9yAwFc6bNSORp42NzgvM-qYd0SPwG3iNckdpZSz53eGJAOlw=@ferdeline.com> References: <-WrRnrS0KYweYgEP7xSVMaL8EUIkKeNFIhiny4ODwdiPvdCU97CatHKWvuR9yAwFc6bNSORp42NzgvM-qYd0SPwG3iNckdpZSz53eGJAOlw=@ferdeline.com> Message-ID: Hi All, I have spent the better part of today adding edits to our EPDP comment. Per Amr's request, I looked closely at the UDRP and URS issues, Questions 14, 15, and 16.? Yes, there are certainly issues we need to address -- including the publication of registrant contact information in a decision.? If the only place you learn about a registrant is in a /published /UDRP or URS decision, is that fair?? What if the registrant wins; still publish the personal data?? What if the sole purpose of filing the UDRP or URS is to "out" the registrant (something I am hearing whispered about a lot in intellectual property hallways)?? Also, should the registrant's attorney and his/her contact information be automatically published?? What if it is one human rights group helping another human rights group? As the Request for Comments note, some of this should go to the RPM WG.? I agree, and in Phase 1 of our RPM WG review, involving the URS and Trademark Clearinghouse, we have already prepared draft policy recommendations for the URS that include amending the rules for GDPR-related requirements.? All good. But what struck me as utterly disastrous is the PDDRP and RRDRP in other questions, including Purpose 6 and in the broad buckets of Question 14. /Unlike the UDRP and URS, PDDRP and RRDRP are not proceedings against the registrant, but against the registry!? The disclosure of the personal data of thousands or even (potentially) millions of innocent and good-faith registrants is a stunning leap of insanity. /Just because you sue GM does not mean you get the name and address of everyone who owns a GM car (!) I've explained in detail what the Trademark Post-delegation Dispute Resolution Policy (PDDRP) and Registry Restriction Dispute Resolution Procedure (RRDRP) in our draft comments (pasted some of it in the "p.s." below). Everywhere I saw a grouping of UDRP, URS, PDDRP and RRDRP? (as well as "future developed domain name registration related dispute procedures," which could mean anything, any future type of proceeding against the registry, registrar, ICANN or the registrant --it's a completely unbounded term), I objected with information and discussion on behalf of NCSG. Happy to discuss!? (Note: PDDRP was the first part of our RPM WG review at the start of Phase 1.) _Other issues_ I'm also deeply troubled about the continuing collection and processing of the street address in the RDDS.? State and even city I can understand, but street address?? This is a piece of data collected largely for the processing of credit card data, and like credit card data, it should be kept locally by the registrars. To transmit this data is to expose individuals and organizations (including the many religious, philosophical, racial, ethnic, political, trade union, health, gender, sexual orientation directly protected under Article 9 of the GDPR) to prosecution and persecution. The idea that every pro-democracy website and its registrants might be requested by law enforcement in China (as a violation of Chinese criminal law) although the registrant, registrar and registry are all based in the US/Europe and protected under the US First Amendment and UN Declaration of Human Rights Article 19 has haunted me since I worked for PIR. Getting rid of the street address, and forcing foreign governments and agents to go through registrars and local law will provide critical due process and procedural protections for individuals and organizations. Whoever wrote the response to Recommendation #2: Standardized Access was brilliant. It is exactly right (although I would make it emphatic): "The NCSG would prefer to replace the term ?Standardized Access to nonpublic Registration Data? with the term ?Lawful disclosure of nonpublic registration data to third parties with legitimate interests.?" As we heard at the Public Forum in Barcelona, IP & WIPO support a general "IP request" and law enforcement wants a vague and general "we want it because we want it" request. But such a request of individuals and religious, philosophical, racial, ethnic, political, trade union, health, gender, sexual orientation is not right or legal under GDPR. For it does not give the information necessary to make the imporarnt evaluation required under GDRP Article 6(f) -- including whether the "fundamental rights and freedoms of the data subject" are put at risk. The GDPR is eminently practical:? the "fundamental rights and freedoms of the data subject" (including organizations) is paramount. That requires data and detail to weigh and balance -- not choosing a pull down slot "IP infringement" or "law enforcement demand." /(GDPR Article 6://1. ?Processing shall be lawful only if and to the extent that at least one of the following applies:? //*** //?(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.?)/ It's getting interesting, Folks!? Tx so the amazing EPDP and I hope my hours today help! Best, Kathy p.s. More on the PDDRP and RRDPR (from the EPDP Comment): "These are proceedings against the Registry itself. In the ?Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP) (note: the only type of PDDRP that exists), the proceeding is against **the Registry** (not the Registrant). ?The allegation is as follows: => ?The Trademark PDDRP generally addresses a Registry Operator's complicity in trademark infringement on the first or second level of a New gTLD. At least 30 days prior to filing a formal complaint, a rights holder must notify the Registry of the alleged infringing conduct and express a willingness to meet to resolve the issue. Review the Trademark PDDRP [PDF, 181 KB].? https://newgtlds.icann.org/en/program-status/pddrp "To the extent in a PDDPR that the Registryis also the registrant of domain names used for abuse, it is likely those domain names will be used as part of the pattern of conduct of the Registry. ?But to the extent that there may be thousands or even millions of innocent domain name registrants within a gTLD accused of complicity with trademark infringement at a registry-scale, there is absolutely no waiver of interest and no relinquishing of privacy for the purpose of pursuit of an arbitration against an entirely different third party (the Registry). ?Accordingly, processing the personal data of registrants for the purpose of ?coordinating, operationalizing and facilitating? a PDDRP dispute between a trademark owner and an ICANN Registrycannot be one which by definition includes the registration data of all registrants -- domain name registrants are not accused in the PDDRP "Ditto for the Registry Restriction Dispute Resolution Procedure (RRDRP) which is similarly a proceeding in the New gTLD Applicant Guidebook against the Registry itselfand the allegation is as follows: => ??The RRDRP is intended to address circumstances in which a community-based New gTLD Registry Operator deviates from the registration restrictions outlined in its Registry Agreement.? https://newgtlds.icann.org/en/program-status/pddrp "The proceeding for an RRDRP, as with the PDDRP above, is expressly against the Registry. ?In the future, there may be thousands or even millions of innocent domain name registrants completely in compliance with the community-based standards of a community-based gTLD. It is absolutely inconsistent with the GDPR or with an notion of registrant privacy and protection to deep all registrants of a gTLD have consented or in any way agreed to the disclosure of their personal information should the titans (large organizations and registries) fight in a RRDRP. There is no legal basis for the RDDS disclosure of the data of innocent and good faith registrants in a PDDRP or RRDRP proceeding." On 12/13/2018 10:00 PM, Ayden F?rdeline wrote: > I support the submission of this comment. > > Ayden > > > ??????? Original Message ??????? > On Thursday, 13 December 2018 20:59, Rafik Dammak > wrote: > >> Hi all, >> >> this is critical and urgent. The deadline for submission is quite >> strict. >> please review and comment the draft response to EPDP initial report. >> >> Best Regards, >> >> Rafik >> >> ---------- Forwarded message --------- >> >> Hi all, >> >> The representatives to EPDP team prepared a draft comment from NCSG >> on the initial report. You can find it here >> https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit >> .?You can find the initial report here >> https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. >> The deadline for submission is the 21st December. >> >> The public comment is using google form, that explains why the draft >> may look long as it includes the questions and explanation. Our draft >> responses are in red. >> This public comment is an important milestone for EPDP and for NCSG >> to submit the comment. It is also important to encourage to have more >> input. >> >> Best Regards, >> >> Rafik >> > > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Wed Dec 19 06:13:42 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Wed, 19 Dec 2018 13:13:42 +0900 Subject: [NCSG-PC] review of NCSG comment on new gTLD supplemental report Message-ID: Hi all, the drafting team finished the work on NCSG comment on new gTLD supplemental report : https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit . They are continuing the work. the deadline for submission is the Friday 21st December. Please review it asap. Best, Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Fri Dec 21 05:10:07 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Fri, 21 Dec 2018 03:10:07 +0000 Subject: [NCSG-PC] Fw: [council] Deadline for public comments on EPDP Initial Report - Friday, 21 December 23:59 UTC In-Reply-To: <50F55781-5851-4260-A65D-2FE2FBC55379@icann.org> References: <50F55781-5851-4260-A65D-2FE2FBC55379@icann.org> Message-ID: FYI no extensions will be granted for EPDP comments. Ayden ??????? Original Message ??????? On Friday, 21 December 2018 12:16, Caitlin Tubergen wrote: > Dear All, > > As noted in Rafik?s EPDP update during today?s call, the deadline to submit [public comments](https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en) on the EPDP?s Initial Report is Friday, 21 December at 23:59 UTC. As Rafik also noted, no extensions will be granted due to the EPDP?s expedited timeline. While we are aware many of you are working to complete your comments, we wanted to send you a courtesy reminder of the impending deadline. > > Additionally, we have attached an FAQ document on commonly-asked questions we?ve received regarding the Google Form. We hope you find this helpful. > > Please feel free to reach out to us if you have any additional questions, and happy holidays to all! > > Best regards, > > Marika, Berry, and Caitlin > > EPDP Policy Staff Support -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Google Form FAQ.pdf Type: application/pdf Size: 47854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4621 bytes Desc: not available URL: From rafik.dammak at gmail.com Fri Dec 21 05:19:02 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Fri, 21 Dec 2018 12:19:02 +0900 Subject: [NCSG-PC] [Urgent] review the NCSG comment on EPDP initial report Message-ID: Hi all. You may have seen the reminders about comment deadline which is today. I will go through the google doc in coming hours to resolve the edits and tidy-up the responses. Please keep reviewing. I also asked EPDP NCSG representatives to review the document to check consistency. When the draft is finalized and no objection made, I will ask Ayden to fill the google form. He kindly accepted to do so since I am council liaison and vice chair in EPDP team it will be inappropriate for me to submit the NCSG comment for this case. Best, Rafik On Fri, Dec 14, 2018, 23:56 Martin Pablo Silva Valent < mpsilvavalent at gmail.com wrote: > Very good work, and thank you all that put something into it. I have no > further comment on it and support the submission. > > > Best, > Martin > > On Fri, Dec 14, 2018, 08:33 Tatiana Tropina wrote: > >> I support the submission. Many thanks to those who worked on it. >> Cheers, >> Tanya >> >> On Fri 14. Dec 2018 at 05:47, Elsa S wrote: >> >>> Hi Rafik, >>> >>> I've reviewed the comment. Added suggestions and a couple of comments. I >>> think it generally looks good to go! >>> >>> E. >>> -- >>> >>> On Thu, Dec 13, 2018 at 9:00 PM Rafik Dammak >>> wrote: >>> >>>> Hi all, >>>> >>>> this is critical and urgent. The deadline for submission is quite >>>> strict. >>>> please review and comment the draft response to EPDP initial report. >>>> >>>> Best Regards, >>>> >>>> Rafik >>>> >>>> ---------- Forwarded message --------- >>>> >>>> Hi all, >>>> >>>> The representatives to EPDP team prepared a draft comment from NCSG on >>>> the initial report. You can find it here >>>> https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit >>>> . You can find the initial report here >>>> https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. >>>> The deadline for submission is the 21st December. >>>> >>>> The public comment is using google form, that explains why the draft >>>> may look long as it includes the questions and explanation. Our draft >>>> responses are in red. >>>> This public comment is an important milestone for EPDP and for NCSG to >>>> submit the comment. It is also important to encourage to have more input. >>>> >>>> Best Regards, >>>> >>>> Rafik >>>> >>>> _______________________________________________ >>>> NCSG-PC mailing list >>>> NCSG-PC at lists.ncsg.is >>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>> >>> >>> >>> -- >>> -- >>> >>> Elsa Saade >>> Consultant >>> Gulf Centre for Human Rights >>> Twitter: @Elsa_Saade >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Fri Dec 21 05:20:29 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Fri, 21 Dec 2018 12:20:29 +0900 Subject: [NCSG-PC] review of NCSG comment on new gTLD supplemental report In-Reply-To: References: Message-ID: Hi all, This is a reminder regarding the review of draft comment for the subpro supplemental report. Best, Rafik On Wed, Dec 19, 2018, 13:13 Rafik Dammak Hi all, > > the drafting team finished the work on NCSG comment on new gTLD > supplemental report : > https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit > . They are continuing the work. > > the deadline for submission is the Friday 21st December. Please review it > asap. > > Best, > > Rafik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Fri Dec 21 11:58:25 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Fri, 21 Dec 2018 09:58:25 +0000 Subject: [NCSG-PC] [Urgent] review the NCSG comment on EPDP initial report In-Reply-To: References: Message-ID: <0WTegzu2Q2GxTLG0YLuPjyoEq2ioOp3ecVjHpNObX32lUklVXD83YaLLWgRn8K0PFdLA4NrrcL-UPPzcGP764rAGZzHMzu2ORRsoaXRkWSE=@ferdeline.com> Thanks, Rafik- I have now re-reviewed our comment and resolved the conflicts. I have also trimmed down some of our responses in the interest of clarity. So please do not be offended if I have deleted some of the text that you added. If you have any concerns please let me know ASAP. I will be submitting our comment in 12 hours time, at 22:00 UTC. Thanks! https://docs.google.com/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit?ts=5c1c7fb5# Best wishes, Ayden ??????? Original Message ??????? On Friday, 21 December 2018 14:19, Rafik Dammak wrote: > Hi all. > > You may have seen the reminders about comment deadline which is today. I will go through the google doc in coming hours to resolve the edits and tidy-up the responses. Please keep reviewing. > I also asked EPDP NCSG representatives to review the document to check consistency. > > When the draft is finalized and no objection made, I will ask Ayden to fill the google form. He kindly accepted to do so since I am council liaison and vice chair in EPDP team it will be inappropriate for me to submit the NCSG comment for this case. > > Best, > > Rafik > > On Fri, Dec 14, 2018, 23:56 Martin Pablo Silva Valent >> Very good work, and thank you all that put something into it. I have no further comment on it and support the submission. >> >> Best, >> Martin >> >> On Fri, Dec 14, 2018, 08:33 Tatiana Tropina > >>> I support the submission. Many thanks to those who worked on it. >>> Cheers, >>> Tanya >>> >>> On Fri 14. Dec 2018 at 05:47, Elsa S wrote: >>> >>>> Hi Rafik, >>>> >>>> I've reviewed the comment. Added suggestions and a couple of comments. I think it generally looks good to go! >>>> >>>> E. >>>> -- >>>> >>>> On Thu, Dec 13, 2018 at 9:00 PM Rafik Dammak wrote: >>>> >>>>> Hi all, >>>>> >>>>> this is critical and urgent. The deadline for submission is quite strict. >>>>> please review and comment the draft response to EPDP initial report. >>>>> >>>>> Best Regards, >>>>> >>>>> Rafik >>>>> >>>>> ---------- Forwarded message --------- >>>>> >>>>> Hi all, >>>>> >>>>> The representatives to EPDP team prepared a draft comment from NCSG on the initial report. You can find it here https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit . You can find the initial report here https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. The deadline for submission is the 21st December. >>>>> >>>>> The public comment is using google form, that explains why the draft may look long as it includes the questions and explanation. Our draft responses are in red. >>>>> This public comment is an important milestone for EPDP and for NCSG to submit the comment. It is also important to encourage to have more input. >>>>> >>>>> Best Regards, >>>>> >>>>> Rafik >>>>> >>>>> _______________________________________________ >>>>> NCSG-PC mailing list >>>>> NCSG-PC at lists.ncsg.is >>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>> >>>> -- >>>> -- >>>> >>>> Elsa Saade >>>> Consultant >>>> Gulf Centre for Human Rights >>>> Twitter: @Elsa_Saade >>>> _______________________________________________ >>>> NCSG-PC mailing list >>>> NCSG-PC at lists.ncsg.is >>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Fri Dec 21 17:42:20 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Sat, 22 Dec 2018 00:42:20 +0900 Subject: [NCSG-PC] [Urgent] review the NCSG comment on EPDP initial report In-Reply-To: <0WTegzu2Q2GxTLG0YLuPjyoEq2ioOp3ecVjHpNObX32lUklVXD83YaLLWgRn8K0PFdLA4NrrcL-UPPzcGP764rAGZzHMzu2ORRsoaXRkWSE=@ferdeline.com> References: <0WTegzu2Q2GxTLG0YLuPjyoEq2ioOp3ecVjHpNObX32lUklVXD83YaLLWgRn8K0PFdLA4NrrcL-UPPzcGP764rAGZzHMzu2ORRsoaXRkWSE=@ferdeline.com> Message-ID: Hi, the document is finalized and clean. last reviews were done by some of representatives to EPDP and consistency checked. after re-reading it several times, I do believe it looks good . there was no objection and there was already support for the comment, I think it is ready to be submitted. @Ayden please go ahead and fill the form when you are ready. thanks again for volunteering. Best, Rafik Le ven. 21 d?c. 2018 ? 18:58, Ayden F?rdeline a ?crit : > Thanks, Rafik- > > I have now re-reviewed our comment and resolved the conflicts. I have also > trimmed down some of our responses in the interest of clarity. So please do > not be offended if I have deleted some of the text that you added. If you > have any concerns please let me know ASAP. *I will be submitting our > comment in 12 hours time*, at 22:00 UTC. Thanks! > > > https://docs.google.com/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit?ts=5c1c7fb5# > > Best wishes, Ayden > > > ??????? Original Message ??????? > On Friday, 21 December 2018 14:19, Rafik Dammak > wrote: > > Hi all. > > You may have seen the reminders about comment deadline which is today. I > will go through the google doc in coming hours to resolve the edits and > tidy-up the responses. Please keep reviewing. > I also asked EPDP NCSG representatives to review the document to check > consistency. > > When the draft is finalized and no objection made, I will ask Ayden to > fill the google form. He kindly accepted to do so since I am council > liaison and vice chair in EPDP team it will be inappropriate for me to > submit the NCSG comment for this case. > > Best, > > Rafik > > On Fri, Dec 14, 2018, 23:56 Martin Pablo Silva Valent < > mpsilvavalent at gmail.com wrote: > >> Very good work, and thank you all that put something into it. I have no >> further comment on it and support the submission. >> >> >> Best, >> Martin >> >> On Fri, Dec 14, 2018, 08:33 Tatiana Tropina > wrote: >> >>> I support the submission. Many thanks to those who worked on it. >>> Cheers, >>> Tanya >>> >>> On Fri 14. Dec 2018 at 05:47, Elsa S wrote: >>> >>>> Hi Rafik, >>>> >>>> I've reviewed the comment. Added suggestions and a couple of comments. >>>> I think it generally looks good to go! >>>> >>>> E. >>>> -- >>>> >>>> On Thu, Dec 13, 2018 at 9:00 PM Rafik Dammak >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> this is critical and urgent. The deadline for submission is quite >>>>> strict. >>>>> please review and comment the draft response to EPDP initial report. >>>>> >>>>> Best Regards, >>>>> >>>>> Rafik >>>>> >>>>> ---------- Forwarded message --------- >>>>> >>>>> Hi all, >>>>> >>>>> The representatives to EPDP team prepared a draft comment from NCSG on >>>>> the initial report. You can find it here >>>>> https://docs.google.com/a/mozillafoundation.org/document/d/1iRZUXqSUJ2FaPEeytbH28wJmRamsmio-kzijQmBF2IE/edit >>>>> . You can find the initial report here >>>>> https://www.icann.org/public-comments/epdp-gtld-registration-data-specs-initial-2018-11-21-en. >>>>> The deadline for submission is the 21st December. >>>>> >>>>> The public comment is using google form, that explains why the draft >>>>> may look long as it includes the questions and explanation. Our draft >>>>> responses are in red. >>>>> This public comment is an important milestone for EPDP and for NCSG to >>>>> submit the comment. It is also important to encourage to have more input. >>>>> >>>>> Best Regards, >>>>> >>>>> Rafik >>>>> >>>>> _______________________________________________ >>>>> NCSG-PC mailing list >>>>> NCSG-PC at lists.ncsg.is >>>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>>> >>>> >>>> >>>> -- >>>> -- >>>> >>>> Elsa Saade >>>> Consultant >>>> Gulf Centre for Human Rights >>>> Twitter: @Elsa_Saade >>>> _______________________________________________ >>>> NCSG-PC mailing list >>>> NCSG-PC at lists.ncsg.is >>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>>> >>> _______________________________________________ >>> NCSG-PC mailing list >>> NCSG-PC at lists.ncsg.is >>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >>> >> _______________________________________________ >> NCSG-PC mailing list >> NCSG-PC at lists.ncsg.is >> https://lists.ncsg.is/mailman/listinfo/ncsg-pc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Sat Dec 22 00:31:46 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Fri, 21 Dec 2018 22:31:46 +0000 Subject: [NCSG-PC] Fw: EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form In-Reply-To: <0000000000007e4e82057d8fbd94@google.com> References: <0000000000007e4e82057d8fbd94@google.com> Message-ID: <9oF2GIaZAmnJzp0WzLy7KKX5OOEj4YdxMZ4_Uiw3IMmsiYD0Laz137SZ1P8auxUFX64jwJkOPlootXU8eA0miP_2Z9QV9tRgLulveqxZhlM=@ferdeline.com> Hi all, For archival purposes, below is our submission re: Initial Report comment. I have also exported our Google Doc, where we drafted the comment, to PDF and have attached it to this email. Best, Ayden ??????? Original Message ??????? On Saturday, 22 December 2018 09:26, Google Forms wrote: > [Google Forms] > > Thanks for filling out [EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form](https://docs.google.com/forms/d/e/1FAIpQLSefRyo0n6_G29cMYZZc1hK-zshjIpEeb7rIZLOo-RKnfXbH0Q/viewform?usp=mail_form_link) > > Here's what we got from you: > > [Edit response](https://docs.google.com/forms/d/e/1FAIpQLSefRyo0n6_G29cMYZZc1hK-zshjIpEeb7rIZLOo-RKnfXbH0Q/viewform?edit2=2_ABaOnuf44eTtWR4tN4LIunQ7FxCf7j59TCRuL0lVIunCwExUSV446IDe8bTO_Kg) > > EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form > > Email address > > * > icann at ferdeline.com > > Important Instructions - PLEASE READ BEFORE PROCEEDING > > This Public Comment forum seeks community feedback on the Initial Report published by the Expedited Policy Development Process (EPDP) Team on the Temporary Specification for gTLD Registration Data. This is a new format for collecting public comment. It seeks to: -- Clearly link comments to specific sections of the initial report -- Encourage commenters to provide reasoning or rationale for their opinions -- Enable the sorting of comment so that the EPDP team can more easily read all the comments on any one topic There is no obligation to complete all sections within this form ? respond to as many or as few questions as desired. Additionally, there is the opportunity to provide comments on the general content of the Initial Report or on new issues not raised by the Initial Report. To preview all questions in the Google Form, please refer to a Word version of this form here here's the link to the Word doc: [https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx](https://www.google.com/url?q=https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx&sa=D&ust=1545434796395000&usg=AFQjCNETWEKQbXw7SeHY8qrsfUgbWQeMlg). As you review the "Questions for Community Input" in the Initial Report, you will note that there is not a 1:1 correspondence with the questions asked in the Public Comment format. This is because, in some instances, the "Questions for Community Input" have been divided into multi-part questions so that feedback on these questions would be clear. The Initial Report and Comment Forum have been reviewed to ensure that all the "Questions for Community Input" have been addressed in this Comment Forum. It is important that your comments include rationale (i.e., by answering the ?rationale? question in each section). This is not a vote. The EPDP team is interested in your reasoning so that the conclusions reached and the issues discussed by the team can be tested against the reasoning of others. (This is much more helpful than comments that simply ?agree? or ?disagree?). You can easily navigate from page to page in the form. There is a table of contents below so that you can ?fast forward? to the desired section by hitting ?next? at the bottom of each page. To preview this entire form in Word format, see the link to the Word doc: [https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx](https://www.google.com/url?q=https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx&sa=D&ust=1545434796395000&usg=AFQjCNETWEKQbXw7SeHY8qrsfUgbWQeMlg). To stop and save your work for later, you MUST (to avoid losing your work): 1. Provide your email address above in order to receive a copy of your submitted responses; 2. Click "Submit" at the end of the Google Form (the last question on every page allows you to quickly jump to the end of the Google Form to submit); 3. After you click "Submit," you will receive an email to the above-provided email address; within the email, click the "Edit Response" button at top of the email; 4. After you click the "Edit Response" button, you will be directed to the Google Form to return and complete; 5. Repeat the above steps 2-4 every time you wish to quit the form and save your progress. NOTES: -- Please refer to the specific recommendation and relevant section or page number of the Initial Report for additional details and context about each recommendation. Where applicable, you are encouraged to reference sections in the report for ease of the future review by the EPDP Team. --Your comments should take into account scope of the EPDP as described by the Charter and General Data Protection Regulation (GDPR) compliance. --For transparency purposes, all comments submitted to the Public Comment forum will be displayed publicly via an automatically-generated Google Spreadsheet. Email addresses provided by commenters will not be displayed. --To maximize the visibility of your comments to the EPDP Team, please submit your comments via this form only. If you are unable to use this form, alternative arrangements can be made. --Please note you may encounter a character limit in your responses when editing a previous submission. (There are no character limits when making a first-time submission.) In the event you encounter a character limit, you may send an email to policy-staff at icann.org, and the EPDP Support Staff will assist you with your response. --The final date of the public comment proceeding is 23:59 UTC on 21 December 2018. Any comments received after that date will not be reviewed / discussed by the EPDP Team. > > Table of Contents > > Page 1: Email Address, Important Instructions, Table of Contents Page 2: Consent & Authorization Page 3: Section 3, Part 1: Purposes for Processing Registration Data ? Recommendation #1 Page 4: Section 3, Part 1: Purposes for Processing Registration Data (Continued) ? Recommendations #2-3 Page 5: Section 3, Part 2: Required Data Processing Activities ? Recommendations #4-13 Page 6: Section 3, Part 3: Data Processing Terms, i.e., roles and responsibilities of parties ? Recommendation #14 Page 7: Section 3, Part 4: Updates to Other Consensus Policies ? Recommendations #15-20 Page 8: Section 3, Other Recommendations ? Recommendations #21-22 Page 9: Other Comments & Submission > > Consent & Authorization > > By submitting my personal data, I agree that my personal data will be processed in accordance with the ICANN Privacy Policy ([https://www.icann.org/privacy/policy](https://www.google.com/url?q=https://www.icann.org/privacy/policy&sa=D&ust=1545434796396000&usg=AFQjCNHruKQyRE9bWk6naJkGMJ1wt6XqpA)), and agree to abide by the website Terms of Service ([https://www.icann.org/privacy/tos](https://www.google.com/url?q=https://www.icann.org/privacy/tos&sa=D&ust=1545434796396000&usg=AFQjCNHXEXDS2O93Q6O5Up1w8L3I-dvMTw)). > > Please provide your name: > > * > > Ayden F?rdeline > > Please provide your affiliation > > * > > Non-Commercial Stakeholders Group > > Are you providing input on behalf of another group (e.g., organization, company, government)? > > * > > - Yes > > - No > > If yes, please explain: > > Non-Commercial Stakeholders Group > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I would like to continue to the next section > > Section 3, Part 1: Purposes for Processing Registration Data > > The EPDP team was tasked with determining whether the ICANN and Contracted Party Purposes for Processing Registration Data listed in the Temporary Specification are appropriate and if additional ?Purposes? are required. The Team developed DNS requirements, the data requirements, and mapped data flows in order to identify these purposes. > > Recommendation #1: Purposes for Processing Registration Data > > The EPDP Team recommends that the following purposes for processing gTLD Registration Data form the basis of the new ICANN policy: Note that for each of the below purposes, the EPDP Team has also identified: (i) the related processing activities; (ii) the corresponding lawful basis for each processing activity; and (iii) the data controllers and processors involved in each processing activity. For more information regarding the above, please refer to the Data Elements Workbooks which can be found in the Annex D of the Initial Report. > > PURPOSE 1 FOR PROCESSING REGISTRATION DATA: > > AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (I) TO ESTABLISH THE RIGHTS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND (III) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER > > Please choose your level of support for Purpose 1: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #1, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > Please provide rationale for your recommendation. > > An official record of the Registered Name Holder?s (RNH) data is needed to assign exclusive control of it to the RNH and to enable the domain name registrant to assert its rights over a domain name. > > PURPOSE 2 FOR PROCESSING REGISTRATION DATA > > MAINTAINING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION THROUGH THE ENABLING OF LAWFUL ACCESS FOR LEGITIMATE THIRD-PARTY INTERESTS TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN > > Choose your level of support of Purpose #2: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #2, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > Please provide rationale for your recommendation. > > Purpose 2 is vague and does not specify what is involved in ?maintaining the security, stability, and resiliency of the domain name system in accordance with ICANN?s mission?. The NCSG has held the position from the start of the discussion on this purpose that what is interpreted to be within the scope of ICANN?s mission in relation to SSR needs to be identified in order for this purpose to hold any true meaning. When the topic had been raised, there was significant disagreement within the EPDP on what the interpretation of the bylaws relevant to SSR includes, thus leading to disagreement on what the scope of this purpose should include. The current vague wording of this purpose seems to intentionally attempt to bypass this discussion (one on which there is likely to be no consensus), and leave the interpretation of the scope of ICANN?s SSR duties to the implementation of this policy recommendation. The NCSG does not find this to be appropriate. Note that the need to be specific in identifying the scope of ICANN?s mission when defining purposes was clearly communicated to the GNSO Next-Generation gTLD RDS to Replace WHOIS PDP WG by EU data protection experts in May 2017, when they said: ?Purpose has to be defined in advance of the data processing. Purposes have to have a legitimate aim and the processing has to be necessary and proportionate to the legitimate aim pursued. Translating this to ICANN means the working group would want to take a look into ICANN role and its mission statement and separate out the legitimate data processing purposes, and determine which data are necessary for which purpose.? [1] [1] https://community.icann.org/download/attachments/64078601/ICANN58-DataProtectionExpert-Responses-7April2017-plus-Intro.pdf > > PURPOSE 3 FOR PROCESSING REGISTRATION DATA > > ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME > > Choose your level of support of Purpose #3: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #3, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > Please provide rationale for your recommendation. > > This is a legitimate purpose that is consistent with ICANN?s mission. Notification and communication with the Registered Name Holder for purposes of technical and/or administrative issue handling is helpful and necessary for both registrants and registrars. > > PURPOSE 4 FOR PROCESSING REGISTRATION DATA > > PROVIDE MECHANISMS FOR SAFEGUARDING REGISTERED NAME HOLDERS' REGISTRATION DATA IN THE EVENT OF A BUSINESS OR TECHNICAL FAILURE, OR OTHER UNAVAILABILITY OF A REGISTRAR OR REGISTRY OPERATOR > > Choose your level of support of Purpose #4: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #4, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > Please provide rationale for your recommendation. > > It is legitimate to collect and process data for this purpose, as it supports the rights and interests of the registrant. > > PURPOSE 5 FOR PROCESSING REGISTRATION DATA > > HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS > > Choose your level of support of Purpose #5: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #5, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > Please provide the rationale for your recommendation. > > Authoritative data about the registrant, the registration, and its contact details can be required for assessing compliance with ICANN policies and for following up on complaints. In particular, ICANN org itself may need to process this data to monitor compliance with its policies. As long as processing of specific data that is fit-for-purpose is strictly restricted to parties who need it for this defined purpose, the NCSG can support Purpose 5. > > PURPOSE 6 FOR PROCESSING REGISTRATION DATA > > COORDINATE, OPERATIONALIZE, AND FACILITATE POLICIES FOR RESOLUTION OF DISPUTES REGARDING OR RELATING TO THE REGISTRATION OF DOMAIN NAMES (AS OPPOSED TO THE USE OF SUCH DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. > > Choose your level of support of Purpose #6: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #6, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > The NCSG requests that the first sentence of Purpose 6 be streamlined by replacing ?coordinate, operationalize, and facilitate? with ?operationalize?. > > Please provide rationale for your recommendation. > > Authoritative data about the registrant, the registration, and contact details can be required for executing ICANN?s dispute resolution policies against the registrant itself. As long as disclosure of the private data is restricted to the parties who need it for this defined purpose, the NCSG can support Purpose 6. > > PURPOSE 7 FOR PROCESSING REGISTRATION DATA > > ENABLING VALIDATION TO CONFIRM THAT REGISTERED NAME HOLDER MEETS OPTIONAL GTLD REGISTRATION POLICY ELIGIBILITY CRITERIA VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR > > Choose your level of support of Purpose #7: > > - Support Purpose as written > > - Support Purpose intent with wording change > > - Significant change required: changing intent and wording > > - Purpose should be deleted > > If your response requires an edit or deletion of Purpose #7, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). > > The NCSG believes this purpose should be deleted in its entirety. Editing should not be considered. > > Please provide rationale for your recommendation. > > Data required for validation could include a wide range of sensitive personal data enabling the identification of individuals or protected groups. There is absolutely no need for this kind of data to be in the RDDS. Registry Operators can and currently do collect and validate this data on their own. Since each specialized registry (including brand registries) have different criteria for validation, this purpose risks opening the door to potentially hundreds of new data elements. Further, it is dangerous and inappropriate for this data to be placed in a global directory that can be accessed by third parties. gTLD validation processes should be limited to individual registries only, and the data needed to do that should not be placed in the RDDS. > > Enter additional comments to Recommendation #1. > > Question #1 for Community Input: Purposes for Processing Registration Data > > If you recommend additional purposes for processing registration data, please enumerate and write them here, keeping in mind compliance with GDPR. > > No additional purposes are required. The addition of new data elements to the RDDS is beyond the scope of the EPDP Team?s work. The EPDP Team has a narrow charter, and was not chartered to create new features and purposes for processing gTLD Registration Data. The NCSG believes such an issue is best taken up in the GNSO Next-Generation RDS to Replace WHOIS PDP, should this PDP Working Group ever be reconvened, or alternatively to be addressed by any PDP Working Group that replaces it in determining RDS functions that fall outside of the scope of this EPDP. > > For each additional purpose identified above, please enumerate and provide rationale for each of them. > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I wish to continue to the next section > > Section 3, Part 1: Purposes for Processing Registration Data (Continued) > > Recommendation #2: Standardized Access > > Per the EPDP Team Charter, the EPDP Team is committed to considering a system for Standardized Access to non-public Registration Data once the gating questions in the charter have been answered. This will include addressing questions such as: ? What are the legitimate purposes for third parties to access registration data? ? What are the eligibility criteria for access to non-public Registration data? ? Do those parties/groups consist of different types of third-party requestors? ? What data elements should each user/party have access to? In this context, amongst others, disclosure in the course of intellectual property infringement and DNS abuse cases will be considered. > > Choose your level of support of Recommendation #2: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > Do you recommend a change to the wording of Recommendation 2? If so, please indicate proposed edits here. > > The NCSG asks that the term ?Standardized Access to nonpublic Registration Data? be replaced with the term, ?Lawful disclosure of personal and sensitive registration data to third parties with legitimate interests.? > > Please include the rationale for your answers here. > > In essence, Recommendation 2 is simply a restatement of one aspect of the EPDP?s charter. We note that later on in this report, the wording change we proposed here was accepted. > > Enter additional comments for Recommendation #2. > > Recommendation #3: Contractual Accuracy Requirements > > The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy. > > Choose your level of support of Recommendation #3: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > Do you recommend a change to Recommendation 3? If so, please indicate proposed edits here. > > Please include the rationale for your answers here. > > The NCSG supports this recommendation as it is written. We do not support making changes to existing accuracy requirements, as policies regarding accuracy are not within the remit of the Temporary Specification. > > Enter any other additional comments or observations you have on Section 3 Part 1 that are not covered by these questions. > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I wish to continue to the next section > > Section 3, Part 2: Required Data Processing Activities > > Recommendation #4: Data Elements > > The EPDP Team recommends that the data elements defined in the data elements workbooks in Annex D are required to be collected by registrars. In the aggregate, this means that the following data elements are to be collected (or automatically generated): Data Elements (Collected and Generated) Note, Data Elements indicated with ** are generated either by the Registrar or the Registry Domain Name** Registry Domain ID** Registrar Whois Server** Registrar URL** Updated Date** Creation Date** Registry Expiry Date** Registrar Registration Expiration Date** Registrar** Registrar IANA ID** Registrar Abuse Contact Email** Registrar Abuse Contact Phone** Reseller** Domain Status** Registry Registrant ID** Registrant Fields: ? Name ? Organization (optional) ? Street ? City ? State/province ? Postal code ? Country ? Phone ? Phone ext (optional) ? Fax (optional) ? Fax ext (optional) ? Email Tech ID (optional) Tech Fields: ? Name (optional) ? Phone (optional) ? Email (optional) Name Server DNSSEC (optional) Name Server IP Address** Last Update of Whois Database** Additional optional data elements as identified by Registry Operator in its registration policy, such as (i) status as Registry Operator Affiliate or Trademark Licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT] > > Question #2 for Community Input > > Do you agree that all these data elements should be collected / generated to achieve the Purposes identified in the Initial Report? > > - Yes > > - No > > If your answer is ?no?, please enumerate which data elements should not be collected / generated. > > The NCSG opposes the inclusion of ?Additional optional data elements as identified by Registry Operator in its registration policy.? > > Please provide the rationale for your answer. > > As noted in our response to Purpose #7, the NCSG opposes the expansion of registration data elements to include potentially unlimited numbers of new data elements reflecting the individual policies of different registry operators. > > If you believe additional data elements should be collected / generated, please enumerate which additional elements should be collected / generated. > > Please provide the rationale for your answer. > > Recommendation #4 Continued: Optional Data Elements > > The EPDP Team recommends that the following data elements are optional for the Registered Name Holder (RNH) to provide: ? technical contact name ? technical contact email and ? technical contact phone number The EPDP Team has discussed two definitions of the term ?optional? as used in this recommendation: (1) registrars must offer the data field and registrants can decide whether to fill in the field or leave in blank (in which case the query would return the registered name hold data; OR (2) registrars can offer this field at their option > > Should the technical contact fields be optional or mandatory (where mandatory means the registrar must offer the fields AND the RNH must fill in information)? > > - Optional > > - Mandatory > > Please provide the rationale for your answer. > > The technical contact field is a legacy element that predates the existence of registrars. Currently, the de facto technical contact for all registered domains is the registrar. The name of the registrar and the contact information for the registrar are already included in the Whois data, so there is no need for an additional technical contact. If the Registered Name Holder really wants a different person or organization listed as a Tech-C it should be optional (where optional means that it is optional for the registrar to seek collection of the data, and optional for the Registered Name Holder to provide it upon a request to have it collected). Furthermore, the principle of data minimization suggests that if a data element is only optional, or not necessary for processing activities or to fulfil a contractual requirement to which the data subject is a party; that it should not be collected or further processed. Ideally, these data elements should not be collected at all. > > If your answer is 'optional', should registrars be required to offer these technical contact fields? > > - Yes > > - No > > Please provide the rationale for your answer. > > Some registrars feel that compliance with the GDPR and its principle of data minimization requires them to eliminate a data field that is not really used. It is best to allow them to navigate the legal risks based on their own judgment. The registrar market is competitive so if there is real consumer demand for this field then registrars can/will offer it. > > The EPDP team recommends that contact information for billing and administrative contacts should not be collected. Do you agree that this information should not be collected? > > - Yes > > - No > > Please provide the rationale for your answer. > > These are also legacy fields that predate ICANN. They are not needed. Billing contact is almost always the same as Admin and/or Technical contact. > > Enter additional comments for Recommendation #4 here. > > Recommendation #5: Transmission of Data from Registrar to Registry > > The EPDP Team recommends that the specifically-identified data elements under ?[t]ransmission of registration data from Registrar to Registry? within the data elements workbooks must be transferred from Registrar to Registry. In the aggregate, these data elements are the same as those in Recommendation #4 for the reasons stated in the Data Workbooks found in Annex D of the Initial Report. > > Do you agree that all these data elements should be transferred from the registrar to the registry? > > - Yes > > - No > > If your answer is ?no?, please enumerate which data elements should not be transferred from the registrar to the registry. > > Please provide the rationale for your answer. > > Once registration records have been appropriately redacted, then the transmission of the redacted data elements to the registry may be appropriate and legal under the GDPR. However, we note that the registries of ICANN are expressly not required to be in the member states of the European Union or in territories declared ?adequate? by the relevant authorities. We have seen many new gTLD registries incorporated in countries which do not have comprehensive data protection laws (and do have strong laws requiring the sharing of data with law enforcement), including the United States. We note that the use of the data of a domain name registration for the prosecution of content, including for moral, ethnic, religious, and especially gender and sexual orientation speech, is growing. The GDPR does not allow us to collect and transmit data elements that will endanger data subjects in jurisdictions to which their personal data and sensitive data could be weaponized against them. Such power over registrant freedoms cannot be delegated to ICANN or ICANN-accredited registries who are not bound by the GDPR, and cannot (even by contract) waive their local obligations to respond to law enforcement demands. Accordingly, the GDPR prohibits the processing of this registrant data -- and similarly, transmission of this registrant data to registries who cannot possibly comply with the GDPR requirements. > > Enter additional comments for Recommendation #5 here. > > Recommendation #6: Transmission of Data to Data Escrow Providers > > 1. The EPDP Team recommends that ICANN Org enter into legally-compliant data processing agreements with the data escrow providers. 2. The EPDP Team recommends updates to the contractual requirements for registries and registrars to transfer data that they process to the data escrow provider to ensure consistency with the data elements workbooks that analyze the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data. 3. The data elements workbook that analyzes the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data Registration Data contains the specifically-identified data elements the EPDP Team recommends be transferred by Registries and Registrars to data escrow providers (see Annex D, Workbook 4). > > Choose your level of support of Recommendation #6: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording here. Additionally, please enumerate which data elements should not be transferred from the registrar/registry to the data escrow provider. > > Please provide the rationale for your answer. > > Recommendation 6 is an appropriate measure to ensure that all data processing activities in which ICANN engages are compliant with data protection law. Registrars and registries must be given the opportunity to transfer to data escrow providers in countries covered by or deemed ?adequate? under GDPR. > > Enter additional comments for Recommendation #6 here. > > Recommendation #7: Transmission of Data from Registries/Registrars to ICANN Compliance > > 1. The EPDP Team recommends that updates are made to the contractual requirements for registries and registrars to transfer to ICANN Compliance the domain name registration data that they process when required/requested, consistent with the data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users (see Annex D, Workbook 5). 2. The data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users contains the specifically-identified data elements the EPDP Team recommends be transferred from registries and registrars to ICANN Compliance (see Annex D, Workbook 5). > > Choose your level of support of Recommendation #7: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > Do you agree that all of these data elements should be transferred from the registrar to ICANN? > > - Yes > > - No > > If your answer is ?no?, please enumerate which data elements should not be transferred from the registrar to ICANN. > > See below > > Please provide the rationale for your answer. > > We answer ?No? here only because the NCSG believes that requests by ICANN Compliance should be limited to those elements required to accommodate issues they will deal with at that time. In principle, this could mean that all data elements are required, but not all elements will be needed for other purposes. We wish to underline the principle that compliance requests should not be open-ended fishing expeditions. We note that ICANN Compliance rules should be more subject to review and understanding by the community, and that there are concerns (and reports) that complaints are being used, in part, as harassment and fishing expeditions against registrants. Accordingly, transfer of data elements even to ICANN Compliance should be subject to special evaluation and review -- not automatically done regardless of purposes, scope and scale. > > Enter additional comments for Recommendation #7 here. > > Recommendation #8: Data Redaction > > The EPDP Team recommends that redaction must be applied as follows to the data elements that are collected. Data elements neither redacted nor anonymized must appear in a freely accessible directory. NOT REDACTED Domain Name Registrar Whois Server Registrar URL Updated Date Creation Date Registry Expiry Date Registrar Registration Expiration Date Registrar Registrar IANA ID Registrar Abuse Contact Email Registrar Abuse Contact Phone Reseller Domain Status Registrant Fields ? State/province ? Country ? Anonymized email / link to web form Tech Fields ? Anonymized email / link to web form NameServer(s) DNSSEC No Name Server IP Address Last Update of Whois Database REDACTED Registrant Fields ? Name ? Street ? City ? Postal code ? Phone ? Email Tech Fields ? Name ? Phone ? Email UNDECIDED (REDACTED/ NOT REDACTED) ? Organization (opt.) Please reference page 14-15 of the Initial Report for details of the data elements. > > Do you agree that all of these data elements should be redacted? > > - Yes > > - No > > If your answer is ?no?, please enumerate the data elements that should not be redacted. > > The NCSG requests the redaction of an additional data element: the State/Province field. > > Please provide the rationale for your answer. > > In nearly all cases, country level data will be sufficient to determine relevant jurisdiction for disputes resolution. When this is not sufficient, parties with legitimate interest can request disclosure. Including the State/Province in public data, in conjunction with other information, may allow identification of individuals by those without a legitimate interest. > > The EPDP Team is of divided opinion as to whether "Organization" should be redacted for reasons stated in the Initial Report. Please see the Initial Report, beginning on p. 42. Should the "Organization" field be redacted? > > - Yes > > - No > > Please provide rationale for your answer above. > > Many natural persons operate small organizations or businesses and contact data in their domain registration will be indistinguishable from that of an individual residence. Also, some organizations might be targeted merely because of their legal political, religious, or social affiliations. Legal advice provided to the GNSO Next-Generation RDS to replace WHOIS PDP Working Group explained that any data element that assists in making a natural person (RNH) identifiable, in conjunction with other data elements, should be treated as personal information, even if the data element does not appear to be personal information in itself. Combining the ?Organization? field with others such as state or city would certainly make a Registered Name Holder more identifiable. > > Enter additional comments for Recommendation #8. > > Recommendation #9: Organization Field > > The EPDP Team recommends that registrars provide further guidance to a Registered Name Holder concerning the information that is to be provided within the Organization field. (For further information, please refer to the Initial Report discussion, beginning on p. 42). > > Choose your level of support of Recommendation #9: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording here. > > Please provide the rationale for your answer. > > ?Guidance? is a poor substitute for redaction. At best, ?guidance? from registrars will reduce some of the risk of inadvertent or mistaken data about natural persons being placed in the DNS record; but redacting the field will reduce all of it. Redaction provides a much more certain response to the potential problem. > > Additional comments for Recommendation #9. > > Recommendation #10: Provision of Email Address/Web Form > > In relation to facilitating email communication between third parties and the registrant, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. > > Choose your level of support of Recommendation #10: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you believe edits are needed for Recommendation #10, please propose edits here. > > Please provide the rationale for your answer. > > Additional comments for Recommendation #10. > > Publication of the registrant?s email address in a way that can be automatically harvested and used for any purpose is clearly not acceptable and not compliant with the GDPR. Recommendation 10 is a good way to optimize privacy while furthering the goal of contactability articulated by Purpose 3. > > Recommendation #11: Data Retention > > The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of one year following the life of the registration. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (?TDRP?). > > Choose your level of support of Recommendation #11: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #11, please provide proposed edits here. > > Please provide the rationale for your answer. > > Retaining the registration data for a year can help protect the rights of registrants and was seen as a legitimate purpose for data collection by contracted parties. > > Additional comments for Recommendation #11. > > Question 3 for Community Input: Differentiating Registrants: Legal v. Natural Persons; and Effects of Geographic Location > > What other factors should the EPDP team consider about whether Contracted Parties should be permitted or required to differentiate between registrants on a geographic basis? (For more information, please refer to the Initial Report, beginning on p. 47. > > A factor not properly aired in the Initial Report is the Internet?s status as a global infrastructure and ICANN?s status as a uniform policy maker for the global Domain Name System. One of the main reasons for creating ICANN was to ensure that the Domain Name System would have a globally consistent set of rules. The NCSG strongly opposes fragmenting the policies regarding domain name registration data on a geographic basis for that reason. ICANN should strive as much as possible to keep its rules and requirements the same for the entire Domain Name System. This helps maintain the global compatibility of the Internet. Recently published EDPB guidelines on territorial scope also indicate that there are more factors that require consideration on the territorial scope of GDPR, including targeting criteria (if the sale of goods and services is targeting EU/EEA residents) as well as whether the data controllers and/or processors have stable establishments located within the EU, irrespective of whether the associated data processing activities take place within the EU, or not. > > Please provide the rationale for your above answer. > > Are there any other risks associated with differentiation of registrants on a geographic basis? If so, please identify those factors and/or risks and how they would affect possible recommendations, keeping in mind compliance with the GDPR. > > What other factors should the EPDP team consider about whether Contracted Parties should be permitted or required to differentiate between natural and legal persons? > > The current discussion in the Initial Report covers all of the relevant factors regarding natural vs legal persons. There is a clear choice between staying firmly within the boundaries of data protection law on the one hand, and exposing more data for the sake of data miners and surveillance interests on another hand. The NCSG strongly believes that there is no need to consider additional factors. > > Please provide the rationale for your above answer. > > The NCSG strongly opposes any attempt to require registrars to separate natural and legal persons at the point of registration. Any attempt to sort out who is an organization and who is a natural person will pose major risks, and impose major cost burdens, on the contracted parties. More importantly, however, Registered Name Holders will be at risk of harm, because many registrants will not understand the distinction and will end up being misclassified as organizations and thus lose their legal entitlement to data protection. Furthermore, the GDPR does not distinguish between the protection of natural and legal persons per se, but rather the protection of personal data of natural persons, which is very likely to be included in gTLD Registration Data of domain names registered by legal persons. The obvious example is the Registered Name Holder email address, which would belong to an employee or representative of the legal person, typically being name at domain.TLD. > > Should there be further study as to whether whether procedures would be feasible to accurately distinguish on a global scale whether registrants/contracted parties fall within jurisdiction of the GDPR or other data protection laws? Please provide a rationale. > > No. The ?E? in EPDP means expedited. The purpose of this exercise is to quickly turn the temporary specification into a consensus policy following ICANN procedures. Pausing to conduct studies about adding new elements into domain registration contracts is not appropriate in this expedited proceeding. Stakeholders who want to explore this further, have the possibility to initiate new PDPs after the tight deadline for this EPDP is met. New policies can always be proposed. The NCSG believes that there is no time for further studies within the timeframe of this EPDP. > > Are you aware of existing examples where a legal/natural differentiation is already made and could it apply at a global scale for purposes of registration data? If yes, please provide additional information. > > There are no directly applicable examples that would work at a global scale. > > Recommendation #12: Reasonable Access > > The EPDP Team recommends that the current requirements in the Temporary Specification in relation to reasonable access remain in place until work on a system for Standardized Access to Non-Public Registration Data has been completed, noting that the term should be modified to refer to ?parameters for responding to lawful disclosure requests.? Furthermore, the EPDP Team recommends that criteria around the term ?reasonable? are further explored as part of the implementation of these policy recommendations addressing: o [Practicable]* timelines criteria for responses to be provided by Contracted Parties; o Format by which requests should be made and responses are provided; o Communication/Instructions around how and where requests should be submitted; o Requirements for what information responses should include (for example, auto-acknowledgement of requests and rationale for rejection of request); o Logging of requests. [*Some concern expressed that timeliness that should not be translated into requirements that are impractical for contracted parties]. > > Choose your level of support of Recommendation #12: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you believe edits are needed for Recommendation #12, please propose them here. > > The NCSG strongly supports replacing ?Standardized Access to Non-Public Registration Data? with ?parameters for requesting lawful disclosure requests,? as that more accurately describes the objective. > > Please provide the rationale for your answer. > > The NCSG strongly supports replacing ?Standardized Access to Non-Public Registration Data? with ?parameters for requesting lawful disclosure requests,? as that more accurately describes the objective. We understand that the topic of lawful disclosure is a controversial one and may take some time to resolve fully. In the meantime, the general guideline in the temp specification, subject to the modification proposed in Recommendation 12 and further fleshing out of the parameters in the implementation process as proposed above, is something that all stakeholder groups can support. > > Additional comments for Recommendation #12. > > It will simply be insufficient to state a mere category of request for data; for instance, ?intellectual property allegation? or ?law enforcement need.? The requirements of the GDPR dictate that prior to revealing the personal and sensitive data of a data subject, there is a balancing test that must take place. > > Recommendation #13: Joint Controller Agreements > > Based on the information and the deliberations the EPDP Team had on this topic and pending further input and legal advice, the EPDP Team recommends that ICANN Org negotiates and enters into a Joint Controller Agreement (JCA) with the Contracted Parties. In addition to the legally required components of such agreement, the JCA shall specify the responsibilities of the respective parties for the processing activities as described below. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that have the primary interest in the processing. > > Choose your level of support of Recommendation #13: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you believe changes are needed for Recommendation #13, please provide proposed edits here. > > Please provide the rationale for your answer. > > Understanding and specifying the roles and responsibilities of ICANN and the contracted parties is a critical and unavoidable part of compliance with the GDPR. There can be disagreements about the appropriate definition of roles, indemnification, and so on, but there cannot be any serious disagreement about the need to enter into such an agreement. Based on our understanding of the GDPR, ICANN and the contracted parties are joint controllers with respect to the Whois (or RDDS). We also believe that a joint controller agreement is the best way to achieve clear and simple lines of responsibility when there are multiple participants and complex processing structures. This will protect data subjects by preventing a splitting of responsibilities in ways that allow the controllers and processors to avoid responsibility. > > Additional comments for Recommendation #13. > > Enter any other additional comments or observations you have on Section 3, Part 2 that are not covered by these questions. > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I wish to continue to the next section > > Section 3, Part 3: Data Processing Terms > > Recommendation #14: Data Processing Roles & Responsibilities > > The EPDP Team recommends that the policy includes the following data processing activities as well as responsible parties. Please reference the Initial Report, beginning on p. 63 for further details. > > Choose your level of support of Recommendation #14: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not agree with the enumerated data processing activities and responsible parties, please provide proposed edits, including specific processing activities that need to be added/deleted here. The EPDP team particularly seeks feedback with the assignment of roles such as: ?joint-controller,? ?controller,? and ?processor. > > Please provide your rationale for the proposed addition/deletion. > > The NCSG supports the intent of this recommendation, and the identification of the different processing activities and responsible parties (controllers and processors) for each. However, the NCSG maintains that we disagree with the inclusion of Purpose #2 and Purpose #7 as they are currently worded in the initial report, and therefore, cannot support any of the processing activities and responsible parties associated with them at this time. > > Additional comments for Recommendation #14. > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I wish to continue to the next section > > Section 3, Part 4: Updates to Other Consensus Policies > > Enter any general comments or observations you may have on the findings in Section 3, Part 4. > > Recommendation #15: Uniform Rapid Suspension/Uniform Domain Name Dispute Resolution Policy Requirements > > The EPDP Team recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to URS and UDRP until such time as these are superseded by recommendations from the RPMs PDP WG (if any). > > Choose your level of support of Recommendation #15: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not agree that the current updated requirements in the UDRP and URS, as provided in the Temporary Specification should remain in place, please provide proposed edits to the current requirements. > > Please provide the rationale, keeping in mind compliance with GDPR. > > The EPDP is supposed to deal primarily with bringing ICANN?s Whois/RDDS into compliance with GDPR. In some cases there are interactions between Whois policy and UDRP and URS procedures. Rather than trying to modify additional policies via the EPDP, we should leave the temporary specification in place and allow the GNSO?s Rights Protection Mechanism PDP to take up the other issues. The extent to which these policies are addressed here should be limited to the extent to which gTLD Registration Data is processed within the context of DRP proceedings. > > Additional comments for Recommendation #15. > > We note that under the Temporary Specification, UDRP and URS proceedings are continuing, with Providers requesting and Registrars sharing registrant data on showing of a complaint filing. These proceedings are moving forward unabated -- with complaints continuing to processed and registrants continuing to be informed (via Notice). We further note it is our understanding that the RPM PDP WG has been reviewing this matter as part of its URS recommendation (UDRP review will not come until a later Phase 2), and is planning to make draft policy recommendations to facilitate URS processing in its upcoming Initial Report in 2019. > > Recommendation #16: Instruction to GNSO and Rights Protection Mechanisms Policy Development Working Group > > The EPDP Team also recommends that the GNSO Council instructs the review of all RPMs PDP WG to consider, as part of its deliberations, whether there is a need to update existing requirements to clarify that a complainant must only be required to insert the publicly-available RDDS data for the domain name(s) at issue in its initial complaint. The EPDP Team also recommends the GNSO Council to instruct the RPMs PDP WG to consider whether upon receiving updated RDDS data (if any), the complainant must be given the opportunity to file an amended complaint containing the updated respondent information. > > Choose your level of support of Recommendation #16: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #16, please provide proposed text/edits. > > Please provide the rationale for your answer. > > This is a fair way to handle disjunctions between the UDRP and URS ? which assumed legacy Whois ? and the temporary specification regime, which redacts most personally identifiable information. This recommendation merely brings certain issues to the attention of the RPM PDP, it does not however, tell them how to resolve them. > > Provide additional comments for Recommendation #16 here. > > We note that it is our understanding that the RPM PDP WG has been reviewing this matter as part of its URS recommendation (UDRP review will not come until a later Phase 2), and is planning to make draft policy recommendations to facilitate URS processing in its upcoming Initial Report in 2019. > > Recommendation #17: UDRP/URS > > The EPDP Team requests that when the EPDP Team commences its deliberations on a standardized access framework, a representative of the RPMs PDP WG shall provide an update on the current status of deliberations so that the EPDP Team may determine if/how the WG?s recommendations may affect consideration of the URS and UDRP in the context of the standardized access framework deliberations. > > Choose your level of support of Recommendation #17: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #17, please provide proposed edits or changes. > > Given the timeline to which the EPDP Team is working, the EPDP Team may complete its work before the RPM PDP WG enters its Phase 2 discussions involving UDRP disclosures. URS discussions (already taking place) may provide the EPDP Team with insight into the deliberations, discussion and draft policy recommendations on URS (which will, in turn, shed light on UDRP). > > Please provide the rationale for your answer. > > This recommendation merely facilitates coordination between the EPDP and the RPM PDP. > > Provide additional comments for Recommendation #17 here. > > Recommendation #18: Data Processing Agreements > > The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed, as this will affect the ability to have publicly-available decisions. > > Choose your level of support of Recommendation #18: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not agree to Recommendation #18, please provide proposed edits or changes here. > > Please provide the rationale for your answer here. > > This change is probably necessary in order to reconcile EPDP recommendations with arrangements with existing UDRP providers. > > Provide additional comments for Recommendation #18 here. > > ICANN Org may also need to enter into data processing agreements with dispute resolution providers to limit the publication of personal and sensitive information about registrants in UDRP and URS decisions. Such data may include the names and contact information of registrants and their attorneys, and the names and contact data of complainant attorneys. Publication of identity, organization, and other data of the registrant and its attorneys -- including in dispute proceedings where the registrant won -- is a collection activity and publication of personal and sensitive data that may well be in violation of the GDPR. The UDRP and URS decision, and even the transfer of domain names, does not require such public disclosure as a necessary part of technical implementation. We further note that older UDRP and URS cases may need to be redacted for publication of personal and sensitive data of the registrant and his/her/its attorneys, email addresses, and other data. > > Question #4 for Community Input > > Are there any changes that the EPDP Team should consider in relation to the URS and UDRP that have not already been identified? > > If so, please provide the relevant rationale, keeping in mind compliance with the GDPR. > > Recommendation #19: Transfer Policy > > The EPDP Team recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to the Transfer Policy until such time these are superseded by recommendations that may come out of the Transfer Policy review that is being undertaken by the GNSO Council. > > Choose your level of support of Recommendation #19: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #19, please provide proposed changes/edits here. > > Please provide the rationale for your answer, keeping in mind compliance with GDPR. > > This recommendation handles appropriately an interdependence between the Temporary Specification and the Transfer policy appropriately. > > Provide additional comments for Recommendation #19 here. > > Recommendation #20: Transfer Policy > > The EPDP Team recommends that the GNSO Council, as part of its review of the Transfer Policy, specifically requests the review of the implications, as well as adjustments, that may be needed to the Transfer Policy as a result of GDPR. > > Choose your level of support of Recommendation #20: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #20, please provide proposed edits/changes here. > > Please provide the rationale for your answer here. > > Provide additional comments for Recommendation #20 here. > > Question #5 for Community Input > > Are there any changes that the EPDP Team should consider in relation to the Transfer Policy that have not already been identified? If so, please provide the relevant rationale, keeping in mind compliance with the GDPR. > > Enter any other additional comments or observations you have on Section 3, Part 3 that are not covered by these questions. > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I wish to continue to the next section > > Section 3: Other Recommendations > > Enter any general comments or observations you may have on the findings in Section 3, Other Recommendation. > > Recommendation #21: Joint Controller and Data Processing Agreements > > The EPDP Team recommends that ICANN Org enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the non-Contracted Party entities involved in registration data processing such as data escrow providers and EBERO providers. These agreements are expected to set out the relationship obligations and instructions for data processing between the different parties. > > Choose your level of support of Recommendation #21: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #21, please provide proposed edits/changes here. > > Recommendation should add ?but not including the domain name registrant? after ?EBERO providers?. > > Please provide the rationale for your answer here, keeping in mind compliance with GDPR. > > The NCSG would like to clarify that we are not recommending that ICANN enter into contracts with registrants, as they are also non-contracted parties, and we would not support ICANN org moving in this direction. > > Provide additional comments for Recommendation #21 here. > > Recommendation #22: Updates to Existing Consensus Policies > > The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as a number of these refer to administrative and/or technical contact which will no longer be required data elements: ? Registry Registration Data Directory Services Consistent Labeling and Display Policy ? Thick WHOIS Transition Policy for .COM, .NET, .JOBS ? Rules for Uniform Domain Name Dispute Resolution Policy ? WHOIS Data Reminder Policy ? Transfer Policy ? Uniform Rapid Suspension System (URS) Rules Please reference the Initial Report, beginning on p. 71 for further details. > > Choose your level of support of Recommendation #22: > > - Support recommendation as written > > - Support intent of recommendation with edits > > - Intent and wording of this recommendation requires amendment > > - Delete recommendation > > If you do not support Recommendation #22, please provide proposed edits or changes here. > > Please provide the rationale for your answer here. > > This is an appropriate ?housekeeping? recommendation that will help ensure consistency of other policies affected by EPDP recommendations with the new policy. > > Provide additional comments on Recommendation #22 here. > > It will be neither simple nor easy to update existing consensus policies. As captured in the NCSG?s comments to the UDRP and URS questions above, there are important aspects of the collection and especially publication of Registrant data in UDRP and URS decisions that needs to be carefully evaluated -- as publication of personal and sensitive data in a public decision is absolutely unnecessary to implement a UDRP decision transferring a domain name. We wish to note the underlying danger that UDRP and URS proceedings will be used as a ruse for discovering the identity and location of the registrant, absent any true or provable domain name disputes. Of course, this must not be allowed to happen, and must be pursued and punished by ICANN Compliance, among others. We further note that publication of registrant name and/or contact data, including registrants who win the UDRP and URS proceedings, may be especially dangerous. The GDPR prevents those who receive personal and sensitive information for particularly purposes (e.g., UDRP and URS Complainants) from misusing, selling, distributing, aggregating and otherwise publishing the personal and sensitive data. Accordingly, RDDS data disclosed to a dispute provider pursuant to a UDRP or URS (or other future registrant-related dispute proceeding) must be expressly protected by all reasonable updates to existing consensus policies. Finally, appropriate revisions to existing consensus policies must be written to ensure that commitments made to limits on the use and disclosure of registrant RDDS data in UDRP and URS proceedings are followed. Provisions must be drafted and agreed to by Complainants and their attorneys, and UDRP and URS dispute resolution providers, as part of any revisions to existing consensus policies. Penalties for breach must be clear, sharp, swift, and enforceable by ICANN, registrants and their representatives, and dispute resolution providers. > > Enter any other additional comments or observations you have on Section 3: Other Recommendations that are not covered by these questions. > > Save Your Progress > > Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. > > - Yes > > - No, I wish to continue to the next section > > Other Comments & Submission > > Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer. > > Save Your Progress > > [Create your own Google Form](https://docs.google.com/forms?usp=mail_form_link) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NCSG EPDP Comment.pdf Type: application/pdf Size: 392651 bytes Desc: not available URL: From rafik.dammak at gmail.com Thu Dec 27 06:22:47 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Thu, 27 Dec 2018 13:22:47 +0900 Subject: [NCSG-PC] Reminder review of NCSG comment on new gTLD supplemental report In-Reply-To: References: Message-ID: Hi all, there were some small editorial changes in the draft but nothing substantial https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit. if there is objection within the next 24 hours I will submit the comment so it can be considered for review bu the subpro WG. Comments and edits are still welcome. Happy holidays! Best, Rafik Le ven. 21 d?c. 2018 ? 12:20, Rafik Dammak a ?crit : > Hi all, > > This is a reminder regarding the review of draft comment for the subpro > supplemental report. > > Best, > > Rafik > > On Wed, Dec 19, 2018, 13:13 Rafik Dammak >> Hi all, >> >> the drafting team finished the work on NCSG comment on new gTLD >> supplemental report : >> https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit >> . They are continuing the work. >> >> the deadline for submission is the Friday 21st December. Please review it >> asap. >> >> Best, >> >> Rafik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icann at ferdeline.com Thu Dec 27 08:45:40 2018 From: icann at ferdeline.com (=?UTF-8?Q?Ayden_F=C3=A9rdeline?=) Date: Thu, 27 Dec 2018 06:45:40 +0000 Subject: [NCSG-PC] Reminder review of NCSG comment on new gTLD supplemental report In-Reply-To: References: Message-ID: Thanks Rafik, I have made a number of stylistic edits to the document now. There is an unresolved comment from Robin in paragraph 13 that needs to be resolved prior to the submission of the document -- like Robin, I'm not clear on what this paragraph is saying. Milton has also flagged some logical fallacies in the document (see paragraphs 5, 6, and 8) that we may want to see to changing, though I think it might be okay to submit this comment even with them in there. But paragraph 13 is confusing and needs to be edited prior to submission. Best wishes, Ayden ??????? Original Message ??????? On Thursday, 27 December 2018 15:22, Rafik Dammak wrote: > Hi all, > > there were some small editorial changes in the draft but nothing substantial https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit. if there is objection within the next 24 hours I will submit the comment so it can be considered for review bu the subpro WG. Comments and edits are still welcome. > Happy holidays! > > Best, > > Rafik > > Le ven. 21 d?c. 2018 ? 12:20, Rafik Dammak a ?crit : > >> Hi all, >> >> This is a reminder regarding the review of draft comment for the subpro supplemental report. >> >> Best, >> >> Rafik >> >> On Wed, Dec 19, 2018, 13:13 Rafik Dammak > >>> Hi all, >>> >>> the drafting team finished the work on NCSG comment on new gTLD supplemental report :https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit . They are continuing the work. >>> >>> the deadline for submission is the Friday 21st December. Please review it asap. >>> >>> Best, >>> >>> Rafik -------------- next part -------------- An HTML attachment was scrubbed... URL: From farell at benin2point0.org Thu Dec 27 09:44:18 2018 From: farell at benin2point0.org (Farell FOLLY) Date: Thu, 27 Dec 2018 08:44:18 +0100 Subject: [NCSG-PC] Reminder review of NCSG comment on new gTLD supplemental report In-Reply-To: References: Message-ID: <99E36F1A-F162-4561-9A74-4402A8B34904@benin2point0.org> Dear Ayden, I have just read and have no comment in substance to add. @__f_f__ Best Regards ____________________________________ (Ekue) Farell FOLLY NCUC Rep. to the NCSG Policy Committee linkedin.com/in/farellf > On 27 Dec 2018, at 07:45, Ayden F?rdeline wrote: > > Thanks Rafik, I have made a number of stylistic edits to the document now. There is an unresolved comment from Robin in paragraph 13 that needs to be resolved prior to the submission of the document -- like Robin, I'm not clear on what this paragraph is saying. Milton has also flagged some logical fallacies in the document (see paragraphs 5, 6, and 8) that we may want to see to changing, though I think it might be okay to submit this comment even with them in there. But paragraph 13 is confusing and needs to be edited prior to submission. > > Best wishes, Ayden > > > ??????? Original Message ??????? > On Thursday, 27 December 2018 15:22, Rafik Dammak wrote: > >> Hi all, >> >> there were some small editorial changes in the draft but nothing substantial https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit . if there is objection within the next 24 hours I will submit the comment so it can be considered for review bu the subpro WG. Comments and edits are still welcome. >> Happy holidays! >> >> Best, >> >> Rafik >> >> Le ven. 21 d?c. 2018 ? 12:20, Rafik Dammak > a ?crit : >> Hi all, >> >> This is a reminder regarding the review of draft comment for the subpro supplemental report. >> >> Best, >> >> Rafik >> >> On Wed, Dec 19, 2018, 13:13 Rafik Dammak wrote: >> Hi all, >> >> the drafting team finished the work on NCSG comment on new gTLD supplemental report :https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit . They are continuing the work. >> >> the deadline for submission is the Friday 21st December. Please review it asap. >> >> Best, >> >> Rafik > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From farell at benin2point0.org Thu Dec 27 09:45:53 2018 From: farell at benin2point0.org (Farell FOLLY) Date: Thu, 27 Dec 2018 08:45:53 +0100 Subject: [NCSG-PC] EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form In-Reply-To: <9oF2GIaZAmnJzp0WzLy7KKX5OOEj4YdxMZ4_Uiw3IMmsiYD0Laz137SZ1P8auxUFX64jwJkOPlootXU8eA0miP_2Z9QV9tRgLulveqxZhlM=@ferdeline.com> References: <0000000000007e4e82057d8fbd94@google.com> <9oF2GIaZAmnJzp0WzLy7KKX5OOEj4YdxMZ4_Uiw3IMmsiYD0Laz137SZ1P8auxUFX64jwJkOPlootXU8eA0miP_2Z9QV9tRgLulveqxZhlM=@ferdeline.com> Message-ID: That is really a great work and I appreciate the google form input of the comments collection process. It targets specific aspects and would reveal efficient during analysis. @__f_f__ Best Regards ____________________________________ (Ekue) Farell FOLLY NCUC Rep. to the NCSG Policy Committee linkedin.com/in/farellf > On 21 Dec 2018, at 23:31, Ayden F?rdeline wrote: > > Hi all, > > For archival purposes, below is our submission re: Initial Report comment. > > I have also exported our Google Doc, where we drafted the comment, to PDF and have attached it to this email. > > Best, Ayden > > > ??????? Original Message ??????? > On Saturday, 22 December 2018 09:26, Google Forms > wrote: > >> >> >> >> >> >> >> Thanks for filling out EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form >> Here's what we got from you: >> EDIT RESPONSE >> >> EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form >> >> >> >> >> Email address >> >> * >> icann at ferdeline.com >> Important Instructions - PLEASE READ BEFORE PROCEEDING >> This Public Comment forum seeks community feedback on the Initial Report published by the Expedited Policy Development Process (EPDP) Team on the Temporary Specification for gTLD Registration Data. >> >> This is a new format for collecting public comment. It seeks to: >> -- Clearly link comments to specific sections of the initial report >> -- Encourage commenters to provide reasoning or rationale for their opinions >> -- Enable the sorting of comment so that the EPDP team can more easily read all the comments on any one topic >> >> There is no obligation to complete all sections within this form ? respond to as many or as few questions as desired. Additionally, there is the opportunity to provide comments on the general content of the Initial Report or on new issues not raised by the Initial Report. To preview all questions in the Google Form, please refer to a Word version of this form here here's the link to the Word doc: https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx . >> >> As you review the "Questions for Community Input" in the Initial Report, you will note that there is not a 1:1 correspondence with the questions asked in the Public Comment format. This is because, in some instances, the "Questions for Community Input" have been divided into multi-part questions so that feedback on these questions would be clear. The Initial Report and Comment Forum have been reviewed to ensure that all the "Questions for Community Input" have been addressed in this Comment Forum. >> >> It is important that your comments include rationale (i.e., by answering the ?rationale? question in each section). This is not a vote. The EPDP team is interested in your reasoning so that the conclusions reached and the issues discussed by the team can be tested against the reasoning of others. (This is much more helpful than comments that simply ?agree? or ?disagree?). >> >> You can easily navigate from page to page in the form. There is a table of contents below so that you can ?fast forward? to the desired section by hitting ?next? at the bottom of each page. To preview this entire form in Word format, see the link to the Word doc: https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx . >> >> To stop and save your work for later, you MUST (to avoid losing your work): >> >> 1. Provide your email address above in order to receive a copy of your submitted responses; >> >> 2. Click "Submit" at the end of the Google Form (the last question on every page allows you to quickly jump to the end of the Google Form to submit); >> >> 3. After you click "Submit," you will receive an email to the above-provided email address; within the email, click the "Edit Response" button at top of the email; >> >> 4. After you click the "Edit Response" button, you will be directed to the Google Form to return and complete; >> >> 5. Repeat the above steps 2-4 every time you wish to quit the form and save your progress. >> >> NOTES: >> -- Please refer to the specific recommendation and relevant section or page number of the Initial Report for additional details and context about each recommendation. Where applicable, you are encouraged to reference sections in the report for ease of the future review by the EPDP Team. >> >> --Your comments should take into account scope of the EPDP as described by the Charter and General Data Protection Regulation (GDPR) compliance. >> >> --For transparency purposes, all comments submitted to the Public Comment forum will be displayed publicly via an automatically-generated Google Spreadsheet. Email addresses provided by commenters will not be displayed. >> >> --To maximize the visibility of your comments to the EPDP Team, please submit your comments via this form only. If you are unable to use this form, alternative arrangements can be made. >> >> --Please note you may encounter a character limit in your responses when editing a previous submission. (There are no character limits when making a first-time submission.) In the event you encounter a character limit, you may send an email to policy-staff at icann.org , and the EPDP Support Staff will assist you with your response. >> >> --The final date of the public comment proceeding is 23:59 UTC on 21 December 2018. Any comments received after that date will not be reviewed / discussed by the EPDP Team. >> >> Table of Contents >> Page 1: Email Address, Important Instructions, Table of Contents >> >> Page 2: Consent & Authorization >> >> Page 3: Section 3, Part 1: Purposes for Processing Registration Data >> ? Recommendation #1 >> >> Page 4: Section 3, Part 1: Purposes for Processing Registration Data (Continued) >> ? Recommendations #2-3 >> >> Page 5: Section 3, Part 2: Required Data Processing Activities >> ? Recommendations #4-13 >> >> Page 6: Section 3, Part 3: Data Processing Terms, i.e., roles and responsibilities of parties >> ? Recommendation #14 >> >> Page 7: Section 3, Part 4: Updates to Other Consensus Policies >> ? Recommendations #15-20 >> >> Page 8: Section 3, Other Recommendations >> ? Recommendations #21-22 >> >> Page 9: Other Comments & Submission >> >> Consent & Authorization >> By submitting my personal data, I agree that my personal data will be processed in accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy ), and agree to abide by the website Terms of Service (https://www.icann.org/privacy/tos ). >> >> Please provide your name: >> >> * >> >> Ayden F?rdeline >> >> Please provide your affiliation >> >> * >> >> Non-Commercial Stakeholders Group >> >> Are you providing input on behalf of another group (e.g., organization, company, government)? >> >> * >> >> Yes >> No >> >> If yes, please explain: >> >> Non-Commercial Stakeholders Group >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I would like to continue to the next section >> >> Section 3, Part 1: Purposes for Processing Registration Data >> The EPDP team was tasked with determining whether the ICANN and Contracted Party Purposes for Processing Registration Data listed in the Temporary Specification are appropriate and if additional ?Purposes? are required. The Team developed DNS requirements, the data requirements, and mapped data flows in order to identify these purposes. >> >> Recommendation #1: Purposes for Processing Registration Data >> The EPDP Team recommends that the following purposes for processing gTLD Registration Data form the basis of the new ICANN policy: >> >> Note that for each of the below purposes, the EPDP Team has also identified: (i) the related processing activities; (ii) the corresponding lawful basis for each processing activity; and (iii) the data controllers and processors involved in each processing activity. For more information regarding the above, please refer to the Data Elements Workbooks which can be found in the Annex D of the Initial Report. >> >> PURPOSE 1 FOR PROCESSING REGISTRATION DATA: >> AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: >> >> (I) TO ESTABLISH THE RIGHTS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; >> >> (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND >> >> (III) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER >> >> Please choose your level of support for Purpose 1: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #1, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> >> >> Please provide rationale for your recommendation. >> >> An official record of the Registered Name Holder?s (RNH) data is needed to assign exclusive control of it to the RNH and to enable the domain name registrant to assert its rights over a domain name. >> >> PURPOSE 2 FOR PROCESSING REGISTRATION DATA >> MAINTAINING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION THROUGH THE ENABLING OF LAWFUL ACCESS FOR LEGITIMATE THIRD-PARTY INTERESTS TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN >> >> Choose your level of support of Purpose #2: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #2, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> >> >> Please provide rationale for your recommendation. >> >> Purpose 2 is vague and does not specify what is involved in ?maintaining the security, stability, and resiliency of the domain name system in accordance with ICANN?s mission?. The NCSG has held the position from the start of the discussion on this purpose that what is interpreted to be within the scope of ICANN?s mission in relation to SSR needs to be identified in order for this purpose to hold any true meaning. When the topic had been raised, there was significant disagreement within the EPDP on what the interpretation of the bylaws relevant to SSR includes, thus leading to disagreement on what the scope of this purpose should include. The current vague wording of this purpose seems to intentionally attempt to bypass this discussion (one on which there is likely to be no consensus), and leave the interpretation of the scope of ICANN?s SSR duties to the implementation of this policy recommendation. The NCSG does not find this to be appropriate. >> >> Note that the need to be specific in identifying the scope of ICANN?s mission when defining purposes was clearly communicated to the GNSO Next-Generation gTLD RDS to Replace WHOIS PDP WG by EU data protection experts in May 2017, when they said: ?Purpose has to be defined in advance of the data processing. Purposes have to have a legitimate aim and the processing has to be necessary and proportionate to the legitimate aim pursued. Translating this to ICANN means the working group would want to take a look into ICANN role and its mission statement and separate out the legitimate data processing purposes, and determine which data are necessary for which purpose.? [1] >> >> [1] https://community.icann.org/download/attachments/64078601/ICANN58-DataProtectionExpert-Responses-7April2017-plus-Intro.pdf >> >> PURPOSE 3 FOR PROCESSING REGISTRATION DATA >> ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME >> >> Choose your level of support of Purpose #3: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #3, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> >> >> Please provide rationale for your recommendation. >> >> This is a legitimate purpose that is consistent with ICANN?s mission. Notification and communication with the Registered Name Holder for purposes of technical and/or administrative issue handling is helpful and necessary for both registrants and registrars. >> >> PURPOSE 4 FOR PROCESSING REGISTRATION DATA >> PROVIDE MECHANISMS FOR SAFEGUARDING REGISTERED NAME HOLDERS' REGISTRATION DATA IN THE EVENT OF A BUSINESS OR TECHNICAL FAILURE, OR OTHER UNAVAILABILITY OF A REGISTRAR OR REGISTRY OPERATOR >> >> Choose your level of support of Purpose #4: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #4, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> >> >> Please provide rationale for your recommendation. >> >> It is legitimate to collect and process data for this purpose, as it supports the rights and interests of the registrant. >> >> PURPOSE 5 FOR PROCESSING REGISTRATION DATA >> HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS >> >> Choose your level of support of Purpose #5: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #5, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> >> >> Please provide the rationale for your recommendation. >> >> Authoritative data about the registrant, the registration, and its contact details can be required for assessing compliance with ICANN policies and for following up on complaints. In particular, ICANN org itself may need to process this data to monitor compliance with its policies. As long as processing of specific data that is fit-for-purpose is strictly restricted to parties who need it for this defined purpose, the NCSG can support Purpose 5. >> >> PURPOSE 6 FOR PROCESSING REGISTRATION DATA >> COORDINATE, OPERATIONALIZE, AND FACILITATE POLICIES FOR RESOLUTION OF DISPUTES REGARDING OR RELATING TO THE REGISTRATION OF DOMAIN NAMES (AS OPPOSED TO THE USE OF SUCH DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. >> >> Choose your level of support of Purpose #6: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #6, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> The NCSG requests that the first sentence of Purpose 6 be streamlined by replacing ?coordinate, operationalize, and facilitate? with ?operationalize?. >> >> Please provide rationale for your recommendation. >> >> Authoritative data about the registrant, the registration, and contact details can be required for executing ICANN?s dispute resolution policies against the registrant itself. As long as disclosure of the private data is restricted to the parties who need it for this defined purpose, the NCSG can support Purpose 6. >> >> PURPOSE 7 FOR PROCESSING REGISTRATION DATA >> ENABLING VALIDATION TO CONFIRM THAT REGISTERED NAME HOLDER MEETS OPTIONAL GTLD REGISTRATION POLICY ELIGIBILITY CRITERIA VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR >> >> Choose your level of support of Purpose #7: >> >> Support Purpose as written >> Support Purpose intent with wording change >> Significant change required: changing intent and wording >> Purpose should be deleted >> >> If your response requires an edit or deletion of Purpose #7, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant). >> >> The NCSG believes this purpose should be deleted in its entirety. Editing should not be considered. >> >> Please provide rationale for your recommendation. >> >> Data required for validation could include a wide range of sensitive personal data enabling the identification of individuals or protected groups. There is absolutely no need for this kind of data to be in the RDDS. Registry Operators can and currently do collect and validate this data on their own. Since each specialized registry (including brand registries) have different criteria for validation, this purpose risks opening the door to potentially hundreds of new data elements. Further, it is dangerous and inappropriate for this data to be placed in a global directory that can be accessed by third parties. gTLD validation processes should be limited to individual registries only, and the data needed to do that should not be placed in the RDDS. >> >> Enter additional comments to Recommendation #1. >> >> >> >> Question #1 for Community Input: Purposes for Processing Registration Data >> >> >> If you recommend additional purposes for processing registration data, please enumerate and write them here, keeping in mind compliance with GDPR. >> >> No additional purposes are required. >> >> The addition of new data elements to the RDDS is beyond the scope of the EPDP Team?s work. The EPDP Team has a narrow charter, and was not chartered to create new features and purposes for processing gTLD Registration Data. The NCSG believes such an issue is best taken up in the GNSO Next-Generation RDS to Replace WHOIS PDP, should this PDP Working Group ever be reconvened, or alternatively to be addressed by any PDP Working Group that replaces it in determining RDS functions that fall outside of the scope of this EPDP. >> >> For each additional purpose identified above, please enumerate and provide rationale for each of them. >> >> >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I wish to continue to the next section >> >> Section 3, Part 1: Purposes for Processing Registration Data (Continued) >> >> Recommendation #2: Standardized Access >> Per the EPDP Team Charter, the EPDP Team is committed to considering a system for Standardized Access to non-public Registration Data once the gating questions in the charter have been answered. This will include addressing questions such as: >> >> ? What are the legitimate purposes for third parties to access registration data? >> ? What are the eligibility criteria for access to non-public Registration data? >> ? Do those parties/groups consist of different types of third-party requestors? >> ? What data elements should each user/party have access to? >> >> In this context, amongst others, disclosure in the course of intellectual property infringement and DNS abuse cases will be considered. >> >> Choose your level of support of Recommendation #2: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> Do you recommend a change to the wording of Recommendation 2? If so, please indicate proposed edits here. >> >> The NCSG asks that the term ?Standardized Access to nonpublic Registration Data? be replaced with the term, ?Lawful disclosure of personal and sensitive registration data to third parties with legitimate interests.? >> >> Please include the rationale for your answers here. >> >> In essence, Recommendation 2 is simply a restatement of one aspect of the EPDP?s charter. We note that later on in this report, the wording change we proposed here was accepted. >> >> Enter additional comments for Recommendation #2. >> >> >> >> Recommendation #3: Contractual Accuracy Requirements >> The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy. >> >> Choose your level of support of Recommendation #3: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> Do you recommend a change to Recommendation 3? If so, please indicate proposed edits here. >> >> >> >> Please include the rationale for your answers here. >> >> The NCSG supports this recommendation as it is written. >> >> We do not support making changes to existing accuracy requirements, as policies regarding accuracy are not within the remit of the Temporary Specification. >> >> Enter any other additional comments or observations you have on Section 3 Part 1 that are not covered by these questions. >> >> >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I wish to continue to the next section >> >> Section 3, Part 2: Required Data Processing Activities >> >> Recommendation #4: Data Elements >> The EPDP Team recommends that the data elements defined in the data elements workbooks in Annex D are required to be collected by registrars. In the aggregate, this means that the following data elements are to be collected (or automatically generated): >> >> Data Elements (Collected and Generated) Note, Data Elements indicated with ** are generated either by the Registrar or the Registry >> >> Domain Name** >> Registry Domain ID** >> Registrar Whois Server** >> Registrar URL** >> Updated Date** >> Creation Date** >> Registry Expiry Date** >> Registrar Registration Expiration Date** >> Registrar** >> Registrar IANA ID** >> Registrar Abuse Contact Email** >> Registrar Abuse Contact Phone** >> Reseller** >> Domain Status** >> Registry Registrant ID** >> Registrant Fields: >> ? Name >> ? Organization (optional) >> ? Street >> ? City >> ? State/province >> ? Postal code >> ? Country >> ? Phone >> ? Phone ext (optional) >> ? Fax (optional) >> ? Fax ext (optional) >> ? Email >> Tech ID (optional) >> Tech Fields: >> ? Name (optional) >> ? Phone (optional) >> ? Email (optional) >> Name Server >> DNSSEC (optional) >> Name Server IP Address** >> Last Update of Whois Database** >> >> Additional optional data elements as identified by Registry Operator in its registration policy, such as (i) status as Registry Operator Affiliate or Trademark Licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT] >> >> Question #2 for Community Input >> >> >> Do you agree that all these data elements should be collected / generated to achieve the Purposes identified in the Initial Report? >> >> Yes >> No >> >> If your answer is ?no?, please enumerate which data elements should not be collected / generated. >> >> The NCSG opposes the inclusion of ?Additional optional data elements as identified by Registry Operator in its registration policy.? >> >> Please provide the rationale for your answer. >> >> As noted in our response to Purpose #7, the NCSG opposes the expansion of registration data elements to include potentially unlimited numbers of new data elements reflecting the individual policies of different registry operators. >> >> If you believe additional data elements should be collected / generated, please enumerate which additional elements should be collected / generated. >> >> >> >> Please provide the rationale for your answer. >> >> >> >> Recommendation #4 Continued: Optional Data Elements >> The EPDP Team recommends that the following data elements are optional for the Registered Name Holder (RNH) to provide: >> >> ? technical contact name >> ? technical contact email and >> ? technical contact phone number >> >> The EPDP Team has discussed two definitions of the term ?optional? as used in this recommendation: >> >> (1) registrars must offer the data field and registrants can decide whether to fill in the field or leave in blank (in which case the query would return the registered name hold data; OR >> >> (2) registrars can offer this field at their option >> >> Should the technical contact fields be optional or mandatory (where mandatory means the registrar must offer the fields AND the RNH must fill in information)? >> >> Optional >> Mandatory >> >> Please provide the rationale for your answer. >> >> The technical contact field is a legacy element that predates the existence of registrars. Currently, the de facto technical contact for all registered domains is the registrar. The name of the registrar and the contact information for the registrar are already included in the Whois data, so there is no need for an additional technical contact. If the Registered Name Holder really wants a different person or organization listed as a Tech-C it should be optional (where optional means that it is optional for the registrar to seek collection of the data, and optional for the Registered Name Holder to provide it upon a request to have it collected). Furthermore, the principle of data minimization suggests that if a data element is only optional, or not necessary for processing activities or to fulfil a contractual requirement to which the data subject is a party; that it should not be collected or further processed. Ideally, these data elements should not be collected at all. >> >> If your answer is 'optional', should registrars be required to offer these technical contact fields? >> >> Yes >> No >> >> Please provide the rationale for your answer. >> >> Some registrars feel that compliance with the GDPR and its principle of data minimization requires them to eliminate a data field that is not really used. It is best to allow them to navigate the legal risks based on their own judgment. The registrar market is competitive so if there is real consumer demand for this field then registrars can/will offer it. >> >> The EPDP team recommends that contact information for billing and administrative contacts should not be collected. Do you agree that this information should not be collected? >> >> Yes >> No >> >> Please provide the rationale for your answer. >> >> These are also legacy fields that predate ICANN. They are not needed. Billing contact is almost always the same as Admin and/or Technical contact. >> >> Enter additional comments for Recommendation #4 here. >> >> >> >> Recommendation #5: Transmission of Data from Registrar to Registry >> The EPDP Team recommends that the specifically-identified data elements under ?[t]ransmission of registration data from Registrar to Registry? within the data elements workbooks must be transferred from Registrar to Registry. In the aggregate, these data elements are the same as those in Recommendation #4 for the reasons stated in the Data Workbooks found in Annex D of the Initial Report. >> >> Do you agree that all these data elements should be transferred from the registrar to the registry? >> >> Yes >> No >> >> If your answer is ?no?, please enumerate which data elements should not be transferred from the registrar to the registry. >> >> >> >> Please provide the rationale for your answer. >> >> Once registration records have been appropriately redacted, then the transmission of the redacted data elements to the registry may be appropriate and legal under the GDPR. >> >> However, we note that the registries of ICANN are expressly not required to be in the member states of the European Union or in territories declared ?adequate? by the relevant authorities. We have seen many new gTLD registries incorporated in countries which do not have comprehensive data protection laws (and do have strong laws requiring the sharing of data with law enforcement), including the United States. >> >> We note that the use of the data of a domain name registration for the prosecution of content, including for moral, ethnic, religious, and especially gender and sexual orientation speech, is growing. The GDPR does not allow us to collect and transmit data elements that will endanger data subjects in jurisdictions to which their personal data and sensitive data could be weaponized against them. >> >> Such power over registrant freedoms cannot be delegated to ICANN or ICANN-accredited registries who are not bound by the GDPR, and cannot (even by contract) waive their local obligations to respond to law enforcement demands. Accordingly, the GDPR prohibits the processing of this registrant data -- and similarly, transmission of this registrant data to registries who cannot possibly comply with the GDPR requirements. >> >> Enter additional comments for Recommendation #5 here. >> >> >> >> Recommendation #6: Transmission of Data to Data Escrow Providers >> 1. The EPDP Team recommends that ICANN Org enter into legally-compliant data processing agreements with the data escrow providers. >> >> 2. The EPDP Team recommends updates to the contractual requirements for registries and registrars to transfer data that they process to the data escrow provider to ensure consistency with the data elements workbooks that analyze the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data. >> >> 3. The data elements workbook that analyzes the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data Registration Data contains the specifically-identified data elements the EPDP Team recommends be transferred by Registries and Registrars to data escrow providers (see Annex D, Workbook 4). >> >> Choose your level of support of Recommendation #6: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording here. Additionally, please enumerate which data elements should not be transferred from the registrar/registry to the data escrow provider. >> >> >> >> Please provide the rationale for your answer. >> >> Recommendation 6 is an appropriate measure to ensure that all data processing activities in which ICANN engages are compliant with data protection law. Registrars and registries must be given the opportunity to transfer to data escrow providers in countries covered by or deemed ?adequate? under GDPR. >> >> Enter additional comments for Recommendation #6 here. >> >> >> >> Recommendation #7: Transmission of Data from Registries/Registrars to ICANN Compliance >> 1. The EPDP Team recommends that updates are made to the contractual requirements for registries and registrars to transfer to ICANN Compliance the domain name registration data that they process when required/requested, consistent with the data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users (see Annex D, Workbook 5). >> >> 2. The data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users contains the specifically-identified data elements the EPDP Team recommends be transferred from registries and registrars to ICANN Compliance (see Annex D, Workbook 5). >> >> Choose your level of support of Recommendation #7: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> Do you agree that all of these data elements should be transferred from the registrar to ICANN? >> >> Yes >> No >> >> If your answer is ?no?, please enumerate which data elements should not be transferred from the registrar to ICANN. >> >> See below >> >> Please provide the rationale for your answer. >> >> We answer ?No? here only because the NCSG believes that requests by ICANN Compliance should be limited to those elements required to accommodate issues they will deal with at that time. In principle, this could mean that all data elements are required, but not all elements will be needed for other purposes. We wish to underline the principle that compliance requests should not be open-ended fishing expeditions. >> >> We note that ICANN Compliance rules should be more subject to review and understanding by the community, and that there are concerns (and reports) that complaints are being used, in part, as harassment and fishing expeditions against registrants. Accordingly, transfer of data elements even to ICANN Compliance should be subject to special evaluation and review -- not automatically done regardless of purposes, scope and scale. >> >> Enter additional comments for Recommendation #7 here. >> >> >> >> Recommendation #8: Data Redaction >> The EPDP Team recommends that redaction must be applied as follows to the data elements that are collected. Data elements neither redacted nor anonymized must appear in a freely accessible directory. >> >> NOT REDACTED >> Domain Name >> Registrar Whois Server >> Registrar URL >> Updated Date >> Creation Date >> Registry Expiry Date >> Registrar Registration Expiration Date >> Registrar >> Registrar IANA ID >> Registrar Abuse Contact Email >> Registrar Abuse Contact Phone >> Reseller >> Domain Status >> >> Registrant Fields >> ? State/province >> ? Country >> ? Anonymized email / link to web form >> >> Tech Fields >> ? Anonymized email / link to web form >> NameServer(s) >> DNSSEC No >> Name Server IP Address >> Last Update of Whois Database >> >> REDACTED >> Registrant Fields >> ? Name >> >> ? Street >> ? City >> ? Postal code >> ? Phone >> ? Email >> >> Tech Fields >> ? Name >> ? Phone >> ? Email >> >> UNDECIDED (REDACTED/ NOT REDACTED) >> ? Organization (opt.) >> >> Please reference page 14-15 of the Initial Report for details of the data elements. >> >> Do you agree that all of these data elements should be redacted? >> >> Yes >> No >> >> If your answer is ?no?, please enumerate the data elements that should not be redacted. >> >> The NCSG requests the redaction of an additional data element: the State/Province field. >> >> Please provide the rationale for your answer. >> >> In nearly all cases, country level data will be sufficient to determine relevant jurisdiction for disputes resolution. When this is not sufficient, parties with legitimate interest can request disclosure. Including the State/Province in public data, in conjunction with other information, may allow identification of individuals by those without a legitimate interest. >> >> The EPDP Team is of divided opinion as to whether "Organization" should be redacted for reasons stated in the Initial Report. Please see the Initial Report, beginning on p. 42. Should the "Organization" field be redacted? >> >> Yes >> No >> >> Please provide rationale for your answer above. >> >> Many natural persons operate small organizations or businesses and contact data in their domain registration will be indistinguishable from that of an individual residence. Also, some organizations might be targeted merely because of their legal political, religious, or social affiliations. >> >> Legal advice provided to the GNSO Next-Generation RDS to replace WHOIS PDP Working Group explained that any data element that assists in making a natural person (RNH) identifiable, in conjunction with other data elements, should be treated as personal information, even if the data element does not appear to be personal information in itself. Combining the ?Organization? field with others such as state or city would certainly make a Registered Name Holder more identifiable. >> >> Enter additional comments for Recommendation #8. >> >> >> >> Recommendation #9: Organization Field >> The EPDP Team recommends that registrars provide further guidance to a Registered Name Holder concerning the information that is to be provided within the Organization field. (For further information, please refer to the Initial Report discussion, beginning on p. 42). >> >> Choose your level of support of Recommendation #9: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording here. >> >> >> >> Please provide the rationale for your answer. >> >> ?Guidance? is a poor substitute for redaction. At best, ?guidance? from registrars will reduce some of the risk of inadvertent or mistaken data about natural persons being placed in the DNS record; but redacting the field will reduce all of it. Redaction provides a much more certain response to the potential problem. >> >> Additional comments for Recommendation #9. >> >> >> >> Recommendation #10: Provision of Email Address/Web Form >> In relation to facilitating email communication between third parties and the registrant, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. >> >> Choose your level of support of Recommendation #10: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you believe edits are needed for Recommendation #10, please propose edits here. >> >> >> >> Please provide the rationale for your answer. >> >> >> >> Additional comments for Recommendation #10. >> >> Publication of the registrant?s email address in a way that can be automatically harvested and used for any purpose is clearly not acceptable and not compliant with the GDPR. Recommendation 10 is a good way to optimize privacy while furthering the goal of contactability articulated by Purpose 3. >> >> Recommendation #11: Data Retention >> The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of one year following the life of the registration. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (?TDRP?). >> >> Choose your level of support of Recommendation #11: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #11, please provide proposed edits here. >> >> >> >> Please provide the rationale for your answer. >> >> Retaining the registration data for a year can help protect the rights of registrants and was seen as a legitimate purpose for data collection by contracted parties. >> >> Additional comments for Recommendation #11. >> >> >> >> Question 3 for Community Input: Differentiating Registrants: Legal v. Natural Persons; and Effects of Geographic Location >> >> >> What other factors should the EPDP team consider about whether Contracted Parties should be permitted or required to differentiate between registrants on a geographic basis? (For more information, please refer to the Initial Report, beginning on p. 47. >> >> A factor not properly aired in the Initial Report is the Internet?s status as a global infrastructure and ICANN?s status as a uniform policy maker for the global Domain Name System. One of the main reasons for creating ICANN was to ensure that the Domain Name System would have a globally consistent set of rules. The NCSG strongly opposes fragmenting the policies regarding domain name registration data on a geographic basis for that reason. ICANN should strive as much as possible to keep its rules and requirements the same for the entire Domain Name System. This helps maintain the global compatibility of the Internet. >> >> Recently published EDPB guidelines on territorial scope also indicate that there are more factors that require consideration on the territorial scope of GDPR, including targeting criteria (if the sale of goods and services is targeting EU/EEA residents) as well as whether the data controllers and/or processors have stable establishments located within the EU, irrespective of whether the associated data processing activities take place within the EU, or not. >> >> Please provide the rationale for your above answer. >> >> >> >> Are there any other risks associated with differentiation of registrants on a geographic basis? If so, please identify those factors and/or risks and how they would affect possible recommendations, keeping in mind compliance with the GDPR. >> >> >> >> What other factors should the EPDP team consider about whether Contracted Parties should be permitted or required to differentiate between natural and legal persons? >> >> The current discussion in the Initial Report covers all of the relevant factors regarding natural vs legal persons. There is a clear choice between staying firmly within the boundaries of data protection law on the one hand, and exposing more data for the sake of data miners and surveillance interests on another hand. The NCSG strongly believes that there is no need to consider additional factors. >> >> Please provide the rationale for your above answer. >> >> The NCSG strongly opposes any attempt to require registrars to separate natural and legal persons at the point of registration. Any attempt to sort out who is an organization and who is a natural person will pose major risks, and impose major cost burdens, on the contracted parties. More importantly, however, Registered Name Holders will be at risk of harm, because many registrants will not understand the distinction and will end up being misclassified as organizations and thus lose their legal entitlement to data protection. >> >> Furthermore, the GDPR does not distinguish between the protection of natural and legal persons per se, but rather the protection of personal data of natural persons, which is very likely to be included in gTLD Registration Data of domain names registered by legal persons. The obvious example is the Registered Name Holder email address, which would belong to an employee or representative of the legal person, typically being name at domain.TLD . >> >> Should there be further study as to whether whether procedures would be feasible to accurately distinguish on a global scale whether registrants/contracted parties fall within jurisdiction of the GDPR or other data protection laws? Please provide a rationale. >> >> No. The ?E? in EPDP means expedited. The purpose of this exercise is to quickly turn the temporary specification into a consensus policy following ICANN procedures. Pausing to conduct studies about adding new elements into domain registration contracts is not appropriate in this expedited proceeding. >> >> Stakeholders who want to explore this further, have the possibility to initiate new PDPs after the tight deadline for this EPDP is met. New policies can always be proposed. The NCSG believes that there is no time for further studies within the timeframe of this EPDP. >> >> Are you aware of existing examples where a legal/natural differentiation is already made and could it apply at a global scale for purposes of registration data? If yes, please provide additional information. >> >> There are no directly applicable examples that would work at a global scale. >> >> Recommendation #12: Reasonable Access >> The EPDP Team recommends that the current requirements in the Temporary Specification in relation to reasonable access remain in place until work on a system for Standardized Access to Non-Public Registration Data has been completed, noting that the term should be modified to refer to ?parameters for responding to lawful disclosure requests.? Furthermore, the EPDP Team recommends that criteria around the term ?reasonable? are further explored as part of the implementation of these policy recommendations addressing: >> >> o [Practicable]* timelines criteria for responses to be provided by Contracted Parties; >> o Format by which requests should be made and responses are provided; >> o Communication/Instructions around how and where requests should be submitted; >> o Requirements for what information responses should include (for example, auto-acknowledgement of requests and rationale for rejection of request); >> o Logging of requests. >> >> [*Some concern expressed that timeliness that should not be translated into requirements that are impractical for contracted parties]. >> >> Choose your level of support of Recommendation #12: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you believe edits are needed for Recommendation #12, please propose them here. >> >> The NCSG strongly supports replacing ?Standardized Access to Non-Public Registration Data? with ?parameters for requesting lawful disclosure requests,? as that more accurately describes the objective. >> >> Please provide the rationale for your answer. >> >> The NCSG strongly supports replacing ?Standardized Access to Non-Public Registration Data? with ?parameters for requesting lawful disclosure requests,? as that more accurately describes the objective. We understand that the topic of lawful disclosure is a controversial one and may take some time to resolve fully. In the meantime, the general guideline in the temp specification, subject to the modification proposed in Recommendation 12 and further fleshing out of the parameters in the implementation process as proposed above, is something that all stakeholder groups can support. >> >> Additional comments for Recommendation #12. >> >> It will simply be insufficient to state a mere category of request for data; for instance, ?intellectual property allegation? or ?law enforcement need.? The requirements of the GDPR dictate that prior to revealing the personal and sensitive data of a data subject, there is a balancing test that must take place. >> >> Recommendation #13: Joint Controller Agreements >> Based on the information and the deliberations the EPDP Team had on this topic and pending further input and legal advice, the EPDP Team recommends that ICANN Org negotiates and enters into a Joint Controller Agreement (JCA) with the Contracted Parties. >> >> In addition to the legally required components of such agreement, the JCA shall specify the responsibilities of the respective parties for the processing activities as described below. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that have the primary interest in the processing. >> >> Choose your level of support of Recommendation #13: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you believe changes are needed for Recommendation #13, please provide proposed edits here. >> >> >> >> Please provide the rationale for your answer. >> >> Understanding and specifying the roles and responsibilities of ICANN and the contracted parties is a critical and unavoidable part of compliance with the GDPR. There can be disagreements about the appropriate definition of roles, indemnification, and so on, but there cannot be any serious disagreement about the need to enter into such an agreement. >> >> Based on our understanding of the GDPR, ICANN and the contracted parties are joint controllers with respect to the Whois (or RDDS). We also believe that a joint controller agreement is the best way to achieve clear and simple lines of responsibility when there are multiple participants and complex processing structures. This will protect data subjects by preventing a splitting of responsibilities in ways that allow the controllers and processors to avoid responsibility. >> >> Additional comments for Recommendation #13. >> >> >> >> Enter any other additional comments or observations you have on Section 3, Part 2 that are not covered by these questions. >> >> >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I wish to continue to the next section >> >> Section 3, Part 3: Data Processing Terms >> >> Recommendation #14: Data Processing Roles & Responsibilities >> The EPDP Team recommends that the policy includes the following data processing activities as well as responsible parties. Please reference the Initial Report, beginning on p. 63 for further details. >> >> Choose your level of support of Recommendation #14: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not agree with the enumerated data processing activities and responsible parties, please provide proposed edits, including specific processing activities that need to be added/deleted here. The EPDP team particularly seeks feedback with the assignment of roles such as: ?joint-controller,? ?controller,? and ?processor. >> >> >> >> Please provide your rationale for the proposed addition/deletion. >> >> The NCSG supports the intent of this recommendation, and the identification of the different processing activities and responsible parties (controllers and processors) for each. However, the NCSG maintains that we disagree with the inclusion of Purpose #2 and Purpose #7 as they are currently worded in the initial report, and therefore, cannot support any of the processing activities and responsible parties associated with them at this time. >> >> Additional comments for Recommendation #14. >> >> >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I wish to continue to the next section >> >> Section 3, Part 4: Updates to Other Consensus Policies >> >> Enter any general comments or observations you may have on the findings in Section 3, Part 4. >> >> >> >> Recommendation #15: Uniform Rapid Suspension/Uniform Domain Name Dispute Resolution Policy Requirements >> The EPDP Team recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to URS and UDRP until such time as these are superseded by recommendations from the RPMs PDP WG (if any). >> >> Choose your level of support of Recommendation #15: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not agree that the current updated requirements in the UDRP and URS, as provided in the Temporary Specification should remain in place, please provide proposed edits to the current requirements. >> >> >> >> Please provide the rationale, keeping in mind compliance with GDPR. >> >> The EPDP is supposed to deal primarily with bringing ICANN?s Whois/RDDS into compliance with GDPR. In some cases there are interactions between Whois policy and UDRP and URS procedures. Rather than trying to modify additional policies via the EPDP, we should leave the temporary specification in place and allow the GNSO?s Rights Protection Mechanism PDP to take up the other issues. The extent to which these policies are addressed here should be limited to the extent to which gTLD Registration Data is processed within the context of DRP proceedings. >> >> Additional comments for Recommendation #15. >> >> We note that under the Temporary Specification, UDRP and URS proceedings are continuing, with Providers requesting and Registrars sharing registrant data on showing of a complaint filing. These proceedings are moving forward unabated -- with complaints continuing to processed and registrants continuing to be informed (via Notice). >> >> We further note it is our understanding that the RPM PDP WG has been reviewing this matter as part of its URS recommendation (UDRP review will not come until a later Phase 2), and is planning to make draft policy recommendations to facilitate URS processing in its upcoming Initial Report in 2019. >> >> Recommendation #16: Instruction to GNSO and Rights Protection Mechanisms Policy Development Working Group >> The EPDP Team also recommends that the GNSO Council instructs the review of all RPMs PDP WG to consider, as part of its deliberations, whether there is a need to update existing requirements to clarify that a complainant must only be required to insert the publicly-available RDDS data for the domain name(s) at issue in its initial complaint. The EPDP Team also recommends the GNSO Council to instruct the RPMs PDP WG to consider whether upon receiving updated RDDS data (if any), the complainant must be given the opportunity to file an amended complaint containing the updated respondent information. >> >> Choose your level of support of Recommendation #16: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #16, please provide proposed text/edits. >> >> >> >> Please provide the rationale for your answer. >> >> This is a fair way to handle disjunctions between the UDRP and URS ? which assumed legacy Whois ? and the temporary specification regime, which redacts most personally identifiable information. This recommendation merely brings certain issues to the attention of the RPM PDP, it does not however, tell them how to resolve them. >> >> Provide additional comments for Recommendation #16 here. >> >> We note that it is our understanding that the RPM PDP WG has been reviewing this matter as part of its URS recommendation (UDRP review will not come until a later Phase 2), and is planning to make draft policy recommendations to facilitate URS processing in its upcoming Initial Report in 2019. >> >> Recommendation #17: UDRP/URS >> The EPDP Team requests that when the EPDP Team commences its deliberations on a standardized access framework, a representative of the RPMs PDP WG shall provide an update on the current status of deliberations so that the EPDP Team may determine if/how the WG?s recommendations may affect consideration of the URS and UDRP in the context of the standardized access framework deliberations. >> >> Choose your level of support of Recommendation #17: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #17, please provide proposed edits or changes. >> >> Given the timeline to which the EPDP Team is working, the EPDP Team may complete its work before the RPM PDP WG enters its Phase 2 discussions involving UDRP disclosures. URS discussions (already taking place) may provide the EPDP Team with insight into the deliberations, discussion and draft policy recommendations on URS (which will, in turn, shed light on UDRP). >> >> Please provide the rationale for your answer. >> >> This recommendation merely facilitates coordination between the EPDP and the RPM PDP. >> >> Provide additional comments for Recommendation #17 here. >> >> >> >> Recommendation #18: Data Processing Agreements >> The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed, as this will affect the ability to have publicly-available decisions. >> >> Choose your level of support of Recommendation #18: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not agree to Recommendation #18, please provide proposed edits or changes here. >> >> >> >> Please provide the rationale for your answer here. >> >> This change is probably necessary in order to reconcile EPDP recommendations with arrangements with existing UDRP providers. >> >> Provide additional comments for Recommendation #18 here. >> >> ICANN Org may also need to enter into data processing agreements with dispute resolution providers to limit the publication of personal and sensitive information about registrants in UDRP and URS decisions. Such data may include the names and contact information of registrants and their attorneys, and the names and contact data of complainant attorneys. Publication of identity, organization, and other data of the registrant and its attorneys -- including in dispute proceedings where the registrant won -- is a collection activity and publication of personal and sensitive data that may well be in violation of the GDPR. The UDRP and URS decision, and even the transfer of domain names, does not require such public disclosure as a necessary part of technical implementation. We further note that older UDRP and URS cases may need to be redacted for publication of personal and sensitive data of the registrant and his/her/its attorneys, email addresses, and other data. >> >> Question #4 for Community Input >> >> >> Are there any changes that the EPDP Team should consider in relation to the URS and UDRP that have not already been identified? >> >> >> >> If so, please provide the relevant rationale, keeping in mind compliance with the GDPR. >> >> >> >> Recommendation #19: Transfer Policy >> The EPDP Team recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to the Transfer Policy until such time these are superseded by recommendations that may come out of the Transfer Policy review that is being undertaken by the GNSO Council. >> >> Choose your level of support of Recommendation #19: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #19, please provide proposed changes/edits here. >> >> >> >> Please provide the rationale for your answer, keeping in mind compliance with GDPR. >> >> This recommendation handles appropriately an interdependence between the Temporary Specification and the Transfer policy appropriately. >> >> Provide additional comments for Recommendation #19 here. >> >> >> >> Recommendation #20: Transfer Policy >> The EPDP Team recommends that the GNSO Council, as part of its review of the Transfer Policy, specifically requests the review of the implications, as well as adjustments, that may be needed to the Transfer Policy as a result of GDPR. >> >> Choose your level of support of Recommendation #20: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #20, please provide proposed edits/changes here. >> >> >> >> Please provide the rationale for your answer here. >> >> >> >> Provide additional comments for Recommendation #20 here. >> >> >> >> Question #5 for Community Input >> >> >> Are there any changes that the EPDP Team should consider in relation to the Transfer Policy that have not already been identified? If so, please provide the relevant rationale, keeping in mind compliance with the GDPR. >> >> >> >> Enter any other additional comments or observations you have on Section 3, Part 3 that are not covered by these questions. >> >> >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I wish to continue to the next section >> >> Section 3: Other Recommendations >> >> Enter any general comments or observations you may have on the findings in Section 3, Other Recommendation. >> >> >> >> Recommendation #21: Joint Controller and Data Processing Agreements >> The EPDP Team recommends that ICANN Org enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the non-Contracted Party entities involved in registration data processing such as data escrow providers and EBERO providers. These agreements are expected to set out the relationship obligations and instructions for data processing between the different parties. >> >> Choose your level of support of Recommendation #21: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #21, please provide proposed edits/changes here. >> >> Recommendation should add ?but not including the domain name registrant? after ?EBERO providers?. >> >> Please provide the rationale for your answer here, keeping in mind compliance with GDPR. >> >> The NCSG would like to clarify that we are not recommending that ICANN enter into contracts with registrants, as they are also non-contracted parties, and we would not support ICANN org moving in this direction. >> >> Provide additional comments for Recommendation #21 here. >> >> >> >> Recommendation #22: Updates to Existing Consensus Policies >> The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as a number of these refer to administrative and/or technical contact which will no longer be required data elements: >> >> ? Registry Registration Data Directory Services Consistent Labeling and Display Policy >> ? Thick WHOIS Transition Policy for .COM, .NET, .JOBS >> ? Rules for Uniform Domain Name Dispute Resolution Policy >> ? WHOIS Data Reminder Policy >> ? Transfer Policy >> ? Uniform Rapid Suspension System (URS) Rules >> >> >> Please reference the Initial Report, beginning on p. 71 for further details. >> >> Choose your level of support of Recommendation #22: >> >> Support recommendation as written >> Support intent of recommendation with edits >> Intent and wording of this recommendation requires amendment >> Delete recommendation >> >> If you do not support Recommendation #22, please provide proposed edits or changes here. >> >> >> >> Please provide the rationale for your answer here. >> >> This is an appropriate ?housekeeping? recommendation that will help ensure consistency of other policies affected by EPDP recommendations with the new policy. >> >> Provide additional comments on Recommendation #22 here. >> >> It will be neither simple nor easy to update existing consensus policies. As captured in the NCSG?s comments to the UDRP and URS questions above, there are important aspects of the collection and especially publication of Registrant data in UDRP and URS decisions that needs to be carefully evaluated -- as publication of personal and sensitive data in a public decision is absolutely unnecessary to implement a UDRP decision transferring a domain name. >> >> We wish to note the underlying danger that UDRP and URS proceedings will be used as a ruse for discovering the identity and location of the registrant, absent any true or provable domain name disputes. Of course, this must not be allowed to happen, and must be pursued and punished by ICANN Compliance, among others. >> >> We further note that publication of registrant name and/or contact data, including registrants who win the UDRP and URS proceedings, may be especially dangerous. The GDPR prevents those who receive personal and sensitive information for particularly purposes (e.g., UDRP and URS Complainants) from misusing, selling, distributing, aggregating and otherwise publishing the personal and sensitive data. Accordingly, RDDS data disclosed to a dispute provider pursuant to a UDRP or URS (or other future registrant-related dispute proceeding) must be expressly protected by all reasonable updates to existing consensus policies. >> >> Finally, appropriate revisions to existing consensus policies must be written to ensure that commitments made to limits on the use and disclosure of registrant RDDS data in UDRP and URS proceedings are followed. Provisions must be drafted and agreed to by Complainants and their attorneys, and UDRP and URS dispute resolution providers, as part of any revisions to existing consensus policies. Penalties for breach must be clear, sharp, swift, and enforceable by ICANN, registrants and their representatives, and dispute resolution providers. >> >> Enter any other additional comments or observations you have on Section 3: Other Recommendations that are not covered by these questions. >> >> >> >> Save Your Progress >> >> >> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. >> >> Yes >> No, I wish to continue to the next section >> >> Other Comments & Submission >> >> Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer. >> >> >> >> Save Your Progress >> >> >> Create your own Google Form > > _______________________________________________ > NCSG-PC mailing list > NCSG-PC at lists.ncsg.is > https://lists.ncsg.is/mailman/listinfo/ncsg-pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafik.dammak at gmail.com Fri Dec 28 09:49:09 2018 From: rafik.dammak at gmail.com (Rafik Dammak) Date: Fri, 28 Dec 2018 16:49:09 +0900 Subject: [NCSG-PC] Reminder review of NCSG comment on new gTLD supplemental report In-Reply-To: References: Message-ID: hi, Thanks Ayden for the review and comments. I accepted the proposed edits in the document. there was some language added to clarify the commented parts. I attached the final version. if I don't hear any objection in coming hours, I will submit it. I will ask our active members in subpro to follow-up during the review of comments . Best, Rafik Le jeu. 27 d?c. 2018 ? 15:45, Ayden F?rdeline a ?crit : > Thanks Rafik, I have made a number of stylistic edits to the document now. > There is an unresolved comment from Robin in paragraph 13 that needs to be > resolved prior to the submission of the document -- like Robin, I'm not > clear on what this paragraph is saying. Milton has also flagged some > logical fallacies in the document (see paragraphs 5, 6, and 8) that we may > want to see to changing, though I think it might be okay to submit this > comment even with them in there. But paragraph 13 is confusing and needs to > be edited prior to submission. > > Best wishes, Ayden > > > ??????? Original Message ??????? > On Thursday, 27 December 2018 15:22, Rafik Dammak > wrote: > > Hi all, > > there were some small editorial changes in the draft but nothing > substantial > https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit. > if there is objection within the next 24 hours I will submit the comment so > it can be considered for review bu the subpro WG. Comments and edits are > still welcome. > Happy holidays! > > Best, > > Rafik > > Le ven. 21 d?c. 2018 ? 12:20, Rafik Dammak a > ?crit : > >> Hi all, >> >> This is a reminder regarding the review of draft comment for the subpro >> supplemental report. >> >> Best, >> >> Rafik >> >> On Wed, Dec 19, 2018, 13:13 Rafik Dammak > >>> Hi all, >>> >>> the drafting team finished the work on NCSG comment on new gTLD >>> supplemental report : >>> https://docs.google.com/document/d/1lpRUS9wRIfXFI2tcrvp6Gpq1D61-EVsChvhIjRu5FCQ/edit >>> . They are continuing the work. >>> >>> the deadline for submission is the Friday 21st December. Please review >>> it asap. >>> >>> Best, >>> >>> Rafik >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Supplemental Initial Report on the New gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4) - NCSG Comment.pdf Type: application/pdf Size: 243074 bytes Desc: not available URL: