[IRT.RegDataPolicy] 9.3.2.1 Consent to Publish Technical Contact Data

Mon Dec 16 20:58:11 UTC 2019

Hi Sarah,

I was going through the latest version of the OneDoc and I must admit I have the same concerns as you.

@Dennis could you shed some light here?

Thank you,

Luc
______________

Luc Seufer
Chief Legal Officer
Namespace

21, rue Léon Laval
L-3372 Leudelange
Luxembourg

Tel.: +352 27 220 166
Mobile: +352 691 600 417
Fax.: +352 20 300 166
Mailto: lseufer at namespace.com<mailto:lseufer at namespace.com>

From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on behalf of Sarah Wyld <swyld at tucows.com>
Organisation: Tucows
Date: Friday, 6 December 2019 at 21:15
To: "irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] 9.3.2.1 Consent to Publish Technical Contact Data

Hello Dennis

and IPT,

Thanks

for the reminder about our respective roles in this implementation process. Further to this email thread, I've also noticed that open OneDoc comments are being resolved without the team having reached agreement on how to best implement the recommendations.

I

would like to more clearly understand how these decisions are being made, and how the IPT is tracking discussion and resolution of issues where the IRT members are not in agreement regarding how best to implement the policy Recommendations. Your discussion

of Staff’s, IPT’s, and IRT’s respective roles didn’t seem to address this.

For

example, the Tech contact consent to publication (as Jody noted), the requirement for the registrar to publish info about the disclosure request process on their website, and the required response time for urgent disclosure requests; in each of these cases,

comment threads were resolved without IRT member consensus.

I

will note the comment history along with the recommendation and the OneDoc policy sections here, because it's difficult to track in the Google Doc. I've done my best to ensure everything included here is accurate based on what I can see in the document history.

Tech

Consent to publication

Rec.

6 text: The EPDP Team

recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish redacted contact information, as well as the email address, in the RDS for the sponsoring registrar.

Onedoc

text: 9.3.2.1 If a Registrar

collects Technical data from the Registrant under Section 5.2 and Redacts the data elements values listed in Sections 8.3.1.10 through 8.3.1.12, Registrar MAY provide the opportunity for the relevant contact to provide Consent to Publish the data element values.

Registrar MAY Publish the data element value(s) for which the relevant contact has provided its Consent. [Rec 6]

CPH

proposed removing the

section, as it is not grounded in the Recommendation

Comment

thread 1:

Jody Kolker

3:37 PM Nov 6: This paragraph allows the Registrar the ability to provide the Technical contact with a consent to publish the technical content in the RDS. Registrars can do this without having this listed in the document. It is language that is not needed

and should be removed. Including it would mean that we should include many more MAYs for allowing any number of options for registrars.

Roger Carney

8:01 AM Nov 7:- +1 Jody, no need to call this out specifically. Plus, the reference seems invalid as Rec 6 is specific to RNH not "relevant contact".

Theo Guerts

5:05 AM Nov 12: +1 for the GD team

Sarah Wyld 2:25

PM Nov 14 (edited 2:55 PM Nov 25): +1, this needs to be removed. Edited to add: Tech contact consent is not part of the Recommendation; we should stick to our narrow purview of implementing the recs.

Susan Kawaguchi

7:27 PM Nov 19: I do not understand why this needs to be removed but welcome the opportunity to discuss in the meeting

Dennis Chang

3:32 PM Dec 6: not removing per the IRT discussion.

My

recollection is not that this was what the team agreed on in the IRT meeting on 5 December.

Comment

thread 2:

Susan Kawaguchi

12:04 AM Dec 4: Do not understand why this is deleted. Should reinstate this language. A commercially practical method could be used to consent such as email or a click through

Sarah Wyld 8:33

AM Dec 4:  Tech contact consent is not part of the Recommendation; we should stick to our narrow purview of implementing the recs.

Dennis Chang

3:32 PM Dec 6: we'll keep this requirement for now for clarity and public comment

Again,

there isn’t any basis in the Recommendation for “keep[ing] this requirement” or putting it out for public comment.

Publishing

info about how to submit disclosure requests

Rec.

18 relevant text: "Registrars

and Registry Operators must publish, in a publicly accessible section of their web-site, the mechanism and process for submitting Reasonable Requests for Lawful Disclosure."

Original

OneDoc 10.2 text: Registrars

and Registry Operators MUST publish the mechanism and process for submitting Reasonable Requests for Lawful Disclosure in a publicly-accessible section of their website.

Comment

thread:

Laureen Kapin

2:48 PM Nov 13 - I recommend that we clarify what is intended here. Information on a website can be "publicly accessible" but very difficult to find. Ideally, we could agree upon a common label and location for this information.

Sarah Wyld 10:36

AM Nov 19 - Flagged for discussion as a team

Dennis Chang

1:22 PM Dec 4 (edited 1:22 PM Dec 4) - Diane: clear and conspicuous, FCC language

Dennis Chang

3:54 PM Dec 5 - thanks all for the suggestion. please see added description

Current

text in the OneDoc as of today: Registrars

