<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>As a general rule, I only use the information when the domain
owner is also the criminal operator or a direct "service
provider". For subdomains, say, for instance, dynamic DNS, it's
another ball of wax. That being said, the more often subdomains
are used for criminality, the more often security vendors use a
heavy hand and just block the whole thing. That's the biggest
reason new TLDs are often blacklisted or have low reputations for
at least the first year, the biggest purchaser of domains under a
new TLD are phishers.</p>
<p>So short answer, unless domain owner = part of criminal
operation, I usually don't pay attention unless some correlation
can be drawn over a large number of discrete incidents.</p>
<p>Rarely do I contact domain registrants directly. More often then
not that just exposes me and my interests to the criminals in
question and the risks outweigh the rewards.</p>
<p>j<br>
</p>
<div class="moz-cite-prefix">On 7/5/2016 10:29 AM, Volker Greimann
wrote:<br>
</div>
<blockquote
cite="mid:b46d6c55-1cc3-e06f-b78c-1502d054b02c@key-systems.net"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>Hey John, <br>
</p>
<p>is it still helpful when the problem exists on a subdomain, a
forum post, hacked sites, etc, i.e. all circumstances where the
registrant is not the (only) user of the domain or only a
service provider himself? In these cases, while you may need to
be able to contact the registrant, knowing who he is is not
really necessary to resolve the issue, correct?</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 05.07.2016 um 17:22 schrieb John
Bambenek via gnso-rds-pdp-wg:<br>
</div>
<blockquote
cite="mid:31b1ffdc-142e-cd94-0fff-5e6db64725b1@bambenekconsulting.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>As someone who uses this information to put people in prison,
it is not as useless as you may think it is even when it's
"incorrect", or for that matter "whois privacy protected".<br>
</p>
<br>
<div class="moz-cite-prefix">On 7/5/2016 4:08 AM, Volker
Greimann wrote:<br>
</div>
<blockquote
cite="mid:bc3898bf-ef51-0417-c25c-6498f596ff2e@key-systems.net"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>Ultimately, everyone accessing the internet can be
identified at the level of the access provider. The domain
name is probably the most useless point to identify a user,
as the domain name registrant may not even have to do
anything with a specific use. <br>
</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 04.07.2016 um 19:25 schrieb
Stephanie Perrin:<br>
</div>
<blockquote
cite="mid:9eff015d-403f-b7f7-ecfe-04b2800bc9ef@mail.utoronto.ca"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p><font size="+1"><font face="Lucida Grande">One point
here, and it is not a big one. I don't accept that
accuracy is a sine qua non (see para 5).
Contactability is, I think it ends there. Excessive
focus on accuracy of data, when that data is not
necessary any more is a cost and consumer burden, not
to mention an invasion of privacy. (eg. if I have
changed my mastercard number but my registration is
paid for two years, no need to change it in the
record) <br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande">I did not
comment earlier on Volker's remark that responsibility
for accuracy of data rests with the registrant, but I
agree whole heartedly. How can it be otherwise? Some
parties would like to authenticate every individual
and every transaction on the INternet, and see the
registrars as the entry point and therefore the
logical ones to bear this (enormous) burden. </font></font><font
size="+1"><font face="Lucida Grande"><font size="+1"><font
face="Lucida Grande">This is unnecessary and will
price domains out of the range of individuals who
can benefit most from their own place on the
Internet, in my view. </font></font> It would
hardly be appropriate for the policy person to point
out that in any authentication scheme, identifying the
individual in the first place (prior to tying that
individual to some identifier) is a big, costly and
complex matter that has slowed down many an
implementation of secure transactions. We need to
limit our attempts to identify individuals to only
what is necessary.</font></font></p>
<p><br>
</p>
<font size="+1">Stephanie Perrin<br>
PS I wish I had taken better notes on the whole thick/thin
whois issue during EWG. Since it took me a good while to
figure out how this thing had developed in the first
place, (and many thanks to my EWG colleagues who patiently
explained it to me over and over again) I may have missed
an invitation to throw it out and discuss it again from
scratch.....but I doubt it. Anyway, we were already
talking about tiered access by then and different
configurations of the model which would make it much less
relevant.<br>
</font>
<div class="moz-cite-prefix"><font size="+1">On 2016-07-04
12:22, Carlton Samuels wrote:</font><br>
</div>
<blockquote
cite="mid:CAOZQb9T+p9T8ZLtSKzYJqjBfCkSUXN2Y+SSN1fpOZqLVpA7+xg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">Coming
to this conversation late but as a member of the
EWG, my recollection is we took seriously the stated
objective to chart a next generation RDDS unfettered
by existing WHOIS constraints.</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">To that
end, I was one of those who insisted and the group
accepted and grappled with the basic question; was
there a need for a RDDS and, to what purpose. For
those mindful of the ALAC perspective, this would
not be new; the ALAC is on record from as early as
2009 insisting that for policy development purposes,
the need and purpose for a RDDS ought, by reason and
judgment, to be the first declarative act of any
policy development process. You would have seen a
reprise of that principle here. </font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">We were
acutely aware that some principles we espoused are
contrary by nature - privacy vs. security,
transparency vs. confidentiality and so on - and
that balancing the scale between contention sets of
principles was not going to be for the
faint-hearted. Some time ago I used a metaphor to
describe what was achieved; we set out to design and
build a sleek racehorse but with the contentions,
likely ended up with a two-humped camel. Naturally,
some took umbrage on behalf of camels. </font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">My
recollection - and the record will show - the EWG
spent an inordinate amount of time looking at use
cases, the thinking being it would allow extraction
of a set of principles grounded in facts on the
ground. Yes, some of us had concerns about this as
starting point to get to principles; use cases
conflated both appropriate and alleged inappropriate
uses, highlighting some of the alleged noisome
abuses. Some of us soldiered on , embracing the idea
that a comprehensive problem statement provides the
best indicator to an improved model. This is why the
gripes of current stakeholders, the expert opinions
and deeper knowledge of what ails the current system
took so much time of our deliberations. </font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">The
mitigation model that emerged is fairly easy to
script. I cannot recall any contest to the idea that
data accuracy is sine qua non for any RDDS. Yes, we
are very much aware of the distributed nature of
current WHOIS and even examined a model so
configured in the solution set we discussed. Again,
balancing the contentions, the centralized database
offers certain advantages - and these are listed in
details - at least for standard enforcement, query
and access control. The concept of a minimum set of
RDDS data elements for global unfettered display
stems from privacy concerns and, coincidentally, a
nod to the 'thin' model. Gated access in the model
addressed the concerns from the perspective of a
broader set of business reasons for RDDS access,
privacy and the evaluation of and better knowledge
of purposeful use. <br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">I could
give a lot more examples that underscore a different
narrative. Not just because I spent almost 2 years
of my life working this on a truly voluntary basis -
I do not make a living from the ecosystem and my day
job has no connection to it - but for the fact I
sincerely believe that what was achieved was
remarkable in and of itself. </font><br>
</div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><br>
</div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small">-Carlton</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature"
data-smartmail="gmail_signature"><br>
==============================<br>
Carlton A Samuels<br>
Mobile: 876-818-1799<br>
<i><font color="#33CC00">Strategy, Planning,
Governance, Assessment & Turnaround</font></i><br>
=============================</div>
</div>
<br>
<div class="gmail_quote">On Wed, Jun 29, 2016 at 8:04
PM, Gomes, Chuck <span dir="ltr"><<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:cgomes@verisign.com"><a class="moz-txt-link-abbreviated" href="mailto:cgomes@verisign.com">cgomes@verisign.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Andrew,<br>
<br>
I am sorry to take so long to respond to your very
thoughtful message but as you know I have been
pretty busy here in Helsinki. It seems to me
personally that you make some suggestions that could
possibly be constructive to the work ahead but I
have two primary concerns:<br>
<br>
1. I am pretty sure that it would require a charter
change. To do that would require going back to the
GNSO Council with the proposed changes and seeking
their approval. That is something that is not out
of the question but it could cause some delays and I
would want to make sure that there is strong WG
support for doing so. Also, I think we need to
remember that a lot of very smart people spent quite
a bit of time developing the framework that resulted
in the charter so I think we should consider
possible changes with that in mind.<br>
<br>
2. My understanding is that EWG debated things like
you are suggesting quite intensely. As you know I
was not a member of the EWG but Lisa has provided
some thoughts about that I include below.<br>
<br>
" It might be useful to reflect upon the EWG's
experience with system modeling. After starting with
use cases, some EWG members needed a system model
against which to test principles on purposes, data
needs, and associated privacy, access, and accuracy
issues. This led to the EWG's Initial Report
proposing both a set of principles and an Aggregated
RDS system model to support those principles - but
without much explanation of the ARDS. Over the year
that followed, the EWG evaluated half a dozen system
models, drilling deeper into two (Federated and
Synchronized) to examine feasibility and costs
before recommending the SRDS. Both SRDS and FRDS
models use RDAP; neither stores data in a single
physical location. While the SRDS is a "thick"
storage model where queries are served from
synchronized data, the runner-up FRDS actually uses
"thin" registries, querying data from registrars and
validators in real-time.<br>
<br>
"While some possible requirements may reflect a
particular system model - for example, those drawn
from today's WHOIS policies -- our PDP WG has yet to
consider whether to recommend a next-gen system. But
no matter what model we recommend, perhaps we can
learn from the EWG's experience. First, while
envisioning a possible new model early on was
helpful to some, reaching agreement on a recommended
model was not possible until the EWG was nearly
finished, following feasibility and cost analysis.
Second, while each had pros/cons, both models were
found to be capable of supporting the EWG's
principles. In other words, model choice did not
drive the EWG's principles - principles and criteria
such as cost drove the EWG's choice of model."<br>
<br>
I want to add to Lisa's thoughts my own personal
opinion: I don't think the issue of Federated v.
Synchronized is a closed issue. My understanding is
that the final recommendation in the EWG report
could have been more the result of the desire to
finish the work than a strong consensus. Whether I
am right on that or not, our WG can consider both
and make our own decision between either one or some
variation.<br>
<br>
Finally, I want to encourage all WG members to share
your thoughts on Andrews comments and on my
responses above.<br>
<span class="HOEnZb"><font color="#888888"><br>
Chuck<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>]
On Behalf Of Andrew Sullivan<br>
Sent: Friday, June 24, 2016 10:04 PM<br>
To: <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
Subject: [gnso-rds-pdp-wg] Apologies, and some
reflections on requirements<br>
<br>
Dear colleagues,<br>
<br>
Apologies first. I'm not going to be in
Helsinki. I'm in the middle of a move from NH
back to Toronto, and it turns out that my
movers'<br>
understanding of, "I need to leave on $date,"
entails arranging things such that goods will
arrive after $date. Alas, in this case the
goods arrive Monday. I will attempt to follow
the ICANN meetings remotely next week, but I
expect it will be tricky.<br>
<br>
I have been deeply dissatisfied with the way the
work is going, and I believe it is because I see
a mismatch in what we are trying to do and the
kind of system we are trying to do it to. In
particular, I think we are trying to treat the
RDS as a single monolithic system, and
attempting to build "requirements" that match
that assumption. Here is an effort to sketch
why I think that. I didn't have time to write a
short note, &c. &c. Sorry this is long.<br>
<br>
Since the very introduction of the
competitive-registrar model (and arguably before
that), the RDS has been a distributed database.
It is far less successful than the other
distrubuted database we all know and love -- DNS
-- but it is nevertheless distributed.<br>
<br>
The distribution comes from different parties
having various parts of the data. In so-called
"thin" registries, this was always the case.<br>
The registry has names and nameservers, and
since the invention of registrars knows who the
registrar is. But if you wanted to know certain
kinds of data, you had to ask the registrar in
question.<br>
<br>
Because in (say) 1999-2001 nobody had anything
better than the whois/rwhois/whois++ protocol(s)
to deliver this kind of data, a whole bunch of
bad compromises got enshrined in policy. First,
we continued to use whois and its descendents
(anything on port 43) as the model for all of
this. The plain fact is that whois was obsolete
nearly at birth. It's a terrible protocol, and
should be taken behind the ice house and put out
of its misery.<br>
<br>
Second, in order to "fix up" whois, clients were
created all over the Internet that built in a
bunch of assumptions about whom to ask for what
data. The consequence of this was that clients
routinely got bad data as they queried the wrong
server. Old registrar data hung around even
after a transfer. When I worked on the org
transition from Verisign to PIR in 2003 (?), it
took a long time before whois clients stopped
asking Verisign about org data. And so on.<br>
<br>
Third, in an attempt to hack around the above
technical flaws in an already-obsolete protocol,
"thick whois" gained popularity in possibly the
worst possible arrangement known to data
science. Instead of insisting that registries
hold the data and that registrars and everyone
else treat the registry data as The Truth, we
created "thick"<br>
whois in registries _without allowing registrars
to stop their service_. Any half-competent
database person will tell you that storing "the
same data" in two places that don't have tight
connections is an excellent way to create data
inconsistency, but is not a good way to arrive
at the truth. (Latterly, as though illustrating
the tendency of people to double down on bad
ideas, there have been suggestions that ICANN
should run the One Giant RDS of the Universe and
hold all the data in a central place. What
could possibly go wrong?)<br>
<br>
The thread running through this history of error
is the idea that the RDS is one system. But
like the DNS, it only appears to be one system.
It's actually a "distributed database", where in
this case the distribution is separable on
organization lines. That is, registries --
including ICANN, who can be thought of in this
case as both the registry and registrar for the
root zone -- have some data.<br>
Registrars have some other data. Resellers and
privacy/proxy services have yet other data. In
many cases, the data does not need to be shared
across these organizational lines to make it
queryable by humans.<br>
<br>
The reason that isn't clear to most of us is
because whois -- the RDS we use today -- _was_
designed as a monolithic system. It was
designed that way because back when it was
created -- RFC 812 is from _1982_! -- the
database _was_ a monolithic database. Whois
(the protocol and the client program) continues
to have all the deficiencies for distributed use
that you might expect of a program or protocol
designed to talk to exactly one authoritative
service.<br>
Whois++ and rwhois attempted to graft on to this
basic protocol some<br>
distributed operation, but the graft didn't
really take and the ornamental shrub now looks
like a weed.<br>
<br>
People have nevertheless internalized the
whois-based thinking, which is why we keep
asking things like, "What data should be
collected?"<br>
In a distributed system like this, that's barely
interesting, for the commercial interests in
this case all militate against collecting data
that nobody needs for any function. Instead, we
should ask what data should be collected _by
different actors_. This implicitly involves
describing what those actors are doing to
require the data.<br>
<br>
The nice thing, of course, is that protocol
designers have done _a lot_ of this work for us,
when they were working on RDAP. They did this
because they were trying to come up with use
cases for the protocol, which finally did away
with the monolithic-system thinking of whois and
offers us a protocol designed precisely to work
in the distributed-database environment that is
the actual registration system. That we even
still have a work step that involves evaluating
what protocol we're going to use for all this
makes me a little ill.<br>
<br>
It seems to me that we can just say that we have
to embrace the distributed-database fact. For
first, it's a fact of how registration actually
works now. If we don't agree with that, I think
we should give up. Second, it's consistent with
how every single other thing on the Internet
that has not crashed and burned works. The
Internet cannot scale depending on monolithic
systems. And nobody has the power to impose one
anyway.<br>
<br>
Once we have done that, there are still
important policy issues about what data ought to
be collected by anyone, under what conditions
they might reveal it to someone else (and who
that someone else is), and so on. But there are
empirical tests for whether some of the answers
people are proposing really match the
distributed nature of the system. If they
don't, we can close off those avenues of
inquiry, because they'll never be productive.<br>
<br>
Best regards,<br>
<br>
A<br>
<br>
<br>
--<br>
Andrew Sullivan<br>
<a moz-do-not-send="true"
href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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
Fax.: +49 (0) 6894 - 9396 851
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
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
Fax.: +49 (0) 6894 - 9396 851
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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
Fax.: +49 (0) 6894 - 9396 851
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
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
Fax.: +49 (0) 6894 - 9396 851
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>