[gnso-rds-pdp-wg] Now open: 18 January Poll on Purpose

[Greg Shatan]

If we are going to consider this in the context of ICANN's mission, I
thought it would be helpful to have the whole package of ICANN's Mission,
Commitments and Core Values in front of us:

ARTICLE 1 MISSION, COMMITMENTS AND CORE VALUESSection 1.1. MISSION

(a) The mission of the Internet Corporation for Assigned Names and Numbers
("*ICANN*") is to ensure the stable and secure operation of the Internet's
unique identifier systems as described in this *Section 1.1(a)* (the "
*Mission*"). Specifically, ICANN:

(i) Coordinates the allocation and assignment of names in the root zone of
the Domain Name System ("*DNS*") and coordinates the development and
implementation of policies concerning the registration of second-level
domain names in generic top-level domains ("*gTLDs*"). In this role, ICANN's
scope is to coordinate the development and implementation of policies:

   - For which uniform or coordinated resolution is reasonably necessary to
   facilitate the openness, interoperability, resilience, security and/or
   stability of the DNS including, with respect to gTLDregistrars and
   registries, policies in the areas described in Annex G-1 and Annex G-2; and
   - That are developed through a bottom-up consensus-based
   multistakeholder process and designed to ensure the stable and secure
   operation of the Internet's unique names systems.

The issues, policies, procedures, and principles addressed in Annex G-1 and
Annex G-2 with respect to gTLD registrars and registries shall be deemed to
be within ICANN's Mission.

(ii) Facilitates the coordination of the operation and evolution of
the DNS root
name server system.

(iii) Coordinates the allocation and assignment at the top-most level of
Internet Protocol numbers and Autonomous System numbers. In service of its
Mission, ICANN (A) provides registration services and open access for
global number registries as requested by the Internet Engineering Task
Force ("*IETF*") and the Regional Internet Registries ("*RIRs*") and (B)
facilitates the development of global number registry policies by the
affected community and other related tasks as agreed with the RIRs.

(iv) Collaborates with other bodies as appropriate to provide registries
needed for the functioning of the Internet as specified by Internet
protocol standards development organizations. In service of its Mission,
ICANN's scope is to provide registration services and open access for
registries in the public domain requested by Internet protocol development
organizations.

(b) ICANN shall not act outside its Mission.

(c) ICANN shall not regulate (i.e., impose rules and restrictions on)
services that use the Internet's unique identifiers or the content that
such services carry or provide, outside the express scope of *Section
1.1(a)*. For the avoidance of doubt, ICANN does not hold any governmentally
authorized regulatory authority.

(d) For the avoidance of doubt and notwithstanding the foregoing:

(i) the foregoing prohibitions are not intended to limit ICANN's authority
or ability to adopt or implement policies or procedures that take into
account the use of domain names as natural-language identifiers;

(ii) Notwithstanding any provision of the Bylaws to the contrary, the terms
and conditions of the documents listed in subsections (A) through (C)
below, and ICANN's performance of its obligations or duties thereunder, may
not be challenged by any party in any proceeding against, or process
involving, ICANN (including a request for reconsideration or an independent
review process pursuant to Article 4) on the basis that such terms and
conditions conflict with, or are in violation of, ICANN's Mission or
otherwise exceed the scope of ICANN's authority or powers pursuant to these
Bylaws ("*Bylaws*") or ICANN's Articles of Incorporation ("*Articles of
Incorporation*"):

(A)

(1) all registry agreements and registrar accreditation agreements between
ICANN and registry operators or registrars in force on 1 October 2016
<https://www.icann.org/resources/pages/bylaws-2016-09-30-en#foot1>[1],
including, in each case, any terms or conditions therein that are not
contained in the underlying form of registry agreement and registrar
accreditation agreement;

(2) any registry agreement or registrar accreditation agreement not
encompassed by (1) above to the extent its terms do not vary materially
from the form of registry agreement or registrar accreditation agreement
that existed on 1 October 2016;

(B)any renewals of agreements described in subsection (A) pursuant to their
terms and conditions for renewal; and

(C)ICANN's Five-Year Strategic Plan and Five-Year Operating Plan existing
on 10 March 2016.

(iii) *Section 1.1(d)(ii)* does not limit the ability of a party to any
agreement described therein to challenge any provision of such agreement on
any other basis, including the other party's interpretation of the
provision, in any proceeding or process involving ICANN.

(iv) ICANN shall have the ability to negotiate, enter into and enforce
agreements, including public interest commitments, with any party in
service of its Mission.

Section 1.2. COMMITMENTS AND CORE VALUES

In performing its Mission, ICANN will act in a manner that complies with
and reflects ICANN's Commitments and respects ICANN's Core Values, each as
described below.

(a) *COMMITMENTS*

In performing its Mission, ICANN must operate in a manner consistent with
these Bylaws for the benefit of the Internet community as a whole, carrying
out its activities in conformity with relevant principles of international
law and international conventions and applicable local law, through open
and transparent processes that enable competition and open entry in
Internet-related markets. Specifically, ICANN commits to do the following
(each, a "*Commitment*," and collectively, the "*Commitments*"):

(i) Preserve and enhance the administration of the DNS and the operational
stability, reliability, security, global interoperability, resilience, and
openness of the DNS and the Internet;

(ii) Maintain the capacity and ability to coordinate the DNS at the overall
level and work for the maintenance of a single, interoperable Internet;

(iii) Respect the creativity, innovation, and flow of information made
possible by the Internet by limiting ICANN's activities to matters that are
within ICANN's Mission and require or significantly benefit from global
coordination;

(iv) Employ open, transparent and bottom-up, multistakeholder policy
development processes that are led by the private sector (including
business stakeholders, civil society, the technical community, academia,
and end users), while duly taking into account the public policy advice of
governments and public authorities. These processes shall (A) seek input
from the public, for whose benefit ICANN in all events shall act, (B)
promote well-informed decisions based on expert advice, and (C) ensure that
those entities most affected can assist in the policy development process;

(v) Make decisions by applying documented policies consistently, neutrally,
objectively, and fairly, without singling out any particular party for
discriminatory treatment (i.e., making an unjustified prejudicial
distinction between or among different parties); and

(vi) Remain accountable to the Internet community through mechanisms
defined in these Bylaws that enhance ICANN's effectiveness.

(b) *CORE VALUES*

In performing its Mission, the following "*Core Values*" should also guide
the decisions and actions of ICANN:

(i) To the extent feasible and appropriate, delegating coordination
functions to or recognizing the policy role of, other responsible entities
that reflect the interests of affected parties and the roles of bodies
internal to ICANN and relevant external expert bodies;

(ii) Seeking and supporting broad, informed participation reflecting the
functional, geographic, and cultural diversity of the Internet at all
levels of policy development and decision-making to ensure that the
bottom-up, multistakeholder policy development process is used to ascertain
the global public interest and that those processes are accountable and
transparent;

(iii) Where feasible and appropriate, depending on market mechanisms to
promote and sustain a competitive environment in the DNS market;

(iv) Introducing and promoting competition in the registration of domain
names where practicable and beneficial to the public interest as identified
through the bottom-up, multistakeholder policy development process;

(v) Operating with efficiency and excellence, in a fiscally responsible and
accountable manner and, where practicable and not inconsistent with ICANN's
other obligations under these Bylaws, at a speed that is responsive to the
needs of the global Internet community;

(vi) While remaining rooted in the private sector (including business
stakeholders, civil society, the technical community, academia, and end
users), recognizing that governments and public authorities are responsible
for public policy and duly taking into account the public policy advice of
governments and public authorities;

(vii) Striving to achieve a reasonable balance between the interests of
different stakeholders, while also avoiding capture; and

(viii) Subject to the limitations set forth in *Section 27.2*, within the
scope of its Mission and other Core Values, respecting internationally
recognized human rights as required by applicable law. This Core Value does
not create, and shall not be interpreted to create, any obligation on
ICANN outside
its Mission, or beyond obligations found in applicable law. This Core Value
does not obligate ICANN to enforce its human rights obligations, or the
human rights obligations of other parties, against other parties.

(c) The Commitments and Core Values are intended to apply in the broadest
possible range of circumstances. The Commitments reflect ICANN's
fundamental compact with the global Internet community and are intended to
apply consistently and comprehensively to ICANN's activities. The specific
way in which Core Values are applied, individually and collectively, to any
given situation may depend on many factors that cannot be fully anticipated
or enumerated. Situations may arise in which perfect fidelity to all Core
Values simultaneously is not possible. Accordingly, in any situation where
one Core Value must be balanced with another, potentially competing Core
Value, the result of the balancing must serve a policy developed through
the bottom-up multistakeholder process or otherwise best serve ICANN's
Mission.

On Wed, Jan 25, 2017 at 11:26 PM, Stephanie Perrin <
stephanie.perrin at mail.utoronto.ca> wrote:

> I am not sure how we get to this discussion.  What I am saying, is that
> the purpose of collecting data has to be linked to ICANN's core mission.
> AS Peter said a while ago, is the core mission to enable law enforcement
> investigations? No.  It is a legitimate purpose to use or disclose limited
> sets of data as required in accordance with law, but it is not the reason
> we collect or generate thin data.  This distinction is important in data
> protection law.  Nobody is saying we should not disclose the thin data,
> including name servers.  What we are trying to say, and obviously with very
> little success, is that several of the purposes for collecting thin data
> which were in the last poll, were not related to ICANN's core mission.
> They might be legitimate disclosures of data, but they are not legitimate
> purposes to collect.
>
> Displaying data in WHOIS is a disclosure.  We are not supposed to be
> talking about that yet.  We keep conflating the legitimacy of collection,
> and why we gather or generate data elements about a domain name, and
> disclosure.
>
> Sorry to keep hammering on this, but it is a very simple concept that is
> fundamental to data protection.  No wonder we have been arguing about this
> for 18 years.....
>
> cheers Stephanie
>
> On 2017-01-25 21:06, John Bambenek wrote:
>
> Regardless of the privacy implications, if someone who wants to look up a
> hostname and can't find can't figure out what the authoritative nameservers
> are for the domain, DNS quite simply will not work and with it the internet
> is down; go home.
>
> Unless someone is suggesting we completely re-architect DNS, having
> nameservers tied to domain records is absolutely essential.
>
> You could deprecate displaying it in whois but any DNS client would easily
> be able to retrieve the data because the resolver still has to know what to
> ask for.
>
> J
>
> Sent from my iPhone
>
> On Jan 25, 2017, at 16:08, Michele Neylon - Blacknight <
> michele at blacknight.com> wrote:
>
> Stephanie
>
>
>
> Do you have any links to any legislation / regulations etc., that are this
> broad?
>
>
>
> And honestly I don’t see how a set of nameserver is “personally
> identifiable” unless you’re using your own name in the hostname (which you
> could, but then I’d see that as your choice and not a technical requirement)
>
>
>
> Regards
>
>
> Michele
>
>
>
>
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> http://www.blacknight.host/
>
> http://blacknight.blog/
>
> http://ceo.hosting/
>
> Intl. +353 (0) 59  9183072 <+353%2059%20918%203072>
>
> Direct Dial: +353 (0)59 9183090 <+353%2059%20918%203090>
>
> -------------------------------
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,
>
> Ireland  Company No.: 370845
>
>
>
> *From: *Stephanie Perrin <stephanie.perrin at mail.utoronto.ca>
> *Date: *Wednesday 25 January 2017 at 19:40
> *To: *Michele Neylon <michele at blacknight.com>, Scott Hollenbeck <
> shollenbeck at verisign.com>, Sam Lanfranco <sam at lanfranco.net>, "
> dave at davecake.net" <dave at davecake.net>
> *Cc: *"gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
> *Subject: *Re: [gnso-rds-pdp-wg] Now open: 18 January Poll on Purpose
>
>
>
> Unfortunately, in a world where the Internet of things is taking off,
> privacy advocates and authorities have to insist that data generated by or
> as a result of the actions of an individual or his devices(eg metadata,
> timestamping, etc) has to be considered as personal information.  If it is
> used to describe processes pertaining to that information, if it could be
> used to incriminate that individual, it is important that it be recognized
> as information for which individuals have rights.  Otherwise, we have a
> situation where the individual has no right to access information that may
> impact him, may incriminate him, but to which he may be utterly oblivious.
> Sorry it is such a pain in the neck, but there we are.
>
> Stephanie
>
>
>
> On 2017-01-25 12:32, Michele Neylon - Blacknight wrote:
>
> Scott
>
>
>
> Sure, but if we go down that route we could make cases for a lot of things
> J
>
> My main problem with this entire debacle is that the data we’re dealing
> with is pretty much useless and isn’t personally identifiable.
>
>
>
> Regards
>
>
>
> Michele
>
>
>
>
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> https://www.blacknight.com/
>
> http://blacknight.blog/
>
> Intl. +353 (0) 59  9183072 <+353%2059%20918%203072>
>
> Direct Dial: +353 (0)59 9183090 <+353%2059%20918%203090>
>
> Social: http://mneylon.social
>
> Some thoughts: http://ceo.hosting/
>
> -------------------------------
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845
>
>
>
> *From: *Scott Hollenbeck <shollenbeck at verisign.com>
> <shollenbeck at verisign.com>
> *Date: *Wednesday 25 January 2017 at 17:15
> *To: *Michele Neylon <michele at blacknight.com> <michele at blacknight.com>,
> Stephanie Perrin <stephanie.perrin at mail.utoronto.ca>
> <stephanie.perrin at mail.utoronto.ca>, Sam Lanfranco <sam at lanfranco.net>
> <sam at lanfranco.net>, "dave at davecake.net" <dave at davecake.net>
> <dave at davecake.net> <dave at davecake.net>
> *Cc: *"gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
> <gnso-rds-pdp-wg at icann.org> <gnso-rds-pdp-wg at icann.org>
> *Subject: *RE: [gnso-rds-pdp-wg] Now open: 18 January Poll on Purpose
>
>
>
> *From:* gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-
> bounces at icann.org <gnso-rds-pdp-wg-bounces at icann.org>] *On Behalf Of *Michele
> Neylon - Blacknight
> *Sent:* Wednesday, January 25, 2017 12:09 PM
> *To:* Stephanie Perrin; Sam Lanfranco; David Cake
> *Cc:* gnso-rds-pdp-wg at icann.org
> *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] Now open: 18 January Poll on
> Purpose
>
>
>
> Stephanie
>
>
>
> Sorry, but policy + the technology go hand in hand. You cannot completely
> separate them and any policy that this (or any other) group produces needs
> to be technically possible to implement.
>
>
>
> As to the specifics ..
>
>
>
> I would argue that generated data is NOT collected, as it’s generated.
>
>
>
> If you register stephanieperrin.com with us the only elements we are
> “collecting” that end up in in the “thin” data are:
>
> the domain name string
>
> the nameservers you’re using (and if you don’t specify any we’ll use our
> own)
>
> All the other elements are NOT collected by the registrar or even the
> registry from the registrant, they are generated as part of the process of
> the domain being registered.
>
>
>
> [SAH] Michele, some might argue that the registration period is also
> collected from the registrant and is then used to generate the expiration
> date at the registry. A case might also be made for status values like
> clientTransferProhibited etc. I agree completely that generated data is
> just that – generated.
>
>
>
> Scott
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> _______________________________________________
> 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/20170126/0beb18e3/attachment.html>