[gnso-rds-pdp-wg] Why the thin data is necessary

allison nixon elsakoo at gmail.com
Wed Jun 7 14:39:53 UTC 2017 

+1 Greg

On Wed, Jun 7, 2017 at 10:30 AM, nathalie coupet via gnso-rds-pdp-wg <
gnso-rds-pdp-wg at icann.org> wrote:

>  +1 @Greg
>
> Nathalie
>
>
> On Wednesday, June 7, 2017 10:26 AM, Kiran Malancharuvil via
> gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org> wrote:
>
>
> Agree with Greg.
>
> Kiran Malancharuvil
> Policy Counselor
> MarkMonitor
> 415-419-9138 <(415)%20419-9138> (m)
>
> Sent from my mobile, please excuse any typos.
>
> On Jun 7, 2017, at 7:15 AM, Greg Aaron <gca at icginc.com<mailto:gca@
> icginc.com>> wrote:
>
> Yes. Our Working Group has:
>
>   *  defined what the thin fields are,
>   *  has heard excellent reasons to publish it,
>   *  has not heard any compelling reasons to withhold the thin data from
> publication.
>   *  Had decent consensus that any kind of authentication or gating for
> access to thin data is not desirable.
>
> The discussion of the above has been pretty exhaustive.  I suggest to the
> leadership that confirming and moving on from these issues is very
> important by Johannesburg.  This WG has been open for one-and-a-half years
> now, needs to show some progress, and the endless re-opening of issues is
> not fair to any of the volunteers.
>
> All best,
> --Greg
>
>
>
> 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 jonathan matkowsky
> Sent: Wednesday, June 7, 2017 8:32 AM
> To: Volker Greimann <vgreimann at key-systems.net<mailto:
> vgreimann at key-systems.net>>
> Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org
> >>
> Subject: Re: [gnso-rds-pdp-wg] Why the thin data is necessary
>
> The problem with is that we are unable to make progress if we keep having
> to re-define the terms subject to discussion upon which such progress is
> predicated. For example, we spent time talking about the ins and outs of
> privacy in relation to thin data--the overwhelming majority agreed there
> were no privacy concerns in relation thereto--and then we went ahead and
> said let's now start re-defining what thin data is. Now we are talking
> about re-defining authentication. I would say that user authentication is a
> fairly basic universal concept of validation that a person has been
> provided with access to a resource. That concept by definition requires
> knowing something about them. It's basically a form of identity management.
>
> We need to keep in mind that when domains expire is critical title
> information for the public. Unlike land which generally doesn't expire,
> domain names exist only from when they are created to when they expire.
> This is the most basic property identification possible.
>
> When domains were created and when they are set to expire is the most
> basic information for the public to have the ability to engage with the
> Internet to make informed choices about information held by the
> registrars.  The accuracy of title to a domain is determined by when it is
> set to expire and when it was created. If the public is to have confidence
> in their investments in the Internet, this basic information is important
> considerations when undertaking any kind of transaction online. The ability
> to acquire and disseminate information and to control its flow is a source
> of institutional power that is also potentially abused.
>
> Transparency and accessibility
> ​ ​
> are
> ​ ​
> principles of good governance
> ​ ​
> that
> ​ ​
> help
> ​ the public
> become and
> remain engaged with
> ​the Internet
> and remain aware of how
> ​it
> functions
> ​.​
>
> Accessibility to
> ​title
> information
> ​ over the Internet​
> is in the public interest because it promotes equality
> ​ ​
> . Accessibility to
> ​this information is a necessary condition for transparency to exist.
> Authentication is by definition, a barrier to access. Certain court
> documents are in the open because it's in the public interest to remain
> effectively engaged in, and with, the legal system while holding it to
> public account. The same is true for the existence of locations where
> people travel online or visit. Access prevents misconduct and exposes
> deficiencies to careful public scrutiny.  Authentication should not be used
> just for the sake of practical obscurity, which is a principle that
> information in public records is effectively protected from disclosure as
> the result of practical barriers to access.
>
> The arguments I am hearing that records will still be available even if
> authentication is required does not mean there is no practical obscurity if
> the public's ability to access them
> ​is limited by practical constraints that come from authentication. The
> authentication may very well translate into barriers that prevent records
> from being readily accessible on a large scale.
>
> ​The existence of domain names (defined by their creation and expiry
> dates) is reliable information related to locations on the public Internet,
> which creates for a stable atmosphere for ownership and transfer of places
> on the Internet, as well as for visiting or doing business at these places
> online.​ The public has the right to know without any barriers to entry the
> most basic facts about places online, like when they were created and when
> they won't exist unless renewed according to the authoritative data. It
> also gives property holders the most basic information about their title
> and some insurance if they suffer a loss due to a lack of care by the
> registrar of the record. This is also important for investor confidence for
> the public doing business online.  It is the most very basic of identifying
> information about the public property--when it was created and when it will
> cease to exist, as well as when it was last updated. This basic information
> should never have a barrier to entry in order to promote the transparent
> and accessible handling of such information.
>
> Expectations of privacy must be balanced with freedom of access to the
> public Internet. There is no guaranteed right to anonymity or complete
> privacy online. No government can possibly guarantee that to their
> citizens, and it's not an unalienable right.  The efficient availability of
> this information is the PRIMARY goal even if we build certain safeguards
> for personal privacy as long as we are not placing unnecessary barriers to
> access at the registry or registrar levels in the process of information
> dissemination.
>
> You can see an example<http://dspace.library.
> uvic.ca:8080/bitstream/handle/1828/6159/Johnson_Taylor_MPA_
> 2015.pdf?sequence=1&isAllowed=y> discussed of how this balance has worked
> for land titles. But domains are a bit different since they cease to exist
> if not renewed on certain dates. Hence, it's even more important to have
> public access.
>
>
> Jonathan Matkowsky,
> VP – IP & Brand Security
> USA:: 1.347.467.1193 <(347)%20467-1193> | Office:: +972-(0)8-926-2766
> <+972%208-926-2766>
> Emergency mobile:: +972-(0)54-924-0831 <+972%2054-924-0831>
> Company Reg. No. 514805332
> 11/1 Nachal Chever, Modiin Israel
> Website<http://www.riskiq.co.il>
> RiskIQ Technologies Ltd. (wholly-owned by RiskIQ, Inc.)
>
> On Wed, Jun 7, 2017 at 2:13 PM, Volker Greimann <vgreimann at key-systems.net
> <mailto:vgreimann at key-systems.net>> wrote:
>
> I think you are getting a step ahead of our target. As we have not yet
> defined how authentification would look like, you are making a presumption
> that may not be correct. We have not yet determined that authentification
> needs to be personal. If may very well be, but lets look at our
> verification and authntification options when we get to that point.
>
> Volker
>
> Am 07.06.2017 um 13:04 schrieb jonathan matkowsky:
> Volker, I am sorry but for privacy reasons, I am advocating that there has
> to be a basis for authentication. Once you authenticate, you are requiring
> personal information to be disclosed. If there is no personal information
> to protect in doing so, than you would be encroaching on privacy for no
> legitimate reason--thereby violating the proportionality principle.
>
> Jonathan Matkowsky,
> VP – IP & Brand Security
> USA:: 1.347.467.1193 <(347)%20467-1193><tel:(347)%20467-1193> | Office::
> +972-(0)8-926-2766 <+972%208-926-2766><tel:+972%208-926-2766>
> Emergency mobile:: +972-(0)54-924-0831 <+972%2054-924-0831><tel:+972%
> 2054-924-0831>
> Company Reg. No. 514805332
> 11/1 Nachal Chever, Modiin Israel
> Website<http://www.riskiq.co.il>
> RiskIQ Technologies Ltd. (wholly-owned by RiskIQ, Inc.)
>
> On Wed, Jun 7, 2017 at 1:05 PM, Paul Keating <paul at law.es<mailto:paul at law.
> es>> wrote:
> Sorry but your position keeps changing.  You clearly favor restrictions on
> access.  You appear to have abandoned the privacy angle as justification
> and are now relying upon an anti-abuse rationale.  This last position is
> rather useless.  We all know that captcha and other gates easily overcome.
>   Thus the abuse you note will continue.  Unless you are going to impose
> downstream use restrictions - which will largely if not entirely be
> unenforceable from a practical standpoint - there would be nothing to
> prevent a spammer to authenticate him/her self using any number of fake
> entities and thereafter publish the same data freely to others.
>
> I am left to conclude that what you really want is to preclude harvesting
> of data so that it can be controlled at the registry/registrar level.
>
> Sent from my iPad
>
> On 7 Jun 2017, at 10:31, Volker Greimann <vgreimann at key-systems.net<
> mailto:vgreimann at key-systems.net>> wrote:
>
> Hi Jonathan,
>
> and I have no issue with the public being able to get that information.
> Still, there is no reason why the requester should not authenticate himself
> when making that inquiry. Remember the access levels do not block access,
> they just require further authentification. So the public would be able to
> find out when a domain is expected to become available. This is no argument
> against gated access.
>
> Best,
>
> Volker
>
>
>
>
>
> Am 07.06.2017 um 11:23 schrieb jonathan matkowsky:
> The public has the right to know when a domain is expected to become
> available. They might need to place a backorder. All UDRPs require the
> provider to check whether the domain is set to expire during the
> proceeding. The fake renewal notices and SEO scams will continue based on
> the existence of the domain. I have seen countless such scams where the
> domain is not set to expire for years, and where it wasn't even recently
> created--which supports keeping the creation and expiration dates ungated
> so that companies can verify that the scams are not bona fide.
>
> On Wed, 7 Jun 2017 at 11:54 Volker Greimann <vgreimann at key-systems.net<
> mailto:vgreimann at key-systems.net>> wrote:
> 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.
> Anything that would reduce this is a basis for restricting access
> somewhat. I do not really see any harm in such restrictions either.
>
> Best,
> Volker
>
> Am 07.06.2017 um 10:27 schrieb jonathan matkowsky:
> There is no basis for restricting ungated access any more so than the
> domain's existence or the string of characters registered.
>
> On Wed, 7 Jun 2017 at 11:22 Volker Greimann <vgreimann at key-systems.net<
> mailto:vgreimann at key-systems.net>> wrote:
> I have no objections against having this data available and accessible.
> The question is whether it should be as accessible as it is now or
> whether there could be certain restrictions. A tiered access system as
> has been proposed would solve this beautifully.
>
> In this case, the dates would be on the second tier (the first tier
> being full unhindered access), which would entail some form of
> authentification and bulk access restrictions. Every single one of the
> uses Andrew desribes would remain possible and unproblematic, but the
> data would no longer be in as much danger of being abused as it is today.
>
> Best,
>
> Volker
>
>
> Am 06.06.2017 um 22:07 schrieb Michael Peddemors:
> > +1 as well..
> >
> > .. but with so many +1's on having that data publicly accessible, it
> > would be interesting to take a straw poll, to a wider audience on that
> > simple question..
> >
> > It would be also nice to see what category the parties in each camp
> > lie? We know that everyone involved in making the internet a safer and
> > better place (security companies, law enforcement et al) want it
> > available, and to define 'thin data' as wide as possible, and I can
> > understand that some consideration to privacy be considered so that it
> > doesn't go too wide, but not really certain I understand the position
> > of those that want it as 'thin' as possible, or non-existant, and/or
> > the parties behind that position and their numbers.
> >
> > And of course the ever present question for both camps, is the opinion
> > coming from a place where there are financial motivations (not that
> > necessarily there is anything wrong with that <sic>) that have formed
> > the basis of that opinion. (eg, if the money equation was removed,
> > would you still have that opinion, or even be in the conversation?)
> >
> > For all we know, the privacy camp are in very small numbers in this
> > conversation, and while they might hold legitimate positions, maybe it
> > isn't enough to affect the directions/positions of ICANN as a group
> > going forward.
> >
> > And IMHO, even if it was 50/50 split, if it came down to two camps, eg
> > 'the ones keeping us safe' and 'it affects/risks our pocketbooks', I
> > would err on policies that would aid the former..
> >
> > Don't want 'politics' to affect such important decisions..
> >
> >
> >
> > On 17-06-06 11:22 AM, Andrew Sullivan wrote:
> >> Hi,
> >>
> >> On the call today there were arguments being made about why certain
> >> fields should not be publicly accessible.  In effect, what we are now
> >> arguing about, in talking about what should be considered "thin data",
> >> is the definition of the set of data to which unauthenticated access
> >> should be permitted.  (Let us please not get distracted by what is
> >> actually required by the RAA or anything like that just now, since the
> >> outcome of this policy discussion might change that.)
> >>
> >> There were several arguments put forth about whether the created on,
> >> updated on, and expiry dates should be included.  Similarly, people
> >> discussed whether the domain status values should be included. I
> >> believe they must be.
> >>
> >> The Internet is unlike many other technologies because of its radical
> >> decentralization.  That is not some sort of political choice, but
> >> instead a fundamental part of the design of the Internet: it's a
> >> network of networks (of networks…) formed by voluntary interoperation
> >> among the participants.  Participants in the Internet interoperate
> >> without setting up formal contractual arrangements between all the
> >> participating parties.  This feature is part of what has made the
> >> Internet so successful compared to other telecommunications systems,
> >> because the barrier to entry is really low.  But that design comes at
> >> a cost.
> >>
> >> The cost is that there's not always a party to speak to, with whom one
> >> has a pre-existing relationship.  If communications break down between
> >> two telephone customers, they know whom to call: the phone company.
> >> The phone company also has contractual (or sometimes treaty)
> >> relationships to other phone companies.
> >>
> >> The Internet doesn't work that way.  If you and I are communicating
> >> over the Internet, there is no guarantee of direct contractual
> >> relationships all the way along the transit path: that's what open
> >> peering policies ensure.  The way we make this work in fact is by
> >> placing the responsibility for troubleshooting out at the edges.  And
> >> because of that, when I need to troubleshoot my site I need to have
> >> tools with which to do that.
> >>
> >> In domain-based communications (such as email, IP telephony, websites,
> >> money transfer, and thousands of other applications), when I encounter
> >> a problem with the communication I need to answer whether the problem
> >> is in _my_ network operation, or in the other end.  Important data to
> >> rule out "the other end" is in the thin RDS data.
> >>
> >> Obviously, the nameserver and DNSSEC information in the RDS will allow
> >> me to tell whether what is in the global DNS is what ought to be
> >> there.  For instance, if the RDS has one value for the name servers,
> >> but the DNS returns something else, there is a problem.
> >>
> >> Less obvious but just as important are the status values.  If a name
> >> is on Hold or is pendingTransfer or something like that, it can tell
> >> me that something is up.  A name that doesn't appear in the DNS but
> >> has a full complement of name servers in the RDS, for example, might
> >> be on hold; and I can't tell that without seeing the status values.
> >>
> >> In the same way, the dates in the RDS allow a troubleshooter to
> >> understand what might be wrong when things are broken.  If a name is
> >> set to expire in a day and you're getting a parking page on the
> >> website, you have a clue about what is going on.  Most of the examples
> >> cited in
> >> https://whoapi.com/blog/1582/5-all-time-domain-expirations-
> in-internets-history/
> >>
> >> were trivial to understand for help desks that could see that a name
> >> that should have existed for some time was just hours old, because the
> >> created_on date was available.  And if you start having trouble and
> >> see a domain was updated about the same time the trouble started, you
> >> have a pretty good clue that the problem is most likely at the target
> >> domain, and not in your own network.
> >>
> >> As for the question of why the global Internet infrastructure needs to
> >> help with this, the answer is that _that's what the infrastructure is
> >> for_.  We have registrars and registries in order to co-ordinate these
> >> assignments and make those assignments available, in support of the
> >> distributed administration and operation of the Internet.  If the
> >> infrastructure isn't providing this kind of information in order to
> >> help administrators of various Internet administrators, then it isn't
> >> doing its job.
> >>
> >> The Internet is a distributed system.  If you want to make distributed
> >> systems work, you have to allow the operators to have enough
> >> information to do their jobs independently of one another.  So,
> >> regardless of where one lands on whether any of this data is personal
> >> data, it makes no difference.  If you want the domain name system to
> >> continue to work reliably, you have to publish this data.
> >> Centralization and locking the data up for just registrars simply
> >> won't scale.
> >>
> >> Best regards,
> >>
> >> A
> >>
> >
> >
> >
>
> --
> 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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
> 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 <http://www.rrpproxy.net/>>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
> 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 <http://www.rrpproxy.net/>>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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
> --
> jonathan matkowsky, vp - ip & head of global brand threat mitigation
>
>
> --
>
> 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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
>
> 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 <http://www.rrpproxy.net/>>
>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
>
> 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 <http://www.rrpproxy.net/>>
>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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.
>
>
>
>
>
>
> --
> jonathan matkowsky, vp - ip & head of global brand threat mitigation
>
>
> --
>
> 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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
>
> 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 <http://www.rrpproxy.net/>>
>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
>
> 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 <http://www.rrpproxy.net/>>
>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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
>
>
>
> --
>
> 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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
>
> 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 <http://www.rrpproxy.net/>>
>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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 <+49%206894%209396901>
> <tel:+49%206894%209396901>
>
> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
> <tel:+49%206894%209396851>
>
> 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 <http://www.rrpproxy.net/>>
>
> www.domaindiscount24.com<http://www.domaindiscount24.com> /
> www.BrandShelter.com<http://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
> 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
>



-- 
_________________________________
Note to self: Pillage BEFORE burning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170607/63c3f872/attachment-0003.html>

More information about the gnso-rds-pdp-wg mailing list