[Epdp-dt] Edits to the charter

Thu Jul 5 12:51:29 UTC 2018

Hi Rubens,

We have modified the language and placed it into question form.

Do current policies address RDAP replacing port 43, if not what policies
should be created?

Are policies needed for RDAP to replace Port 43?

 Are further policies needed to facilitate tiered access for RDAP? •

How can RDAP+ allow Registries/Registrars to accept accreditation tokens
and purpose for the query?

Once accreditation models are developed by the appropriate accreditors and
approved by the relevant legal authorities, how can we ensure that RDAP+ is
ready to accept, log and respond to the accredited requestor’s token?

Susan

On Wed, Jul 4, 2018 at 9:06 PM, Rubens Kuhl <rubensk at nic.br> wrote:

>
>
> On 5 Jul 2018, at 00:40, Susan Kawaguchi <susankpolicy at gmail.com> wrote:
>
> Thanks Marika.
>
> Stephanie - I am fine with Unified typo on my part in using Uniform
> although we already have a Uniform Dispute Resolution Policy and a Uniform
> Rapid Suspension.  None the less the BC does not want to limit the ePDP to
> the ICANN model for access.  Our intention in suggesting the lower case was
> to allow discussion of models different than ICANN's proposed model.
>
> Rubens - The BC does not agree that discussing access and creating
> policies surrounding access would be that much more of a burden or time
> consuming to the ePDP.  The ePDP will have to discuss purpose and that can
> be used to inform the access discussion.
>
>
> Susan,
>
> The annex is not just about access, it's a laundry-list containing many
> items, while access is already contemplated in 4.4 and 4.5. Perhaps
> clarifying that 4.4 and 4.5 includes access so the ePDP can still have some
> chance of getting to the finish line ?
>
>
>
>
> I can redraft the proposed language as questions if that is more
> acceptable.
>
>
> If the questions are also neutrally worded, that might be a solution.
>
>
> Rubens
>
>
>
> Susan
>
>
>
> On Wed, Jul 4, 2018 at 1:59 AM, Marika Konings <marika.konings at icann.org>
> wrote:
>
>> Thanks, Susan, Rubens and Stephanie. I’ve added your comments to the
>> Scope Google Doc (see https://docs.google.com/docume
>> nt/d/1x2k9e3w752j-C_Ix43A7HSDV2G-_zXlyzZozei4WNJ0/edit). If there are
>> further comments, and especially proposed compromise language, please feel
>> free to add.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Marika
>>
>>
>>
>> *From: *Epdp-dt <epdp-dt-bounces at icann.org> on behalf of Stephanie
>> Perrin <stephanie.perrin at mail.utoronto.ca>
>> *Date: *Wednesday, July 4, 2018 at 05:13
>> *To: *"epdp-dt at icann.org" <epdp-dt at icann.org>
>> *Subject: *Re: [Epdp-dt] Edits to the charter
>>
>>
>>
>> I agree with all of Rubens' observations, and would note that changing
>> "unified" to "uniform" is already a policy decision.  ICANN called its
>> model a "Unified access model".  It will not and cannot be uniform across
>> some parameters, so I find it misleading as a label.  Access model is
>> sufficient.
>>
>> And to reiterate, we do not have the bandwidth to do both at the same
>> time.  Furthermore, setting up an implementation scheme is implementation.
>>
>> cheers Stephanie
>>
>>
>>
>> On 2018-07-03 23:00, Rubens Kuhl wrote:
>>
>> Susan,
>>
>>
>>
>> Comments inline.
>>
>>
>>
>>
>>
>> On 3 Jul 2018, at 23:37, Susan Kawaguchi <susankpolicy at gmail.com> wrote:
>>
>>
>>
>> Hello Marika,
>>
>>
>>
>> The BC has agreed upon adding the following to the draft charter.
>>
>> Add highlighted text to section j of charter Draft:
>>
>> j)      Disclosure of non-public data to outside parties, including
>> definition of terms in the Temp Spec, such as “reasonable access”
>>
>> j1) Should existing requirements in Temporary Specification remain in
>> place until a Uniform Access Model is finalized?
>>
>>
>>
>> Considering your last comment, perhaps removing the capitalisation in
>> Uniform Access Model ? And considering all the controversies regarding
>> uniform, perhaps not using uniform or any other adjective and going for
>> "access model" ?
>>
>>
>>
>> On a different matter, the EPDP can choose every one of 4 options: ( )
>> accept, ( ) reject, ( ) change, ( ) out of scope of PDPs. So something in
>> the charter can't automatically presume an outcome out, like "remain in
>> place", which is what it would be doing. So by putting something like this
>> in the charter, Council would be actually making policy.
>>
>>
>>
>>
>>
>>
>>
>> The BC requests that the Temp Spec Annex is added back into the EPDP
>> charter and work on access be in parallel with all other work.
>>
>> As many others mentioned, expanding the scope is likely setting up this
>> effort to failure.
>>
>> On mentioning one specific topic as made in parallel, why we are defining
>> something that is usually done by the WG in finding optimal paths thru
>> discussions ?
>>
>>
>>
>>
>>
>> Also include the following language concerning access to the scope of the
>> ePDP charter.
>>
>> EPDP scope already includes developing policy for access, and for RDAP to
>> replace Port 43.  This scope should include policy development for tiered
>> access via RDAP+, which could accept an accreditation token and purpose for
>> query. This would allow legally-accredited entities to access non-public
>> Whois if and when such accreditation is accomplished.   The design of
>> accreditation processes and legal clearance for those accreditation models
>> would occur entirely *outside* of this EPDP.  If and when an
>> Accreditation model is cleared by appropriate legal authorities, RDAP+
>> should be ready to accept, log, and respond to these accredited access
>> queries.
>>
>>
>>
>> There are two mentions of "RDAP+" above but there is no IETF-protocol for
>> that name. What would that mean, and knowing what it means, how to describe
>> then in technical references currently defined ?
>>
>> Also, by only mentioning an accreditation token and a purpose, we are
>> limiting the decisions of the WG and making policy beforehand. For
>> instance, for having an specific result for an specific object an specific
>> allowance might be needed.
>>
>> Also, "legally-accredited" would imply accreditations that might be legal
>> but not desirable. Extreme example: someone could be an accredited child
>> molester.
>>
>> Also, queries can not be accredited, since they are transactions, not
>> entities.
>>
>>
>>
>> This also looks like policy making in the charter to me.
>>
>>
>>
>>
>>
>> The BC requests that we refer to a uniform access model as a generic term
>> and does not refer to the ICANN org model Uniform Access Model.
>>
>>
>>
>> Agreed.
>>
>>
>>
>>
>>
>> Rubens
>>
>>
>>
>>
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Susan Kawaguchi
>>
>>
>>
>> Councilor for the Business Constituency
>>
>>
>>
>>
>>
>> _______________________________________________
>> Epdp-dt mailing list
>> Epdp-dt at icann.org
>> https://mm.icann.org/mailman/listinfo/epdp-dt
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Epdp-dt mailing list
>>
>> Epdp-dt at icann.org
>>
>> https://mm.icann.org/mailman/listinfo/epdp-dt
>>
>>
>> _______________________________________________
>> Epdp-dt mailing list
>> Epdp-dt at icann.org
>> https://mm.icann.org/mailman/listinfo/epdp-dt
>>
>
> _______________________________________________
> Epdp-dt mailing list
> Epdp-dt at icann.org
> https://mm.icann.org/mailman/listinfo/epdp-dt
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/epdp-dt/attachments/20180705/20e397db/attachment-0001.html>