<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
It is remarkable how much of the spam that we see on a regular basis
that is tied to the domain lifecycle. Fake renewal notices, SEO
offers, the lot. <br>
Anything that would reduce this is a basis for restricting access
somewhat. I do not really see any harm in such restrictions either.<br>
<br>
Best,<br>
Volker<br>
<br>
<div class="moz-cite-prefix">Am 07.06.2017 um 10:27 schrieb jonathan
matkowsky:<br>
</div>
<blockquote type="cite"
cite="mid:CALsyHBn2jOp9msZqByik+RmKOu5-nYLmaVNcG-TfYwA+nxtVhA@mail.gmail.com">
<div>There is no basis for restricting ungated access any more so
than the domain's existence or the string of characters
registered.</div>
<div><br>
<div class="gmail_quote">
<div>On Wed, 7 Jun 2017 at 11:22 Volker Greimann <<a
href="mailto:vgreimann@key-systems.net"
moz-do-not-send="true">vgreimann@key-systems.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I have no
objections against having this data available and
accessible.<br>
The question is whether it should be as accessible as it is
now or<br>
whether there could be certain restrictions. A tiered access
system as<br>
has been proposed would solve this beautifully.<br>
<br>
In this case, the dates would be on the second tier (the
first tier<br>
being full unhindered access), which would entail some form
of<br>
authentification and bulk access restrictions. Every single
one of the<br>
uses Andrew desribes would remain possible and
unproblematic, but the<br>
data would no longer be in as much danger of being abused as
it is today.<br>
<br>
Best,<br>
<br>
Volker<br>
<br>
<br>
Am 06.06.2017 um 22:07 schrieb Michael Peddemors:<br>
> +1 as well..<br>
><br>
> .. but with so many +1's on having that data publicly
accessible, it<br>
> would be interesting to take a straw poll, to a wider
audience on that<br>
> simple question..<br>
><br>
> It would be also nice to see what category the parties
in each camp<br>
> lie? We know that everyone involved in making the
internet a safer and<br>
> better place (security companies, law enforcement et
al) want it<br>
> available, and to define 'thin data' as wide as
possible, and I can<br>
> understand that some consideration to privacy be
considered so that it<br>
> doesn't go too wide, but not really certain I
understand the position<br>
> of those that want it as 'thin' as possible, or
non-existant, and/or<br>
> the parties behind that position and their numbers.<br>
><br>
> And of course the ever present question for both camps,
is the opinion<br>
> coming from a place where there are financial
motivations (not that<br>
> necessarily there is anything wrong with that
<sic>) that have formed<br>
> the basis of that opinion. (eg, if the money equation
was removed,<br>
> would you still have that opinion, or even be in the
conversation?)<br>
><br>
> For all we know, the privacy camp are in very small
numbers in this<br>
> conversation, and while they might hold legitimate
positions, maybe it<br>
> isn't enough to affect the directions/positions of
ICANN as a group<br>
> going forward.<br>
><br>
> And IMHO, even if it was 50/50 split, if it came down
to two camps, eg<br>
> 'the ones keeping us safe' and 'it affects/risks our
pocketbooks', I<br>
> would err on policies that would aid the former..<br>
><br>
> Don't want 'politics' to affect such important
decisions..<br>
><br>
><br>
><br>
> On 17-06-06 11:22 AM, Andrew Sullivan wrote:<br>
>> Hi,<br>
>><br>
>> On the call today there were arguments being made
about why certain<br>
>> fields should not be publicly accessible. In
effect, what we are now<br>
>> arguing about, in talking about what should be
considered "thin data",<br>
>> is the definition of the set of data to which
unauthenticated access<br>
>> should be permitted. (Let us please not get
distracted by what is<br>
>> actually required by the RAA or anything like that
just now, since the<br>
>> outcome of this policy discussion might change
that.)<br>
>><br>
>> There were several arguments put forth about
whether the created on,<br>
>> updated on, and expiry dates should be included.
Similarly, people<br>
>> discussed whether the domain status values should
be included. I<br>
>> believe they must be.<br>
>><br>
>> The Internet is unlike many other technologies
because of its radical<br>
>> decentralization. That is not some sort of
political choice, but<br>
>> instead a fundamental part of the design of the
Internet: it's a<br>
>> network of networks (of networks…) formed by
voluntary interoperation<br>
>> among the participants. Participants in the
Internet interoperate<br>
>> without setting up formal contractual arrangements
between all the<br>
>> participating parties. This feature is part of
what has made the<br>
>> Internet so successful compared to other
telecommunications systems,<br>
>> because the barrier to entry is really low. But
that design comes at<br>
>> a cost.<br>
>><br>
>> The cost is that there's not always a party to
speak to, with whom one<br>
>> has a pre-existing relationship. If communications
break down between<br>
>> two telephone customers, they know whom to call:
the phone company.<br>
>> The phone company also has contractual (or
sometimes treaty)<br>
>> relationships to other phone companies.<br>
>><br>
>> The Internet doesn't work that way. If you and I
are communicating<br>
>> over the Internet, there is no guarantee of direct
contractual<br>
>> relationships all the way along the transit path:
that's what open<br>
>> peering policies ensure. The way we make this work
in fact is by<br>
>> placing the responsibility for troubleshooting out
at the edges. And<br>
>> because of that, when I need to troubleshoot my
site I need to have<br>
>> tools with which to do that.<br>
>><br>
>> In domain-based communications (such as email, IP
telephony, websites,<br>
>> money transfer, and thousands of other
applications), when I encounter<br>
>> a problem with the communication I need to answer
whether the problem<br>
>> is in _my_ network operation, or in the other end.
Important data to<br>
>> rule out "the other end" is in the thin RDS data.<br>
>><br>
>> Obviously, the nameserver and DNSSEC information in
the RDS will allow<br>
>> me to tell whether what is in the global DNS is
what ought to be<br>
>> there. For instance, if the RDS has one value for
the name servers,<br>
>> but the DNS returns something else, there is a
problem.<br>
>><br>
>> Less obvious but just as important are the status
values. If a name<br>
>> is on Hold or is pendingTransfer or something like
that, it can tell<br>
>> me that something is up. A name that doesn't
appear in the DNS but<br>
>> has a full complement of name servers in the RDS,
for example, might<br>
>> be on hold; and I can't tell that without seeing
the status values.<br>
>><br>
>> In the same way, the dates in the RDS allow a
troubleshooter to<br>
>> understand what might be wrong when things are
broken. If a name is<br>
>> set to expire in a day and you're getting a parking
page on the<br>
>> website, you have a clue about what is going on.
Most of the examples<br>
>> cited in<br>
>> <a
href="https://whoapi.com/blog/1582/5-all-time-domain-expirations-in-internets-history/"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://whoapi.com/blog/1582/5-all-time-domain-expirations-in-internets-history/</a><br>
>><br>
>> were trivial to understand for help desks that
could see that a name<br>
>> that should have existed for some time was just
hours old, because the<br>
>> created_on date was available. And if you start
having trouble and<br>
>> see a domain was updated about the same time the
trouble started, you<br>
>> have a pretty good clue that the problem is most
likely at the target<br>
>> domain, and not in your own network.<br>
>><br>
>> As for the question of why the global Internet
infrastructure needs to<br>
>> help with this, the answer is that _that's what the
infrastructure is<br>
>> for_. We have registrars and registries in order
to co-ordinate these<br>
>> assignments and make those assignments available,
in support of the<br>
>> distributed administration and operation of the
Internet. If the<br>
>> infrastructure isn't providing this kind of
information in order to<br>
>> help administrators of various Internet
administrators, then it isn't<br>
>> doing its job.<br>
>><br>
>> The Internet is a distributed system. If you want
to make distributed<br>
>> systems work, you have to allow the operators to
have enough<br>
>> information to do their jobs independently of one
another. So,<br>
>> regardless of where one lands on whether any of
this data is personal<br>
>> data, it makes no difference. If you want the
domain name system to<br>
>> continue to work reliably, you have to publish this
data.<br>
>> Centralization and locking the data up for just
registrars simply<br>
>> won't scale.<br>
>><br>
>> Best regards,<br>
>><br>
>> A<br>
>><br>
><br>
><br>
><br>
<br>
--<br>
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.<br>
<br>
Mit freundlichen Grüßen,<br>
<br>
Volker A. Greimann<br>
- Rechtsabteilung -<br>
<br>
Key-Systems GmbH<br>
Im Oberen Werk 1<br>
66386 St. Ingbert<br>
Tel.: +49 (0) 6894 - 9396 901<br>
Fax.: +49 (0) 6894 - 9396 851<br>
Email: <a href="mailto:vgreimann@key-systems.net"
target="_blank" moz-do-not-send="true">vgreimann@key-systems.net</a><br>
<br>
Web: <a href="http://www.key-systems.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.key-systems.net</a>
/ <a href="http://www.RRPproxy.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.RRPproxy.net</a><br>
<a href="http://www.domaindiscount24.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a>
/ <a href="http://www.BrandShelter.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.BrandShelter.com</a><br>
<br>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei
Facebook:<br>
<a href="http://www.facebook.com/KeySystems"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a><br>
<a href="http://www.twitter.com/key_systems"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/key_systems</a><br>
<br>
Geschäftsführer: Alexander Siffrin<br>
Handelsregister Nr.: HR B 18835 - Saarbruecken<br>
Umsatzsteuer ID.: DE211006534<br>
<br>
Member of the KEYDRIVE GROUP<br>
<a href="http://www.keydrive.lu" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.keydrive.lu</a><br>
<br>
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.<br>
<br>
--------------------------------------------<br>
<br>
Should you have any further questions, please do not
hesitate to contact us.<br>
<br>
Best regards,<br>
<br>
Volker A. Greimann<br>
- legal department -<br>
<br>
Key-Systems GmbH<br>
Im Oberen Werk 1<br>
66386 St. Ingbert<br>
Tel.: +49 (0) 6894 - 9396 901<br>
Fax.: +49 (0) 6894 - 9396 851<br>
Email: <a href="mailto:vgreimann@key-systems.net"
target="_blank" moz-do-not-send="true">vgreimann@key-systems.net</a><br>
<br>
Web: <a href="http://www.key-systems.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.key-systems.net</a>
/ <a href="http://www.RRPproxy.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.RRPproxy.net</a><br>
<a href="http://www.domaindiscount24.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a>
/ <a href="http://www.BrandShelter.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.BrandShelter.com</a><br>
<br>
Follow us on Twitter or join our fan community on Facebook
and stay updated:<br>
<a href="http://www.facebook.com/KeySystems"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a><br>
<a href="http://www.twitter.com/key_systems"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/key_systems</a><br>
<br>
CEO: Alexander Siffrin<br>
Registration No.: HR B 18835 - Saarbruecken<br>
V.A.T. ID.: DE211006534<br>
<br>
Member of the KEYDRIVE GROUP<br>
<a href="http://www.keydrive.lu" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.keydrive.lu</a><br>
<br>
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.<br>
<br>
<br>
<br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote>
</div>
</div>
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">jonathan matkowsky, vp - ip
& head of global brand threat mitigation</div>
</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 class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a 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 class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a 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 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 class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a 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 class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a 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 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>
</body>
</html>