[IRT.RegDataPolicy] IRT Liaison report on Rec7 during the 20Aug2020 GNSO Council Meeting

[Alex Deacon]

Hi Rubens,

OK, but clearly policy that includes mandatory obligations on CPs that are
enforceable by ICANN Compliance plus a procedure for handling conflicts is
very different from a policy that gives the CP the discretion to do
something with no review/input from ICANN.   If contractual obligations are
voluntary we don't need ICANN at all.

Also, if the choice of OneDoc language results in a situation where the
conflict procedure is no longer required or relevant, we are right back
where we were.  e.g. The IRT language is amending policy recommendations
adopted by the GNSO Council and the ICANN Board - and we don't have the
power to do that.

Alex

___________
*Alex Deacon*
Cole Valley Consulting
alex at colevalleyconsulting.com
+1.415.488.6009



On Thu, Sep 10, 2020 at 12:17 PM Rubens Kuhl <rubensk at nic.br> wrote:

> Alex,
>
> That assumption is wrong. A legal basis is also required in the Thick
> WHOIS policy, as listed in
> https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en
>
> Implementation Note
> Where a conflict exists between local privacy laws and requirements
> included in this Policy, ICANN Procedure for Handling WHOIS Conflicts with
> Privacy Law is available for Registry Operators and Registrars
>
> Deference to laws are also present in the RAA and RA. Since we are talking
> about data from registrars, this is the RAA section:
> https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en
>
> 3.7.2 Registrar shall abide by applicable laws and governmental
> regulations.
>
> So if everything is already constrained by law, saying a new policy is
> also constrained by law changes nothing.
>
>
> Rubens
>
>
>
>
> > On 10 Sep 2020, at 14:15, Alex Deacon <alex at colevalleyconsulting.com>
> wrote:
> >
> > Again let's not overcomplicate things.
> >
> > I appreciate the argument that we should keep the "provided an
> appropriate legal basis exists" language as that the IRT is not empowered
> to amend policy recommendations adopted by the GNSO Council and the ICANN
> Board.
> >
> > It has also been stated numerous times that a legal basis doesn't
> exist.  (As you know I don't agree but whatever...)
> >
> > So I'm simply pointing out that if we include that language in the one
> doc the IRT explicitly amends policy recommendations adopted by the GNSO
> Council and the ICANN board (Thick WHOIS) which everyone is admonishing me
> not to do.
> >
> > This is the jam we are in - don't kill the messenger.
> >
> > Alex
> >
> >
> >
> >
> > ___________
> > Alex Deacon
> > Cole Valley Consulting
> > alex at colevalleyconsulting.com
> > +1.415.488.6009
> >
> >
> >
> > On Wed, Sep 9, 2020 at 2:23 PM Rubens Kuhl <rubensk at nic.br> wrote:
> >
> >
> >> On 9 Sep 2020, at 15:10, Sarah Wyld <swyld at tucows.com> wrote:
> >>
> >> Hello team,
> >>
> >> I'd like us to return to Roger's initial email, which I think had some
> very valuable points in it that have been a bit passed over. I've attached
> it here for reference (hope it comes through).
> >>
> >> Recommendation #7 says the data "must be transferred from registrar to
> registry provided an appropriate legal basis exists and data processing
> agreement is in place."
> >>
> >> Whether the Thick Whois Transition Policy is itself the grounds for a
> legitimate interest in the data or not is beside the point; our duty in
> this IRT is to implement the recommendations, and omitting that language
> from the final Policy would mean we lose requirements which the Phase 1
> EPDP team found important enough to specifically include in the
> recommendation.
> >>
> >> If a Registry's implementation of the Thick Whois Transition Policy is
> such that all the data elements listed in Rec 7 are required, then that's
> fine as long as the registry provides an appropriate data processing
> agreement to the registrar. But it's not appropriate for us as the IRT to
> modify the Policy by removing this requirement.
> >>
> >
> > And if the IPT tries removing that language without an IRT consensus,
> this would be fast grounds to an RfR or to an IRP.
> >
> > If the legal basis exists, there is no problem in keeping the exact
> recommendation language since it always be true, right ?
> >
> >
> > Rubens
> >
> >
> > _______________________________________________
> > IRT.RegDataPolicy mailing list
> > 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.
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> 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/20200913/63300fba/attachment.html>