and Registry Operators MUST publish the mechanism and process for submitting Reasonable Requests for Lawful Disclosure on the home page of Registrar's website (or in another standardized place that may be designated by ICANN from time to time).

Note

also the email thread on this topic (attached). This new text differs significantly from the Recommendation and should be adjusted accordingly.

Response

time for urgent disclosure requests

Rec.

18 relevant text: "A

separate timeline of [less than X business days] will considered for the response to ‘Urgent’ Reasonable Disclosure Requests"

Original

OneDoc 10.5 text - "[...]

Registry Operators and Registrars MUST instead respond within 24 hours."

CPH

Proposed adding "business"

(24 business hours")

Comment

thread:

Laureen Kapin

2:07 PM Nov 13 - By adding "business" the 24 hours becomes three days (or more if its over a weekend) which guts the 24 hour requirement. The 24 hour period is a reasonable turnaround for this narrow category of urgent requests.

Susan Kawaguchi

12:01 AM Dec 4 - Agree with Laureen that 24 hour turnaround is reasonable. We could think about adding an SLA of 95% of the time the response is within the 24 hour time frame to allow flexibility for requests that take longer to fulfill.

Dennis Chang

4:53 pm Dec 5 - agree with Laureen and Susan here.

Result:

Suggestion was rejected. This issue was not discussed on the Dec 5 call.

This

is clearly a matter that the IRT should be allowed to continue to discuss before action is taken by the IPT.

There

may be further areas of misalignment where the comment thread has been resolved and thus the conversation history is not easily available, nor is it readily obvious that there were differing views.

I

look forward to learning more about how these decisions are arrived at and how disagreement within the advice provided by IRT members is tracked, so that we can all better understand how to work together and reach our goals in a more predictable manner.

Thank

you and have a great weekend,

Sarah

--

Sarah Wyld

Domains Product Team

Tucows

+1.416 535 0123 Ext. 1392

On 12/6/2019 11:36 AM, Dennis Chang wrote:
Good questions.

This MAY requirement was written in to bring clarity to Tech Contact. There were IRT discussions that Tech Contact can never be published and MUST always be redacted. It was a concern that if we are silent, this may be the assumption with the implementors later. The question to the IRT now would be “Is this a misalignment with the recommendation?” All, policy languages that receive “Misalignment” comments will be discussed again at the IRT meeting.

It seems to be a good time to remind the IRT of the roles we each play. As the policy implementation project is new to many on the IRT and most have gained their policy experience in the Policy Development world, I think it would be helpful to explain the role of the IRT again.  This was covered in the first IRT session but it’s been awhile and many have joined since then.

Policy implementation (PI) is different than the Policy Development Process (PDP) in the roles we play.
In PDP, the community working group (WG) is accountable for the development of the policy recommendation language with support from the staff.  This role is provided by the Policy Development Support team. https://www.icann.org/policy

In PI,  the staff is accountable for the implementation led by GDD and therefore resp0sible for the policy language.
IRT’s role is to advise the IPT with their expertise and most importantly with their alignment to the recommendations.

This is why PDP WG is led by a community WG Chair and PI is led by a staff.

Yours truly,
Dennis Chang
Registration Data Policy Implementation Program Director

From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org><mailto:irt.regdatapolicy-bounces at icann.org> on behalf of Rubens Kuhl <rubensk at nic.br><mailto:rubensk at nic.br>
Date: Thursday, December 5, 2019 at 17:13
To: "irt.regdatapolicy at icann.org"<mailto:irt.regdatapolicy at icann.org> <irt.regdatapolicy at icann.org><mailto:irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] 9.3.2.1 Consent to Publish Technical Contact Data

On 5 Dec 2019, at 19:56, Jody Kolker <jkolker at godaddy.com<mailto:jkolker at godaddy.com>> wrote:

Hi Team,

I see that this paragraph is no longer marked in the One Doc:

9.3.2.1   If a Registrar collects Technical data from the Registrant under Section 5.2 and Redacts the data elements values listed in Sections 8.3.1.10 through 8.3.1.12, Registrar MAY provide the opportunity for the relevant contact to provide Consent to Publish the data element values. Registrar MAY Publish the data element value(s) for which the relevant contact has provided its Consent.

All comments have been removed.  We discussed this paragraph and I know that CPH entities wanted this paragraph removed.  How did staff make a decision that it should remain and that all comments for the paragraph need to be removed?

Besides this specific process issue, I have a general comments on MAY; every MAY should have, at least in our work docs even though not in final policy, what previously existing exclusion the MAY is trying to address by allowing it to be performed sometimes. So, if a current policy or contract clause would prohibit that, the MAY clause makes senses, because it allows something to be done that otherwise wouldn't be permitted, even though not mandating it.

But if something was already allowed, there is no point in have a policy with a MAY clause.

So, was there something prohibiting this specific action that requires a MAY sentence ?

Rubens

_______________________________________________

IRT.RegDataPolicy mailing list

IRT.RegDataPolicy at icann.org<mailto:IRT.RegDataPolicy at icann.org>

https://mm.icann.org/mailman/listinfo/irt.regdatapolicy

_______________________________________________

By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20191216/d0bc34c3/attachment.html>