[gnso-rds-pdp-wg] Notes and action items from today's meeting
Farell Folly
farellfolly at gmail.com
Wed Dec 21 08:31:21 UTC 2016
Morning,
Thanks Lisa for these notes.
I apologize for not have been able to attend.
Will go through the actions items
Best Regards
@__f_f__
about.me/farell
________________________________.
Mail sent from my mobile phone. Excuse for brievety.
Le 21 déc. 2016 08:09, "Lisa Phifer" <lisa at corecom.com> a écrit :
> Dear All,
>
> Please find below the notes and action items from today's meeting. Please
> note that our next WG call will be on 10 January.
>
> Best regards,
> Lisa
>
>
>
> *RDS PDP WG Meeting - 21 December 2016 *
>
> *These high-level notes are designed to help PDP WG members navigate
> through the content of the call and are not meant as a substitute for the
> transcript and/or recording. The MP3, transcript, and chat are provided
> separately and are posted on the wiki at:
> https://community.icann.org/x/i6TDAw <https://community.icann.org/x/i6TDAw>
> 1. Roll call / SOI*
>
> - Roll call will be taken from Adobe Connect
> - Please remember to keep your SOIs up to date
>
>
> *2. Review poll results *
>
> - Refer to poll results posted at https://community.icann.org/x/i6TDAw
> - Result Summary: Option (b) had greatest support, followed by options
> (a) and (e). Just two respondents agreed with option (c) – no limitation by
> purpose, and two respondents stated that their answers differed for subsets
> of thin data elements. No support for option (d) – eliminating access to
> “thin data” entirely.
> - Consideration of poll results as a guide to find a productive path
> forward for deliberations
> - 90% of respondents through purpose should play some kind of role in
> policy for "thin data" - strong indication the WG should consider
> legitimate/illegitmate purposes. Why shouldn't policy take purpose into
> consideration?
> - Possible reasons: cost and effort involved in checking and enforcing
> purpose, limited benefit in return for that cost; not sure we can prevent
> sharing data after it was taken from the system; extra layers of access
> control may not be warranted for minimal data included in thin data
> - Reactions: May want to separate anonymous access from identification
> or authentication for access to thin data - may not want to allow anonymous
> access? Privacy policies may require authentication but that may lead to
> logging access which may not be desirable
> - Is the answer for thin data different than for other registration
> data? Purposes for thin data may be more technical, may not require PII,
> may pose less risk of abuse (and be dealt with using rate limiting, etc)
> because thin data includes few elements - so why should it be hidden? There
> are purpose(s) for thin data but access shouldn't be limited
> - The language used in the poll questions may have led to results that
> are farther apart than we really are - I didn't find options satisfactory
> so I wrote option (e) to include anonymous access without declaring a
> purpose. The wording implied access controls to check purpose, which is why
> (e) is closer to (c) than (a).
> - Re: "except for illegitimate purposes" - if someone does bad things,
> their access can be blocked - but what does that cost?
> - Two of the thin data elements are already accessible anonymously -
> name servers, domain name - so the set of thin data elements you might
> control access to is very small
> - How hard is it to authenticate requestors? Really hard for today's
> WHOIS or an open system
> - Even with this limited number of responses, we have opposing views
> about whether purpose should play an inclusive or exclusive role in “thin
> data” policy. But further deliberation on specific purpose(s) and thin data
> elements may uncover common ground.
> - We may be stumbling a bit over possible implementations when trying
> to visualize impact of potential policy requirements. For example, captive
> portal pages often offer both anonymous Internet access and authenticated
> access to more network resources – it is possible to implement both kinds
> of policies. While we need to consider whether implementation of potential
> policies is feasible, policy should drive implementation not the other way
> around
>
>
> *3. Continue deliberation on question 2.1, focusing on thin data*
>
> - Is there anyone who thinks we should not consider purpose at all?
> - *Agreement: Concluding that purpose is useful to consider further
> (without implying authentication, disclosure, or access control)..*
> - Refer to handout posted at https://community.icann.org/x/
> <https://community.icann.org/x/i6TDAw> i6TDAw
> <https://community.icann.org/x/i6TDAw>
> - What is the purpose of collecting thin data elements? Specifically:
> - What is the purpose of collecting the domain name's Sponsoring
> Registrar? It tells the registrant who is responsible for their domain name
> (but see note about Resellers below), required by policy to help facilitate
> registrar to registrar transfers; see also EWG pg 129-132 for purposes of
> any field
> - There's also a contractual line through the reseller to the
> registrar; may have an optional Reseller field for registrars who wish to
> avail themselves of it
> - What is the purpose of collecting the domain name registration's
> Status(es)?
> - Could put "thin data" elements into a few categories - (1)
> Registrar/URL, (2) operational data - Name Servers, (3) rest are metadata
> about the domain registration such as dates, status
> - Note that many thin data elements are not "collected" per se - the
> fields are populated but from the RDS/WHOIS perspective we refer to
> collection
> - *Agreement that for all thin data elements, there is at least one
> purpose for collection*
> - Referring to EWG report pages 129-131, the thin data elements are
> listed by purpose - are there comments on the purposes listed for "thin
> data" elements?
> - Noted that purposes listed by EWG were not comprehensive - but they
> were recommended as "permissible"
>
>
> *Action:* Staff to launch poll to confirm two main points of agreement
> and allow those not on call to weigh in; poll to remain open through the
> holidays with results aggregated for use in next WG call 10 January
>
>
>
>
> *4. Confirm next meeting date: Tuesday 10 January 2017 at 17.00 UTC *
> *Meeting Materials: * https://community.icann.org/x/i6TDAw
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161221/660e86d1/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list