[gnso-rds-pdp-wg] Apologies, and some reflections on requirements
John Bambenek
jcb at bambenekconsulting.com
Tue Jul 5 15:34:33 UTC 2016
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.
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.
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.
j
On 7/5/2016 10:29 AM, Volker Greimann wrote:
>
> Hey John,
>
> 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?
>
> Best,
>
> Volker
>
>
> Am 05.07.2016 um 17:22 schrieb John Bambenek via gnso-rds-pdp-wg:
>>
>> 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".
>>
>>
>> On 7/5/2016 4:08 AM, Volker Greimann wrote:
>>>
>>> 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.
>>>
>>> Best,
>>>
>>> Volker
>>>
>>>
>>> Am 04.07.2016 um 19:25 schrieb Stephanie Perrin:
>>>>
>>>> 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)
>>>>
>>>> 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. 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. 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.
>>>>
>>>>
>>>> Stephanie Perrin
>>>> 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.
>>>> On 2016-07-04 12:22, Carlton Samuels wrote:
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> -Carlton
>>>>>
>>>>>
>>>>> ==============================
>>>>> Carlton A Samuels
>>>>> Mobile: 876-818-1799
>>>>> /Strategy, Planning, Governance, Assessment & Turnaround/
>>>>> =============================
>>>>>
>>>>> On Wed, Jun 29, 2016 at 8:04 PM, Gomes, Chuck
>>>>> <cgomes at verisign.com> wrote:
>>>>>
>>>>> Andrew,
>>>>>
>>>>> 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:
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> " 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.
>>>>>
>>>>> "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."
>>>>>
>>>>> 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.
>>>>>
>>>>> Finally, I want to encourage all WG members to share your
>>>>> thoughts on Andrews comments and on my responses above.
>>>>>
>>>>> Chuck
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> 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
>>>>> <mailto:gnso-rds-pdp-wg-bounces at icann.org>] On Behalf Of
>>>>> Andrew Sullivan
>>>>> Sent: Friday, June 24, 2016 10:04 PM
>>>>> To: gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>>>>> Subject: [gnso-rds-pdp-wg] Apologies, and some reflections on
>>>>> requirements
>>>>>
>>>>> Dear colleagues,
>>>>>
>>>>> 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'
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> The distribution comes from different parties having various
>>>>> parts of the data. In so-called "thin" registries, this was
>>>>> always the case.
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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"
>>>>> 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?)
>>>>>
>>>>> 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.
>>>>> 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.
>>>>>
>>>>> 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.
>>>>> Whois++ and rwhois attempted to graft on to this basic
>>>>> protocol some
>>>>> distributed operation, but the graft didn't really take and
>>>>> the ornamental shrub now looks like a weed.
>>>>>
>>>>> People have nevertheless internalized the whois-based
>>>>> thinking, which is why we keep asking things like, "What data
>>>>> should be collected?"
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> A
>>>>>
>>>>>
>>>>> --
>>>>> Andrew Sullivan
>>>>> ajs at anvilwalrusden.com <mailto:ajs at anvilwalrusden.com>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gnso-rds-pdp-wg mailing list
>>>> 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
>>> Fax.: +49 (0) 6894 - 9396 851
>>> Email: vgreimann at key-systems.net
>>>
>>> Web: www.key-systems.net / www.RRPproxy.net
>>> www.domaindiscount24.com / www.BrandShelter.com
>>>
>>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>>> www.facebook.com/KeySystems
>>> 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
>>>
>>> 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: vgreimann at key-systems.net
>>>
>>> Web: www.key-systems.net / www.RRPproxy.net
>>> www.domaindiscount24.com / www.BrandShelter.com
>>>
>>> Follow us on Twitter or join our fan community on Facebook and stay updated:
>>> www.facebook.com/KeySystems
>>> 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
>>>
>>> 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
>>> 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
>
> --
> 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: vgreimann at key-systems.net
>
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems
> 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
>
> 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: vgreimann at key-systems.net
>
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
>
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems
> 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
>
> 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
> 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/20160705/fd7ed8ca/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list