[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Stephanie Perrin
stephanie.perrin at mail.utoronto.ca
Sat Oct 8 00:14:13 UTC 2016
I agree Chris, my point to those insisting on accuracy in the actual
RDS, is that if someone is a real miscreant (as opposed to someone who
forgot to send in a change of address, as most of us have done at some
point) the registrars have additional information that would help us
track them down.
Let us not underestimate what secure ID checking actually costs for
governments. Pensioners from several European countries have to go to
Canadian Service Canada offices to identify themselves annually, to
prove they are alive and still deserve a cheque. Someone has to verify
their identity (not so easy) and address, process them, and certify
whatever paperwork is required (in this case, I think the employee has
to a commissioner of oaths but I could be wrong there.) This is for
pension cheques, worth considerably more than a domain name. I realize
that the Chinese registration authorities were working on biometric
identification of registrants, but I don't think that idea is going to
catch on in Europe or North American any time soon.
Every time I show up at a hospital in my province, for a test or xray or
appointment, they verify the information that I have on file (reading it
out to the whole waiting room, a privacy complaint I plan to file as
soon I get bored at ICANN). Those minutes of staff time are
theoretically justified by the amount of healthcare fraud that goes on,
but the nexus between the service and the verification is a lot closer,
and once again the financial implications are vastly different.
Cheers Stephanie
On 2016-10-07 19:22, Chris Pelling wrote:
> Hi Stephanie,
>
> I would love as my olive branch put out yesterday to have the ability
> to authenticate what we have as being true / correct but until the
> governments of this world get together and suggest/provide a means of
> proving a person who is registering a domain is in fact the ACTUAL
> person doing it - the data received cannot be totally 100% accurate.
>
>
> Kind regards,
>
> Chris
>
> ------------------------------------------------------------------------
> *From: *"Stephanie Perrin" <stephanie.perrin at mail.utoronto.ca>
> *To: *"Richard Leaning" <rleaning at ripe.net>, "Greg Shatan"
> <gregshatanipc at gmail.com>
> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
> *Sent: *Friday, 7 October, 2016 21:15:26
> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS
> Statement of Purpose
>
> Well the registrar has quite a bit of information about the registrant
> that is not necessarily in the RDS/WHOIS.
>
> SP
>
>
> On 2016-10-07 14:20, Richard Leaning wrote:
>
> Thats Greg for articulating it so well.
>
> all i was going to say was -
>
> 'You can’t contact someone if the contact information is inaccurate’
>
> So i can’t see how you can split the two.
>
> Richard Leaning
> External Relations
> RIPE NCC
>
>
>
>
> On 7 Oct 2016, at 17:21, Greg Shatan <gregshatanipc at gmail.com
> <mailto:gregshatanipc at gmail.com>> wrote:
>
> It might be useful to bring in the findings of the WHOIS
> review team on this point. There have been multiple
> discussions of contactability and accuracy in various ICANN
> groups.
>
> We don't need to choose between "accuracy" and
> "contactability" to have this discussion. Quite the opposite.
> These are related concepts and our discussion needs to
> consider both concepts. Contactability can be correlated to
> "functional accuracy" and also to certain amount of "fault
> tolerance" in the data. Inaccuracy in some fields is highly
> detrimental to contactability, in others not so much.
> Sometimes a certain combination of inaccuracies is fatal to
> contactability. In other words, contactability informs the
> discussion of accuracy, and vice versa.
>
> Greg
>
> On Fri, Oct 7, 2016 at 10:13 AM, Stephanie Perrin
> <stephanie.perrin at mail.utoronto.ca
> <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
>
> Indeed, I think we should talk about contactable, not
> "accurate". This was the result of similar discussions of
> the WHOIS review team, as I understand it, accuracy was
> defined as contactable. It makes sense to me. I realize
> that others want more data and more accuracy, but that is
> their goal, not necessarily the goal of this pdp. The goal
> of privacy advocates, or those who wish to see data
> protection law implemented (and I do realize we are few in
> number) is to minimize the collection of information to
> what is necessary.
>
> Stephanie
>
>
> On 2016-10-07 08:27, Michele Neylon - Blacknight wrote:
>
> Stephanie
>
> Here’s one we run into all the time:
>
> A lot of our clients in Northern Ireland do not view
> themselves as being part of the UK, so they’ll choose
> to list their country as “Ireland’.
>
> Is the data they supply “bad”? Strictly speaking yes
>
> Are they still reachable? Of course they are.
>
> Regards
>
> Michele
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> http://www.blacknight.host/
>
> http://blacknight.blog/
>
> http://www.blacknight.press
> <http://www.blacknight.press/> - get our latest news &
> media coverage
>
> http://www.technology.ie <http://www.technology.ie/>
>
> Intl. +353 (0) 59 9183072
>
> Direct Dial: +353 (0)59 9183090
>
> Social: http://mneylon.social <http://mneylon.social/>
>
> Random Stuff: http://michele.irish
> <http://michele.irish/>
>
> -------------------------------
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside
> Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,Ireland Company
> No.: 370845
>
> *From: *<gnso-rds-pdp-wg-bounces at icann.org>
> <mailto:gnso-rds-pdp-wg-bounces at icann.org> on behalf
> of Stephanie Perrin
> <stephanie.perrin at mail.utoronto.ca>
> <mailto:stephanie.perrin at mail.utoronto.ca>
> *Date: *Friday 7 October 2016 at 00:42
> *To: *Mark Svancarek <marksv at microsoft.com>
> <mailto:marksv at microsoft.com>,
> "gnso-rds-pdp-wg at icann.org"
> <mailto:gnso-rds-pdp-wg at icann.org>
> <gnso-rds-pdp-wg at icann.org>
> <mailto:gnso-rds-pdp-wg at icann.org>
> *Subject: *Re: [gnso-rds-pdp-wg] For your review -
> updated RDS Statement of Purpose
>
> Not at all, ordinary people make mistakes all the
> time. However, rarely would this kind of mistake
> render the person/organization un-contactable, which
> it seems to me is the evil we are trying to avoid with
> bad data. On the other hand, criminals have a goal of
> being untraceable, so will continue to make sure they
> are not located, right?
>
> SP
>
> On 2016-10-06 19:20, Mark Svancarek wrote:
>
> There seems to be a presumption that bad data is
> caused entirely by bad people.
>
> Do we actually have data showing which fraction of
> bad data is created with criminal intent, and
> which fraction is just people being lazy or
> careless and then never being held accountable by
> the data actually being verified?
>
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On
> Behalf Of *Stephanie Perrin
> *Sent:* Thursday, October 6, 2016 3:09 PM
> *To:* gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
> *Subject:* Re: [gnso-rds-pdp-wg] For your review -
> updated RDS Statement of Purpose
>
> I agree with those pushing back on including a
> commitment to accuracy in this statement of
> purpose. I think there are a number of sound
> reasons for this. Those of us who push back are
> not advocating for bad data, that would be silly.
> What we are addressing is the futility of
> attempting to get the criminal element to put good
> data in their registration data. If we force
> them, we drive ID theft. Here are a few of my reasons:
>
> 1. Governments actually do not usually invest
> taxpayers money verifying citizen data, they
> provide penalties for having inaccurate data and
> leave it at that. Verifying address and phone
> number, given the mobility of the population in
> the countries I am familiar with from my past
> government service (US, Canada, Australia, New
> Zealand, and UK) is expensive and there is very
> little way to enforce it. This being the case,
> why would we force ICANN to do this? The cost
> inevitably would fall on the Registrars and
> registries, and be passed on to the end users.
>
> 2. As mentioned above, any pressure to improve
> data quality can hardly be expected to get
> criminals to give their accurate data, it will
> drive them to steal good data.
>
> 3. The vast majority of people are actually
> honest. I do realize that there is a high volume
> of cybercrime, but penalizing the majority of end
> users for the actions of a few (even if those
> actions result in a high volume of phishing and
> malware etc) is not good policy. There are other
> ways to catch and dump bad domains. Prosecution of
> malfeasant registrants remains a problem, but
> frankly how many can be prosecuted across borders
> anyway?
>
> 4. We do have questions about accuracy that we
> need to address, according to our charter. The
> purpose of this purpose statement is to boil down
> our business requirements for the activity in
> which we are engaged. While many actors want more
> accurate data, how to get that accuracy is so open
> to question that I regard its inclusion in the
> statement of purpose as setting impossible goals.
> I would be happy to revise this sentence as follows:
>
> To enable release of accurate gTLD registration
> data that may not otherwise be publicly available,
> under specific and explicit policy-defined
> conditions Change to
>
> To enable release of gTLD registration data that
> may not otherwise be publicly available under
> specific conditions defined by policy, and to
> develop mechanisms to encourage greater accuracy
> of data.
>
> Stephanie Perrin
>
> On 2016-10-06 16:48, Chris Pelling wrote:
>
> Hi Nick,
>
> I would actually concur with Volker. I see
> your point but, can I ask a question, the data
> collected cannot be proven to any certainty
> because we have nothing as the
> registry/registrar community to "check" it
> against. Simply checking say the address
> against a city, against a State, against a
> postal/zip code then country isnt proving the
> registrant data is correct, its simply proving
> that the registrant can open a phone book and
> pick an address out.
>
> Until tools are created to prove that
> registrant is actually at address X, accuracy
> is a rather moot point.
>
> I agree with your point about law enforcement
> and bad data being a cost to the public purse,
> but until the governments can get together and
> work out a solution for the data to be
> verified there is little anyone can do.
>
> Registrant giving fake address = bad data
>
> Registrant giving correct address of neighbour
> = bad data
>
> Registrant giving old address where previously
> lived = bad data - but at least it could be
> validated against old correct data and cross
> checked
>
> This list could be endless :
>
> Registrant giving correct data = good,
> verifiable. Maybe the governments can work
> out a solution to being able to verify their
> citizens data.
>
> I would love to find a solution that is
> workable and commercially viable, the
> governments and LEA can then use the data with
> some surety to its worthiness - although this
> is a totally separate topic, I would like to
> sit down and discuss it further - the
> governments getting together and helping this
> work.
>
> Just a thought.
>
> Kind regards,
>
> Chris
>
> ------------------------------------------------------------------------
>
> *From: *"Nick Shorey"
> <nick.shorey at culture.gov.uk>
> <mailto:nick.shorey at culture.gov.uk>
> *To: *"Volker Greimann"
> <vgreimann at key-systems.net>
> <mailto:vgreimann at key-systems.net>
> *Cc: *"gnso-rds-pdp-wg"
> <gnso-rds-pdp-wg at icann.org>
> <mailto:gnso-rds-pdp-wg at icann.org>
> *Sent: *Thursday, 6 October, 2016 17:38:55
> *Subject: *Re: [gnso-rds-pdp-wg] For your
> review - updated RDS Statement of Purpose
>
> Interesting comments Volker! I guess it's all
> about the perspective you view it from I
> suppose. The impact of bad data on law
> enforcement investigations can also be waste
> of valuable time and cost. Except the cost
> comes out of of the public purse...
>
>
> *Nick Shorey BA(Hons) MSc.*
>
> Senior Policy Advisor | Global Internet Governance
>
> Department for Culture, Media & Sport
>
> HM Government | United Kingdom
>
> Email: nick.shorey at culture.gov.uk
> <mailto:nick.shorey at culture.gov.uk>
>
> Tel: +44 (0)7710 025 626
>
> Skype: nick.shorey
>
> Twitter: @nickshorey
>
> LinkedIn: www.linkedin.com/in/nicklinkedin
> <http://www.linkedin.com/in/nicklinkedin>
>
> On 6 October 2016 at 17:23, Volker Greimann
> <vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>> wrote:
>
>
> Hi Greg,
>
> Arguments to the contrary tend to look
> like a Defense of Bad Data. I can't
> think of any reasons to defend bad
> data, unless one wants a bad database.
>
> If you want reasons, here are a few:
> 1) Cost
> 2) Waste of valuable time
> 3) Implementation nightmares
> 4) No actual standard that applies worldwide
> 5) Legacy data from legacy sources
> 6) Customer service nightmare
>
> It's reasonable to strive for
> perfectly accurate data, but accept
> that one will never get there. There
> should be commercially reasonable and
> proportionate methods to get as close
> as practically possible.
>
> One can strive for anything, but it may
> never be achieved, consuming valuable
> ressources on the way. How many people
> died trying to reach the south pole, the
> north pole, the peak of the Matterhorn,
> before someone made it. While that first
> one to make is famous now, consider the
> loss of life and ressources wasted we
> spent getting there.
>
> We have not (in this group) discussed
> data migration, but assuming a Garbage
> In, Garbage Out approach doesn't seem
> reasonable. Whether all the data is
> validated before migration, or just
> validated as part of a normal
> validation cycle, it needs be validated.
>
> Existing data in is the only feasible
> solution if you want a manageable
> transition process.
> As for validation by the road, before
> designing a process we should define who
> is going to have to implement it, process
> it, deal with user complaints, pay for it,
> etc. What is better data worth to those
> who have to pay for it? Are those that
> benefit from better data going to finance
> it (including all associated costs)? If
> so, let's talk....
>
> Best,
> Volker
>
> On Thu, Oct 6, 2016 at 11:00 AM,
> Carlton Samuels
> <carlton.samuels at gmail.com
> <mailto:carlton.samuels at gmail.com>> wrote:
>
>
> +1.
>
> Not to make too fine a point of
> it. But the EWG was tasked to
> re-imagine an RDS. If this PDP is
> tasked to build on the works of
> EWG maybe it'd be useful to
> re-visit certain ideas we now hold
> as verities.
>
> -Carlton
>
>
>
> ==============================
> /Carlton A Samuels/
> /Mobile: 876-818-1799
> <tel:876-818-1799>
> Strategy, Planning, Governance,
> Assessment & Turnaround/
> =============================
>
> On Wed, Oct 5, 2016 at 7:38 PM,
> Holly Raiche
> <h.raiche at internode.on.net
> <mailto:h.raiche at internode.on.net>>
> wrote:
>
>
> Folks
>
> Maybe we need to back up a bit
> and go back to the Charter and
> what we are supposed to be
> doing. Let me quote directly
> from it:
>
> First - background: Quoting
> the Charter on the Board
> decision to launch this PDP:
>
> /On 26 May, 2015, the ICANN
> Board passed
> a resolution adopting that
> Process Framework and
> reaffirming its 2012 request
> for a Board - initiated PDP to
> define the purpose of
> collecting, maintaining and
> providing access to gTLD
> registration data, and to
> consider safeguards for
> protecting data, using the
> recommendations in the EWG’s
> Final Report as an input to,
> and, if appropriate, as the
> foundation for a new gTLD policy/
>
>
>
>
> Later - what The Charter
> tasked this Working Group with:
>
>
>
>
> /As part of its Phase 1
> deliberations, the PDP WG
> should work to reach consensus
> recommendations by
> considering, at a minimum, the
> following complex and
> inter-related questions:/
>
> /// Users/Purposes: Who
> should have access to gTLD
> registration data and why?/
>
> /// Gated Access: What steps
> should be taken to control
> data access for each
> user/purpose?/
>
> /// Data Accuracy: What steps
> should be taken to improve
> data accuracy?/
>
> /// Data Elements: What data
> should be collected, stored,
> and disclosed?/
>
> /// Privacy: What steps are
> needed to protect data and
> privacy?/
>
> /// Coexistence: What steps
> should be taken to enable
> next-generation RDS
> coexistence with and
> replacement of the legacy
> WHOIS system?/
>
> ///Compliance: What steps are
> needed to enforce these policies?/
>
> /// System Model:What system
> requirements must be satisfied
> by any next-generation
> RDS implementation?/
>
> /// Cost: What costs will be
> incurred and how must they be
> covered?/
>
> /// Benefits: What benefits
> will be achieved and how will
> they be measured?/
>
> /// Risks: What risks do
> stakeholders face and how will
> they be reconciled?/
>
>
>
>
> So accuracy’s there - along
> with a lot of other issues.
> That is not saying that
> accuracy is not covered in
> existing requirements on
> registries/registrars. But it
> is giving a broader meaning to
> RDS - i.e., it’s not just
> about collection, maintenance
> and access to data; it’s also
> about safeguards, etc - using
> the EWG work.
>
> So thanks Rob. It’s a bit
> premature to rule issues out
> when they are well and truly
> on our table.
>
>
>
>
> Holly
>
>
>
>
>
>
>
> On 6 Oct 2016, at 6:37 am, Rod
> Rasmussen
> <rrasmussen at infoblox.com
> <mailto:rrasmussen at infoblox.com>>
> wrote:
>
> Folks,
>
> Gotta chime in here, since
> the EWG provided a lot of
> thinking on this issue. If
> you haven’t already,
> please review the EWG
> report sections on data
> accuracy and also the
> concept of data validators
> and their relationship to
> the RDS. For example, I
> would note that a
> well-provisioned RDS would
> be able to provide some
> sort of validation checks
> against existing data in
> the use case of trying to
> prevent impersonation (a
> form of accuracy) of an
> existing registrant (a big
> brand like Facebook for
> instance). Another concept
> we found very important in
> the EWG is the idea of
> creating a contact data
> set tied to a contact ID
> that is portable between
> registrars and registries.
> This provides for the
> purpose-based contacts we
> talk about at great length
> in the report. It also is
> key for addressing some of
> the fundamental
> operational issues that
> lead to inaccurate,
> out-of-date data at
> various registrars. If you
> have a change in your
> contact information (a new
> e-mail for instance) and
> hold multiple roles in
> conjunction with many
> domains, you have a real
> challenge making updates
> throughout the universe of
> your domain names. Using
> a data validator and then
> acting via the RDS, when
> you make a change to your
> contact info, that
> automatically can be
> reflected in all domains
> you are associated with
> and thus improve accuracy
> tremendously. Those are
> just a couple examples of
> how an RDS can be involved
> in dealing with accuracy
> issues and represent many
> of the concepts you can
> address once you look
> beyond the current
> paradigm of registrar
> controlled contact
> information anchored
> specifically to individual
> domain names. Accuracy in
> the “generic” system
> (including registries,
> registrars, RDS,
> validators, some other
> group we haven’t thought
> of yet) is definitely
> in-scope. How that is
> done can take many forms
> and could have different
> roles played by different
> participants in the entire
> ecosystem.
>
> Cheers,
>
> Rod
>
> On Oct 5, 2016, at
> 10:36 AM,
> benny at nordreg.se
> <mailto:benny at nordreg.se>
> wrote:
>
> But the data accuracy
> can’t be done in RDS,
> the accuracy is done
> on a registrar level
> when collecting data.
>
> RDS shall under no
> circumstances alter
> any information
> received from registry
> / registrars and
> showing any different
> info than what is
> collected on that level.
>
> WG can look at what
> accuracy they want
> registrars to do yes,
> but RDS doesn’t do
> anything.
>
> --
>
> Med vänliga hälsningar
> / Kind Regards / Med
> vennlig hilsen
>
>
> Benny Samuelsen
> Registry Manager -
> Domainexpert
>
> Nordreg AB - ICANN
> accredited registrar
>
> IANA-ID: 638
>
> Phone: +46.42197080
> <tel:%2B46.42197080>
> Direct: +47.32260201
> <tel:%2B47.32260201>
> Mobile: +47.40410200
> <tel:%2B47.40410200>
>
> *From:*<gnso-rds-pdp-wg-bounces at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>>
> on behalf of
> "Metalitz, Steven"
> <met at msk.com
> <mailto:met at msk.com>>
> *Date:*Wednesday, 5
> October 2016 at 19:32
> *To:*'Marika Konings'
> <marika.konings at icann.org
> <mailto:marika.konings at icann.org>>,
> Volker Greimann
> <vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>>,
> "gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>"
> <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Subject:*Re:
> [gnso-rds-pdp-wg] For
> your review - updated
> RDS Statement of Purpose
>
> Volker, what is the
> basis for your
> assertion that “data
> will be presented "as
> is" in this system,
> with no
>
> presumption of any
> prior cleanup work”?
>
> That statement will be
> true if we ultimately
> conclude that the
> current system is
> adequate and that we
> do not recommend
> establishment of a new
> RDS. However, if we do
> recommend a new
> system, then
> improvements to data
> accuracy are very much
> on the table, as the
> charter provision
> quoted by Marika
> indicates.
>
> Steve Metalitz
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>
> [mailto:gnso-rds-pdp-wg-bounces at icann.org]*On
> Behalf Of*Marika Konings
> *Sent:*Wednesday,
> October 05, 2016 12:53 PM
> *To:*Volker Greimann;
> gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
> *Subject:*Re:
> [gnso-rds-pdp-wg] For
> your review - updated
> RDS Statement of Purpose
>
> Volker, please note
> that the PDP WG
> Charter
> (seehttps://community.icann.org/x/E4xlAw)
> includes the following
> question:
>
> **
>
> */AspartofitsPhase1deliberations,/*/thePDPWGshouldworktoreach
> consensusrecommendations
> byconsidering,*ataminimum*,
> thefollowingcomplexandinter-related
> questions:/
>
> /(…..)/
>
> ·*/Data
> Accuracy:/*/Whatstepsshould
> betakentoimprovedataaccuracy?/
>
> /(……)/
>
> Best regards,
>
> Marika
>
> On 05/10/16 05:58,
> "gnso-rds-pdp-wg-bounces at icann.org
> on behalf of Volker
> Greimann
> <mailto:gnso-rds-pdp-wg-bounces at icann.org%20on%20behalf%20of%20Volker%20Greimann>"
> <gnso-rds-pdp-wg-bounces at icann.org
> on behalf of
> vgreimann at key-systems.net
> <mailto:gnso-rds-pdp-wg-bounces at icann.org%20on%20behalf%20of%20vgreimann at key-systems.net>>
> wrote:
>
> I would move to
> strike all references
> to data quality
> altogether from
>
> this document,
> e.g. "current",
> "accurate" etc.
>
> These are already
> required by existing
> policies and
> agreements and do
>
> not have to be
> referenced again at
> this point. We should
> focus on having
>
> to reflect the
> data as provided by
> the RNH at this stage,
> not make any
>
> presumptions about
> its quality.
>
> After all, data
> will be presented "as
> is" in this system,
> with no
>
> presumption of any
> prior cleanup work.
>
> Best,
>
> Volker
>
> >> THE purpose of
> the "Registration Data
> Service" (hereafter
> referred to
>
> >> as
>
> >> "RDS") is to
> manage authorised
> parties' access to
> information about
>
> >> [gTLD Domain
> Names, gTLD
> Nameservers, gTLD
> Registries and gTLD
>
> >> Registrars]
>
> >>
>
> >> Purpose 3(a/b)
> are possible use
> cases, not Purposes as
> such
>
> >>
>
> >> "Accurate" is
> definitely not a term
> to use if we ever
> expect to finish
>
> >> - "Current"
> would be more accurate
> (sic) / appropriate.
>
> > Agreed, with one
> minor suggestion:
>
> >
>
> > "access to
> information about
> generic top-level
> domain registries,
> registrars, names, and
> name servers."
>
> >
>
> > Scott
>
> >
> _______________________________________________
>
> > gnso-rds-pdp-wg
> mailing list
>
>
> >gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
>
>
> >https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
> --
>
> Bei weiteren
> Fragen stehen wir
> Ihnen gerne zur Verfügung.
>
> Mit freundlichen
> Grüßen,
>
> Volker A. Greimann
>
> - Rechtsabteilung -
>
> Key-Systems GmbH
>
> Im Oberen Werk 1
>
> 66386 St. Ingbert
>
> Tel.: +49 (0) 6894
> - 9396 901
> <tel:%2B49%20%280%29%206894%20-%209396%20901>
>
> Fax.: +49 (0) 6894
> - 9396 851
> <tel:%2B49%20%280%29%206894%20-%209396%20851>
>
>
> Email:vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>
>
> Web:www.key-systems.net
> <http://www.key-systems.net/>/www.RRPproxy.net
> <http://www.rrpproxy.net/>
>
> www.domaindiscount24.com
> <http://www.domaindiscount24.com/>/www.BrandShelter.com
> <http://www.brandshelter.com/>
>
> Folgen Sie uns bei
> Twitter oder werden
> Sie unser Fan bei
> Facebook:
>
> www.facebook.com/KeySystems
> <http://www.facebook.com/KeySystems>
>
> www.twitter.com/key_systems
> <http://www.twitter.com/key_systems>
>
> Geschäftsführer:
> Alexander Siffrin
>
> Handelsregister Nr.:
> HR B 18835 - Saarbruecken
>
> Umsatzsteuer ID.:
> DE211006534
>
> Member of the
> KEYDRIVE GROUP
>
> www.keydrive.lu
> <http://www.keydrive.lu/>
>
> Der Inhalt dieser
> Nachricht ist
> vertraulich und nur
> für den angegebenen
> Empfänger bestimmt.
> Jede Form der
> Kenntnisgabe,
> Veröffentlichung oder
> Weitergabe an Dritte
> durch den Empfänger
> ist unzulässig. Sollte
> diese Nachricht nicht
> für Sie bestimmt sein,
> so bitten wir Sie,
> sich mit uns per
> E-Mail oder
> telefonisch in
> Verbindung zu setzen.
>
> --------------------------------------------
>
> Should you have
> any further questions,
> please do not hesitate
> to contact us.
>
> Best regards,
>
> Volker A. Greimann
>
> - legal department -
>
> Key-Systems GmbH
>
> Im Oberen Werk 1
>
> 66386 St. Ingbert
>
> Tel.: +49 (0) 6894
> - 9396 901
> <tel:%2B49%20%280%29%206894%20-%209396%20901>
>
> Fax.: +49 (0) 6894
> - 9396 851
> <tel:%2B49%20%280%29%206894%20-%209396%20851>
>
>
> Email:vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>
>
> Web:www.key-systems.net
> <http://www.key-systems.net/>/www.RRPproxy.net
> <http://www.rrpproxy.net/>
>
> www.domaindiscount24.com
> <http://www.domaindiscount24.com/>/www.BrandShelter.com
> <http://www.brandshelter.com/>
>
> Follow us on
> Twitter or join our
> fan community on
> Facebook and stay updated:
>
> www.facebook.com/KeySystems
> <http://www.facebook.com/KeySystems>
>
> www.twitter.com/key_systems
> <http://www.twitter.com/key_systems>
>
> CEO: Alexander Siffrin
>
> Registration No.: HR B
> 18835 - Saarbruecken
>
> V.A.T. ID.:
> DE211006534
>
> Member of the
> KEYDRIVE GROUP
>
> www.keydrive.lu
> <http://www.keydrive.lu/>
>
> This e-mail and
> its attachments is
> intended only for the
> person to whom it is
> addressed. Furthermore
> it is not permitted to
> publish any content of
> this email. You must
> not use, disclose,
> copy, print or rely on
> this e-mail. If an
> addressing or
> transmission error has
> misdirected this
> e-mail, kindly notify
> the author by replying
> to this e-mail or
> contacting us by
> telephone.
>
> _______________________________________________
>
> gnso-rds-pdp-wg
> mailing list
>
> gnso-rds-pdp-wg at icann.org
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:gnso-rds-pdp-wg at icann.org>
>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
> --
>
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
>
>
> Mit freundlichen Grüßen,
>
>
>
> Volker A. Greimann
>
> - Rechtsabteilung -
>
>
>
> Key-Systems GmbH
>
> Im Oberen Werk 1
>
> 66386 St. Ingbert
>
> Tel.:+49 (0) 6894 - 9396 901
> <tel:%2B49%20%280%29%206894%20-%209396%20901>
>
> Fax.:+49 (0) 6894 - 9396 851
> <tel:%2B49%20%280%29%206894%20-%209396%20851>
>
> Email:vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>
>
>
>
> Web:www.key-systems.net
> <http://www.key-systems.net/> /www.RRPproxy.net <http://www.rrpproxy.net/>
>
> www.domaindiscount24.com
> <http://www.domaindiscount24.com/> /www.BrandShelter.com
> <http://www.brandshelter.com/>
>
>
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>
> www.facebook.com/KeySystems
> <http://www.facebook.com/KeySystems>
>
> www.twitter.com/key_systems
> <http://www.twitter.com/key_systems>
>
>
>
> Geschäftsführer: Alexander Siffrin
>
> Handelsregister Nr.: HR B 18835 - Saarbruecken
>
> Umsatzsteuer ID.: DE211006534
>
>
>
> Member of the KEYDRIVE GROUP
>
> www.keydrive.lu <http://www.keydrive.lu/>
>
>
>
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
>
>
>
> --------------------------------------------
>
>
>
> Should you have any further questions, please do not hesitate to contact us.
>
>
>
> Best regards,
>
>
>
> Volker A. Greimann
>
> - legal department -
>
>
>
> Key-Systems GmbH
>
> Im Oberen Werk 1
>
> 66386 St. Ingbert
>
> Tel.:+49 (0) 6894 - 9396 901
> <tel:%2B49%20%280%29%206894%20-%209396%20901>
>
> Fax.:+49 (0) 6894 - 9396 851
> <tel:%2B49%20%280%29%206894%20-%209396%20851>
>
> Email:vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>
>
>
>
> Web:www.key-systems.net
> <http://www.key-systems.net/> /www.RRPproxy.net <http://www.rrpproxy.net/>
>
> www.domaindiscount24.com
> <http://www.domaindiscount24.com/> /www.BrandShelter.com
> <http://www.brandshelter.com/>
>
>
>
> Follow us on Twitter or join our fan community on Facebook and stay updated:
>
> www.facebook.com/KeySystems
> <http://www.facebook.com/KeySystems>
>
> www.twitter.com/key_systems
> <http://www.twitter.com/key_systems>
>
>
>
> CEO: Alexander Siffrin
>
> Registration No.: HR B 18835 - Saarbruecken
>
> V.A.T. ID.: DE211006534
>
>
>
> Member of the KEYDRIVE GROUP
>
> www.keydrive.lu <http://www.keydrive.lu/>
>
>
>
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
>
>
>
>
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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/20161007/092fbf52/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list