[gnso-rds-pdp-wg] Why the thin data is necessary
Gomes, Chuck
cgomes at verisign.com
Thu Jun 8 21:02:54 UTC 2017
As I just stated, Greg is correct: ‘the discussion has gotten ahead of things’.
Chuck
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Greg Aaron
Sent: Wednesday, June 07, 2017 12:24 PM
To: Stephanie Perrin <stephanie.perrin at mail.utoronto.ca>; gnso-rds-pdp-wg at icann.org
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Why the thin data is necessary
Dear Stephanie:
Look at it this way. Why would a kind of special accreditation be needed for a company to protect itself from cybercrime? Many private cybercrime investigators work within companies and not-for-profits that need to protect their own networks, employees, and users. (Examples: your ISP, Google, the University of Toronto IT department, etc. etc.)
Why would a kind of special accreditation be needed for a company to provide protection and advice to other entities, such as companies and not-for-profits? A government should not tell those entities who they can and can’t hire to help protect their own networks, employees, and users.
Would roughly equivalent accreditations be available in every country? Answer: no; such global regimes don’t exist because they are neither advisable nor practical.
How can the global public trustany expert in any field?
I think. What’s now being discussed on this thread is who should be allowed to have gated access to contact data. I suggest that we will get to that issue in due time, and that we should stick to more immediate concerns.
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 Stephanie Perrin
Sent: Wednesday, June 7, 2017 10:55 AM
To: 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
These are excellent questions. I would add an additional one: why are private cybercrime investigators not accredited? How can the global public trust them, or perhaps why?
Stephanie Perrin
On 2017-06-07 10:49, Volker Greimann wrote:
All good questions that we will no doubt come to later.
Am 07.06.2017 um 16:47 schrieb John Bambenek via gnso-rds-pdp-wg:
I want to add. Requiring authentication means that you will be creating a database (potentially many of them) that will contain private data (usernames, emails, passwords, and api keys combined is some of the most sensitive private data there is) to access public data. You will be creating logs of what we search and why (what's the point of requiring purpose be disclosed if not to store it. For a subset of us that exposes our customer lists that could be easily derived.
The first problem is, who has access to this data and under what conditions? Will every domain owner see who queries their domains? That inherently means targets of our investigations are not only tipped off that there is an investigation, but can expose specifically WHO is investigating. You are increasing the direct PERSONAL risk investigators take to solve the problems you have raised with anti-abuse.
Further, you are inherently creating a database of high profile targets for intelligence agencies. System admins, network admins and investigators are targets of intelligence agencies because they have privileged access if not the full "keys to the kingdom". (See: https://www.usenix.org/conference/enigma2016/conference-program/presentation/joyce short version, the NSA says these are the exact people they try to compromise). This system almost exclusively has those people in it. If LE has access to the logs and this database, it is hard to see how intelligence agencies can't get it. Do you want the NSA knowing what domains you are looking at knowing its a mere NSL away?
Further, creating this pool of high-profile targets also makes the RDS a major target of attack. By literally everyone. Considering the problem of password reuse, if this database were ever compromised, a huge number of organizations would face very immediate existential threats. Who is going to pay for the security of RDS? Who is going to accept the liability when its breached?
Putting public info behind a gate creates huge liabilities, assumes great cost, and delivers no real anti-abuse features because domain status alone is not weaponizable via phishing (you need contact info, and if that's behind the gate or a proxy registration, lets just assume the spammer can't get to it; also a bad assumption).
So the basic question for you guys even if you set the value of MY risk at 0 and completely irrelevant, what is the return on this massive investment and who's going to pay that bill? It won't be me.
The last point, and I will be very direct about this. Some of you on this list made a startling bald statement that you ignore your contractual OBLIGATIONS as they exist today regarding registrant accuracy because you "don't like them" in such a way that at least one investigation was already opened. For those of you who openly admitted that you ignore ICANN contractual requirements for a contract you signed, how can we (who will bear the personal risks) trust any assurances you will give that you simply won't give this data to criminals despite any policy we create here?
--
John Bambenek
On Jun 7, 2017, at 15:20, Michael Peddemors <michael at linuxmagic.com<mailto:michael at linuxmagic.com>> wrote:
Hi Volker,
Maybe we are getting to the root of your position, too much spam ;)
Maybe a better spam filter would be the solution? ;)
But in all seriousness, what you are discussing are problems that really should NOT be part of this discussion. Just because cars are a target for theft, we should not prevent owners from parking on the street.
What you are discussing are criminal activities, for which other resources are available to address that problem. But a gated solution would inherently add to the problem. First of all, most spam of that type are already addressed by good filters, and domains involved in such activity usually end up on blacklists etc quite quickly, but a gated approach would prevent some of the ability to identify those actors, and report/stop them.
Some of these tests are automated, eg right in software policies, and need to have access to that data on the fly, and that type of automated detection tool cannot work properly, or will be very inhibited with any form of gated access.
And to argue that in the case of unfettered access can be used by both the bad players and the good, do remember that the 'bad actors' have a commercial interest in gaining that data, and will be the first people to automate work arounds.. (eg when SPF came out, surprised how many spammers were early adopters)
Every email operator should be able to have access to that data, eg domain creation date, expiry date, and that data cannot be restricted by bulk (have you seen the volume of senders?) and distributed protection software should not require the end user to 'register' for access to this data to have their protections work.
Gated Access:
* Inhibits the ability to create systems that protect privacy
* Adds a commercial burden (extra systems) to those with legitimate requirements
* Requires an authentication mechanism which can create privacy concerns
* requires an authentication mechanism which may not be usable or desired by all parties
* Raises the bar on who can develop protections and legitimate systems
* Provides protection for the very actors you are worried about.
* Adds unnecessary burdens/costs on ICANN and registrars as well
* Adds a point of failure
* Research and innovation will be inhibited
IMHO, you had better have a STRONG reason to put a gate up..
Let's not mix the problems of certain criminal elements getting access to this data, that is a separate issue, and we can't cut off our nose to spite our face..
I might suggest that rather than promoting 'gated' access, which those elements would be the first to sign up for, is spend the same amount of time working on getting internet providers to prevent that activity from occurring in the first place, and doing anything you can to help those who are trying to stop such activity, including ensuring that they (the good guys) have unfettered access.
On 17-06-07 01:54 AM, Volker Greimann 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>
<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
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net> <mailto:vgreimann at key-systems.net>
Web: www.key-systems.net<http://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> <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> <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems<http://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> <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
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net> <mailto:vgreimann at key-systems.net>
Web: www.key-systems.net<http://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> <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> <http://www.facebook.com/KeySystems>
www.twitter.com/key_systems<http://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> <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> <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
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>
Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
www.twitter.com/key_systems<http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu<http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>
Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
www.twitter.com/key_systems<http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu<http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>
Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
www.twitter.com/key_systems<http://www.twitter.com/key_systems>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu<http://www.keydrive.lu>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>
Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
www.twitter.com/key_systems<http://www.twitter.com/key_systems>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu<http://www.keydrive.lu>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170608/315216af/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list