[NCSG-PC] Fw: [NCUC-DISCUSS] Suggested Comment: Draft Framework for Registry Operators to Respond to Security Threats

Wed Aug 9 05:50:17 EEST 2017

hi Tatiana,

thanks, I removed those 2 statements and we have this version now
https://docs.google.com/document/d/1TfgHuMqzD660_CHLQMXMW4phnBtLSP94j6X5riY2Ko4/edit
. with those changes, I can understand that you are supporting the comment.
looking to hear from other PC members.
if I don't hear any objection by Wednesday 9th August 11:59am UTC, I can
interpret that the comment is endorsed by NCSG Policy committee.

Best,

Rafik

2017-08-08 17:40 GMT+09:00 Dr. Tatiana Tropina <t.tropina at mpicc.de>:

> Hi Rafik,
>
> As I said - I do not quite get what the first statement means in terms of
> issues raised so I can't come up with any suggestion. I wish I could. As
> this statement doesn't really contribute to anything and doesn't raise any
> issue (although it's supposed to as it is placed in the "issue" section) I
> suggest we just remove it for the sake of clarity. Unless the drafters are
> ready to clarify or rephrase. But I don't think removal will change
> anything in the document except making it clearer.
>
> I am totally supporting your suggestion for removal of anotehr statement -
> let's not send the mix messages especially with vague wording proposals.
>
> Thanks!
>
> Tanya
>
> On 08/08/17 08:08, Rafik Dammak wrote:
>
> Hi Tatiana,
>
> Thanks for the comments,
> while we are late by our deadline to submit a comment, I think we can
> solve the concerns.
> 1/ do you have a proposal of rephrasing for the first statement?
> 2/ I understand your concerns and indeed doesn't seem aligned with our
> previous stances regarding domain suspension. probably we can remove that.
>
> really looking forward to solving this within the next 24hours.
>
> Best,
>
> Rafik
> 2017-08-05 6:56 GMT+09:00 Dr. Tatiana Tropina <t.tropina at mpicc.de>:
>
>> Hi all,
>>
>> I have a couple of comments:
>>
>> 1) I have hard time making sense of the first point:
>>
>> "1. Registry Response, Responsible Parties
>>
>>  “ROs are not necessarily the best parties to address certain security
>> threats. The identification of the parties considered as being most
>> relevant and appropriate in resolving the security threat is critical to
>> the prompt resolution of the matter.”
>>
>> More specifically, responsibility of identifying security threats
>> connected to New gTLDs and resolving them when possible rests with ROs."
>>
>> As this point is a part of the comment that refers to the "issue" I
>> wonder what is this - a statement? What kind of issue is identified here?
>> Are we recommending anything?  If not and if this is just an introduction,
>> may be it's better to rephrase? May be it's just too late here but I
>> struggling with what this "issue" implies.
>>
>> 2) I wonder if this one is really in line with NSCG values such as due
>> process:
>>
>> 2. We ask you to consider including the following GAC recommendation in
>> Registry Response:
>>
>> “If Registry operator identifies risk of  harm, Registry operator will
>> notify the relevant registrar and , if the registrar does not take
>> immediate action, suspend the domain name until the matter is resolved.”
>>
>> The framework already lists the actions that Registry can take even in
>> the case if "a negative or non-existent response from the Registrar", which
>> "should not
>> preclude the Registry from taking action". I do not like the notion of
>> "immediate action" as it sound to vague to me and I believe that there are
>> enough actions listed to address the issue under the framework rather than
>> suspension of domain name - again, "till the matter is resolved" looks too
>> vague. I don't think it's acceptable when it comes to such a matter as a
>> suspension of domain name. I know enough cases of mistakes when due to
>> abuse claims customers went dark, etc. I suggest we rather be careful here.
>> But if everyone is comfortable with this suggestion, I'll surrender.
>>
>> Warm regards,
>>
>> Tanya
>>
>>
>>
>> On 04/08/17 09:39, Rafik Dammak wrote:
>>
>> Dear PC members,
>>
>> any comment on the draft? we got an extension till 6th August, we should
>> review quickly and make a decision.
>>
>> Best,
>>
>> Rafik
>>
>> 2017-07-31 19:33 GMT+09:00 Rafik Dammak <rafik.dammak at gmail.com>:
>>
>>> Hi Ayden,
>>>
>>> Yes it is for PC review. We worked on it the last days with Juan, Dina
>>> and Niels. James cannot response since is off for the coming days. I was
>>> going to send email to related ICANN staff to inform that we will make a
>>> late submission, hopefully by end of this week.
>>>
>>> Best,
>>>
>>> Rafik
>>>
>>>
>>> On Jul 31, 2017 7:18 PM, "Ayden Férdeline" <icann at ferdeline.com> wrote:
>>>
>>> I believe the PC is being asked to review this comment which has been
>>> drafted by Dina and Juan. The submission deadline for comments on this
>>> issue is today, but I suspect we will not be able to meet that, so let's
>>> try for this Friday? I think we need to bring in a topic expert, James
>>> Gannon (cc'd), to get his opinion on this comment, too -- because I am
>>> happy to raise my hand and say I do not know anything about this topic.
>>>
>>> Best, Ayden
>>>
>>>
>>> -------- Original Message --------
>>> Subject: [NCUC-DISCUSS] Suggested Comment: Draft Framework for Registry
>>> Operators to Respond to Security Threats
>>> Local Time: July 30, 2017 11:24 PM
>>> UTC Time: July 30, 2017 10:24 PM
>>> From: thomascovenant at thomascovenant.org
>>> To: NCUC-discuss <ncuc-discuss at lists.ncuc.org>
>>>
>>> Hello,
>>>
>>> the comment proposal is underneath, what are your thoughts?
>>>
>>> https://docs.google.com/document/d/1TfgHuMqzD660_CHLQMXMW4ph
>>> nBtLSP94j6X5riY2Ko4/edit
>>>
>>> Note from Security Framework Drafting Team wiki workspace:
>>>
>>> - Is Public Comment required for the draft Framework?
>>> - This is not a policy implementation nor a contractual requirements
>>> document; therefore, a public comment proceeding would not be required.
>>> However, SFDT has decided to conduct a public comment for broader community
>>> feedback prior to finalization of the Framework.
>>>
>>> Main points:
>>>
>>> - Framework should be expanded
>>> - Several minor details are to be clarified, restructuring proposal
>>> - as a small step in response to proposed detailed report examination, I
>>> suggest we include a recommendation on Responsible Threat Disclosure.
>>>
>>> Finally, I quote Point 3 from the Comment:
>>>
>>> "Since the following examination of threat report is identified in the
>>> Framework, we strongly suggest including a recommendation on Responsible
>>> Threat Disclosure to be included in the document:
>>>
>>> "Each RO should scrutinize, question or otherwise inquire about the
>>> legitimacy of the origin
>>> of a request, in accordance with their own internal policies and
>>> processes."
>>>
>>> We have seen a broad variation in handling security threat reports,
>>> varying from constructive actions addressing the issues to punishment of
>>> the reporting party. Benefits of responsible threat submission are obvious.
>>>
>>> In this context, it is important to underline benefits and importance of
>>> responsible threat disclosure. We request recommendation to extend goodwill
>>> and not cause harm to the reporting party whenever possible:
>>>
>>> When applicable, RO should provide:
>>>
>>> - an easy way to report security threats and violation
>>> - encrypted ways of communication
>>> - option of anonymous submission"
>>>
>>> Other:
>>>
>>> - This is my first comment drafted with input from Juan Manuel Rojas
>>> (thank you for commenting). Access to shared document and request for
>>> review was given to those who expressed interest in working on it. All
>>> input from the list is very welcome. Please let me know what needs to be
>>> corrected and I will promptly do it.
>>> - Comment is a bit late, I will request an extra week to discuss the
>>> proposal with my humble excuses.
>>>
>>> BR,
>>> Dina Solveig Jalkanen
>>> --
>>> * * *
>>> Friendly geek in Amsterdam, FSFE Fellow
>>> https://wiki.techinc.nl/index.php/User:Thomascovenant
>>>
>>>
>>> _______________________________________________
>>> Ncuc-discuss mailing list
>>> Ncuc-discuss at lists.ncuc.org
>>> http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
>>>
>>>
>>>
>>> _______________________________________________
>>> NCSG-PC mailing list
>>> NCSG-PC at lists.ncsg.is
>>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> NCSG-PC mailing listNCSG-PC at lists.ncsg.ishttps://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: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20170809/8a633bda/attachment.htm>